Modelagem de Sistemas de

Informaes
Da Anlise de Requisitos ao Modelo de Interface
Incluindo:
Modelagem de Negcios
Modelagem Conceitual de Dados
Casos de Uso
Pontos de Funo

Edio 2006/1 Semestre

Geraldo Xexo
dados de diretor

Pedido
Recebido

dados de novela + diretor

operador

operador
novela
cadastrar
diretor

cadastrar
novela
diretor

Digitar
Pedido

Pedido

dados de ator + tipo

operador

Vendas

diretor
captulo + resumo
autor

cadastrar
ator

ator

aviso de alocao

Pedido
Digitado

captulo
dep.
pessoal

ator

receber
captulo

ator

captulo
captulo

diretor
ator horista

Dados de
Produto

diretor

Vendas

Verificar
Pedido

novela
ator horista
horas

Pedido
novela
diretor

enviar
formulrio

form. ator/horas
diretor

ator

registrar
horas
trabalh.

diretor

ator

XOR

ator horista
ator hor + horas

Pedido
Correto

Solicita

(0,N)

Livro

(1,1)

(1,N)

Estado
Inicial
Receber pedido

Entrega

(1,N)

Cliente

Pedido
Incorreto

Atividades

Processar pedido

Distribuidora
Enviar pedido

Transaes

Estado
Final

Incio

Evento a
Sada 1
Evento c
Sada 2

Evento b
Estado 1

Estado2

Evento d

Fim

Modelagem de Sistemas de Informao: Da Anlise de Requisitos ao Modelo de Interface

Geraldo Xexo.

Copyright 2006 Geraldo Xexo.

Este documento est licenciado sob a Creative Commons Atribuio-Uso NoComercial-No a obras derivadas 2.0 Brasil.
Para ver uma cpia dessa licena visite

http://creativecommons.org/licenses/by-nc-nd/2.0/br/

ou envie uma carta a Creative Commons, 543 Howard Street, 5th Floor, San
Francisco, California, 94105, USA.

Todo o esforo foi feito para fornecer a mais completa e adequada informao.
Contudo, o autor no assume responsabilidade pelos resultados e uso da informao
fornecida.
e-mail de contato: xexeo@ufrj.br

Captulo I. Introduo
Este livro sobre a Modelagem de Sistemas de Informao seguindo uma forma
bastante atualizada da Anlise Essencial, unificada com outros mtodos importantes no dia a
dia do desenvolvedor de software, como o Modelo de Entidades e Relacionamentos.
Ele fruto da experincia de 10 anos ensinando Anlise de Sistemas para graduao,
primeiro na Universidade Estcio de S e depois na Universidade Federal do Rio de Janeiro,
j como professor Adjunto. O texto foi criado, alterado, cortado e aumentado de forma a
atender as necessidades do curso, do mercado e dos alunos. Muito do contedo aqui
apresentado resultado direto de dvidas e dos erros mais comuns que os alunos apresentam
durante o curso. A matria apresentada tambm resultado de 15 anos de atuao como
consultor, envolvido direta ou indiretamente na anlise e implementao de sistemas em
diferentes projetos, sobre temas variados como administrao pblica, gerncia de satlites,
controle de caminhes, etc.
O livro foi construdo com dois propsitos. O primeiro apoiar um primeiro curso de
modelagem de sistemas de informao, fundamentado na anlise essencial, no nvel de
graduao ou extenso, visando formar um analista de sistemas. O segundo fornecer uma
base de sustentao para o analista no seu dia a dia no trabalho. No apresentamos um
mtodo nico de anlise ou especificao de sistemas, mas sim um conjunto de ferramentas
que podem ser usadas tanto em conjunto como em separado, porm baseadas em uma
filosofia comum. Este livro no trata de modelagem orientada a objeto, que normalmente
assunto de um segundo curso de modelagem de sistemas.
Algumas premissas foram importantes na construo do texto. No um texto com
foco terico, mas sim aplicado. Durante os 10 anos em que o curso j foi dado, todas as
provas foram prticas, apresentando problemas para serem analisados e modelados, e com
consulta.
Neste livro, seguindo a anlise essencial, estamos interessados em sistemas de
informao que produzem respostas planejadas, isto , que executam aes prprogramadas em funo de mudanas reconhecveis e previsveis no ambiente externo.
Chamamos essas mudanas no estado do ambiente de eventos essenciais. No estamos
interessados em respostas ad-hoc, isto , respostas que tem que ser praticamente inventadas
caso a caso, mas sim em eventos que podem ser previstos e para os quais podemos programar
respostas em um computador digital.
importante deixar claro que a anlise essencial, unificada com o modelo de
entidades e relacionamento, uma ferramenta de grande qualidade para o desenvolvimento
de sistemas de informao.
Quando um cliente solicita um sistema de informao, pensa em automao de algum
processo, na modernizao de um processo j automatizado ou na criao de um novo
processo em sua empresa. O cliente ento imagina um sistema que executa algumas funes,
gerencia alguns dados e fornece alguns relatrios. Esse sistema imaginado pelo cliente,
porm, raramente descreve de forma clara o que ele realmente precisa, ou que precisar no
dia que o sistema ficar pronto. Cabe ao analista ajudar ao cliente a descobrir como o sistema
realmente necessrio.
O segundo captulo faz uma pequena introduo aos Sistemas de Informao,
principalmente aqueles que encontramos dentro de organizaes. O terceiro captulo discute o
desenvolvimento de software. Ambos os captulos so introdutrios e tm como finalidade
4

nivelar conhecimento, sendo que o ideal que o aluno envolvido nesse estudo tenha feito
antes desse curso cadeiras equivalentes a Sistemas de Informao e Introduo a Engenharia
de Software.
O quarto captulo discute o levantamento de requisitos do sistema. Apresenta ao leitor
dois conceitos importantes: o stakeholder, palavra que significa aquele que tem algum
interesse (aposta), e que traduzimos de forma liberal para interessado, e uma classificao de
tipos de requisitos de um sistema, onde se sobressaem os requisitos funcionais e no
funcionais. O captulo tambm apresenta uma leve introduo a mtodos de elicitao de
requisitos, discutindo os mtodos tradicionais e mais comuns, a entrevista e o JAD,
detalhadamente.
O quinto captulo apresenta a proposta inicial. O objetivo permitir ao desenvolvedor
compreender de forma geral o que ser feito no projeto de desenvolvimento, dando margem
para a criao de uma proposta comercial. Nesse captulo ainda tratamos o desenvolvimento
de sistemas como uma atividade informal, a nvel de negcios.
O sexto captulo trata da modelagem de negcios, partindo de modelos de alto grau de
abstrao, como o IDEF0, para modelos detalhados do comportamento da organizao, como
EPC e regras de negcio. Esses mtodos podem substituir na sua totalidade o uso de DFDs
para modelar a encarnao de um sistema, sendo na prtica mais adequados para o
mapeamento do funcionamento real de uma organizao.
O stimo captulo trata da modelagem conceitual de dados, baseado no modelo de
entidades e relacionamentos, necessidade primordial para uma boa anlise de sistemas. O
oitavo captulo trata da modelagem funcional essencial. Juntos, esses dois modelos definem o
funcionamento esperado do novo sistema.
Esta edio apresenta a primeira verso de um captulo sobre Casos de Uso (o nono).
Casos de Uso so provavelmente a forma mais indicada, hoje em dia, para levantar requisitos
funcionais de uma aplicao. Porm, o conhecimento da Anlise Essencial ainda me parece
importante para poder trabalhar com Casos de Uso, que so mais informais. Por outro lado, j
h alguns anos no vejo projetos usando DFDs, e resolvi definitivamente relega-los a um
apndice.
Esses modelos so completados com um modelo da interface do sistema,
preferivelmente na forma de um prottipo, que discutido no capitulo dez.
Finalmente o captulo onze trata de formas de prever o esforo necessrio para
desenvolver um sistema de software, usando como fator de determinao os documentos
previamente gerados.
Alm disso, apresentamos ao final alguns projetos para os alunos usarem nos
exerccios.
Recomenda-se que os captulos sejam apresentados na ordem em que esto no livro.
Os captulos de anlise funcional e modelagem de dados j foram dados em diferentes
ordens, tanto um quanto o outro na frente, porm a anlise de dados independente da anlise
funcional e o inverso no verdade, o que recomenda que seja a ordem adotada. Alm disso,
a modelagem de dados pode ser vista como uma forma de detalhar, a nvel do sistema, as
regras de negcio, o que apresenta uma continuidade ao curso. O livro suporta bem um
perodo de 15 semanas, com 4 horas por semana, incluindo aulas tericas e exerccios, duas
provas e um trabalho por equipe que tem em mdia 15 eventos e 10 entidades, e que deve
modelar de forma completa um sistema, de acordo com todo material apresentado.

Captulo II. Sistemas de Informao

"A complex system that works is invariably found
to have evolved from a simple system that worked."
John Gall
Sistemas de Informao
Dados, Informao, Conhecimento
SI e a Organizao
ERP

Sistemas de Informao so utilizados em organizaes para planejamento,

monitorao, comunicao e controle das suas atividades, por meio da manipulao e guarda
de informaes. Segundo o Dicionrio Aurlio, a palavra sistema significa, entre outras
coisas, um Conjunto particular de instrumentos e convenes adotados com o fim de dar
uma informao. Os instrumentos so as ferramentas, os mecanismos, concretos ou
abstratos, que utilizamos para fazer funcionar os sistemas, tais como: programas de
computador, relatrios, formulrios, etc. As convenes so as suas regras de utilizao.
Apesar de sistemas de informao no necessitarem de computadores para existir, hoje em
dia comum associar o termo imediatamente a uma implementao usando software,
hardware e redes.
Um exemplo tpico de sistema de informao um sistema de aluguel para uma
vdeo-locadora. Entre suas vrias finalidades, a principal certamente controlar o aluguel das
fitas, informando quem est com qual fita em um determinado momento (quando), e quanto
deve pagar por isso. Alm disso, o sistema permite outras atividades, como a gerncia do
estoque de fitas, a monitorao das fitas mais e menos alugadas, etc.
Um Sistema de Informao um conjunto de componentes interrelacionados que coleta dados no ambiente em que opera, usando
recursos de sensoriamento e telecomunicaes (entrada), analisa
esses dados (processamento) e finalmente apresenta o produto como
informao til (sada), sendo construdo de forma a atender os
interesses de uma organizao, de seus clientes internos e externos e
de todos aqueles atingidos direta ou indiretamente pelo novo
produto1.

Ao longo deste livro usaremos a palavra organizao para representar empresas,

rgos pblicos, entidades beneficentes, associaes e qualquer outra forma de instituio
com objetivos definidos e que pode obter algum benefcio com o uso de sistemas de
informao. Nisso inclumos um enorme espectro de interesses e tamanhos, tanto um
consultrio dentrio quanto uma multinacional de bebidas.
Apesar de estarmos preocupados com o desenvolvimento de sistemas de informao
automatizados, implementados na forma de programas de computador, isso no uma
necessidade. Durante sculos as organizaes usaram sistemas de informao apenas com o
uso de pessoas, papel e tinta. Apenas bem mais tarde, aparecem mquinas como mquinas de
escrever e de somar. No seria exagerado dizer que a escrita e os nmeros foram criados para
suportar os primeiros sistemas de informao, que tratavam, por exemplo, de colheitas e
1

Xexo, J.A. Tese de Doutorado XXX

comrcio Muitas das tcnicas deste livro podem, e devem, ser aplicadas para entender
sistemas de informao manuais.
Este captulo apresenta uma breve descrio de como funciona, para que servem e
quem usa os sistemas de informao dentro de uma organizao.

II.1 Dados, Informao, Conhecimento

Antes de entender o que um Sistema de Informao, preciso entender melhor o
que significa a palavra Informao.
Novamente, vamos recorrer a dicionrios para ter uma definio inicial. Segundo o
American Heritage, informao o dado quando processado, guardado ou transmitido. J no
dicionrio Aurlio, informao, entre outros significados, pode ser Conhecimento amplo e
bem fundamentado, resultante da anlise e combinao de vrios informes, Coleo de
fatos ou de outros dados fornecidos mquina, a fim de se objetivar um processamento ou
ainda Segundo a teoria da informao, medida da reduo da incerteza, sobre um
determinado estado de coisas, por intermdio de uma mensagem. Apesar de no estarmos
diretamente envolvidos com a teoria da informao, no podemos de deixar de notar a
importncia da definio que diz que a informao reduz a incerteza por meio de uma
mensagem.
Estamos interessados em criar uma diferenciao entre dados, informao e
conhecimento, mesmo que as palavras possam ser consideradas sinnimas em muitos
contextos. Apesar de serem normalmente confundidas ou utilizadas de forma intercambivel,
elas podem ser mais bem entendidas e utilizadas se analisadas como representando conceitos
diferentes.
Dados so apenas os smbolos que usamos para representar a informao, o registro
de diferentes aspectos de um fato ou fenmeno. Os nmeros que guardamos em um banco de
dados so, como diz o nome, dados. Dados no so interpretados, eles existem, so
adquiridos de alguma forma, via coleta, pesquisa ou criao, guardados de outra forma e,
possivelmente, apresentados em uma terceira. O computador uma mquina que manipula
dados.
Por outro lado, informao o dado com significado, normalmente processado de
forma a ser til. Uma informao deve permitir responder perguntas como quando,
quanto, quem, qual e onde2 sobre alguma coisa.
Informao = Dado + Significado

necessrio fazer um mapeamento entre dados e informao. Esse mapeamento pode

ser simples ou complexo, dependendo de vrias variveis envolvidas, que vo desde decises
arbitrrias tomadas pelo desenvolvedor at padres internacionais. Por exemplo, em muitos
sistemas preciso ter a informao do sexo de uma pessoa (masculino ou feminino). Para
isso, guardados um nmero (1 ou 0) ou uma letra (M ou F) que o dado que faz a indicao
da informao.
Conhecimento a aplicao da informao. Podemos dizer que permite responder a
pergunta como, pois envolve argumentos, explicaes e justificativas. Entre as trs palavras
que estamos analisando, conhecimento a que tem significado mais geral na lngua
2

What, where, when, who, How much

portuguesa, podendo ser usada no dia a dia como sinnimo de informao. Em informtica,
porm, normalmente chamamos de conhecimento algo que pode ser escrito na forma de
regras (como em se for maior de 18 anos, ento pode tirar carteira de motorista).
Alm disso, ainda podemos analisar as palavras compreenso (ou entendimento) e
sabedoria. A compreenso permite responder a pergunta por que, enquanto a sabedoria
um processo complexo e pessoal de compreenso e avaliao do entendimento, que no pode
ser compartilhado [B1].
Bellinger et. al. .[B2] afirmam que com o aumento da compreenso e da capacidade
de fazer conexes entre partes (dados, informaes, etc.), passamos do trabalho direto com o
dado em si para informao, ento para o conhecimento e finalmente para a sabedoria.

Figura 1. Entendimento das relaes entre dados, informao,

conhecimento e sabedoria, segundo Bellinger et al.[B2]

II.2 Caractersticas dos Sistemas de Informao

importante entender que sistemas de informao so sistemas interativos e
reativos.
Interativo significa que o sistema troca informaes com o ambiente, em especial com
os agentes externos que fazem parte desse ambiente, pessoas e outros sistemas de
computador. O sistema s faz sentido se capaz dessa interao.
Reativo significa que o sistema funciona reagindo a mudanas no ambiente, e em
especial, a mudanas provocadas pelos agentes externos.
Nossos sistemas tambm so sistemas de respostas planejadas. Isso significa que
nossas respostas so determinadas e determinsticas, que podemos criar um programa que as
produza. Tambm significa que todas as perguntas que podem ser feitas ao sistema podem, e
so, identificadas previamente.
Escolhendo essas regras de modelagem, escolhemos um caminho para decidir quando
o sistema vai funcionar: em vez de deixar isso incerto, como em muitos mtodos, ns
determinamos que o sistema s funciona para responder um evento no ambiente, causado por
um agente externo, e que possua uma resposta planejada.

10

A metodologia de desenvolvimento apresentada neste livro feita sob medida para

sistemas interativos e reativos, de respostas planejadas. Nesse caso, somos ao mesmo tempo
restritivos, pois se o sistema no pode ser modelado dessa forma no serve para nossa
metodologia, como ampliativos, pois a grande maioria dos sistemas pode ser modelada de
forma natural com esses princpios.

II.3 Sistemas de Informao e a Organizao

Sistemas de informao atualmente servem em todas as reas e nveis das
organizaes, sendo considerados como ferramenta essencial para o sucesso de suas
atividades. Isso nos permite classific-los de acordo com a responsabilidade assumida por
seus usurios dentro da organizao em quatro tipos principais, como sugerido por Laudon
[B3]:
Sistemas de nvel operacional, que tratam da execuo, acompanhamento e registro da
operao diria da empresa, sendo geralmente sistemas fortemente transacionais. Exemplos
so sistemas de vendas, folha de pagamento, etc.
Sistemas de nvel de conhecimento, que suportam as pessoas que trabalham com dados
e conhecimento dentro da organizao. Exemplos simples de sistemas desse tipo so os
processadores de texto e as planilhas eletrnicas.
Sistemas de nvel gerencial, que utilizam dados da operao e outros dados inseridos
nesses sistemas para permitir a obteno de informaes que permitam a gerncia da
empresa, suportando a tomada de decises, o controle e o monitoramento.
Sistemas de nvel estratgico, que so sistemas destinados a decises de mais alto nvel
(efeito estratgico) e utilizam dados de todos os sistemas anteriores, normalmente de forma
agregada e processada, sendo utilizados pela alta gerncia.

Estratgico

Gerencial

Conhecimento

Operacional
Figura 2. Nveis dos sistemas de informao dentro de uma organizao

Ainda segundo Laudon, a cada nvel de sistemas de informao podemos associar um

ou mais tipos de sistemas.
Sistemas de Suporte Executivo (SSE), encontrados no nvel estratgico, so destinados
a apoiar a alta gerncia em tarefas estratgicas, como o planejamento de longo prazo. Usam
dados fortemente agregados, internos e externos a organizao e so capazes de responder
perguntas especficas ou ainda fazer projees. Podem ser capazes de fazer simulaes e ter
uma interface interativa.
11

 Sistemas de Apoio a Deciso (SAD), encontrados no nvel gerencial, so utilizados pelos

vrios nveis de gerncia e utilizam como entrada dados em pequeno volume (agregaes) ou
ainda bases massivas de dados previamente preparadas para permir atividades de anlise de
dados. Como resposta, devem fornecer relatrios especficos, anlises e decises e respostas a
perguntas ad-hoc.
Sistemas de Informao Gerencial (SIG), tambm encontrados no nvel gerencial, so
utilizados pelos vrios nveis de gerncia. Utilizam grande volume de dados ou sumrios de
transaes e modelos simples para obter relatrios sumrios (agregados) e de excees.
Sistemas de Trabalho com Conhecimento (STC), encontrados no nvel de
conhecimento, utilizam projetos, especificaes e bases de conhecimento em geral para
produzir modelos e grficos. Normalmente so utilizados por profissionais com nvel
superior.
Sistemas de Escritrio (SE), encontrados no nvel de conhecimento, tem como objetivo
aumentar a produtividade na manipulao de dados em um escritrio. Permitem a
manipulao de documentos, correio eletrnico e agendas.
Sistemas Processamento de Transaes (SPT), encontrados no nvel operacional,
tratam eventos e transaes e fornecem relatrios detalhados, listas e sumrios, utilizados
pelos gerentes, alm de documentos especficos para a transao em que so utilizados.
Os SPT suportam no s a operao diria da empresa, mas tambm criam os dados
que so mais tarde utilizados pelos outros tipos de sistemas.
II.3.1 Sistemas de Informaes Tpicos
Atualmente j consideremos que vrios sistemas de informaes tpicos de uma
empresa so necessidades bsicas que podem ser atendidas de uma s vez. Esses sistemas
constroem o que comumente chamado de ERPs de Enterprise Resource Planning ou
Sistemas de Gesto Empresarial em portugus mas que na prtica no so sistemas de
planejamento (ou de recursos), mas sim de controle e administrao de uma empresa.
Entre as caractersticas encontradas em ERPs podemos citar a integrao das
atividades da empresa e o uso de um banco de dados nico. O lder mundial do mercado a
SAP AG, com o produto SAP R/3. O custo de implantao de um ERP de grande porte pode
chegar at 300 milhes de dlares. No Brasil, existem produtos menos ambiciosos e mais
baratos.
Os sistemas de ERP atuais contm mdulos representando os mais tpicos sistemas de
informaes necessrios em uma empresa, tais como: Contabilidade Fiscal, Contabilidade
Gerencial, Oramento e Execuo Oramentria, Ativo Fixo, Caixa e bancos, Fluxo de
Caixa, Aplicaes e Emprstimos, Contas a Receber, Contas a Pagar, Controle de Viagens,
Controle de Inadimplncia, Administrao dos preos de venda, Compras, Controle de fretes,
Controle de contratos, Controle de investimentos, Cotaes de vendas, Estoque, Exportao,
Faturamento, Gerenciamento de armazns, Importao, Obrigaes fiscais, Pedidos,
Previso de vendas, Recebimento, Gesto de informao de RH, Pagadoria, Treinamento, RH
scorecard, Planejamento de RH, Planejamento de produo, Planejamento da capacidade,
Custos industriais, Controle de cho de fbrica, Controle da produo, Configurador de
produtos, Planejamento de Manuteno, Acompanhamento de Manuteno e ainda muitos
outros...

12

II.4 Tipos de Projetos de Sistemas de Informao

Existem trs tipos de projeto de sistemas de informao: manual, manual para
automtico e re-automao [B4]. Os processos de re-automao ainda podem se dividir em
recodificao, re-projeto e re-desenvolvimento, melhoria ou manuteno.
Todos esses tipos de projeto apresentam ao analista de sistemas o mesmo desafio:
descobrir o que deve ser feito. Porm, cada tipo apresenta certas particularidades que
facilitam ou dificultam esse trabalho de anlise.
O trabalho do analista em sistemas manuais mais relacionado formalizao, por
meio de documentao e padres, de processos j adotados, a criao de novos processos e a
transformao de processos existentes tendo em vista otimiz-los ou possibilitar que atendam
novas necessidades da organizao. Esses processos podem ser bastante complexos e
convolutos em alguns casos, o que exige do analista uma boa capacidade de compreenso e
modelagem. Porm, como no sero transformados em programas de computador, o analista
pode trabalhar com ferramentais mais informais e mais prximas ao dia a dia do usurio.
Os projetos que apresentam maior dificuldade so os de passagem do processo
manual para o automtico. Isso acontece porque normalmente esses projetos exigem todo o
trabalho feito no tipo anterior, e, de forma adicional, a criao de um modelo computacional e
com certo grau de formalidade, que possa ser usado pelos desenvolvedores. No h, a
princpio, uma guia que indique a adequao da automao ou que novos resultados podem
ser obtidos. O usurio, por no ter acesso a sistemas de informao que executem a mesma
atividade, tem pouco conhecimento sobre o que possvel fazer, ou no tem idia de qual o
custo de produzir certos resultados.
J os projetos de re-desenvolvimento apresentam a vantagem de possuir uma base que
pode ser utilizado como referncia do que deve ser feito (repetido), do que no deve ser
mantido (eliminaes) e das novas atividades necessrias. O usurio, acostumado e
experiente com um sistema existente, pode fornecer informaes mais adequadas sobre o que
espera do novo sistema, ou da manuteno ou melhoria sendo feita.
II.4.1 Porque so feitos projetos de SI
Muitos so os motivos que influenciam o incio de um projeto de desenvolvimento de
um Sistemas de Informao. Em geral, usando um raciocnio econmico, podemos dizer que
um projeto iniciado quando o benefcio do retorno esperado supera o custo do projeto. O
problema que no fcil converter esses valores em nmeros normalmente.
Custo Total de Propriedade
Quanto se analisa o custo de um sistema normal falar de Custo Total de
Propriedade, conhecido pela sigla em ingls TCO (Total Cost of Ownership). O TCO de um
produto o custo total que ele implica para uma organizao. Por exemplo, se decidirmos
trocar todo o parque computacional de uma empresa que usa Windows para Linux, mesmo
que o custo do Linux seja zero, o TCO bem alto, pois envolve o processo de troca, novos
profissionais, treinamento, etc... Outro exemplo comum o da compra de uma impressora.
Seu TCO no envolve apenas o custo da impressora, mas tambm o custo do material
consumvel, quando uma certa produo prevista. Por isso que grandes empresas comprar
menos impressoras, porm impressoras maiores e mais cara, para baixar o TCO.
Para o software desenvolvido vale o mesmo conceito. Qual seu TCO? Envolve o
preo pago pelo software mais tudo que vai ser pago para possibilitar a implantao e
utilizao do produto (instalao, cursos de treinamento, manuteno mensal, etc...)

13

Benefcios do Sistema
Vrios motivos podem ser analisados como benefcios esperados de um projeto. Um
deles modernizao de um sistema. Com o tempo a tecnologia de um sistema vai se
tornando superada. Isso faz com que o risco e o custo de manter o sistema funcionando
naquela tecnologia aumentem, aumentando gradativamente o interesse de se transportar o
sistema para uma nova plataforma. Simultaneamente, novas tecnologias apresentam novas
oportunidades, como desempenho superior ou facilidade de aprendizado, aumentando
tambm com o tempo o interesse nessa atualizao. Chega um momento ento que passa a
valer a pena o investimento em modernizao.
Outro motivo importante a mudana de premissas bsicas do negcio, causada pela
atuao da firma no mercado. Essas mudanas tanto podem de dentro da empresa quanto
podem ser provocadas por mudanas na legislao ou por ao dos concorrentes. Por
exemplo, h alguns anos atrs, no Brasil, foram feitas vrias modificaes nos sistemas
financeiros das empresas para aceitar a mudana de moedas e o convvio com moedas
diferentes simultaneamente. Em outro exemplo, com a inveno e grande aceitao dos
sistemas de premiao por viagens ou por milhas, as companhias areas tiveram que
desenvolver sistemas especficos, interagindo com seus sistemas de passagens, para tratar do
assunto. Muito comum tambm a mudana de uma atividade da empresa, seja por um
processo contnuo, como o de qualidade total, quanto por processos radicais como os de
reengenharia e downsizing.
Os sistemas de informao tambm so importantes por oferecerem as empresas uma
capacidade maior de competio. Com a informao correta e com os processos corretos de
tratamento da informao uma empresa pode ter um diferencial de qualidade no mercado. Por
outro lado, se todo um mercado j adotou um tipo de sistema, ou se pelo menos um
concorrente j o fez, a empresa que no tem um sistema equivalente fica prejudicada na
competio. Esse tipo de efeito foi visto quando as companhias areas passaram a vender
passagens via Internet. No incio era mais uma propaganda, depois passou a ser um
diferencial positivo. Atualmente todas as companhias areas possuem formas de vender
passagens diretamente via Internet.
Hoje em dia um grande motivador de novos projetos e a busca por melhor tratamento
da informao que j existe em sistemas de tipo operacional, como a criao de Sistemas
Suporte Executivo.

II.5 Exerccios
1)

Escolha um tipo de negcio de pequeno porte, como uma agncia de viagens, e descubra
(ou imagine) quais os principais sistemas de informao que ela necessita ou pode usar.

2)

Classifique os sistemas anteriores quanto ao seu nvel na organizao.

3)

Classifique os sistemas anteriores quanto ao seu tipo.

4)

Imagine que esse negcio se torna um grande negcio, por exemplo, uma grande cadeia
de agncias de viagens, e descubra (ou imagine) que novos sistemas podem ser
necessrios.

5)

Que sistemas de informao fazem parte de seu dia a dia? Que papel voc assume ao
utilizar esses sistemas?

6)

Que sistemas de informao voc pode se lembrar que contm informaes importantes
sobre sua vida pessoal ou profissional?

14

7)

Imagine uma empresa de plano de sade que possui um sistema de nvel operacional que
registra e permite a aprovao pela pessoa responsvel de exames e consultas. Que
sistemas de informao de outros nveis podem ser feitos para utilizar essa informao?
Que outros sistemas de informao podem fornecer informao para o sistema de
aprovao?

8)

Defina, para um sistema de informao escolhido por voc, as informaes necessrias,

que dados s descrevem e que conhecimento pode ser obtido a partir delas.

9)

Muitas lojas no Rio de Janeiro ainda utilizam sistemas de informao feitos em MS-DOS.
Faa uma anlise dos custos e benefcios para mudar um sistema desse tipo para
Windows ou de mant-lo como est. Qual a melhor opo atualmente? Qual a melhor
opo nos prximos 2, 5 e 10 anos?

10)

Que tipos de sistemas podem interessar a Livraria ABC?

11)

Que tipos de sistemas podem interessar a Empresa de Clipping ClipTudo?

12)

Uma empresa precisa comprar uma impressora nova. Existem duas opes interessantes
no mercado, como descritas na tabela abaixo. Qual impressora comprar se a empresa
prev fazer 30.000 impresses com a impressora. E se forem 100.000? E se forem
146.668? E se forem 500.000?

Caracterstica

Impressora A

Impressora B

Preo da impressora (sem

tinta)

R$ 300,00

R$ 5.000,00

Preo do cartucho de tinta

R$ 80,00

R$ 250,00

1.000

5.000

120.000

800.000

Nmero
cartucho

de

cpias

Vida til da impressora

por

15

17

Captulo III. O Desenvolvimento de Software

Anlise: ... 3. Exame de cada parte de um todo,
tendo em vista conhecer sua natureza,
suas propores, suas funes, suas relaes, etc.
Novo Dic. Aurlio
Anlise de Sistemas
Analista de Sistemas
Ferramentas
Ciclo de Vida
Equipe de Desenvolvimento

Desenvolver software a atividade, de longo prazo, de criar um ou mais programas de

computador, um sistema, de forma a atender necessidades especficas de um cliente ou grupo
de clientes.
No desenvolvimento de software realizamos as atividades de descoberta das
necessidades e de criao do produto de software propriamente dito. Podemos dividir as
atividades do processo de desenvolvimento em alguns grandes grupos:

Atividades de Anlise, cuja finalidade descobrir o que deve ser feito.

Atividades de Projeto, cuja finalidade descobrir como o software deve ser feito.

Atividades de Implementao, cuja finalidade produzir o produto de software de acordo

com as especificaes produzidas nas fases anteriores.

Atividades de Controle de Qualidade, onde se incluem todas as atividades com objetivo

de garantir a qualidade do produto, como testes e verificaes.

De acordo com o processo de desenvolvimento escolhido, cada uma dessas atividades

pode ser dividida em vrias outras sub-atividades ou tarefas. Elas podem ser executadas de
diferentes formas, em diferentes ordens. Tambm possvel que as atividades de anlise e
projeto sejam feitas de forma implcita, por exemplo, quando desenvolvemos o software
unicamente por meio de prottipos.
Dependendo do grau de formalidade do processo de desenvolvimento, que deve ser
escolhido em funo de um grupo de variveis, como a complexidade do projeto, prazo e
caractersticas da equipe. Enquanto um produto para um nico usurio pode ser feito por
meio de prottipos, sem nenhuma fase bem-definida, produtos muito grandes, como um
sistema de informaes para toda um empresa, necessitam ser realizados em passos muito
bem planejados.
Esse livro trata de algumas metodologias usadas no processo desenvolvimento de
software. Dependendo da fonte que utilizamos, esse processo pode envolver uma mirade de
atividades. Na norma ISSO 12207 so citadas, por exemplo: anlise de requisitos, projeto,
codificao, integrao, testes, instalao e aceitao. Outras referncias podem apresentar
divises distintas dessas atividades, ou incluir atividades novas (como testes de integrao e
testes de unidades). Nesse livro estamos principalmente interessados em conhecer
ferramentas para realizar a anlise de um sistema de informao.

18

III.1 Anlise
Por anlise entendemos a tarefa de levantar e descrever os requisitos de um sistema,
definindo de que forma deve funcionar para atender as expectativas de todos que nele
possuem algum interesse. Normalmente se diz que a anlise define o que o sistema deve
fazer sem especificar como far. Durante a anlise devem ser explicitadas que tarefas o
sistema deve executar e que dados deve manter em memria. Para isso, criamos um ou mais
modelos do sistema, descrevendo-o com diferentes perspectivas e graus de detalhe.
a partir da anlise de desenvolvemos um sistema. Ela , simultaneamente, um
acordo entre os desenvolvedores e seus clientes e um mecanismo de comunicao entre os
desenvolvedores. Em ambos os casos, a anlise define que servios devem ser fornecidos
pelo sistema a ser implementado e, por conseqncia, que servios no esto no escopo do
sistema.
Segundo Pressman [B5], todos os mtodos de anlise devem ser capazes de suportar
cinco atividades:

Representar e entender o domnio da informao;

Definir as funes que o software deve executar;

Representar o comportamento do software em funo dos eventos externos;

Separar os modelos de informao, funo e comportamento de maneira a

apresentar os detalhes de forma hierrquica, e,

Prover a informao essencial em direo determinao dos detalhes de

implementao.

Dessa definio, possvel deduzir que para a anlise de um sistema ser til e de
qualidade, no basta entender o que deve ser feito, mas tambm desenvolver uma
representao que permita documentar e comunicar essa informao.
III.1.1

Modelos de Anlise
Vrios autores fizeram propostas de modelos para descrever a anlise de sistemas.
Dentro do conceito de anlise, apresentaremos os seguintes modelos:

Modelo de Negcio, que descrevem como funciona o negcio onde o sistema est
inserido.

Modelo de Dados, que descreve os dados guardados pela memria do sistema, na forma
de um Modelo Conceitual e segundo o mtodo de entidades e relacionamentos.

Modelo Funcional, que descreve a funcionalidade essencial do sistema, utilizando

diagramas de fluxo de dados.

Incorporamos tambm, em nossa fase de anlise, a modelagem por pontos de funo,

que nos permitir definir um tamanho para nosso sistema.
III.1.2

Ferramentas da Anlise
A maior parte do trabalho de anlise feita da comunicao entre pessoas. Muito
dessa comunicao feita na linguagem natal dessas pessoas, como o portugus. Um grande
problema dessa comunicao que lnguas como o Portugus e o Ingls permitem a
construo de sentenas ambguas.

No desenvolvimento de sistemas temos que evitar ao mximo as ambigidades. Para

isso, temos que restringir a linguagem utilizada de forma que uma sentena s tenha uma
19

interpretao possvel (ou mais provvel). Para isso foram criadas vrias linguagens, algumas
grficas, que tem o poder de restringir as interpretaes possveis do que queremos dizer.
Veremos no decorrer desse livro uma viso geral de algumas dessas linguagens.
III.1.3

A Tecnologia
A grande maioria dos autores advoga que no devemos levar em conta a tecnologia
que a ser empregada no desenvolvimento durante a anlise de sistemas. A anlise deve se
preocupar com o o que fazer e nunca com o como fazer.

Como estaremos seguindo os princpios da anlise essencial, esta questo ficar

inicialmente ainda mais restrita, pois o modelo essencial no pode conter nenhuma referncia
tecnologia, sob o risco de produzir requisitos falsos.
Isso no quer dizer que o analista no possua as informaes sobre a tecnologia,
apenas que no as usa enquanto faz o trabalho de anlise. Na prtica, estamos sempre
limitados por escolhas como linguagens, sistemas gerenciadores de bancos de dados,
arquiteturas de rede e de computador. O que devemos fazer no deixar que essas limitaes
influenciem nossas decises sobre o que deve fazer o sistema3.
Da mesma forma, no queremos dizer que o analista deve ignorar essas questes ao
trabalhar. Ele deve anot-las, pensar em seus impactos, porm no deve traz-las para o
modelo criado na anlise.
III.1.4

O Analista de Sistemas
O Analista de Sistemas o responsvel por levantar os requisitos do sistema e
transform-los em uma especificao do que deve ser feito, i.e., a Anlise do Sistema. Para
isso, assume vrios papis [B4]: reprter, detetive, consultor, diagnosticador, investigador,
organizador, solucionador de problemas, avaliador, simplificador, artista, escultor, arquiteto,
auditor, especialista de organizao e mtodos, especialista do domnio da aplicao, gerente,
etc. O porqu dessa longa relao de papis o fato de o analista realmente ter que assumilos ao longo do processo. Ele entrevista pessoas em busca de fatos e detalhes, descobre fatos
escondidos (intencionalmente ou no), muitas vezes por meio de inferncias ou pistas
encontradas, prope solues mais adequadas para problemas atuais e futuros, a partir de
diagnsticos, planeja sistemas abstratos a partir de diagramas, e ainda muitas outras
atividades.

III.2 Ciclo de Vida e Processo de Desenvolvimento

A norma ISO 12207 fornece um framework para compreender as atividades e
processos do ciclo de vida do software da sua concepo at o fim do seu uso, que podemos
indicar pela figura a seguir. importante perceber a quantidade de processos envolvidos no
ciclo de vida do software, pois eles nos mostram que muitas vezes subestimamos as
verdadeiras necessidades para implantar e manter um sistema de informao.

Ou seja, essas decises, muitas vezes tomadas antes de se iniciar a anlise de um sistema, devem influenciar apenas a
forma de funcionamento, no a razo desse funcionamento.

20

Processos Fundamentais

Processos de Apoio

Aquisio

Documentao

Fornecimento

Gerncia de Configurao
Garantia de Qualidade

Operao

Verificao

Reviso Conjunta
Manuteno

Auditoria

Adaptao

Validao
Desenvolvimento

Soluo de Problemas

Processos Organizacionais
Infraestrutura

Treinamento

Gerncia

Melhoria

Figura 3. Framework fornecido pela norma ISO 12207, adaptado de

Machado [B6].

III.2.1

A Necessidade de Garantir a Qualidade

Desenvolver software um processo de transformao de uma necessidade do cliente
em uma seqncia de produtos de software (anlise, projeto, prottipo, manuais) que tem em
seu fim um programa de computador. Essas transformaes so imperfeitas, devidos a
problemas de comunicao entre o usurio e o desenvolvedor e falhas nas tcnicas utilizadas
pelo desenvolvedor para garantir que nenhuma informao perdida ou inserida de forma
espria no sistema.

Para garantir que o sistema faz o que o usurio deseja, utilizamos duas tcnicas: a
verificao e a validao. Verificar significa analisar se o produto de uma fase do processo de
desenvolvimento est de acordo com sua especificao. Validar significa analisar se o
produto de uma fase do processo de desenvolvimento est de acordo com as expectativas do
cliente.
Precisamos ter claro em nossa mente a diferena entre as duas atividades. Quando
transformamos um algoritmo em portugus para pascal, por exemplo, podemos fazer isso de
forma perfeita e, ao mesmo tempo, fazer algo que o cliente no deseja. Quando validamos um
programa com o cliente e o aprovamos, no necessariamente o que fizemos foi o que estava
escrito na especificao do programa.
A tarefa mais importante, na verdade, a validao, j que devemos atender o cliente.
A validao, porm, geralmente mais informal e mais custosa que a verificao. Assim,
verificando que cada passo dado durante o processo de desenvolvimento esta conforme o
passo anterior previu podemos economizar na validao.

21

III.2.2

Modelos de Processo mais Comuns

III.2.2.1 Processo

em Cascata
Tambm conhecido como Linear Seqencial. Nesse processo, assumimos que as
atividades de anlise, projeto e implementao podem ser feitas de forma seqencial, sem que
sejam necessrias interaes entre as fases.
Um processo em cascata tpico contaria com as seguintes fases:
1. Modelagem do Sistema, onde so estabelecidos os requisitos do sistema do
qual o software sendo realizado participa, incluindo os requisitos de informao e de
negcios.
2. Anlise de Requisitos, onde so modelados os requisitos de informao,
funcionais, comportamentais, de desempenho e de interface do software..
3. Projeto, onde so planejadas as estruturas de dados, a arquitetura do sistema e
o comportamento mapeado em procedimentos.
4. Codificao, onde o projeto transformado em uma linguagem inteligvel
pelo computador.
5.

Testes, onde verificamos e validamos o software.

6.

Manuteno, onde garantimos a usabilidade do software.

Defendido inicialmente como a forma correta de desenvolver software, basicamente

impossvel de ser realizado. Podemos encontrar alguns exemplos de sucesso em casos onde o
produto sendo desenvolvido e o ambiente de desenvolvimento so muito bem conhecidos.
Devido diviso radical entre as fases, dada grande nfase a documentao.
Inicialmente assumia-se que cada fase seria executada por uma equipe distinta de
especialistas, fato que est se tornando mais raro hoje em dia. Tambm havia discusses
sobre at que ponto deveria ir o projeto e onde comeava codificao. De acordo com a
complexidade do sistema, muitas vezes as fases de codificao e testes eram dividas em
codificao e teste de unidades e integrao e testes de integrao.
Entre seus principais defeitos est o fato que o cliente s v o produto final no ltimo
dia do desenvolvimento. Assim, impossvel detectar falhas ou atender demandas imediatas
do cliente. Alm disso, a participao do usurio muito baixa.

Anlise
Projeto
Codificao
Testes

Figura 4. O Modelo de Processo em Cascata ou Seqencial

Prototipagem
No processo de Prototipagem (pura) o desenvolvedor interage diretamente com o
usurio, escutando seus pedidos e desenvolvendo, imediatamente, um prottipo do produto
desejado. O usurio, ento, utiliza esse prottipo e fornece ao desenvolvedor novas

22

informaes que o levam a modificar o prottipo, de maneira a atender todas as necessidades

do usurio.
claramente um processo de desenvolvimento baseado em um ciclo de realimentao
de informaes, com alta participao do usurio.
No existe uma fase formal de anlise ou projeto. Isso pode causar problemas graves
e difceis de corrigir no produto final, dificultando de sobremaneira a manuteno dos
produtos. Pouca nfase dada documentao.
Atualmente quase todos os processos de desenvolvimento utilizam prottipos, mas
no um ciclo de vida de prototipagem.
Usamos prottipos descartveis quando o prottipo usado apenas para levantar
alguns ou todos os requisitos e depois abandonado, em troca de uma implementao mais
organizada. Um prottipo operacional um software feito rapidamente para atender uma
demanda do usurio e que usado, mais tarde, como modelo de especificao para uma nova
implementao do sistema.
possvel diferenciar prottipos de mock-ups. Um prottipo apresentaria o
comportamento correto, ou aproximadamente correto, e seria caracterizado principalmente
pela falta de rigor na implementao. Um mock-up apresentaria apenas uma interface que
serviria como prvia da interface final.
Contruo ou
Reviso do
Prottipo
Avaliao
do Prottipo

Escutar
o
Cliente

Figura 5. O Processo de Prototipagem

Processos Evolucionrios
Os modelos de processo evolucionrios reconhecem que sistemas complexos se
alteram com o tempo, usando a iterao do ciclo de desenvolvimento para acompanhar a
evoluo do sistema.
III.2.2.1.1

Processo Incremental

Pode ser visto como combinando o linear com a prototipagem. Tem o foco principal
na entrega do produto. Para realiz-lo, repetimos a seqncia linear em vrios calendrios
defasados no tempo. Busca implementar funcionalidades essenciais o mais cedo possvel.

23

Anlise
Projeto

Anlise

Codificao
Testes

Projeto

Anlise

Codificao
Testes

Anlise

Projeto
Codificao

Projeto
Codificao

Testes
Tempo

Testes

Figura 6. O Ciclo de Vida Incremental

III.2.2.2 Processo

Espiral
O Processo Espiral se caracteriza pelo desenvolvimento por uma srie de produtos
desenvolvidos em seqncia, cada vez mais complexos e mais prximos do produto final
desejado. Ele se diferencia do Processo incremental porque os produtos de cada ciclo no so
subsistemas do sistema original, mas sim produtos especficos que atendem necessidades
especficas do projeto, como por exemplo, teste de viabilidade e definio da interface
com o usurio.

Em cada ciclo da espiral, algumas atividades so realizadas em ordem seqencial:

comunicao com o cliente, planejamento, anlise de riscos, engenharia, construo e,
finalmente, avaliao dos resultados.
Do RUP foram derivados vrios outros processos, sendo o RUP o mais conhecido
deles.

Avaliao

Comunicaao com
o Cliente

Planejamento
Construo

Engenharia

Anlise de
Riscos

Figura 7. O Processo em Espiral, viso abstrata

III.2.2.3 Processo

Win-Win
O Processo Todos Ganham - Espiral (Win-Win Spiral) a unificao de dois
trabalhos distintos de Barry Boehm. No primeiro, o Processo espiral, ele prope que um
processo de software seja feito de acordo com um ciclo de especificaes cada vez mais
detalhadas que resultam em verses incrementais das capacidades operacionais desejadas.
Cada ciclo envolve a elaborao dos objetivos, restries e alternativas do produto, a
avaliao das alternativas e riscos, a elaborao da definio do produto e do processo e o

24

planejamento do prximo ciclo. No segundo, a Teoria-W, ele prope que todas as decises
tomadas em um processo gerencial devem gerar uma situao de todos ganham4.
As fases para esse Processo so

Identificar X

Identificar condies de ganho para cada X

Conciliar condies de Ganho

Estabelecer objetivos, restries e alternativas.

Avaliar alternativas de produto e processo, resolver riscos.

Definir produto e processo, incluindo parties.

Validar produto e processo, incluindo parties.

Revisar e alcanar compromisso (commit)

III.2.2.4 Desenvolvimento

Acelerado
Devido a grande presso pela produtividade que as empresas sofrem no processo de
desenvolvimento de software, constantemente so propostas novas tcnicas com a finalidade
de acelerar o processo de desenvolvimento. Entre elas podemos citar a prpria prototipagem,
Rapid Application Development (RAD), Adaptative Programming, Extreme Programming e
toda uma gama de processos geis.

Figura 8. O processo espiral como definido originalmente por Boehm

(1988)

Em contrapartida com o caso normal, onde um ganha e os outros perdem, ou, ainda pior, com os casos onde a
deciso tomada vista como uma situao onde todos perdem.

25

III.3 A Equipe de Desenvolvimento

A equipe de desenvolvimento o conjunto de pessoas responsveis por construir o
software. Dela fazem parte pessoas com diferentes habilidades. Em sistemas de informaes
tradicionais teremos gerentes de desenvolvimento, analistas, projetistas, programadores,
administradores de banco de dados, etc. Em sistemas mais modernos, como sistemas
multimdia e websites, podemos ainda ter profisses novas como artistas e professores.
importante verificar que as pessoas em uma equipe de desenvolvimento se
comunicam de alguma forma. Seguindo a regra de quanto maior o projeto, maior o nmero
de pessoas, muito maior o nmero de formas em que essas pessoas podem se comunicar.
A figura a seguir tenta demonstrar essa idia. Como uma pessoa, no h nenhuma
comunicao. Com duas pessoas, s h uma maneira delas se comunicarem. Com 3 pessoas,
escolhendo apenas a comunicao entre duas pessoas, j existem 3 formas. Com 4 pessoas,
so 6 formas, com 5 pessoas so 10 formas. Basicamente, com N pessoas, existem (N(N1))/2 formas delas se comunicarem duas a duas.
Em projetos enormes, se todos puderem falar com todos para fazer algo, a situao
fica incontrolvel.
Por isso, temos que organizar a equipe de desenvolvimento de alguma forma.

Figura 9. As linhas de comunicao entre as pessoas crescem

rapidamente, segundo uma exploso combinatria.

Em uma equipe com organizao democrtica, todos podem se comunicar com todos.
Esse tipo de equipe razovel para projetos pequenos, com equipes de at 5 ou 6 pessoas,
onde a comunicao incentivar a descoberta. Normalmente essas equipes so encontradas
em universidades e no desenvolvimento de pequenos projetos de alta tecnologia (um web
site, por exemplo).

Figura 10. Em uma equipe democrtica todos falam com todos

A forma mais tradicional de organizar uma equipe a forma hierrquica, baseada nas
teorias clssicas de administrao (que por sua vez, so baseadas na forma de organizao do
Exrcito e da Igreja).
26

Na equipe hierrquica temos um ou mais nveis de gerncia. Cabe a gerncia controlar

o funcionamento do projeto. Os nveis mais baixos so responsveis pela execuo do
projeto.
A equipe hierrquica boa para manter regras e padres, sendo uma escolha boa para
projetos repetidos e que exigem grande estrutura. Muitas empresas utilizam esse tipo de
organizao, porm ele considerado fraco para o desenvolvimento de software novo, pois a
estrutura cobe a criatividade.
Em relao ao uso dos profissionais, podemos indicar um defeito importante: o
profissional de desenvolvimento experiente transformado em gerente e tira a mo da
massa. Muitas vezes, inclusive, ele transformado em um mau gerente...

Figura 11. Em uma equipe hierrquica, diminuem-se as linhas de

comunicao.

Brooks[B7] prope uma equipe conhecida como Equipe do Programador Chefe.

Nesse tipo de equipe o desenvolvedor vai recebendo cada vez mais responsabilidade em
relao ao desenvolvimento, mas no em relao tarefa diria de administrao, que
tratada a parte. Cada programador-chefe responsvel por parte do projeto e delega tarefas
aos programadores seniores, que por sua vez podem delegar tarefas aos programadores
juniores. Alguns desses programadores compem uma equipe de teste.
Programadores

Secretria
Chefe

Administrador

Senior

Bibliotecria
Junior
Figura 12. Equipes do tipo programador chefe se baseiam na capacidade
do programador chefe

Os mtodos mais modernos, como RUP e XP, falam de papis necessrios nno
processo. Papis tpicos do RUP so Analista de Sistema, Arquiteto, Especificador de
Use-Case e Projetista de Interface com o Usurio, Engenheiro de Casos de Uso e
Engenheiro de Componentes. J os papis do XP so: o comprador ou GoldOwner, o
cliente ou GoalDonor, o gerente, o testador, o programador, o monitor ou tracker e o
treinador ou coach. Em ambos os casos, papis diferentes podem ser assumidos pela
mesma pessoa. importante notar que no caso do XP os dois primeiros papis so do cliente.

27

Existem muitas outras formas de organizar equipes. Cada tipo de produto exige um
tipo especial de equipe. Afinal, no desenvolveramos um software para controle de vo de
um avio com o mesmo tipo de equipe para o qual desenvolvemos um software para controle
de uma biblioteca.

III.4 Exerccios
13) Descreva de forma sucinta os seguintes processos descritos na literatura:
1) RUP Rational Unified Process
2) XP eXtreme Programming
3) Adaptative Software Development
14) Descreva como so as equipes de desenvolvimento da empresa em que voc trabalha
e de uma grande empresa (como a Microsoft, por exemplo).
III.4.1

Trabalho em Grupo (Projeto de Cadeira)

A turma deve se dividir em grupos de trs a cinco pessoas, com quatro sendo o
tamanho ideal. Cada grupo deve escolher um projeto de um sistema de informao. Essa
escolha deve se basear nos seguintes princpios e conselhos:

O sistema deve ser simples o bastante para que todos o entendam

Algum participante do grupo deve ter experincia com o sistema ou com um sistema
parecido
A melhor opo escolher um aspecto do funcionamento de um negcio familiar que
algum membro do grupo tenha acesso. Exemplos tpicos: estoque de uma loja, atendimento
de um consultrio, notas de um curso, pagamento de mensalidades de uma academia, etc.
Outra opo um sistema que algum membro do grupo tenha desenvolvido (ou
participado do desenvolvimento).
No ser aceito um sistema de locadora de vdeo, por ser um exemplo muito utilizado
na literatura, permitindo plgio facilmente.
Na prtica, um trabalho de cadeira deve conter de 10 a 20 eventos e mais de cinco
entidades para ter alguma graa. Porm nesse ponto o aluno no sabe ainda o que um
evento ou uma entidade. O professor deve orientar os alunos para que o sistema faa
aproximadamente 15 coisas, incluindo cadastros, relatrios e processamentos.
Os alunos muitas vezes misturam em suas definies mais de um sistema entre os
sistemas de informao tpicos. O professor deve orientar e explicar a diferena. Confuses
comuns incluem sistemas de vendas, estoque, compras e controle de produo.
Os alunos devem preparar uma descrio informal desse projeto. Esse tema ser
utilizado no desenvolvimento de um projeto durante todo o curso.

28

29

Captulo IV. Usurios e Requisitos

A hundred objective measurements didn't sum the worth of a garden;
only the delight of its users did that.
Only the use made it mean something.
Lois McMaster Bujold, A Civil Campain, 1999
Stakeholders
Requisitos Funcionais
Requisitos No Funcionais
Requisitos Verdadeiros
Requisitos Falsos
Elicitao de Requisitos
Entrevistas
JAD

A principal tarefa de um analista descobrir o que o sistema deve fazer e como deve
se comportar segundo as expectativas de seus usurios e outros interessados. Usualmente,
chamamos isso de requisitos do sistema. O problema que, no incio do desenvolvimento,
ningum realmente sabe o que um sistema desejado deve fazer ao ficar pronto, inclusive o
cliente. Descobrir os requisitos de um sistema uma tarefa investigativa, criativa e contnua.

IV.1 O que um Requisito

O objetivo da anlise capturar todos os requisitos para o software sendo
desenvolvido e apenas aqueles requisitos verdadeiros.
Qualquer que seja o sistema, existem vrias formas de entend-lo. Similarmente,
existem vrios tipos de requisitos, que so aplicveis ou no, dependendo da viso necessria
naquele instante.
Segundo a norma IEEE Std 1220-1994, um requisito uma sentena identificando
uma capacidade, uma caracterstica fsica ou um fator de qualidade que limita um produto ou
um processo.

Um requisito do usurio algum comportamento ou caracterstica que o

usurio deseja do software ou o sistema como um todo; o que o usurio quer.
So escritos pelo prprio usurio ou levantados por um analista de sistemas
que consulta o usurio.

Um requisito do sistema algum comportamento ou caracterstica exigido do

sistema como um todo, incluindo hardware e software. O comportamento
desejado do sistema. So normalmente levantados por engenheiros ou
analistas de sistemas, refinando os requisitos dos usurios e os transformando
em termos de engenharia.

Um requisito do software algum comportamento ou caracterstica que

exigido do software. So normalmente levantados por analistas de sistemas.

Exemplos de requisitos so:

O sistema dever imprimir a nota fiscal de venda ao consumidor referente

venda sendo registrada.
30

O sistema dever permitir ao usurio calcular diferentes oramentos para uma

mesma proposta, baseados em formas diferentes de pagamento.

O sistema dever avisar que a rede est fora do ar em 204 segundos aps a
rede sair do ar.

O sistema dever permitir o agendamento de uma consulta, reservando a data

e o horrio da sala e do profissional de acordo com as disponibilidades da
clnica e o desejo do paciente.

IV.1.1 Caractersticas de um Bom Requisito

Um requisito deve ter as seguintes caractersticas [B8]:

Necessrio, significando que, se retirado, haver uma deficincia no sistema,

isto , ele no atender plenamente as expectativas do usurio.
o Em especial, no devem existir requisitos do tipo seria interessante
ter. Ou o requisito necessrio ou dispensvel.
o Deve ser levado em conta que cada requisito aumenta a complexidade
e o custo do projeto, logo, no podem ser introduzidos de forma
espria.

No-ambguo, possuindo uma e apenas uma interpretao. Nesse caso muito

importante prestar ateno na linguagem sendo utilizada.

Verificvel, no sendo vago ou geral e sendo quantificado de uma maneira

que permita a verificao de uma das seguintes formas: inspeo, anlise,
demonstrao ou teste.

Conciso, de forma que cada requisito defina apenas um requisito que deve ser
feito e apenas o que deve ser feito, de maneira clara e simples.
o Um requisito, para ser conciso, no inclui explicaes, motivaes,
definies ou descries do seu uso.
o Estes textos podem ser mantidos em outros documentos, apontados
pelo requisito (de preferncia sob o controle de um sistema de gerncia
de requisitos).

Independente da Implementao, ou seja, o requisito define o que deve ser

feito, mas no como.
o Um requisito no deve refletir um projeto ou uma implementao.
o Um requisito no deve descrever uma operao.

Requisitos de interface so uma exceo a essa regra

Alcanvel, ou seja, realizvel a um custo definido por uma ou mais partes do

sistema

Completo, ou seja, no precisa ser explicado ou aumentado, garantindo

capacidade suficiente do sistema.

Consistente, no contradizendo ou mesmo duplicando outro requisito e

utilizando os termos da mesma forma que outros requisitos,

Ordenvel, por estabilidade ou importncia (ou ambos).

31

Aceito, pelos usurios e desenvolvedores.

IV.2 Stakeholders e Usurios

Usurios so todos aqueles que usam o sistema com algum objetivo. O nome pode
ser entendido de forma restrita, indicando apenas aqueles usurios finais, isto , que
realmente usam o sistema dentro do escopo do seu objetivo, ou de forma ampla indicando
todos aqueles que usam o sistema ou algum de seus produtos, de alguma forma, o que inclui
tambm os desenvolvedores.
Stakeholders so todos aqueles com algum interesse no sistema, afetando ou sendo
afetados por seus resultados. A palavra uma composio dos termos stake, interesse ou
aposta, e holder, possuidor. Fica claro que um stakeholder uma pessoa que possui algum
interesse no sistema, em especial um interesse que envolve algum risco. Alguns autores
brasileiros traduzem o termo como interessados, mas esse termo no tem todo o significado
do termo em ingls, que adotaremos na falta de um melhor em portugus. O grupo de
stakeholders bem maior que o grupo de usurios, pois envolve no s estes, mas tambm
desenvolvedores, financiadores, e outros.
Um tipo de stakeholder que muitas vezes esquecido formado por aquelas pessoas
que so afetadas indiretamente pelo funcionamento do sistema, mesmo sem saber que ele
existe ou est funcionando. Dizemos que essas pessoas esto na sombra do sistema.
Como exemplo, podemos citar o caso de um sistema hospitalar destinado a indicar
que paciente deve tomar que remdio a que horas. Nesse sistema, enfermeiras e mdicos
seriam usurios. Claramente, os pacientes, mesmo no sendo usurios, so stakeholders, pois
seu interesse no bom funcionamento do sistema direto. Uma falha pode causar at mesmo a
morte de um ou mais pacientes. A famlia e os acompanhantes do paciente, porm, esto na
sombra do sistema, sendo afetados apenas indiretamente.
Abordagens simplificadas permitem identificar imediatamente trs tipos de
stakeholders: desenvolvedores, compradores e usurios. Uma investigao mais profunda
pode achar muitos outros interessados, como: gerentes dos usurios finais, auditores,
responsveis pela operao, responsveis pela manuteno, usurios de sistemas que enviam
ou recebem dados para o sistema especfico, etc. interessante que seja feito um esforo para
levantar todos os stakeholders de um sistema e mapear, de alguma forma, seus interesses e
interaes com o mesmo.
IV.2.1 Interesses e Objetivos
Usurios possuem um ou mais objetivos ao usar um sistema, i.e., ele usa o sistema
para obter uma resposta planejada. Usurios e stakeholders tem interesses no sistema, isto ,
eles esperam que o sistema afete o negcio de alguma forma.
Uma prtica possvel definir uma tabela indicando que objetivos cada usurio e que
interesse cada stakeholder tem no sistema. Isso pode ser feito de forma preliminar nessa fase.

32

Objetivos e Interesses de Stakeholders

Agente ou
Interessado

Objetivo

Interesse

Prioridade

Cliente

Fazer pedido

Receber o
produto pedido

Cliente

Obter status do
pedido

Prever o prazo de
chegada do
pedido

Gerente

Obter lista de
pedidos diria

Saber a produo
diria

Tabela 1. Lista de objetivos e interesses

IV.3 Perspectivas dos Usurios

Quando estamos fazendo a anlise de um sistema, por meio de entrevistas ou
reunies, interagimos com pessoas com vises e descries diferentes do que o sistema. Um
cuidado importante que devemos ter quanto posio da descrio que est sendo feita em
relao ao sistema.
Nossa metodologia est interessada em eventos que partem do ambiente, de fora, para
dentro do sistema. Assim, devemos descrever cada evento com essa perspectiva. Nossos
clientes, porm, no tm sua perspectiva limitada pelo nosso modelo, afinal eles conhecem
seu negcio e no precisam de um mtodo como o nosso, onde as limitaes tm como
objetivo clarificar a compreenso do sistema pelo analista.
Assim, muitas vezes um entrevistado descreve o sistema como se fosse uma entidade
mgica, outros descrevem o sistema como se fizessem parte dele, outros descrevem apenas as
sadas do sistema, etc.
Devemos estar preparados para isso e garantir uma modelagem condizente com o
modelo essencial que atenda todos os pedidos do usurio. Devemos tambm fazer,
sutilmente, o usurio compreender a nossa forma, essencial, de descrever os eventos. Muitos
usurios entendem facilmente o conceito de eventos quando traduzidos para portugus mais
simples, como entrada de dados e entrada de comandos.
As perspectivas bsicas que encontramos em entrevistas e reunies so as seguintes:

Entrevistado omnisciente: descreve o sistema como o sistema, indicando

coisas que ele deve fazer. V tanto o sistema como os seus usurios de uma
perspectiva externa, aparentemente conhecendo os mecanismos tanto por
dentro quanto por fora. Normalmente a posio da alta gerncia e de quem
contratou o sistema. comum que no conhea os procedimentos internos do
sistema como acontecem realmente, mas apenas de forma geral ou como
aconteciam no passado. Exige funcionalidade do sistema, principalmente para
atender o nvel gerencial.

Entrevistado usurio: descreve o sistema como se o estivesse usando

diretamente, muitas vezes j usando o sistema atual. Exige funes do sistema,
principalmente para atender o seu nvel de atuao (gerencial ou operacional).
Pode apresentar alguma desconfiana, pois o novo sistema pode exigir novos

33

conhecimentos. Conhece a entrada e a sada do sistema, mas no

necessariamente os procedimentos internos.

Entrevistado parte do sistema: descreve o sistema visto por dentro. Muitas

vezes quem vai ter o trabalho substitudo, em todo ou em parte, pelo sistema,
o que pode causar desconfiana e at mesmo franca hostilidade. Conhece os
procedimentos na forma como so realizados e as excees que podem
acontecer.

No podemos deixar de entender que alguns usurios fornecem uma perspectiva

mista, principalmente quando envolvidos com diferentes partes do sistema.

Figura 13. Os tipos de entrevistados em relao ao sistema

IV.4 Requisitos e Necessidades

Requisitos so originrios de necessidades dos usurios e stakeholders. Enquanto os
requisitos vivem no mundo das solues, as necessidades vivem no mundo dos
problemas. Os requisitos implementam as caractersticas observadas do sistema, que
atendem as necessidades (Figura 14).

34

Figura 14. Enquanto as necessidades surgem no mundo dos

problemas, caractersticas e requisitos definem a soluo desejada.

Um problema uma diferena entre uma situao percebida e uma situao desejada.
Mais tarde vamos analisar vrios tipos de problema. No momento, nos basta a noo que o
problema incomoda o usurio (ou stakeholder) ao ponto dele considerar necessrio investir
alguma quantia de forma a evitar que o problema acontea.
comum ouvirmos o ditado Em time que est ganhando, no se mexe. Quando
somos chamados para desenvolver um sistema, devemos imaginar imediatamente que, se
algum deseja mexer em sua organizao, ento porque no est ganhando, pelo menos da
maneira que supe possvel. Faz pouco sentido imaginar que algum iria fazer um
investimento de risco, e sempre h risco no desenvolvimento de software, sem que haja uma
necessidade clara. No prximo captulo veremos que um sistema precisa, alm de um
objetivo funcional, metas de negcio, que visam determinar como ser a soluo para
problemas especficos.

Figura 15. O problema uma diferena entre uma situao percebida e

uma desejada.

Muitas vezes o analista se depara com a necessidade de, antes de definir requisitos,
definir propriamente qual o problema a ser tratado. Para isso, deve fazer com que os clientes
cheguem a um acordo sobre qual o verdadeiro problema, ou o problema mais importante.
Faz pouco sentido construir um sistema se o verdadeiro problema de negcios no for
endereado pela soluo planejada.
Para analisar o problema, necessrio que os usurios:

Concordem com a definio do problema

Entendam as causas do problema

35

o O problema por trs do problema pode ser mais importante, sendo que
o problema visto inicialmente apenas um sintoma

Identificem todos os stakeholders e usurios

Definam a fronteira do sistema de soluo

Identifiquem as restries impostas soluo

Para estabelecer o problema, interessante criar uma sentena apropriada, como a

seguinte:

O problema de <descrio do problema> , afeta <stakeholders afetados> e resulta

em <impacto nos stakeholders>. A soluo <indicar a soluo> Trar os benefcios
de <lista dos principais benefcios>.

Um sistema pequeno certamente produzir a soluo para uma pequena quantidade de

problemas, um sistema grande certamente atingir uma grande quantidade de problemas. O
ponto em questo que deve existir alguma no conformidade, seja ela atual ou futura, para
valer a pena o investimento, e o risco, de tentar um sistema novo.

IV.5 Tipos de Requisitos

IV.5.1 Requisitos Funcionais e de Informao
Uma maneira de dividir os requisitos do sistema separ-los entre requisitos
funcionais e no funcionais.
Um requisito funcional representa algo que o sistema deve fazer, ou seja, uma
funo esperada do sistema que agregue algum valor a seus usurios. Exemplos tpicos
incluem a emisso de relatrios e a realizao e manuteno de cadastros.
Como veremos mais tarde, os eventos essenciais definem todos os requisitos
funcionais do sistema, dado que a funo dele responder a todos os eventos. Apesar de no
ser fcil levantar corretamente os requisitos funcionais, a metodologia essencial fornece um
arcabouo eficiente para essa tarefa, que perfeitamente adequado para sistemas de
informao.
Requisitos de Informao representam a informao que o cliente deseja obter do
sistema. Requisitos de informao tambm so atendidos por eventos. Muitas vezes o cliente
expressa requisitos de informao de forma funcional Outras vezes o cliente est preocupado
em conseguir uma informao, mas no sabe como faz-lo na forma de um requisito
funcional. Em todo caso, sempre nos preocuparemos em levantar todos os requisitos de
informao, pois eles representam as respostas fundamentais do sistema.
IV.5.2 Requisitos no funcionais
Requisitos no funcionais falam da forma como os requisitos funcionais devem ser
alcanados. Eles definem propriedades e restries do sistema. Muitos requisitos no
funcionais so tambm requisitos de qualidade, como exigncias de desempenho e robustez.
Outros so restries ou exigncias de uso de uma ou outra tecnologia.
Porm, muitas vezes no s difcil descobrir quais so os requisitos no-funcionais,
mas tambm produzir uma especificao do sistema que possa ser cumprida em custo
razovel e prazo hbil de forma a atender os usurios. Um exemplo tpico seriam dois
requisitos no funcionais que, genericamente, so opostos: velocidade e transportabilidade.
Ora, para fazer um software muito veloz voc precisa adapt-lo especificamente para o
36

ambiente onde ele est funcionando. Para fazer um software transportvel, voc precisa
implement-lo de forma a funcionar no maior nmero possvel de ambientes. Normalmente
esses dois requisitos se relacionam de forma inversa e para implement-los simultaneamente
necessrio um grande investimento de recursos.
Existem muitas formas de se dividir os requisitos no funcionais, a figura a seguir
apresenta uma dessas formas, apenas para deixar clara a quantidade de fatores que podem
envolver um requisito no funcional, mas sem consider-la melhor ou pior que outras.
Requisitos
No Funcionais

Requisitos
do
Produto

Requisitos
de
Usabilidade

Requisitos
de
Confiabilidade

Requisitos
de
Eficincia

Requisitos
de
Desempenho

Requisitos
da
Organizao

Requisitos
De
Prazo

Requisitos
de
Espao

Requisitos
de
Portabilidade

Requisitos
de
Implementao

Requisitos
Externos

Requisitos
de Interoperabilidade

Requisitos
De
tica

Requisitos
De
Padronizao

Requisitos
Legais

Requisitos
de
Privacidade

Requisitos
de
Segurana

Figura 16. Tipos de requisitos funcionais, adaptado de

http://dme.uma.pt/jcardoso/Teaching/EMR/Lectures/11 (8/ago/2003) e Ian
Sommervile, Software Engineering.

Esse texto tem como foco requisitos funcionais e requisitos de informao. Ainda no
existe uma forma plenamente aceita de tratar requisitos no funcionais, mas o leitor
interessado poder encontrar diferentes mtodos na literatura de Engenharia de Software.
Alguns requisitos no funcionais, quando negados, geram um anti-requisito que
nunca seria pedido por um cliente. Por exemplo, um requisito no funcional comum que o
software seja confivel. Ningum pediria para ser construdo um software no confivel,
porm diferentes clientes esto interessados em diferentes nveis de confiabilidade e
diferentes formas de certificar esse nvel. Deve ser levado em conta que quanto mais esforo
colocado para se alcanar um requisito, maior o custo agregado ao projeto e isso servir
como referncia para o cliente escolher o grau de confiabilidade que deseja.
IV.5.3 Outros tipos de Requisitos
James e Susan Robertson [B9] identificam mais trs tipos de requisitos: restries de
projeto, temas de projeto e impulsionadores de projeto.

37

 As restries de projeto so os limites impostos ao sistema para que funcione no seu

ambiente operacional. Estas restries tanto podem ser tcnicas, envolvendo necessidades ou
disponibilidades de fatores como hardware, software, rede e interoperabilidade com outros
sistemas, quanto podem ser ligadas ao negcio. Restries podem ser vistas como requisitos
no funcionais de certa forma especiais, pois so limitantes.
Os impulsionadores de projeto so as foras do negcio que fazem o projeto acontecer.
Podem ser considerados requisitos na medida em que so os geradores originais dos
requisitos funcionais e no funcionais. Tanto o objetivo inicial do sistema como todos os nele
interessados (stakeholders) so impulsionadores.
Assuntos de projeto servem para completar o quadro geral de todos os fatores que
influenciaro o sucesso ou o fracasso do projeto.

IV.6 Requisitos Verdadeiros e Falsos

Um requisito verdadeiro quando o sistema deve cumpri-lo qualquer que seja a
tecnologia de implementao escolhida. Se um sistema pode cumprir sua finalidade sem que
um requisito seja implementado, ento esse requisito falso.
Requisitos falsos aparecem de vrias formas dentro do sistema: por cpia de sistemas
antigos, por hbito do analista, por pensarmos na tecnologia antes do tempo. Dividem-se em
dois grupos:
Requisitos falsos tecnolgicos so aqueles includos em um sistema por antecipao
de alguma caracterstica tecnolgica futura, como a linguagem de programao a ser
utilizada, ou por alguma caracterstica tecnolgica passada, como o tipo de arquivo em que
esto guardados os dados atualmente. Podem, novamente, ser divididos em:
Requisitos tecnolgicos includos pelo passado, quando inclumos na especificao
algo que existe na implementao existente, mas que no necessrio ao funcionamento do
sistema;
Requisitos tecnolgicos includos por antecipao, quando inclumos algo na
especificao em funo de alguma tecnologia escolhida para a implementao;
Requisitos falsos arbitrrios so includos pelos analistas, ou por preciosismo5 ou
por caractersticas da ferramenta de modelagem sendo utilizadas. Tambm podem ser
divididos em:
Requisitos arbitrrios includos por influncia da ferramenta de modelagem,
quando inclumos na especificao algo desnecessrio para fazer o sistema, mas necessrio
por alguma caracterstica da ferramenta de modelagem, e
Requisitos arbitrrios includos por preciosismo, quando inclumos uma funo
espria no sistema, i.e., uma funo que foi no solicitada pelo usurio.
Qualquer requisito que no possa ser verificado, ou seja, que sua presena no possa
ser garantida por alguma forma quantificvel e mensurvel no final do projeto um requisito
falso.
O principal problema de introduzir requisitos falsos que eles aumentam de vrias
formas o risco do projeto no se completar a contento. Um requisito falso, por si s, pode
5

Chamado em ingls de gold-plating

38

mascarar um requisito verdadeiro. Alm disso, o acmulo de requisitos falsos aumenta a

complexidade do sistema, de tal modo que pode tornar sua implementao invivel.
Assim, a busca dos requisitos verdadeiros, e apenas esses, deve ser uma das principais
formas de garantir o sucesso de um projeto.
Para que tenhamos um sistema apenas com requisitos verdadeiros, imaginamos que
ele ser implementado com uma tecnologia perfeita. Assim, evitamos os requisitos falsos
causados pela tecnologia, seja ela passada ou antecipada. Em um sistema de tecnologia
perfeita, como diz o nome, os processadores so infinitamente velozes, no gastam energia e
no cometem erros, as memrias so infinitamente grandes, os dados so transportados sem
gastar tempo.
A Anlise Essencial fornece conceitos importantes para que possamos nos guiar na
descoberta de todos os requisitos verdadeiros e para que evitemos a incluso de requisitos
falsos em nossos sistemas.
IV.6.1 O Usurio no Sabe Tudo
Um problema comum o usurio pedir algo como requisito porque ele pensa que esta
a forma de implementar um funcionalidade desejada. Esse erro, alm de comum,
provavelmente prejudicial ao sistema se no for detectado.
A verdade que apesar do analista ter que atender aos stakeholders, ele no tem que
atender exatamente ao que eles dizem, mas sim ao que eles realmente precisam. O trabalho
de anlise um trabalho investigativo, realizado junto com os usurios.

IV.7 Descrevendo Requisitos

Normalmente as especificaes de requisitos so escritas em linguagem natural
(ingls ou portugus, por exemplo). O problema, claro, que a forma como falamos e
normalmente escrevemos bastante ambgua. Isso exige que adotemos algumas tcnicas
bsicas, principalmente um formato padronizado, um estilo de linguagem e uma organizao
que facilite a manipulao do conjunto de requisitos.
Algumas dicas para escrever requisitos so [B10]:

Use sentenas e pargrafos curtos.

Use a voz ativa.

Use verbos no futuro.

Use os termos de forma consistente e mantenha um glossrio.

Para cada requisito, avalie se a partir de sua definio possvel determinar se

ele est pronto ou no.

Garanta que todos os requisitos so verificveis imaginando (e possivelmente

documentando) uma forma de faz-lo.

Verifique requisitos agregados (termos como e e ou so uma boa

indicao) e divida-os.

Mantenha um nvel de detalhe nico em todos os requisitos.

IV.7.1 Documentando os requisitos

Requisitos de projeto podem ser descritos com as seguintes informaes [B11]:
39

Nmero identificador,
o para facilitar a discusso, identificamos todos os requisitos unicamente.

Tipo
o Classificando-o como funcional, no funcional,...

Evento que o atende6

Descrio

Justificativa

Fonte do requisito
o A pessoa ou o grupo que o originou

Critrio de aceitao
o Uma medida que possa ser usada para garantir que o requisito foi
alcanado.

Satisfao do usurio
o Um grau, de 1 (nenhum interesse) a 5 (extremamente satisfeito), por
exemplo, indicando a satisfao do cliente se esse requisito for
alcanado.

Insatisfao do usurio
o Um grau, de 1 (nenhum interesse) a 5 (extremamente insatisfeito), por
exemplo, indicando a satisfao do cliente se esse requisito no for
alcanado.

Dependncias
o Referncias a outros requisitos que dependem de alguma forma desse
requisito

Conflitos
o Referncia aos requisitos que de alguma forma conflitam com esse

Material de apoio

Listagem de material de apoio para atender esse requisito

Histrico

Documentao da criao e das mudanas efetuadas

Esses autores ainda propem que os requisitos sejam levantados em cartes

padronizados, que facilitam sua discusso. O uso de cartes facilita no s por auxiliar a
documentao, mas tambm por criar um foco (se discute apenas o que est no carto sendo
tratado) em entrevistas e reunies.

Eventos Essenciais sero descritos no Captulo VII.

40

Figura 17. Um carto padronizado da metodologia Volere [B12].

IV.7.2 Dependncia de Requisitos

importante notar que os requisitos no so independentes uns dos outros. Muitos
requisitos s podem ser implementados se outros requisitos forem implementados antes. Por
exemplo, impossvel fazer um relatrio de vendas sem que se cadastrem as vendas
previamente no sistema. Uma das atividades mais importantes da gerncia de requisitos
manter esse relacionamento de dependncia, que influenciar em todo desenvolvimento e
Processo do sistema.
Para isso existem algumas solues possveis. Uma delas manter uma tabela de
dependncia de requisitos, outra manter um banco de dados de requisitos que inclua relaes
de dependncia. Existem alguns produtos no mercado especializados na gerncia de
requisitos.
IV.7.3 Priorizando Requisitos
Existe uma tendncia grande de o sistema crescer muito durante a anlise.
Principalmente se entrevistamos um grande nmero de pessoas, existe uma facilidade natural
das pessoas para propor novas funcionalidades para um sistema que ainda no existe, por
imaginarem alguma utilidade nessas funes propostas.
Assim, muitas vezes nos vemos envolvidos com uma quantidade de requisitos to grande
que bvio que o sistema a ser feito no poder ser entregue no prazo ou pelo custo combinado,
ou que se pensava em combinar.

Nesse caso, algumas tcnicas podem ser utilizadas para caracterizar o que deve ser
realmente feito ou, pelo menos, em que ordem as coisas devem ser feitas.
A primeira tcnica disponvel associar a cada requisito do sistema uma importncia.
Uma escala de trs ou cinco valores adequada para isso, como em: Imprescindvel para o
sucesso do sistema, Funcionalidade Importante, mas podemos esperar algum tempo,
Ajudaria ter, mas possvel viver sem essa funcionalidade, Benefcios mnimos,
Desnecessrio.
A segunda tcnica disponvel planejar o sistema para ser entregue em vrias verses,
mesmo que nem todas as verses estejam includas nesse contrato, e pedir para o cliente
determinar que funcionalidades devem aparecer em cada verso. Nesse caso pode ser

41

interessante dar um peso ou custo para cada requisito, de modo que o cliente possa controlar
seus gastos.
Uma terceira tcnica disponvel dar uma moeda virtual para o cliente, por exemplo,
1000 dinheiros, e pedir para ele distribuir quanto pagaria por cada funo, priorizando no
desenvolvimento aquelas funes que o cliente decidir pagar mais.
Todas essas tcnicas, porm, ficam dependentes de uma outra priorizao importante
dos requisitos: a priorizao por dependncia.
Devem ser levados em conta os vrios fatores que influenciam nessa determinao de
prioridades, entre eles os citados por [B13]:

Diminuir o custo da implementao

Valor para o comprador

Tempo para implementar

Facilidade tcnica de implementar

Facilidade do negcio para implementar

Valor para o negcio

Obrigao por alguma autoridade externa

IV.7.4 Questionando os requisitos

Em vrios momentos do projeto, importante tratar a lista de requisitos como uma
lista a ser abertamente questionada. Para isso devemos analisar as caractersticas desejadas
dos requisitos (Seo IV.1.1 ) e verificar, para cada requisito, se elas so verdade. Alm
disso, devemos tambm analisar de que forma os requisitos respondem as perguntas 5W2H
(Who, When, Where, What, Which, How, How much). Se o requisito passar por todos os
questionamentos, temos um requisito muito bom. Se falhar em alguns, pode ser que no seja
o momento ainda no projeto ou que a pergunta no seja pertinente, porm deve ser analisado
cada caso.
Os maiores problemas sempre sero encontrados na ambigidade dos requisitos.
Qualquer ambigidade um risco, porm no incio do projeto a ambigidade necessria,
pois decises importantes ainda no foram tomadas. Cabe ao analista saber em que p est
o projeto e qual o nvel de detalhe adequado aos requisitos.

IV.8 Mtodos de Elicitao de Requisitos

A elicitao de requisitos o levantamento, registro e validao [B14] das
expectativas dos diversos interessados no sistema, seguido da consolidao e validao
dessas expectativas em requisitos formais. Contemplar essas diferentes vises implica
projetar interesses divergentes e concili-los.
Para levantar requisitos necessria a interao entre aqueles que conhecem os
requisitos ou a necessidades dos usurios e stakeholders e os desenvolvedores. um processo
interativo de comunicao, onde, por aproximaes sucessivas, o desenvolvedor constri um
modelo aceito pelos usurios.

42

Figura 18 A elicitao de requisitos um processo interativo onde, por

aproximaes sucessivas, o desenvolvedor consegue a aprovao de
uma especificao de requisitos.

Para exemplificar esse processo, podemos imaginar a seguinte histria: uma criana e
seu pai esto conversando em uma praa, a criana ento pede a seu pai:
Pai, pega aquela pedra.
E o pai entrega uma pedra, a primeira que v, criana
No pai, a pedra pequena.
E o pai troca a pedra por um bem menor.
No pai, a pedra redonda.
E o pai troca a pedra por uma quase esfrica.
No pai, a pedra azul.
E o pai percebe ento que a criana queria uma bola de gude azul que estava na areia.
A criana fica feliz.
O mesmo acontece na investigao que um analista tem que fazer com o cliente em
busca do requisito. Inicialmente o cliente ser ambguo, generalista e paulatinamente, com a
ajuda do analista, dever chegar a uma especificao precisa do que deseja.
Uma receita geral para o levantamento de requisitos pode ser dada em 5 passos:
1. Identificar quem fornecer os requisitos
2. Levantar lista de desejos para estas pessoas
3. Refinar cada lista de desejos at que seja auto-consistente
4. Integrar as listas de desejos de forma que sejam consistentes
5. Determinar os requisitos no funcionais.
Apesar de tudo, no uma tarefa fcil levantar os requisitos. Muitos problemas
podem acontecer. comum que stakeholders no saibam exatamente o que querem ou no
saibam articular propriamente suas idias, especialmente quando o desenvolvedor no possui
o linguajar tpico da rea de aplicao (jargo). Muitas vezes, tambm, os desenvolvedores
pensam entender melhor do problema que seus clientes, propondo supostas melhorias que
afetam custo e aumento o risco dos sistemas propostos.

43

IV.8.1 Processo de elicitao de requisitos

A elicitao de requisitos pode ser modelada em um processo como o proposto por
Christel e Kang, apresentado nas figuras a seguir.
Busca de Fatos
Coleta e Classificao
de Requisitos
Racionalizao e
Avaliao
Priorizao
Integrao e
Validao

Figura 19. O processo de elicitao de requisitos, adaptado de Christel e

Lang [B14].

44

Tarefas da Elicitao de Requisitos

Atividade

Tarefas orientadas ao usurio

Tarefas orientadas ao
desenvolvedor

Busca de Fatos

Identificar
grupos
relevantes
atravs de mltiplos nveis da
organizao.
Determinar
os
contextos
operacional e do problema,
incluindo a definio dos modos
operacionais, objetivos e cenrios
de misso como apropriados.
Identificar sistemas similares.
Realizar anlise de contexto.

Identificar especialistas do domnio

da
aplicao
e
de
desenvolvimento.
Identificar modelo de domnio e
modelo de arquitetura.
Conduzir pesquisas tecnolgicas,
para mais tarde fazer estudo de
viabilidade e anlise de risco.
Identificar custos e restries
implementao impostas pelo
patrocinador.

Coleta e
Classificao dos
Requisitos

Levantar a lista de desejos de

cada grupo.

Classificar a lista de acordo com

funcionais,
no
funcionais,
restries de ambiente, restries
de projeto e ainda de acordo com
as parties definidas pelo modelo
de domnio e pelo paradigma de
desenvolvimento.

Racionalizao e
Avaliao

Responder questes da forma

Por que voc precisa de X?, a
partir de raciocnio abstrato. Isso
auxilia a transformar o raciocnio
das questes sobre como? para
as questes sobre o qu?.

Realizar uma anlise de riscos,

investigando tcnicas, custos,
prazos e incluindo anlise de
custos e benefcios e viabilidade
baseado na disponibilidade da
tecnologia.

Priorizao

Determinar
funcionalidades
crticas para a misso.

Priorizar requisitos baseados em

custo e dependncia. Estudar
como o sistema pode ser
implementado
de
forma
incremental, investigando modelos
arquiteturais apropriados.

Integrao e
Validao

Resolver a maior quantidade

possvel de pontos em aberto.
Validar que os requisitos esto
concordando com os objetivos
iniciais.
Obter autorizao e verificao
para passar ao prximo passo de
desenvolvimento
(e.g.
a
demonstrao e a validao).

Resolver conflitos
consistncia.

verificar

Tabela 2. Tarefas do processo de elicitao de requisitos, adaptado de

Christel e Kang [B14].

Existem muitas tcnicas avanadas de elicitao de requisitos que no cabem no

contexto desse livro. Aqui trataremos de duas tcnicas bsicas que coleta de informaes: a
entrevista e reunies de JAD.
IV.8.2 A entrevista
Entre as tcnicas mais importantes de elicitao de requisitos est a entrevista. Ela
est constantemente presente dentro de outras tcnicas porque, quase sempre, a Elicitao de
Requisitos em algum ponto - exige comunicao direta com os usurios e outros

45

interessados e a forma bsica de comunicao, seja de que forma esteja disfarada, a

entrevista.
A entrevista procura explicitar o pensamento do entrevistado a respeito das suas
relaes com seu universo em determinada instncia, tanto como indivduo quanto como
profissional, revelando o conhecimento do entrevistado sobre as pessoas, objetos, fatos e
procedimentos com os quais interage.
Os objetivos so os mais diversos, por exemplo: estabelecer expectativas do
consumidor, verificar nveis de satisfao e necessidades atuais e futuras; estudar tendncias
na satisfao do cliente ao longo do tempo ou avaliar programas em andamento.
O primeiro passo de uma entrevista determinar, entre outros aspectos: seus
propsitos ou objetivos; a informao necessria, e de quem obter, para alcanar esses
objetivos e os recursos disponveis para implementar e manter o processo de pesquisa. Outros
fatores merecem destaque: preciso na determinao da amostra; abrangncia e relevncia do
contedo da pesquisa e, essencial, a validao. Os resultados da entrevista so sumariados em
um relatrio interpretativo que inclui relato sobre os achados e as recomendaes mais
importantes. A anlise pode ser qualitativa ou quantitativa. Normalmente, as entrevistas
abertas esto no primeiro caso, enquanto que os questionrios so analisados
quantitativamente.
A responsabilidade do entrevistador tambm grande. Normalmente, alm das
entrevistas, ele quem integra as diferentes interpretaes, objetivos, metas, estilos de
comunicao, e o uso de terminologia. H tambm outras tarefas complexas como decidir a
oportunidade ou no de incluir certo tipo de informao no conjunto inicial de requisitos.
Finalmente, entrevistar e integrar toma tempo. Como os requisitos so volteis, quanto mais
longo o processo mais facilmente os requisitos deixam de atender as necessidades e
expectativas dos interessados. Todos esses encargos recomendam que o analista conhea
tanto as tcnicas de desenvolvimento quanto o domnio no qual se insere.
Existem vrios tipos de entrevistas. Durante o processo de anlise, elas normalmente
seguem o seguinte processo:
1. Introduo inicial
2. Familiarizao com o ambiente
3. Busca de fatos
4. Verificao de informaes conseguidas de outras formas
5. Confirmao de informaes conseguidas com os candidatos
6. Acompanhamento, amplificao ou clarificao de entrevistas anteriores.
7. Outra grande varivel da entrevista o seu objetivo, entre outros:
8. Levantar informaes sobre a organizao
9. Levantar informaes sobre uma funo de negcio
10. Levantar informaes sobre um processo ou atividade
11. Descobrir problemas
12. Verificar fatos previamente levantados
13. Fornecer informao
14. Obter dicas para entrevistas futuras
46

H vrias formas de entrevista, entre elas: entrevista por questionrio; entrevista

aberta; entrevista estruturada.
IV.8.2.1 Entrevista

por Questionrio
O questionrio muito usado como tcnica de entrevista, principalmente em
pesquisas de mercado e opinio. Exige preparao elaborada. Alguns aspectos particulares do
processo merecem destaque: emprego de vocabulrio adequado para o pblico entrevistado;
incluso de todos os contedos relevantes e de todas as possibilidades de respostas; cuidado
com os itens redundantes ou ambguos, contendo mais de uma idia ou no relacionados com
o propsito da pesquisa; redao clara; execuo de testes de validade e confiabilidade da
pesquisa.

H uma tenso no resolvida entre o uso do questionrio como um evento interativo

ou como instrumento neutro de medida. Por um lado, como entrevista, visto como uma
interao. Por outro lado, no interesse de torn-lo um instrumento, muitos recursos da
interao existentes na conversao no so permitidos, suprimindo recursos de medida de
incertezas de relevncia e interpretao.
Dificuldade importante o fato das palavras possurem significados diferentes para
pessoas diferentes em diferentes contextos. Em interaes normais essas questes de
interpretao so negociadas entre os participantes, mas em entrevistas com questionrios o
treinamento e o mtodo utilizados probem essa negociao. Alm disso, h necessidade do
uso de tcnicas especficas nem sempre do conhecimento dos projetistas - para a construo
e aplicao de questionrios. A menor ambigidade uma das principais vantagens da
entrevista via questionrio.
Para gerar bons itens de questionrio, devemos:

Evitar palavras ambguas ou vagas que tenham significados diferentes para

pessoas diferentes;

Redigir itens especficos, claros e concisos e descarte palavras suprfluas;

Incluir apenas uma idia por item;

Evitar itens com categorias de respostas desbalanceadas;

Evitar itens com dupla negao;

Evitar palavras especializadas, jarges, abreviaturas e anacronismos;

Redigir itens relevantes para a sua pesquisa;

Evitar itens demogrficos que identifiquem os entrevistados

IV.8.2.2 Entrevista

Aberta
Esse tipo de entrevista evita muitos dos problemas dos questionrios, porm tambm
cria outros. O entrevistador formula uma questo e permite que o entrevistado responda como
quiser. O entrevistador pode pedir mais detalhes, mas no determina os termos da entrevista.
Permanecem, entretanto, as questes: as perguntas podem ser respondidas? A resposta faz
parte do repertrio normal do discurso do entrevistado? H muitas coisas que as pessoas
sabem fazer, mas tem dificuldade de descrever, como h tambm o conhecimento tcito, que
de difcil elicitao.

Os benefcios das entrevistas abertas so: a ausncia de restries, a possibilidade de

trabalhar uma viso ampla e geral de reas especficas e a expresso livre do entrevistado.

47

H desvantagens tambm. A tarefa de entrevistar difcil e desgastante. O

entrevistador e o entrevistado precisam reconhecer a necessidade de mtua colaborao ou o
resultado no ser o desejado. H falta de procedimentos padronizados para estruturar as
informaes recebidas durante as entrevistas. A anlise da informao obtida no trivial.
difcil ouvir e registrar simultaneamente; principalmente, porque h fatos que s tomam
importncia depois de outros fatos serem conhecidos, e a ele j no foi registrado. Da a
importncia da gravao e da respectiva transcrio; fica mais fcil selecionar e registrar o
que relevante e validar com o entrevistado.
So exigncias para o relacionamento entre os participantes de uma entrevista:
respeito ao conhecimento e habilidade do especialista; percepo de expresses no verbais;
sensibilidade s diferenas culturais; cordialidade e cooperao.
IV.8.2.3 Entrevista

Estruturada
A entrevista estruturada extrai informaes sobre perguntas especficas. Nesse tipo de
entrevista, importante entrevistar a pessoa certa. uma boa tcnica para ser usada aps uma
pesquisa com questionrio, quando possvel selecionar, entre as respostas, as partes
interessadas com maior potencial de gerao de outras informaes. Suas vantagens so:
Respostas diretas, com menos ambigidade, informao detalhada. Sua desvantagem bsica
que as questes relevantes precisam ser identificadas com antecedncia.

IV.8.2.4 O

processo da entrevista
O processo de entrevista no se resume ao ato especfico da entrevista. Na verdade ele
comea muito antes e acaba muito depois. O processo normal da entrevista inclui:
1. Determinao da necessidade da entrevista

2. Especificao do objetivo da entrevista

3. Seleo do entrevistado
4. Marcao da entrevista
5. Preparao das questes ou do roteiro
6. A entrevista propriamente dita
7. Documentao da entrevista, incluindo os fatos e a informao conseguida durante a
entrevista.
8. Reviso da transcrio da entrevista com o entrevistado
9. Correo da transcrio
10. Aceitao por parte do entrevistado
11. Arquivamento
IV.8.2.5 Preparando

a entrevista

A preparao uma necessidade bsica da entrevista. No s precisamos preparar a

entrevista propriamente dita, mas tambm preparar a ns mesmos, como entrevistadores, e ao
entrevistado.

Uma entrevista deve ter um objetivo. As perguntas ou o roteiro devem ser coerentes.
Para isso importante a determinao desse objetivo,. O entrevistado deve ter noo clara da
finalidade da entrevista e perceber sua utilidade. Isso se faz por meio de palestras, textos de
divulgao e, principalmente, se explicando ao entrevistado, no incio da entrevista, seu
objetivo e importncia.
48

Muitas vezes esse objetivo no especfico, principalmente na fase inicial do projeto.

Mas deve ser claro, isso , quando expressado deve permitir que entrevistador e entrevistado
compreendam o motivo da entrevista. Assim, no incio do projeto os objetivos podem ser:
Conhecer o ambiente de trabalho, Levantar expectativas iniciais dos usurios. J com o
passar do tempo do projeto o objetivo se torna mais detalhado, como em: Levantar os
documentos utilizados no processo de compra ou Avaliar as telas relativas ao cadastro de
bens.
A escolha do entrevistado o segundo aspecto importante. Devem ser escolhidas as
pessoas que permitam obter no final das entrevistas uma viso clara e o mais completa
possvel do problema, das diversas formas de analis-lo e solucion-lo. Nunca se deve tratar
um problema a partir de um nico nvel funcional, nem de uma nica viso organizacional,
pois estaramos correndo o srio risco de obter uma viso distorcida. Devemos lembrar que o
sistema afetar todos os nveis funcionais e departamentos da instituio.
Dependendo do tipo de entrevista, ser necessrio um roteiro ou um questionrio. No
incio da anlise os roteiros levam a execuo de entrevistas abertas, no final geralmente
temos entrevistas por questionrios. Entrevistas estruturadas so preparadas principalmente
para esclarecimento de processos e atividades.
Todos os roteiros e questionrios devem seguir um modelo padro, incluindo a
apresentao e a concluso da entrevista. Quanto maior o nmero de entrevistadores, maior a
importncia de seguir um padro.
Outros aspectos fundamentais a serem preparados so:

A linguagem

A coerncia das perguntas

A programao dos horrios

importante estar preparado para a linguagem a ser usada na entrevista. Nisso

influenciam vrios fatores, como nvel cultural do entrevistado, terminologia do trabalho,
jargo da rea, etc. Devemos evitar ao mximo usar os nossos termos tcnicos e aproveitar ao
mximo a oportunidade de aprender os termos tcnicos do entrevistado. Se necessrio, ler um
pequeno texto esclarecedor sobre a rea e, sempre, ler o glossrio do projeto. O entrevistador
deve sempre esclarecer com o entrevistado todas as dvidas quanto ao vocabulrio utilizado
no ambiente onde o sistema ser implantado.
Marque a entrevista com antecedncia, com confirmao de data, hora, durao e
local por todas as partes. As seguintes regras devem ser observadas quanto ao horrio;

As entrevistas devem ter 30, 60 ou 90 minutos e, no mximo, duas horas.

As entrevistas iniciais podem ser mais longas, enquanto as entrevistas finais

devem ser mais rpidas.

Evite horrios perto da hora do almoo ou no final de expediente, ou em uma

tarde de sexta-feira ou vspera de feriado.

Obtenha o telefone do entrevistado, para poder avis-lo de sua ausncia em

caso de urgncia.

Chegue sempre 10 minutos adiantado e esteja preparado para esperar e para ter
que encerrar a entrevista mais cedo, principalmente com a alta gerncia.

49

Se possvel, caso a entrevista seja mais curta que o combinado, marque

imediatamente a sua continuao.

Quanto ao material necessrio para uma entrevista, alm do roteiro:

Prepare e teste o equipamento, principalmente um gravador. Atualmente

existem bons gravadores digitais a preos razoveis no mercado.

Tenha pelo menos 2 horas de gravao e um jogo de pilhas extras.

Tenha um caderno de anotaes ( melhor que um bloco) reservado para o

projeto. Canetas de vrias cores, lpis, borrachas.

IV.8.3 Realizando a entrevista

O objetivo normal de uma entrevista conseguir informaes do entrevistado, para
isso devemos fazer no s que o usurio fale, mas tambm que ele pense. importante para o
entrevistador no assumir nada e no fazer pr-julgamentos, caso contrrio correr o risco de
fazer uma entrevista viciada.
O entrevistador deve manter o controle o assunto da entrevista. No deixe o
entrevistador mudar de assunto ou tergiversar, mantendo suas perguntas direcionadas para o
objetivo da entrevista.
As duas principais armas do entrevistador so a pergunta e o silncio. Para perguntar
devemos ter conscincia do tipo de pergunta que escolhemos. Se quisermos que o usurio
explique algo, ento devemos utilizar uma pergunta aberta. Isso muito comum em
entrevistas abertas no incio da anlise.
O importante fazer o usurio pensar, para isso, o entrevistador deve evitar perguntas
que contenham a prpria resposta ou as que podem ser respondidas apenas com um sim ou
no. As perguntas fechadas devem ser utilizadas para tirar dvidas do entrevistador. Use
questes comeando com quem, qual, quando, onde, porque e como sempre que
possvel. Tente completar o ciclo (quem qual quando onde porque como) para todos
os assuntos.
Em dvida, pergunta novamente de outra forma. O entrevistador deve pedir que
processos complicados sejam explicados mais de uma vez, preferencialmente sob
perspectivas diferentes.
importante estabelecer exemplos concretos para o que est sendo descrito pelo
usurio. Tambm, em caso de uma dvida, melhor descrever um exemplo concreto (o que
aconteceria se ...) do que uma dvida abstrata. O entrevistador deve estar consciente que
muito difcil encontrar um entrevistado capaz de raciocinar plenamente de forma abstrata
sobre um problema. Mesmo nesse caso, normalmente a forma abstrata se resume ao caso
perfeito, sendo que as excees so melhores explicadas com exemplos.
No tenha pressa, no responda pelo entrevistado. No se preocupe com a demora
para responder ou o silncio. O silncio, inclusive, uma boa ttica para fazer o entrevistado
continuar falando. Deixe o entrevistado pensar, olhe para ele curiosamente.
Antes de mudar de assunto, verifique sua compreenso, explicando de forma
resumida o que acabou de ouvir. Isso permite ao entrevistado pensar e dar uma clarificao se
necessrio
Esteja atento para a ausncia de crticas por parte do candidato. Isso pode ser causado
pela falta de confiana do entrevistado em voc ou porque o problema constrangedor

50

demais para ser tratado. O analista deve constatar esse fato no processo de anlise, mas no
durante a entrevista.
Observe (e anote) as interrupes casadas por fatores externos (telefone, pessoas que
entram e que saem, etc.).
Separe o que fato do que opinio.
Conclua a entrevista de forma positiva
IV.8.3.1 O

Comportamento do Entrevistador
Esteja atento ao prprio comportamento. Lembre-se que no importa sua inteno ao
fazer ou deixar de fazer algo, mas a interpretao que o entrevistado dar ou que fizer ou no
fizer.

No passado era comum que consultores sempre se vestissem de terno, at mesmo

apenas ternos escuros. A maioria das empresas hoje utiliza um cdigo de vestimenta
informal. A regra mais atual que o entrevistador ou consultor tome cuidado para no
provocar um grande desnvel entre a sua roupa e a roupa do entrevistado ou cliente, se
adaptando as normas de vestimenta do cliente (ou do mercado ao qual o cliente pertence).
Fisicamente, no faa movimentos desnecessrios como bater o lpis na mesa, mexer
as chaves no bolso, etc. Movimentos automticos e cacoetes distraem o entrevistado e, alm
disso, podem ser interpretados como falta de ateno. No fume, mas tambm no evite que
seu entrevistado fume. No constranja o entrevistado comentado sobre os males do fumo.
No pea caf, mas pode aceitar o oferecido. Se necessrio, pode pedir gua.
Estabelea um horrio para a entrevista e o cumpra rigidamente. Devido aos
constantes problemas de trnsito da cidade, e a necessidade de se identificar para seguranas
e secretrias, o entrevistador deve sempre planejar chegar ao local com uma folga de tempo,
algo em torno de 15 minutos.
Mantenha o interesse. Tome notas, mas no seja obsessivo, principalmente no
interrompa o candidato para manter suas notas atualizadas. Grave a entrevista e a reveja mais
tarde se necessrio. Escute ativamente sem interromper. O entrevistado que deve falar a
maior parte do tempo.
Utilize um tom educado e corts. No seja engraado, sarcstico ou depreciativo. No
faa comentrios pejorativos ou preconceituosos. No faa comentrios sobre poltica e
religio, ou outro tema controverso. Seja cordial, mas sem deixar de ser profissional.
Pergunte e responda com cortesia e honestidade. No de opinies particulares, mesmo
quando pedido. A entrevista o momento de levantar informaes, no de emiti-las.
No de a um entrevistado informaes passadas por outros entrevistados.
Educadamente, responda que no cabe a voc a deciso ou a opinio.
Evite, de toda a forma, confrontar o entrevistado. No torne a entrevista um
interrogatrio. Evite discutir, mesmo que no concorde com o usurio. Em caso de discusso,
defina claramente o motivo do desacordo, seja ele motivado por fato ou por opinio. Utilize
perguntas para restabelecer a comunicao em caso de desacordo. Se necessrio, pea
desculpas.
Basicamente o entrevistador deve ser muito educado.

51

IV.8.3.2 Roteiro

Bsico
1. Apresente-se ao entrevistado: Ol, muito prazer, eu sou fulano-de-tal,
responsvel por parte do projeto XYZ. Apresente seu carto de visitas se for
o primeiro encontro.
2. Informe ao entrevistado o motivo da entrevista e porque foi selecionado:
Estou aqui para levantar o funcionamento da sua rea, e seu nome foi
escolhido por ser o funcionrio mais experiente ou Estou aqui para levantar
o funcionamento da atividade X, que de sua responsabilidade.
3. Deixe clara a idia que o conhecimento e as opinies do entrevistado so
importantes e sero teis no processo de anlise
4. Diga o que vai acontecer com a informao levantada
5. Garanta que o entrevistado ler a transcrio da entrevista e ter a
oportunidade de corrigi-la, garanta que nada ser passado a outras pessoas sem
a reviso e verificao do entrevistado.
6. Determine os assuntos confidenciais ou restritos a serem tratados na entrevista
7. Deixe claro que no haver conseqncias negativas em funo do resultado
da entrevista
8. Solicite permisso para gravar a entrevista
9. Se autorizado, inicie a gravao com um texto de apresentao: Entrevista
realizada no dia X....
10. Faa a entrevista at faltarem 5 ou 10 minutos para o tempo determinado

11. Avise ao entrevistado que o tempo est acabando e pergunte se gostaria de

adicionar alguma informao
12. Solicite ao candidato que responda as perguntas de concluso
13. Se necessrio, marque outra entrevista.
14. Entregue ao candidato o formulrio de avaliao de entrevista e o envelope
correspondente. Ensine-o a enviar a avaliao preenchida.
15. Despea-se educadamente, agradecendo a ateno e o tempo dispensado.
Muitas vezes a entrevista precedida por um bate-papo informal de apresentao.
Tente manter essa conversao em um tempo mnimo razovel.
IV.8.3.3 Documentando

a Entrevista
A entrevista deve ser documentada logo aps sua realizao. Ao document-la
rapidamente, estar garantindo que recuperar mais informao.
A documentao da entrevista deve fornecer a seguinte informao.

A data, hora e local da entrevista.

Nome do entrevistador

Cargo do entrevistador

Nome do entrevistado

Funo do entrevistado e a descrio desse cargo

52

Se necessrio, informaes de background do entrevistado, como experincia

no cargo ou com computadores.

Organograma do entrevistado (superior imediato, colegas do mesmo nvel,

subordinados).

O objetivo da entrevista

Nomes e ttulos de todos os outros presentes na entrevista

Uma descrio completa dos fatos descritos e opinies do entrevistado

Opcionalmente, uma transcrio da entrevista, possivelmente expurgada das

falas que no tinham relao com o assunto da entrevista.

Todas as concluses tiradas dos fatos e opinies como apresentados

Todos os problemas de negcio levantados durante a entrevista

Exemplos de todos os relatrios, diagramas, documentos, etc., discutidos

durante a entrevista.

Todos os desenhos e diagramas feitos a partir ou durante a entrevista

Qualquer comentrio relevante feito pelo entrevistado

Todos os nmeros relevantes (quantidades, volume de dados, etc.) coletados

durante a entrevista.

importante notar que o relatrio da entrevista deve ser aceito pelo entrevistado.
normal o entrevistado remover alguma coisa ou colocar algo a mais. O analista deve ficar
atento aos motivos do usurio em fazer modificaes.
Se houver discusso quanto interpretao de algo e o analista achar essencial manter
sua verso no relatrio, deve tambm permitir que o entrevistado coloque sua verso.
IV.8.3.4 As

perguntas de concluso
Ao final da entrevista, importante realizar uma avaliao da percepo do
entrevistado sobre a entrevista que acabou de ser realizada. Para isso necessrio que seja
respondido um formulrio, contendo perguntas como:

Voc acha que essa entrevista cobriu tudo que era necessrio?

Voc acha que foram feitas as perguntas certas?

Voc acha que era a pessoa mais certa para responder essas perguntas?

IV.8.4 JAD
Outra tcnica importante de elicitao de requisitos, que merece um tratamento
separado, o JAD.
Muitas vezes, quando um grupo de informtica entrega um sistema de informao aos
seus clientes escuta a frase: no era isso que eu queria! Isto acontece porque os
desenvolvedores no conseguiram levantar com os usurios suas verdadeiras necessidades.
Este problema de comunicao pode ter diversas causas: linguagem especializada de
ambas as partes, desconhecimento da rea de atuao pelos desenvolvedores, preocupaes
com a tecnologia empregada ao invs das necessidades dos usurios, etc. Na fase inicial do
projeto, a dificuldade de comunicao entre clientes e equipe de desenvolvimento a
principal causa de defeitos que sero encontrados no produto final.
53

Para enfrentar os problemas de comunicao entre desenvolvedores e usurios, foram

desenvolvidos, ao final da dcada de 1970, vrios mtodos onde o desenvolvimento de
sistemas baseado na dinmica de grupo.
Na forma tradicional de desenvolver sistemas os analistas entrevistam os usurios, um
aps outro, tomando notas que so mais tarde consolidadas e ento validadas com o usurio,
finalmente se transformando em um documento de anlise.
O JAD, Joint Application Design, ou Mtodo de Projeto Interativo, substitui as
entrevistas individuais por reunies de grupo, onde participam representantes dos usurios e
os representantes dos desenvolvedores.
Quando o mtodo aplicado de forma correta, os resultados alcanados ultrapassam
os objetivos imediatos da obteno de informao dos usurios e cria um ambiente de alta
sinergia na equipe, onde todos se sentem comprometidos com as solues encontradas. Esse
comprometimento permite que todos se considerem proprietrios e colaboradores no
desenvolvimento do sistema.
IV.8.4.1 O

Objetivo do Mtodo
O objetivo do mtodo extrair informaes de alta qualidade dos usurios, em curto
espao de tempo, atravs de reunies estruturadas para alcanar decises por consenso.

IV.8.4.2 Os

Componentes
O lder de sesso tem como tarefa nmero um conduzir o grupo para solues de
consenso. Esse lder de sesso age como facilitador, um servidor neutro dentro do grupo que
no avalia nem contribui com idias. A responsabilidade do facilitador sugerir mtodos e
procedimentos que ajudem o grupo a concentrar energia em tarefas especficas, garantindo a
todos os membros do grupo condies de participar.
O documentador um auxiliar imparcial do lder de sesso, responsvel pelo registro
das decises e especificaes produzidas. Apenas as informaes relevantes so
documentadas, segundo orientao do lder de sesso.
O patrocinador detm a autoridade formal sobre as reas afetadas pelo sistema,
estabelecendo diretrizes e objetivos do projeto.
A equipe responsvel pelo contedo da sesso, representando as reas envolvidas
no projeto.

IV.8.4.3 A

Dinmica
A base de trabalho a equipe presente na reunio. Para que no acontea como na
figura abaixo devemos combinar algumas regras de jogo, de modo a alcanar o mximo de
produtividade. natural que em um grupo de 15 pessoas surjam discusses, conversas
paralelas, interrupes, etc. Em respeito ao tempo precioso dos participantes vamos
necessrio estabelecer um cdigo de cooperao.

IV.8.4.4 O

Ambiente
O Ambiente fsico da reunio fundamental para a produtividade dos trabalhos. Os
seguintes aspectos devem ser considerados:
Os participantes devem estar organizados de forma a poderem se olhar e olhar para o
lder de sesso. A melhor arrumao a em forma de U.
No devem acontecer interrupes aos participantes.
Todos devem cumprir a agenda, principalmente o incio e o fim da reunio.
54

Figura 20. Uma sala de JAD bem planejada

IV.8.4.5 O

Consenso
A forma mais produtiva de deciso do grupo aquela obtida por consenso. Consenso
no a unanimidade de opinies, mas, sim, a situao em que cada membro concorda que a
soluo encontrada a melhor para o grupo e que possvel conviver com ela sem ferir
convices ou valores essenciais.

55

IV.9 Mind-Map

Figura 21. Principais tpicos do captulo na forma de um mind-map.

IV.10

Exerccios

IV.10.1
Projeto 1: Livraria ABC
Baseado em todos os textos disponveis sobre a Livraria ABC, faa:
1. Uma lista de requisitos funcionais preliminares
2. Uma lista de requisitos no-funcionais preliminares
3. Uma lista de requisitos de informao preliminares
IV.10.2
Projeto de Curso
Para o seu projeto de curso, faa uma lista com:
1. Requisitos funcionais preliminares
2. Requisitos de informao preliminares
3. Requisitos no funcionais preliminares
4. Documente cada requisito dessa lista de acordo os descritores de requisitos
mostrados nesse captulo.
5. Para o seu projeto de curso, prepare:
6. Um roteiro de uma entrevista inicial do projeto
7. Um questionrio a ser feito com os usurios atuais do servio com a finalidade
de descobrir sua qualidade

56

Captulo V. Uma Proposta Inicial

It isn't that they can't see the solution. It is that they can't see the problem.
Chesterton, G. K. (1874 - 1936) in The Point of a Pin in The Scandal of Father Brown.
Objetivo
Problemas
Oportunidades
Metas
Mtricas
Requisitos Iniciais
Descrio Sucinta do Sistema Atual
Restries
Proposta Inicial

V.1 O Primeiro Contato e Os Primeiros Resultados

Quando vamos iniciar o desenvolvimento de um sistema, somos em geral convidados
por um cliente em potencial para conhecer seus problemas, seus desejos e propor uma
soluo.
Essa uma fase muito difcil para o desenvolvedor, pois precisa tomar muitas
decises com poucas informaes. Algumas vezes obrigado a fornecer uma proposta de
trabalho, incluindo previso de custos ou preo7, a partir de uma entrevista curta. Essa
situao est muito longe da ideal, onde s teramos que fornecer uma proposta de trabalho
aps saber exatamente o que ser preciso fazer. Outro problema para o desenvolvedor que
esta uma fase de investimento. Entre vrias propostas apresentadas, apenas algumas sero
aceitas. O tempo gasto nas propostas no aceitas um custo a mais, a ser dividido por todos
os projetos aceitos.
Esta fase inicial de negociaes deve ter um objetivo: desenvolver um documento
chamado Proposta Inicial8. A proposta inicial o primeiro passo para atingir a proposta de
desenvolvimento e pode ser mantida como documento interno se o cliente no exigir uma
proposta imediatamente.
O objetivo dessa proposta construir um quadro claro da situao atual do cliente e
uma viso da sua situao futura com o sistema funcionado. Esse quadro permite,
simultaneamente, ao desenvolvedor previses mais embasadas e ao cliente uma maior
confiana nessas previses.

V.2 A solicitao do cliente

Normalmente, o cliente, ao solicitar um software, tem idia do que necessita que esse
software faa, possuindo inclusive um documento descrevendo essa idia. nesse

7
O custo de um sistema quanto ser gasto para o seu desenvolvimento. O preo do sistema quando ser cobrado ao
cliente. O custo funo direta do tamanho do sistema, o preo uma questo de mercado.
8

No chamaremos esse documento de proposta de desenvolvimento por considerar que so necessrios mais alguns
dados para desenvolver uma verdadeira proposta de desenvolvimento

57

documento, ou a partir das entrevistas iniciais, que o analista deve procurar as principais
motivaes e necessidades do cliente.
sempre importante focalizar nas necessidades de negcio do cliente. Muitas vezes o
cliente acredita precisar de um sistema para resolver um problema em seu negcio, quando na
verdade precisa de outro. Deixando claras as expectativas, teremos clientes mais contentes.

V.3 Objetivo do Sistema

O Objetivo do Sistema descrito por uma sentena de poucas linhas que permite
identificar imediatamente sua finalidade. A sentena deve ser clara, de forma a permitir uma
definio rpida do seu escopo, isto , da fronteira que define o que faz parte e o que no faz
parte do sistema. Deve tambm esclarecer a razo do projeto existir e ser necessrio.
Alguns objetivos razoveis so:

O Sistema dever controlar a recepo e envio de pacotes pelo setor de

cargas.

O Sistema permitir o gerenciamento de cardpios em uma rede de

restaurantes populares, definindo pratos e receitas e verificando sua
aceitao.

O Sistema controlar a entrada e sada de funcionrios, realizando o servio

de ponto e fornecendo dados para a folha de pagamento.

Em todos esses objetivos podemos, at certo ponto, que tarefas podem fazer parte e
que tarefas no devem fazer parte do sistema9.
O objetivo deve identificar junto ao cliente, de forma mais padronizada possvel
frente ao mercado, que tipo de sistema est sendo desenvolvido. Ao mesmo tempo, deve
fornecer informaes suficientes que caracterizem de que forma esse sistema especial.
Assim, um bom objetivo exemplo o seguinte:
Desenvolver um sistema de controle de vendas para uma loja de materiais de
construo que permita encomenda de mercadorias.
Nesse exemplo descrevemos o sistema de forma bastante geral e reconhecida no
mercado (sistema de controle de vendas), permitindo uma imediata compreenso do escopo
bsico do projeto. Logo aps, declaramos que ele deve ser especfico para um tipo de negcio
(loja de materiais de construo), ao mesmo tempo reduzindo e ampliando o escopo, em
funo da rea de aplicao. Finalmente, declaramos que deve suportar uma funo no
necessariamente comum nesse tipo de aplicao, como um requisito primordial (permita
encomenda de mercadorias), provavelmente diferenciando o sistema da prtica normal do
mercado.
No devemos dar vrios objetivos a um sistema. Quando isso parece necessrio,
temos a forte indicao que estamos tratando de mais de um sistema. Ao declarar um objetivo
devemos evitar o uso das conjunes e e tambm, ou ainda outra construo que leve a
representar mais de uma idia. Quando um objetivo tem mais de uma idia proposta,
9

Alguns exemplos de objetivos mal definidos:

O Sistema otimizar o desempenho da empresa na sua rea de atuao

O Sistema possibilitar o controle dos clientes

58

geralmente temos na verdade mais de um sistema sendo descrito. importante no misturar

sistemas distintos, principalmente para reduzir o risco do projeto, j que quanto maior for o
projeto, maiores sero os riscos envolvidos.

V.4 Problemas
Ao conversar com o cliente, principalmente nas entrevistas iniciais, temos a
oportunidade de ouvir muitas reclamaes sobre o sistema atual, seja ele informatizado ou
no. Isso esperado, pois se no existissem defeitos na forma como o sistema executado no
momento, no haveria necessidade de implementar um novo sistema. Assim, devemos
entender que a verdadeira motivao que o cliente tem em chamar uma equipe de
desenvolvimento de sistema a de corrigir os seus problemas, principalmente os que mais
afetam negativamente o seu negcio.
Um problema pode ser classificado como:

De negcio

Funcional

Operacional

Um problema operacional ocorre quando uma funcionalidade do sistema funciona

de forma errada. Por exemplo, na automatizao do processo de gerncia das contas (pedido e
fechamento de conta) de um restaurante, problemas operacionais comuns so: a dificuldade
de fechar a conta e os erros de clculo que acontecem.
Um problema funcional ocorre quando o sistema no permite uma funcionalidade.
No mesmo sistema de contas de restaurante, por exemplo, pode ser impossvel ou muito
difcil saber quanto cada garom vendeu em um dia.
Finalmente, os problemas de negcio esto relacionados manuteno do negcio
propriamente dito e podem tanto ser isolados quanto causados por problemas operacionais ou
funcionais. Um problema operacional como a demora ao calcular o valor final de uma conta
pode causar um problema de negcio como filas na sada do restaurante.
Para identificar problemas, podemos adotar algumas estratgias [B15], como:
verificar os resultados obtidos atualmente nos processos e compar-los com objetivos da
empresa ou padres do mercado, observar o comportamento dos empregados e levantar a
opinio de fornecedores, clientes e vendedores (representantes ou distribuidores) da empresa.
Sinais especficos que podem ser verificados so:

Quanto s tarefas realizadas, se contm erros, se so feitas vagarosamente, se

no so mais feitas como definidas em documentos da companhia, se no so
completadas;

Quanto aos funcionrios, se esto desestimulados, se no podem descrever

suas responsabilidades e objetivos, se a taxa de demisses alta.

Quanto aos parceiros externos (clientes, fornecedores e vendedores):

reclamaes, sugestes de melhoria, queda nas vendas, vendas com perdas.

Para auxiliar o processo de levantamento de problemas, pode ser criada uma tabela
com as colunas: Causa, Resultado, Valor, Processo Causador, Dados causadores, Sugesto de
soluo.

59

Problemas do Negcio
#

Causa

Resultado

Valor

Processo

Dados

Causador

Causadores

Sugesto
de
Soluo

Como no
podemos
analisar
planos de
negcio
alternativos

No
possvel
analisar
cenrios de
mercado

Acima de 1
milho

Planejamento

Modelagem
de cenrios

Como no
sabemos o
custo real de
produo
futura

No
possvel
fazer
contratos de
longo prazo

30% do
faturamento
poderiam ser
passados de
curto prazo
para longo

Compras

Preos

Sistema de
acompanha
mento de
custos

Tabela 3. Identificando problemas de negcio

V.5 Oportunidades
As oportunidades so ofertas que fazemos ao nosso cliente. Devido ao nosso
conhecimento tcnico e tecnolgico, normalmente ficamos vontade para oferecer
oportunidades tecnolgicas. Uma oportunidade tecnolgica, como diz o nome, a oferta de
uma tecnologia especfica de implementao que oferecer alguma vantagem ao cliente. Por
exemplo, ao implantar um novo sistema de estoque podemos oferecer a entrada e sada de
produtos pelo uso de cdigo de barras. A oportunidade tecnolgica no altera a
funcionalidade que o cliente necessita, mas sim sua forma de implementao.
Algumas vezes tambm podemos oferecer oportunidades de negcio. Uma
oportunidade de negcio alguma funcionalidade no prevista pelo cliente, mas que sabemos
ser possvel implementar. Devemos ter muito cuidado com oportunidades de negcio, pois
elas podem ser, na verdade, falsos requisitos. Um exemplo tpico a proliferao de
relatrios em sistemas que na prtica usam apenas alguns.
Uma oportunidade de negcio deve ser exaustivamente discutida com o cliente de
forma a ficar claro que ela realmente traz benefcios, que esses benefcios so considerveis,
que o risco do projeto no aumenta muito e que ela ser realmente utilizada.
Um exemplo que podemos dar , em um controle de estoque, a funcionalidade de
prever que produtos esto prximos de sua data de vencimento. Essa no uma funo
normal de sistemas de estoque. Exige um custo adicional no s de desenvolvimento, mas
tambm de operao, como identificar a data de vencimento, controlar diferentes datas para
um produto, etc. Em muitos contextos, essa funo pode parecer interessante mais ser, na
prtica, intil. Em uma oficina mecnica, por exemplo, ela pode ser totalmente intil. Em um
grande mercado, ela pode ser bastante til. Porm em um pequeno mercado, onde o
proprietrio tem na verdade um controle mental do estoque e precisa do sistema de estoque
apenas para fazer um controle legal ou financeiro, essa funcionalidade pode parecer til a
princpio, mas nunca ser usado no dia a dia.
As oportunidades devem produzir resultados teis para a empresa, como acelerar
processos, eliminar passos desnecessrios, reduzir erros na entrada e sada de dados,
aumentar a integrao entre sistemas, aumentar a satisfao do usurio e facilitar a interao
com os parceiros externos da organizao (fornecedores, representantes e clientes). [B15]

60

V.6 Metas e suas mtricas

Enquanto o objetivo define o que far o sistema, as metas justificam a sua existncia
para o negcio.
Uma meta um efeito positivo no negcio do cliente que esperado com a
implantao do novo sistema. Metas so benefcios trazidos pelo novo sistema ao negcio.
A anlise das metas permite ao cliente verificar qual a relao custo/benefcio da
implantao de um novo sistema. Baseado nas metas o cliente capaz de fazer uma avaliao
econmico-financeira, comparando o preo do sistema, ou melhor, ainda, com o custo total
de propriedade (TCO Total Cost of Ownership) do sistema, com o valor equivalente dos
benefcios trazidos pelo sistema.
Por exemplo, um sistema que transforme um trabalho de 1 hora por dia de uma pessoa
que ganha R$ 10,00 por hora para 15 minutos, poupa R$ 7,50 por dia. Isso corresponde a
aproximadamente R$ 165,00 por ms, ou ainda R$ 1980,00 por ano. Como se admite que um
investimento tenha retorno em dois anos, o benefcio total causado apenas pela acelerao do
processo, em dois anos, seria de R$ 3960,00. Caso esse fosse o nico benefcio do sistema,
esse valor seria ento um limite superior para o TCO.
O uso de metas para nortear o desenvolvimento de sistemas uma proposta diferente
das tradicionais, porque as metas no esto relacionadas a funcionalidades do sistema, mas
sim aos resultados obtidos quando inserimos o sistema novo no ambiente.
Assim, devemos definir metas que possam ser verificadas quando o sistema for
instalado. Cada meta vir acompanhada de uma mtrica, uma medida objetiva que permite
comprovar que a meta foi alcanada. Metas que no possuem mtricas objetivas, como
"satisfao do cliente", devem ser evitadas ou devem ser associadas a um instrumento de
medida que permita verificar conceitos subjetivos, nesse caso uma pesquisa de opinio.
Ao implantar um sistema de atendimento automtico, poderamos ter como metas:

Acelerar o atendimento, com a mtrica tempo mdio de atendimento.

Diminuir o tamanho das filas, com a mtrica tamanho mdio da fila.

Para cada para par meta - mtrica, podem ser necessrios um procedimento de medida
e um procedimento de levantamento de dados passados. Isso no uma prtica comum no
desenvolvimento de sistemas, porm algo desejvel.
A principal vantagem de associar ao sistema metas que no fazem parte dos requisitos
demonstrar a sua utilidade, isto , como o sistema far o cliente ganhar mais dinheiro ou
realizar melhor sua tarefa.
Devemos tomar cuidado, porm, com as armadilhas que existem na escolha das
metas. Primeiro, muito comum que um cliente deseje uma meta que no pode ser alcanada
por um sistema com o objetivo definido. A questo, nesse caso, se resume a negociar a
mudana da meta ou negociar a mudana do objetivo. Como exemplo, podemos citar o caso
de um cliente que desejava um sistema de controle de pedidos para os fornecedores baseado
em pedidos de clientes e desejava que o sistema diminusse o prazo de entrega para os
clientes. Analisado o funcionamento da empresa, comprovamos que era impossvel acelerar o
prazo meramente controlando os pedidos. Era possvel, porm, fazer uma previso mais
acertada do prazo de entrega e estar preparado para atrasos, mediante o acompanhamento dos
pedidos.

61

Outra armadilha ter uma meta que afetada por muitas coisas alm do sistema. Em
um caso simples, tnhamos a proposta de um sistema de reservas de hotel que se propunha a
aumentar a ocupao dos quartos. Ora, o nvel de ocupao dos quartos de um hotel depende
de muitos fatores, inclusive da economia geral. Entendemos que o sistema poderia ter como
meta, por exemplo, diminuir o nmero de reservas no cumpridas. Essa meta mensurvel
e pode ser diretamente influenciada pelo sistema (por meio de verificaes com o cliente, por
exemplo). interessante notar que a meta selecionada um dos fatores que afeta a meta
proposta inicialmente. Essa outra armadilha comum, escolher uma meta (e uma mtrica)
que na verdade derivada da meta (e da mtrica) que o sistema tem condies de atingir.
Se no possvel nenhuma medida, no ser possvel tambm saber se a meta foi
alcanada, o que a torna suprflua.
V.6.1

Metas subjetivas
possvel que sejam definidas metas no mensurveis de forma objetiva. Isso pode
ser resolvido por meio de avaliaes subjetivas.

Por exemplo, uma meta comum melhorar o atendimento ao usurio. Essa meta
pode, em alguns casos, ser transformada em outra meta, como diminuir o tempo de
atendimento, diretamente mensurvel. Mas tambm pode ser medida por meio de
entrevistas, com avaliaes subjetivas, ou observao do servio.
V.6.2

Levantando Objetivos e Metas

A melhor maneira de levantar objetivos e metas entender simultaneamente: o que o
cliente deseja, o que est funcionando agora, quais os problemas atuais e quais oportunidades
existem para um novo sistema.

As entrevistas iniciais para levantamento de necessidades de informao so

geralmente feitas com executivos. Um bom conjunto inicial de questes que podem ser feitas
apresentado a seguir (sugeridas em Gillenson & Goldberg):

Quais seus objetivos?

Quais suas responsabilidades?

Que medidas voc usa?

Que informaes voc precisa?

Quais so seus problemas de negcio?

Que mudanas voc v no futuro (que vo impactar a infra-estrutura do seu

negcio)?

Quais so os fatores crticos de sucesso?

Qual a informao mais til que voc recebe?

Como voc classificaria as informaes que recebe quanto adequao,

validade, durao, consistncia, custo, volume, etc.?

Alguns pontos podem ser notados sobre essas perguntas. A pergunta sobre objetivos
muitas vezes pode no ser muito bem respondida, assim a segundo pergunta, sobre
responsabilidades, permite uma resposta mais prtica e mais fcil de ser dada. A terceira
pergunta visa buscar uma compreenso sobre os dados importantes para o entrevistado,
abrindo uma seqncia de perguntas sobre o tema. A quinta pergunta, sobre os problemas de
negcio, a mais importante do conjunto e deve ser dada a maior ateno e quantidade de
62

tempo disponvel. interessante que o problema seja estruturado em um formato causaefeito, por exemplo: "por causa da falta de dinheiro, o resultado que no possvel comprar
peas de reposio". Tambm importante verificar se a causa primordial do problema um
processo ou um dado. Alm disso, o entrevistador deve tentar obter alguma informao de
valor (financeiro) sobre o impacto do problema, seja em valores absolutos ou relativos,
objetivos ou subjetivos.
V.6.3

Metas em sistemas novos

Em nossa definio de metas falamos sobre a melhoria do negcio do cliente. Mas o
que acontece quando o negcio ainda no existe? Como definir uma melhoria nesse caso?
Claramente, temos que mudar nossa definio nesse caso. O melhor abandonar o
conceito de melhoria, ou seja, um conceito relativo, por um conceito absoluto, como um
objetivo de negcio. Assim, em vez da meta ser Diminuir o tempo de atendimento ao cliente
para 2s, passaria a ser Atender o cliente em 2s.
Devemos notar que, nesse caso, as metas ficam iguais a requisitos no funcionais.

V.7 Os Requisitos Preliminares

importante registrar todos os requisitos que forem percebidos durante essa fase
inicial do contato com o cliente. Esses requisitos aparecem informalmente, mas devem ser
anotados diligentemente, pois talvez sejam at mesmo esquecidos por parte do cliente (o que
no garante que sejam menos importantes, apesar de ser um indicativo).
V.7.1

Definindo o Escopo
Uma boa estratgia complementar a especificao dos requisitos preliminares a
definio do escopo por meio de uma lista Dentro/Fora (in/out list) [B16]. Essa lista
simplesmente uma tabela contendo tpicos e a indicao se aquele tpico est dentro ou no
do escopo do sistema.

63

Escopo do Sistema
Tpico

Dentro

Receber pedido do cliente




Enviar nota fiscal

Atender
parcialmente
Analisar crdito

Fora

pedido 


Tabela 4. Exemplo de uma tabela de definio de escopo.

V.7.2

Documentando os requisitos iniciais

No Error! Reference source not found.discutimos como levantar e descrever os
requisitos de um sistema. Esses requisitos, mesmo em forma informal e superficial, devem
ser levantados j nessa fase inicial.

O uso de cartes para cada requisito uma abordagem interessante, pois permite a
manipulao dos mesmos de vrias formas, como comparao, correo e priorizao.

V.8 O sistema atual

Uma das tarefas mais importantes compreender, perfeitamente, como funciona o
sistema atual. Desprezar o sistema atual, por mais antigo ou mal feito que ele seja, um dos
erros mais freqentes dos desenvolvedores. S podemos criar um sistema novo aps conhecer
perfeitamente o sistema atual, como funciona e porque funciona dessa forma.
Idealmente, deveramos recuperar o Modelo Ambiental do sistema atual. Isso,
porm, nem sempre possvel, devido s presses de tempo e custo que sofremos na vida
real. Uma descrio em portugus pode ser bastante satisfatria para sistemas pequenos. Para
sistemas maiores pode ser necessrio indicar outras fontes de obteno de informao, como
manuais existentes e os prprios programas.
Nesse ponto nossa abordagem bem diferente da abordagem essencial tradicional
[B17], que defende a criao de um modelo da encarnao atual. Entendemos que o tempo e
esforo necessrios para levantar o sistema atual de forma detalhada, para depois transformlo em um novo sistema, com requisitos bastante diferentes, podem inviabilizar um projeto.
Assim, normalmente por presses do negcio, somos obrigados a tratar cada projeto segundo
a metodologia essencial para derivar sistemas novos. Temos de nos perguntar se vlido
documentar um sistema obsoleto para implementar um sistema novo. A resposta essencial
sim, pois no envolve o clculo de custos. A resposta prtica, baseada na experincia real de
levantar sistemas novos para substituir sistemas j existentes no. No temos tempo,
recursos ou pessoas para isso.
V.8.1

Problema do sistema atual

Aps o levantamento do sistema atual, devemos apontar, baseado nas reclamaes
dos clientes e em nossas observaes, quais so os problemas do sistema atual.

64

Novamente importante lembrar que os problemas de negcio so mais importantes

que os problemas tcnicos. Muitas lojas hoje em dia utilizam sistemas feitos em MS-DOS10
porque eles atendem perfeitamente seus requisitos de negcio.
Os problemas atuais, principalmente quando relacionados ao negcio, podem ser os
principais fornecedores de metas para o sistema. Assim, se o problema for lentido, o
aumento do desempenho uma meta importante. Da mesma forma, se o problema for a
dificuldade de utilizao, a meta pode ser facilitar a utilizao do sistema e as mtricas
podem estar relacionadas ao tempo de aprendizado ou ao nmero de erros na entrada de
dados.

V.9 Viso do novo sistema

Devemos tentar responder como vai funcionar o novo sistema em uma descrio
simples, em linguagem corrente. Chamamos essa descrio de Viso do novo sistema. Essa
viso deve ser escrita com forte apoio do cliente, seno pelo prprio cliente.
Normalmente a Viso e a descrio do sistema atual tm o mesmo nvel de abstrao
dentro de uma mesma proposta inicial.
A viso pode incluir o prottipo de algumas telas do novo sistema, com a finalidade
de mostrar a diferena do sistema novo para o velho ou ainda mostrar como ser o
comportamento de uma nova finalidade.
A viso do sistema pode incluir no s o funcionamento do sistema, mas tambm
expectativas de comportamento e de efeitos do sistema no negcio. Deve ficar claro que a
viso do sistema uma declarao do usurio, no necessariamente um comprometimento do
desenvolvedor. Isso, porm, deve ficar claro na documentao.
A viso do sistema inclui tambm os requisitos j detectados, informalmente, pelo
analista. Como descrito no captulo anterior esses requisitos podem ser divididos em
requisitos funcionais, requisitos de informao e requisitos no funcionais. Obviamente s
estamos interessados em requisitos verdadeiros.
V.9.1

Oportunidades para o novo sistema

Devemos incluir em nossa proposta oportunidades que detectamos a partir do nosso
conhecimento do que factvel atualmente ou em futuro prximo.

As oportunidades que detectamos para um novo sistema esto normalmente ligadas a

novas tecnologias ainda no utilizadas pelos clientes.
V.9.2

Pontos Crticos ou Pontos Chave

Os pontos crticos (ou chave) de sucesso para um projeto so aquelas questes que,
no estando diretamente relacionada ao desenvolvimento propriamente dito, so essenciais
para o bom andamento do projeto.

Exemplos: compromisso de certos funcionrios, fornecimento de certa informao,

chegada de alguma mquina ou software, compromisso de entrega de dados ou equipamentos
pelo cliente, etc.
Os pontos crticos devem ser levantados detalhadamente, pois os compromissos do
desenvolvedor s podero ser cumpridos caso sejam resolvidos satisfatoriamente.
10

Sistema operacional simples antecessor do Microsoft Windows.

65

V.9.3

Restries
Muitos sistemas tm restries, que devemos considerar em nossas propostas. Um
tipo importante de restries so as exigncias de implementao, como banco de dados,
linguagem, sistema operacional, etc.

Quanto mais cedo forem detectadas as restries, mais cedo o analista evitar que haja
desperdcio de recursos pela equipe de desenvolvimento.

V.10

Construindo um Glossrio

Uma das atividades mais importantes da anlise compreender o domnio da

aplicao. Essa compreenso s pode acontecer se o analista souber o significado exato das
palavras tpicas do negcio do cliente. Assim, desde o incio da anlise o analista deve
construir um glossrio, ou seja, um dicionrio especializado nos termos do negcio do
cliente.
No podemos enfatizar demais a importncia de aprender a linguagem do negcio do
cliente. Isso no s facilita a comunicao como d ao cliente uma confiana maior no
analista.

V.11

Proposta Comercial

Se necessrio, a proposta inicial se encerra com os termos comerciais sendo propostos

ao cliente, incluindo preo, tempo de desenvolvimento, formas de cobranas, etc.
de praxe no mercado, apesar de no recomendado, o cliente aceitar uma proposta e
dispensar a assinatura de um contrato ou discutir os termos legais do contrato enquanto se
inicia o trabalho de anlise.
V.11.1

Calculando Preo e Custo

Antes de comear essa discusso, devemos deixar clara a diferena entre preo e
custo: preo o que cobramos para fazer um sistema, custo quanto gastamos para
desenvolv-lo.

No razovel ensinar como calcular o preo de um sistema em um curso de anlise,

pois esse um problema de mercado, no um problema de desenvolvimento de sistemas. O
que um analista pode fazer calcular o custo de desenvolvimento11 de um sistema.
Apenas no final de um projeto temos certeza absoluta do custo que tivemos para
desenvolv-lo. At l, o que podemos fazer levantar, de forma mais ou menos educada, uma
previso de custos para o projeto. Essa previso deve ser atualizada constantemente enquanto
o projeto caminha.
Devemos compreender que o grande fator de custo no desenvolvimento de um
software a mo de obra. Normalmente esse custo levantado em homem-hora ou homemms. O uso dessa mo de obra proporcional12 a complexidade do projeto, fruto de seu
tamanho e de suas exigncias operacionais ou funcionais.
Existem vrias tcnicas de previso do tamanho de um sistema. No captulo Qual o
tamanho do software estudaremos algumas dessas tcnicas. Na prtica, porm, devemos
11

E ainda implantao, manuteno e operao.

12

De forma exponencial

66

compreender que a maioria das empresas ainda as desconhece ou no as implementa. Nesse

caso, elas acabam utilizando a experincia de seus funcionrios para, informalmente, fazer
previses que normalmente se mostram pouco acuradas.
Quanto ao preo, podemos fazer algumas observaes. A primeira que no h
necessariamente uma relao direta entre custo e preo. Apesar de muitas empresas de
desenvolvimento fazerem uma previso de custo e calcularem o preo em cima dessa
previso, usando margens de lucro e de risco previamente acordadas, o verdadeiro preo vem
do valor de mercado do produto, ou ainda do ganho previsto. Isso pode inclusive ser uma boa
oportunidade de negcios. Muitas empresas, ao perceberem que um produto especfico vai
dar um lucro direto ao seu cliente, propem fazer esse produto de graa em troca de um
percentual sobre o lucro. Em longo prazo isso pode ser altamente vantajoso para a empresa de
desenvolvimento, enquanto que para o cliente pode ser a nica forma de conseguir um
sistema que exigiria um investimento inicial muito alto para seu caixa.

V.12

O Resumo Executivo

O resumo executivo deve permitir que o leitor tenha uma viso completa do texto do
documento em uma pgina. Resumos executivos tm esse nome por partir da hiptese que
um executivo, ao tomar uma deciso, no tem tempo para ler longos documentos. Na prtica
eles leriam o resumo executivo e folheariam os documentos.

Se voc nunca fez anlise de sistemas, essa proposta pode parecer

difcil demais. Isso acontece porque para fazer a proposta inicial
devemos fazer, de maneira extremamente simplificada, uma anlise
de sistema.

V.13

Estrutura da Proposta Inicial

Uma proposta de trabalho pode se configurar de vrias formas, em funo de que

pontos desejamos ressaltar ou em que ordem desejamos apresent-la. A seguir apresentamos
uma estrutura possvel para uma proposta inicial que uma empresa de desenvolvimento de
software poderia fazer para um cliente.

Resumo Executivo

Apresentao do Documento

Identificao do Projeto
o Objetivo13
o Identificao do Cliente
o Identificao do Prestador de Servio
o Histrico do Apresentador de Servio

Proposta Tcnica
o Pequena Descrio da Solicitao do Cliente

13

O Objetivo do projeto implementar o sistema, que tem um objetivo para cumprir no negcio.

67

o Descrio Sucinta do Sistema Atual

o Stakeholders
o Identificao de Problemas
o Descrio do Sistema Proposto

Objetivo do Sistema

Objetivos de Negcios e Interesses

Metas

Mtricas para avaliao das Metas

Escopo

Viso

Requisitos Funcionais Iniciais

Requisitos de Informao Iniciais

Requisitos No Funcionais Iniciais

Pontos Crticos

Restries

Glossrio

o Identificao de Oportunidades

Proposta Comercial
o Cronograma Proposto
o Investimento Proposto14
o Exclusividade
o Forma de pagamento
o Reajustes
o Renegociao
o Confidencialidade
o Outras Clusulas (opcionais)

V.14
V.14.1

Exerccio
Projeto 1: Livraria ABC
Faa uma proposta inicial para a Livraria ABC.

V.14.2

Projeto de curso
Os grupos devem fazer uma proposta inicial, de acordo com o item V.13 e apresentla ao professor para discusso e aprovao.
14

Sutilmente, o preo do sistema proposto como investimento, o que de fato verdade na viso da empresa
contratante.

68

69

Captulo VI. Modelo de Negcio

The sciences do not try to explain, they hardly even try to interpret, they mainly make models. By a model is meant a
mathematical construct which, with the addition of certain verbal interpretations, describes observed phenomena. The
justification of such a mathematical construct is solely and precisely that it is expected to work.
John Von Neumann
Organograma
Funes de Negcio
Processos de Negcio
EPC
Diagrama de Atividades
Regra de Negcio

A Modelagem de Negcio no faz parte da modelagem essencial ou da modelagem

estruturada, mas cada vez mais vem sendo usada como uma ferramenta principal ou de
auxlio do processo de desenvolvimento de software, visando o levantamento completo dos
requisitos do sistema.
Nesse captulo trataremos de diferentes formas de modelagem de negcio:

Organograma15

Modelagem de Funes de Negcio

Modelagem de Processos

Modelagem de Regras de Negcio

Um organograma uma descrio da organizao de uma empresa, amplamente

divulgada, descrevendo as reas da empresa e as hierarquias entre elas. O Organograma
ferramenta essencial na compreenso de uma empresa e suas linhas de poder.
A modelagem de funes de negcio permite a compreenso do funcionamento da
empresa sem sofrer a interveno da forma de organizao da empresa. De certa forma, pode
ser desenvolvido como tanto como um modelo da encarnao do sistema atual como quanto
uma ferramenta de substituio ou complementao da anlise essencial.
A modelagem de processos demonstra como funciona a empresa, passo a passo, no
seu dia a dia. A partir dela pode ser possvel levantar os pontos a serem automatizados de um
processo e como os processos realmente realizados diferem dos processos normatizados da
empresa.
A modelagem de regras de negcio permite a compreenso da empresa de forma mais
detalhada que os modelos anteriores. As regras de negcio podem ser utilizadas para ajudar a
levantar o modelo essencial, o modelo conceitual de dados, ou para ajudar a implement-los.
Em alguns mtodos, pode at mesmo ser utilizada no lugar desses modelos.

15

O organograma uma das formas mais simples e antigas de modelar uma empresa.

70

Figure 22. Passos da Modelagem de Negcios adaptado de Ross e Lam

[B19].

VI.1 O Organograma
Organogramas descrevem cargos, por meio de retngulos, e linhas hierrquicas, por
meio de linhas. Alguns autores utilizam uma notao levemente mais complicada com o
objetivo de descrever diferenas sutis em uma organizao.
Em geral o analista no precisa levantar o organograma, pois a empresa j o possui,
mas comum que haja algumas mudanas. importante tambm levantar no s a hierarquia
de cargos, mas tambm quem ocupa cada cargo, principalmente para apoio s tarefas de
anlise.
A importncia de conhecer o organograma da empresa se reflete tanto na modelagem
propriamente dita, pois ele fornece a descrio da empresa que ser convertida objetos do
modelo, como no processo de modelagem, pois a partir do organograma temos o
conhecimento de cargos e responsabilidades, definindo pessoas a serem entrevistadas.

71

Conselho
Administrativo

Presidente

Diretor
Comercial

Gerente de
Grandes Clientes

Diretor de
Produo

Gerente de
Vendas

Gerente de
Fbrica

Diretor
Administrativo

Gerente de
Logstica

Gerente de
Recursos
Humanos

Gerente
Financeiro

Figura 23. Um exemplo de organograma simples, contendo apenas

cargos.

Um organograma pode ser utilizado para representar diferentes formas de

subordinao, como a subordinao direta (onde o subordinado deve cumprir as ordens de
seu chefe), a assessoria (onde o assessor fornece conselhos e pareceres) e a subordinao
funcional (onde o superior pode determinar funes e mtodos a outras reas). Normalmente
a subordinao direta representada por uma linha cheia vertical, a assessoria por uma linha
cheia horizontal e a subordinao funcional por uma linha pontilhada.
Ao levantar o organograma, pode ser interessante tambm levantar as descries dos
cargos, se elas existirem (o que no comum, principalmente em pequenas e mdias
empresas).

VI.2 Nveis de Abstrao e Modelos

Neste captulo estudaremos modelos que foram projetados para trabalhar com
diferentes nveis de abstrao.
Para melhor compreender essa noo, vamos entender primeiro o que um modelo:
todo modelo uma abstrao de algo que existe ou se imagina que possa existir no mundo
real. Abstrao o processo mental de separar um ou mais elementos de uma totalidade
complexa de forma a facilitar a sua compreenso por meio de um modelo.
No nosso dia a dia utilizamos a abstrao para poder trabalhar com toda a informao
que o mundo nos fornece. Um mapa, por exemplo, um modelo de uma cidade. Dependendo
da informao que queremos, colocamos alguns smbolos e tiramos outros do mapa. Um
mapa tambm no pode ser perfeito, tem que abstrair as informaes que no so
necessrias naquele instante, ou teria que ter o mesmo tamanho da cidade.
Podemos usar mapas com diversos graus de detalhe, ou seja, mais ou menos abstratos.
Um globo terrestre, por exemplo, um mapa muito abstrato. Geralmente com o objetivo de
ensinar noes bsicas de geografia. J uma carta nutica um mapa muito detalhado, que
permite a navios ou barcos menores navegarem de forma segura em uma regio. Ainda mais
detalhada ser a planta de uma casa ou prdio. Os nveis de detalhe so infinitos e so usados
de acordo com a necessidade do problema a ser resolvido.

72

900mm

900mm
4775mm

(a) Globo Terrestre16

(b) Mapa Antigo17

(c) Planta baixa decorativa

Figura 24. Diferentes tipos de mapas, ou seja, modelos, cada um com

um nvel diferente de abstrao e dedicado a uma utilizao distinta.

VI.3 Funes de Negcio

As funes de uma instituio so os grupos de processos que gerenciam um recurso
bsico da organizao [B20] Elas descrevem o que a organizao faz, devendo estar de
acordo com os objetivos da empresa.
Funes de negcio mantm a organizao em operao, formando um conjunto de
atividades (processos) relacionadas que tem como objetivo alcanar a misso ou objetivos da
empresa.
Segundo Modell [B4] uma funo deve:

Ser identificvel

Ser definvel, por si s e em termos das atividades e responsabilidades

associadas.

No necessariamente ser mensurvel (o que influenciado pelo seu grau de

abstrao);

Alm disso, ainda segundo Modell, uma funo pode:

Ser uma rea principal de controle ou atividade da organizao

Ser composta de uma ou mais subfunes

Ser realizada em uma ou mais reas18

16

Images copyright 2000 by Cartography Associates. Images may be reproduced or transmitted, but not for
commercial use. For commercial use or commercial republication, contact carto@luna-img.com. This work is
licensed under a Creative Commons License.
(http://creativecommons.org/licenses/by-nc-sa/2.0/).

17

Images copyright 2000 by Cartography Associates. Images may be reproduced or transmitted, but not for
commercial use. For commercial use or commercial republication, contact carto@luna-img.com. This work is
(http://creativecommons.org/licenses/by-nc-sa/2.0/).
licensed under a Creative Commons License..

18

No h necessariamente um mapeamento direto entre funes e o organograma

73

Ser realizada por um indivduo, um grupo, grupos de grupos, reas da

organizao ou at por toda a organizao.

Envolver um ou mais atividades distintas, sejam elas dependentes ou

independentes.

Ser identificada e definida mesmo que no seja executada.

Tambm possvel entender dois tipos de funes: as de negcio, ou seja, aquelas

presentes na cadeia de valor da empresa e que tm relao com o aspecto operacional do
negcio, e as de administrao (ou suporte).

VI.4 Modelagem de Funes com IDEF019

IDEF0, Integration Definition Language 0, ou Integration Method for Function
Modelling [B21] uma forma de representar sistemas, desde mquinas especficas at
grandes empresas, por meio de uma rede de funes interconectadas e interfaces entre essas
atividades. Esses modelos representam funes do sistema, relacionamentos funcionais e
dados que suportam a integrao do sistema.
Segundo o padro IFIPS 183, um modelo IDEF0 composto por uma srie
hierrquica de diagramas que apresentam, gradativamente, um nvel maior de detalhe,
descrevendo funes e suas interfaces no contexto de um sistema..... A descrio a seguir
fortemente baseada e algumas vezes a traduo literal do padro IFIPS 183.
O IDEF0 pode ser feito em vrios nveis de abstrao. Podemos descrever as funes
de uma empresa, como receber pedidos ou produzir encomendas; ou podemos descrever
as funes de uma pequena mquina, como medir temperatura.
A caracterstica mais importante do IDEF0 que ele no descreve como as coisas so
feitas e tambm no d nenhuma ordem. Ele apenas define as responsabilidades, ou, de certa
forma, os requisitos funcionais de um sistema, isto , que funes devem ser feitas e qual a
interface de cada funo. Assim, quando precisarmos descrever passos seqenciais,
algoritmos ou outros detalhes, devemos usar outro modelo.
VI.4.1 Sintaxe do IDEF0
Os componentes da sintaxe de IDEF0 so diagramas (formados de caixas, setas,
linhas), textos e glossrios.
As funes, definidas como atividades, processos ou transformaes, so
representadas por caixas, que so conectadas uma s outras por meio de setas com
significados distintos, representado dados ou objetos relacionados a cada funo, como na
20
Figura 25. Todas as caixas e conectores so rotulados, sendo que um dicionrio deve ser
usado para definir detalhadamente cada rtulo. Todas as caixas devem tambm receber um
nmero (no canto inferior direito).
Diagramas IDEF0 so construdos de forma hierrquica, a partir de um diagrama
inicial, chamado A-0 (A menos zero)21 que sempre contm uma nica atividade, numerada 0,

19

Algumas imagens dessa seo no so originais, porm fazem parte de um documento (IFIP 183) em domnio
pblico (obra do governo americano).

20

A metodologia IDEF0 derivada de uma metodologia anterior conhecida como SADT.

21

O processo inicial sempre o A-0, no existindo um processo B-0 em nenhum caso. A letra A vem de atividade.

74

a partir do qual so feitos detalhamentos22 sucessivos. Cada detalhamento representado por

outro diagrama, contendo atividades interligadas, permitindo uma compreenso top-down do
processo sendo descrito. O mtodo limita o nmero de subfunes para uma funo entre 3 e
6.
O mtodo IDEF0 no representa a seqncia de atividades no tempo, apenas as
interaes entre as atividades. Ele pode ser usado tanto para representar processos j
existentes quanto para representar processos novos. No primeiro caso se sugere uma
estratgia de construo bottom-up, no segundo caso a estratgia top-down pode ser mais
apropriada.
A funo de cada uma das setas dada pelo seu posicionamento ao redor da caixa da
atividade, como descrito na figura a seguir.

Entradas (setas entrando pela direita) so dados ou objetos que so transformados ou

consumidos na sada pelo processo.

Controles (setas entrando por cima) so condies necessrias para produzir a sada
correta, podendo ou no ser transformados na sada. Controles so restries na operao
do processo.

Uma sada (setas saindo pela esquerda) apresenta um resultado do processo, um artefato
ou informao criada ou transformada por ele.

Os mecanismos ou recursos (setas entrando por baixo) so os meios necessrios para a

realizao da funo, porm no so consumidos para produzir a sada.

possvel que uma seta saia da parte de baixo do diagrama. Isso indica uma chamada de
funo, que na verdade representa que o processo chamador explicado pelo processo
chamado.

Figura 25. Um processo em IDEF0 e suas entradas e sadas.

22

Tambm conhecidos informalmente como exploses.

75

Figura 26. Exemplo, em um fragmento de IDEF0, dos usos de controles e

entradas.

Algumas regras sintticas:

Diagramas so identificados (Node) na forma An, onde n um nmero.

O diagrama A-0 (A menos zero) contm s uma caixa (a caixa zero), que expandida no
diagrama A0 (A zero).

Pode existir, opcionalmente, um diagrama que coloque o diagrama A-0 dentro de um

contexto maior, chamado A-1 (A menos 1).

O nmero de um diagrama formado pelas iniciais do autor e um nmero seqencial.

Um diagrama por ser FEO (ver abaixo) ou conter apenas texto ou glossrio. Nesse caso, o
n recebe o seu identificador seguido respectivamente das letras F, T ou G.

Os diagramas so desenhados em formulrios padronizados (ver Figura 27)

Caixas denotam atividades, por isso devem ser ou conter verbos em seu nome.

Cada caixa numerada adicionando mais um nmero inteiro entre 1 e 6 (nmero mximo
de caixas em um diagrama) ao nmero da caixa pai.

As caixas dos diagramas so numeradas 1, 2, 3,...

As caixas so indicadas pelo nome do diagrama adicionadas do nmero da caixa (a caixa

1 do diagrama A1 se chama A1.1)

Quando uma caixa detalhada em outro diagrama, colocada uma referncia a esse
diagrama abaixo do canto inferior esquerdo. Essa referncia conhecida como DRE.

Cada caixa (funo) representada por um rtulo centralizado formado por um verbo ou
um verbo-objeto e um segundo rtulo, no canto inferior direito, representando a
identificao (nmero) do rtulo.

Caixas so retangulares com cantos arredondados.

76

Figura 27. Formulrio padro para um diagrama IDEF0

Figura 28. Um diagrama IDEF0 tpico em seu formulrio padro, Segundo

o software Allfusion Process Modeller (previamente BPWin)23

23

Cada diagrama deve conter todas as setas que entram e saem do seu diagrama superior,
que podem ser indicadas pela seguinte notao (conhecida como ICOM):

BPWin Methods Guide, Logic Works, Inc. 1997.

77

Controle: C1, C2, C3..., contados da esquerda para a direita na caixa explodida.

A cada reviso deve ser marcado um nmero de reviso (no diagrama, ver
NOTES 1 2 3...).

Figura 29. Exemplo de numerao ICOM e seu significado

Entradas: I1, I2, I3, contadas de cima para baixo na caixa explodida.

Sadas: O1, O2, O3, contadas de cima para baixo na caixa explodida.

Mecanismos: M1, M2,... contados da esquerda para a direita na caixa explodida.

Setas denotam objetos ou dados (por isso devem ser substantivos)

As setas s fazem curvas de 90, no apresentam inclinaes.

Setas no representam fluxo, mas sim como os dados e objetos necessrios para o
funcionamento de uma funo so obtidos.

Setas podem ser tuneladas. Isso significa que no apareceram no diagrama filho
de uma caixa, mas apenas em diagramas netos. Para tunelar uma seta coloque
parnteses em torno da ponta ou da raiz da seta (formando um tnel)

78

parent
diagram

parent
box

1
2
A12

3
A1

child
diagram

This arrow (position C2) is not

shown on child diagram.

C1
I1

C3
1
2
3

A12

O1
This output is not
shown connecting to
the parent box.

Figura 30. Exemplo de tunelamento e DRE (na caixa 2 do diagrama A1)

Uma seta pode ser dividida ou setas podem ser agregadas. Os segmentos
resultantes devem ser nomeados adequadamente para representar as partes. Por
exemplo, uma seta identificao de usurio e uma seta solicitao de servio
podem ser unificadas na seta solicitao identificada. O inverso tambm pode
acontecer.

Se uma seta contm dados e controles, ou se estamos incertos se contm controle

ou dados, devemos mostr-la como controle.

79

GRAPHIC

INTERPRETATION
A

means
A

means
A

means
Where B is a
portion of A

A&B

means
A

Figura 31. Fork e join no rotulados tm interpretaes padronizadas

Uma caixa possui

No mnimo 1 seta de controle

No mnimo 1 seta de sada

No mximo 1 seta de chamada

Zero ou mais setas de entrada e mecanismo

Informao de suporte pode ser colocada em um texto associado ao diagrama.

Abreviaes, jargo, etc., devem ser colocados em um glossrio (nico para o modelo).
This fork means that Files contains
Customer Records (needed by Function 2) and
Price & Tax Tables (needed by Function 3).

Tax
Requirements

This join means Account

Entries are created by
Deliver Products and
"Do Billings".

Files
KEEP
RECORDS
1

Customer
Records

Price & Tax

Tables

DELIVER
PRODUCTS
Ordered
Product

Account
Entries

Transactions
DO
BILLING

Account
Clerk

Invoices

Figura 32. Conexes entre caixas

80

parent
diagram

parent
box

1
2
A12
3

child
diagram

A1

This arrow is a control

on the parent box.

1
2
3
A12

This arrow is an output

on the parent box.
This arrow is an input
on the parent box.

Figura 33. Relacionamento entre diagramas, com exemplo de DRE na

caixa 2 do diagrama A1.

Diagramas apenas para exposio (FEO "for exposition only") podem ser usados onde
um nvel adicional de conhecimento necessrio para entender adequadamente uma rea
especfica do modelo.

Diagramas FEO no precisam seguir as regras de sintaxe do IDEF0

Diagramas FEO so numerados com um F no final de seu cdigo, ou seja, do cdigo que
teriam se fossem um diagrama normal.

Ao se referenciar a objetos do diagrama, a seguinte notao deve ser usada:

81

Notao de referncia para o IDEF0

Notao de Referncia

Significado

2I1

Caixa 2 Entrada 1

O2

A seta cujo cdigo ICOM O2 (Sada 2)

2O2 para 3C1 ou 2o2 para 3c1

A seta de 2O2 para 3C1 (I, C, O ou M podem ser

maisculas ou minsculas).

I2 para 2I3 para 2O2 para (3C1

e 4C2)

Da seta com cdigo ICOM I2 para a caixa 2, entrada

3, atravs da ativao da caixa 2 que fornece a sada
2, para a disponibilidade (por meio de um fork) dessa
sada como controle 1 na caixa 3 e controle 2 na
caixa 4.

A21.3C2

No diagrama A21 nesse modelo, veja o controle 2 da

caixa 3. O ponto significa olhe especificamente para.

A42.3

No diagrama A32, veja a nota de modelo 3.

A42.|3|

Notao opcional para No diagrama A32, veja a nota

de modelo 3, usando barras verticais em vez de uma
caixa para identificar a nota.

A42.3

No diagrama A42 desse modelo, veja a caixa 3.

MFG/A42.1

NO diagrama A42 do modelo MFG veja a caixa 1

Tabela 5. Notao de referncia para o modelo IDEF0, segundo IFIPS 183.

O padro IDEF0 pede que um modelo seja publicado como no formato dado na figura
a seguir.

Figura 34. Formato de publicao pedido pelo padro IDEF0

O tunelamento
Existem duas posies para colocar um tunelamento (na forma de parnteses): na
extremidade prxima a funo ou na extremidade prxima borda do diagrama:

82

Quando colocado em torno da extremidade conectada a funo, isso significa que

todas as sub-funes daquela funo presentes no diagrama inferior possuem, de forma
implcita, essa seta.
A seta pode ser retomada, se necessrio, nos diagramas de nveis mais baixos, sem
nenhum problema (ela pula um ou mais nveis do diagrama, do mais abstrato para o menos
abstrato).
Quanto colocado em torno da extremidade prxima a borda do diagrama significa que
essa seta existe implicitamente em todas as funes mais abstratas (diagramas superiores) que
a funo sendo descrita.
VI.4.2

Construo de um modelo IDEF0

Um modelo IDEF0 deve ser construdo normalmente da forma top-down, partindo do
mais abstrato para o mais detalhado. O mtodo top-down permite que nos preocupemos
primeiro com questes gerais do sistema, como a sua justificativa, que funes deve realizar
e, mais tarde, com sua realizao. Outra caracterstica importante a necessidade de delimitar
o escopo de anlise e descrio do sistema, o que tambm apoiado pela tcnica top-down do
IDEF0, j que ela exige que uma descrio abstrata do sistema tenha sua fronteira bem
definida, na forma de entradas, sadas, controles e mecanismos {Pierre Nancy, 2004 1998
/id}.

Um conjunto de diagramas IDEF0, conhecido como um kit IDEF0, tem que responder
a duas perguntas: para que serve o sistema e como ele funciona.
Objetivo
Para comear a modelagem IDEF0 o analista deve primeiro determinar e descrever de
forma clara qual o objetivo do modelo, em que ponto de vista as atividades sero descritas e
em que contexto isso feito. Isso funciona como uma especificao de requisitos do modelo
que est sendo feito. Quando o objetivo do modelo atingido, o modelo est completo.
Um objetivo possvel , por exemplo, identificar oportunidades para consolidar
funes j existentes de forma a melhorar o desempenho da organizao. Claro que esse
objetivo sofre de um excesso de linguagem de negcios que pode ofuscar sua verdadeira
utilidade. Normalmente devemos preferir termos mais diretos como identificar as funes da
organizao em busca de estud-las e propor um plano de melhoria de desempenho com
possvel reestruturao das mesmas.
Ponto de Vista
O ponto de vista descreve a perspectiva tomada na construo, reviso e leitura do
modelo, definindo, na prtica, os limites do modelo e como as atividades do sistemas sendo
descrito sero abstradas ou idealizadas. A partir de um ponto de vista controlamos o escopo
e o nvel de detalhe de um modelo IDEF0. O ponto de vista sempre nico, apesar das
sesses de modelagem inclurem normalmente diferentes participantes com mltiplos pontos
de vista.
Uma forma de imaginar um ponto de vista e melhor descreve-lo entender o IDEF0
como parte de um manual destinado a descrever o funcionamento do sistema para alguma
pessoa ou algum grupo no contexto do negcio.

83

Contexto
O escopo do modelo dividido em duas partes: a profundidade e a extenso. A
profundidade define o nvel de detalhe esperado do modelo. A extenso define as fronteiras
do sistema sendo analisado.
importante a definio inicial do contexto, mesmo tendo conscincia que ele pode
sofrer alteraes (intencionais) durante o curso do processo de modelagem.
O contexto representado fortemente no diagrama de contexto (A-0), principalmente
pela definio de fronteira do sistema indicada pelas entradas (incluindo controles) e sadas.
Regras gerais de construo
O mtodo sempre se inicia pela definio da caixa inicial (A-0) e sua expanso em um
diagrama de primeiro nvel (A0). A partir desse ponto, sempre que for necessrio expandir
uma funo ser criado outro diagrama filho, mantendo as seguintes regras {Pierre Nancy,
2004 1998 /id}:

Cada funo deve trazer algum valor agregado a suas entradas e controles.

Cada funo recebe um nome na forma verbo no infinitivo + objeto direto

Os sub-sistemas de uma funo devem suportar diretamente a funo.

Cada seta que entra ou sai de uma funo deve ser encontrada em seu
diagrama de expanso .

As setas podem entrar ou sair de uma ou mais funes

As setas pode ser divididas de forma a transportar parte de informao para

uma funo e parte para outra.

Em casos especiais as setas podem no aparecer em um diagrama superior, em

um processo conhecido como tunelamento, destinado a abstrair informaes.

Cada seta deve receber um nome ou um cdigo que a identifique unicamente.

Os mecanismos podem ser suprimidos se isso no afetar a compreenso do

modelo

S devem ser mencionados os elementos necessrios para o objetivo da

construo do modelo

As sadas indicam um valor agregado as entradas e controles, ou ainda

resultados colaterais, sub-produtos, ou dejetos dos processos.

A borda de um diagrama representa a borda da atividade expandida. Todas as

atividades so realizadas nas folhas, isto , na ltima atividade modelada
(mais detalhada). As atividades superiores so apenas abstrao que no
desempenham nenhum procedimento real.

Algumas heursticas interessantes para se usar durante a modelagem{Richard

J.Mayer, 1992 1999 /id}:

Questione as fronteiras.

Essa atividade cai dentro do escopo da atividade superior?

Esta atividade est conforme o escopo e o ponto de vista estabelecido no

projeto?

84

Observe os limites numricos do modelo (3 a 6 sub-funes por diagrama)

No procure sempre 6 atividade, descreve as atividades como elas aparecem

no mundo real.

Cuidado com excesso de ligao entre as atividades (teia de aranha), que

indica a falta de organizao dos nvel de abstrao das atividades

Passos da construo do modelo

A seguir, os passos a serem seguidos quando da construo de um modelo IDEF0:
1. Defina objetivo e motivao
2. Responda as seguintes perguntas
3. Por que o processo est sendo modelado?
4. O que esse modelo vai mostrar?
5. O que os leitores desse modelo podero fazer com ele?

Exemplo: Identificar as tarefas de cada funcionrio da loja,

entendendo como elas se relacionam em detalhe suficiente para
desenvolver um manual de treinamento

6. Desenvolva as questes que o modelo deve responder

Exemplos: Quais as tarefas do atendente?, Quais as tarefas do

arrumador?, Como os produtos circulam na loja?

7. Desenvolva o ponto de vista

8. Defina o escopo do sistema
9. D um nome ao sistema
10. Use um nome condizente com o escopo definido

Normalmente o nome de um sistema utiliza termos bastante genricos

11. Defina os ICOMs principais

12. Defina as sadas, incluindo as sadas que acontecem quando o processo no
acontece de forma satisfatria

Todas as sadas possveis do processo devem estar presente no modelo

13. Defina as entradas

As entradas devem ser processadas para gerar as sadas

Normalmente o nome de uma entrada no permanece o mesmo na

sada

Algumas vezes entradas recebem adjetivos como simples ou sadas

recebem adjetivos como verificada para demonstrar que apesar de
no haver uma modificao houve um processamento da entrada para a
sada.

14. Defina os mecanismos

15. Defina os controles
16. Lembre que todas as atividades possuem ao menos um controle
85

Controle existem na forma de regras, polticas, procedimentos,

padres, etc.

No caso de indeciso entre entrada e controle, modele como controle.

17. Numere as atividades e diagramas

18. Se necessrio, decomponha as atividades
19. Repita o processo de modelagem, mantendo a consistncia
20. Se necessrio, construa modelos FEO (apenas para informao)

Por exemplo, para indicar outro ponto de vista

Para ilustrar detalhes que no so suportados pela notao IDEF0

21. Controle o tamanho do diagrama a partir do escopo (principalmente

controlando a extenso do diagrama)
22. Controle a profundidade do diagrama a partir do detalhe necessrio para o
objetivo do modelo.

VI.5 Processos de Negcio

Processos de negcio so grupos de decises e atividades, logicamente relacionadas,
requeridas para o gerenciamento de recursos da empresa24.
Podemos entender processos de negcio como uma seqncia de passos e decises,
iniciadas em resposta a um evento de negcio, que alcana um resultado especfico e
mensurvel, tanto para o consumidor do processo como para outros interessados
(stakeholder).[B22] Alm disso, necessrio que identifiquemos instncias especficas dos
resultados.
No trivial identificar processos, pois eles acontecem dentro da organizao de
forma esparsa, provavelmente envolvendo diversas pessoas e departamentos. Tambm no
trivial representar processos, pois corremos vrios riscos, como fazer uma representao
muito complexa ou muito simples, ser impreciso ou utilizar o mtodo de forma errada.
Normalmente, sistemas de informao so utilizados para automatizar processos de
negcios. Pode ser necessrio, antes de fazer o levantamento de requisitos de um sistema,
levantar como funciona o processo onde ele est inserido ou que vai substituir.
Nesse tipo de modelagem estamos preocupados com a forma em que os processos so
executados dentro da empresa. Existem vrias formas de se tratar a descrio de processos
atualmente, variando em diferentes nveis de complexidade.
VI.5.1

Fluxogramas
Fluxogramas so provavelmente a forma mais tradicional de modelar processos.
Atualmente, fluxogramas so poucos utilizados, tendo sido substitudos por outras formas,
semelhantes, que foram criadas com a finalidade de evitar problemas comuns encontrados na
criao dos fluxogramas.

importante frisar que fluxogramas podem ser utilizados em vrios nveis do

desenvolvimento de sistemas. Seu uso mais comum, no passado, era na especificao de
24

Esta a definio do BSP

86

algoritmos, mas esta prtica est totalmente superada, sendo normalmente substitudo por
programas em linguagens de alto nvel. Seu uso na especificao de processos tambm est
em franca decadncia, nesse caso o que se v a sua substituio por diagramas mais
modernos (incluindo o uso de fluxogramas em diagramas de raia25).
VI.5.2

EPC
EPC a sigla em ingls para Event Driven Process Chain (Cadeia de Processos
Dirigida por Eventos). Esse mtodo parte simplificada do mtodo ARIS usada para
modelagem de processo e tem grande aceitao no mundo, estando muitas vezes associado
implantao de sistemas de ERP SAP/R3.

Nesse mtodo, um processo modelado segundo fluxo de eventos e funes.

As principais primitivas, descritas na figura abaixo, so:

25

Funes, que representam atividades, tarefas ou passos do processo que

precisam ser executadas. Funes so possivelmente iniciadas ou habilitadas
por eventos. Funes possivelmente geram eventos. Funes consomem
recursos, exigem gerenciamento, tempo, e ateno. Funes podem
representar:

Atividades tangveis

Decises (mentais)

Processamento de Informaes

Eventos, que representam situaes, ou estados do sistema, antes ou depois da

execuo de uma funo. Um evento pode ser uma pr-condio ou uma pscondio para uma funo. Um evento no consome tempo nem recursos por
si s.

Conectores Lgicos, que permitem a unificao e separao de fluxos segundo

os conceitos de E, OU ou OU-exclusivo.

Caminho, que indica que um passo descrito por meio de um diagrama

completo EPC.

swimlane diagrams

87

Tipo

Smbolo

Definio

Evento

Um Evento descreve uma ocorrncia

que causa um efeito (funo)

Funo

Uma funo descreve uma

transformao (uma mudana no
estado do sistema)

Conectores

Um conector estabelece conexes

lgicas entre eventos e funes

XOR
XOR

AND

OR

Fluxo

Um fluxo descreve uma relao

lgica ou temporal entre funes e
eventos

Caminho

Um caminho estabelece uma relao

entre processos.
Figura 35. Principais componentes de um EPC

A figura a seguir demonstra um diagrama EPC simples demonstrando parte de um

processo de recebimento de pedidos.
Pedido
Recebido

Digitar
Pedido

Pedido
Digitado

Verificar
Pedido

XOR

Pedido
Correto

Pedido
Incorreto

Figura 36. Exemplo de um EPC de um processo de recebimento de

pedidos.

Segundo a verso original de EPCs, sempre deveria haver um evento entre dois
processos. Atualmente permitido que uma seqncia de processos no tenha nenhum evento
entre eles.
De acordo com as regras sintticas para EPCs, possvel que um processo produza
um ou mais eventos simultaneamente, pelo conector E, ou no, pelos conectores OU ou OU88

EXCLUSIVO. J um evento s pode habilitar um grupo de processos simultaneamente, pelo

conector E, no sendo vivel que de um evento se tenha uma opo de caminho, no sendo
possvel a partir de um evento alcanar diretamente um conector OU ou OU-EXCLUSIVO.
eEPC
eEPC a sigla em ingls para Extended Event Driven Process Chain (Cadeia de
Processos Dirigida por Eventos). Nessa extenso possvel declarar mais algumas
informaes sobre o processo sendo descrito.
Esses elementos adicionais funcionam basicamente como comentrios ao processo
que est sendo documentado. Assim, depois de descrito o processo pelo mtodo no
estendido, colocamos sobre eles novos elementos documentando informaes como quem
realiza o processo, que informao utiliza, que produtos gera ou consome, etc...
Os principais elementos adicionais em um eEPC so:

Unidades Organizacionais, que representam departamentos envolvidos em um

processo.

Pessoas, que representam pessoas ou papis envolvidos em um processo.

Informao ou dados, que representam informao utilizada ou gerada em um

processo.

Produtos ou servios, que so gerados ou consumidos pelo processo.

Objetivos, que representam o motivo da realizao de um processo ou tarefa

Tipo

Smbolo

Unidade
Organizacional
Informao

Pessoa ou
Cargo

Fluxo de
Informao
Relaes
Organizacionais

Produto ou
Servio

Objetivo

Figura 37. Elementos complementares dos diagramas eEPC.

89

A seguir, apresentamos um exemplo de diagrama EPC para demonstrar os

usos dos elementos adicionais.
Pedido
Recebido

Vendas

Digitar
Pedido

Pedido

Pedido
Digitado

Dados de
Produto
Vendas

Verificar
Pedido
Pedido
XOR

Pedido
Correto

Pedido
Incorreto

Figura 38. Exemplo de eEPC

Formas diferentes dos diagramas

possvel desenhar os EPCes de diferentes formas. Uma dessas formas permite que
iniciemos apenas com as comunicaes entre unidades, como mostrado na figura a seguir.
Isto permite um conhecimento inicial do processo que pode ser muito til na sua discusso
durante reunies ou entrevistas.

vendas
solicitao
pedido
estoque

cliente
produto

produto
entregas

Figura 39. EPCe baseado apenas em unidades da organizao, observe

que nesse nvel so permitidos loops.

VI.5.2.1 EPC

e 5W2H
Um evento indica quando (when) algum processo, funo ou tarefa deve ser iniciado.
Uma funo ou tarefa indica o qu (what) deve ser feito.
90

Uma unidade organizacional indica quem (who) deve fazer.

Passos para construir modelos EPC/EPCe[B23]
Identifique os eventos que iniciam as funes, que servem como gatilhos para o
processo se iniciar. Normalmente vem de fora para dentro do processo.

VI.5.2.2

Identifique as funes do processo, associando-as aos eventos que as iniciam e sua

seqncia.
Decomponha as funes, verificando se so aes lgicas simples ou compostas,
executadas por uma ou mais pessoas (ou ainda um sistema de computador). Verifique
tambm se a funo uma transao isolada ou pode ser dividida em partes, se pode ser
interrompida em um momento especfico e se existe um evento que a interrompa ou que a
faa funcionar novamente.
Analise os eventos novamente, definindo-os e refinando-os se necessrio. Garanta que
so necessrios e suficientes para iniciar a funo. Analise se existem casos especiais nos
quais as funes acontecem ou no. Use operadores lgicos para montar as relaes entre os
eventos.
Identifique os eventos de finalizao e as sadas (tanto de material quanto de
informao). Procure identificar quem processos e pessoas no resto da organizao que
dependem do processo sendo analisado.
EPCs podem ser muito pequenos ou enormes, dependendo unicamente do tamanho do
processo que est sendo mapeado.
VI.5.2.3 Regras

de ouro de EPCs[B23]
No existem ns isolados

No existem loops

Funes e eventos tm apenas uma entrada e uma sada

Operadores lgicos contm vrios fluxos de entrada e um de sada, ou um

nico fluxo de entrada e vrios de sada.

Conexes entre operadores lgicos so acclicas.

Dois ns s podem possuir um nico link entre eles

Existe um evento inicial e um evento final

Eventos no tomam decises, logo s possuem uma sada.

VI.5.3

Diagramas de Atividade
O Diagrama de Atividade uma das formas que UML [B24] prope para modelar os
aspectos dinmicos de um sistema, sendo basicamente um tipo de fluxograma mostrando
como o controle flui entre atividades. Um diagrama de atividades tambm um tipo de
diagrama de transio de estados que permite a modelagem de concorrncia.

Em um diagrama de atividades, cada atividade modelada em um estado (activity

state). Atividades podem, eventualmente, ser detalhadas em aes (action states), que so
atmicas. No existe uma diferena na notao entre atividades e aes, ambas so
representadas pelo mesmo smbolo.

91

Atividade

Figura 40. Smbolo para uma atividade (com texto).

Quando uma atividade ou ao terminada, o controle passa imediatamente para o

prximo estado, o que indicado por meio de uma transao (seta). No diagrama, o fluxo
sempre se inicia em um estado inicial e termina em um estado final.

Estado
Inicial
Receber pedido

Atividades

Processar pedido

Enviar pedido

Transaes

Estado
Final

Figura 41. Um diagrama de atividades de UML simples (linear), indicando

as suas figuras bsicas.

Tambm possvel indicar a possibilidade de tomar caminhos diferentes em funo

de uma deciso. Isso indicado por um losango, sendo que cada caminho possvel deve
receber como rtulo uma expresso que indique a deciso (guard expression). O padro
tambm admite que no seja usado o losango (ver exemplo mais adiante), mas sim setas
saindo diretamente de um estado.

Processar pedido

Recusar pedido
[material disponvel]

[material no disponvel]

Enviar pedido

Figura 42. Fragmento de diagrama de atividade mostrando uma deciso

92

Outra caracterstica interessante de diagramas de atividade que permite a criao de

caminhos paralelos, e sua possvel sincronizao (fork e join).
Praparar entrega

Preparar Nota
Fiscal

Separar
produtos

Empacotar
entrega

Figura 43. Exemplo de caminhos em paralelo e sincronizao. Forks e

Joins devem ser balanceados, mas no necessariamente de forma
imediata como na figura.

93

Figura 44. Exemplo de diagrama de atividades descrevendo, em alto nvel,

o processo de definio de um plano de modernizao de software
legado, segundo a verso 1.5 do padro UML (maro de 2003).

VI.5.4

Diagramas de Raias
Qualquer diagrama que passe a idia de um fluxo de execuo, como um fluxograma
ou um diagrama de atividades, pode ser construdo dentro de um espao que modele alguma
partio dessas atividades. Normalmente o que se faz utilizar colunas (ou linhas) para
modelar os agentes que realizam a atividade especfica, dando a impresso de raias de
natao ao diagrama (swimlanes).

94

Figura 45. Exemplo de diagrama de atividades com raias

VI.6 Regras de Negcio

Uma regra de negcio uma sentena que define algum aspecto do negcio. Tem o
objetivo de afirmar a estrutura do negcio ou de controlar ou influenciar o comportamento do
mesmo. Regras de negcio so atmicas, isto , no podem ser quebradas[B26].
Regras de negcio so muito estudadas hoje em dia. A maioria dos importantes
autores americanos se reuniu em um grupo conhecido com Business Rule Group26, que
produziu alguns documentos [B26;B27] que forneceram a estrutura bsica que estamos
apresentando aqui. Todas as definies so ou verses dos originais em ingls.
26

Originalmente The Guide Business Rules Project

95

Uma regra de negcio pode ser de trs categorias.

VI.6.1

Declaraes Estruturais, um conceito ou a declarao de um fato que

expressa algum aspecto da estrutura da organizao. Podem ser termos
simples ou fatos relacionando esses termos. Normalmente so descritas por
meio de um diagrama de entidades e relacionamentos27.

Declaraes de Ao, que descrevem aspectos dinmicos do negcio, sendo

uma expresso de uma restrio ou de uma condio que controla as aes de
uma organizao.

Derivaes, a declarao de um conhecimento que derivado a partir de

outro.

Declaraes Estruturais
Inclui os termos de negcios e fatos relacionando termos.

VI.6.1.1 Definio

de Termos de Negcios
O elemento bsico de uma regra de negcio a linguagem utilizada para express-la.
A definio das palavras utilizadas nessa linguagem descreve como as pessoas pensam e
falam [B26].
Normalmente um projeto s comea realmente a progredir quando a equipe de
desenvolvimento compreende o discurso dos clientes. Para isso, nas primeiras entrevistas ou
reunies, feito um esforo para levantar um glossrio de termos, e, mais tarde, muitos
desses termos podem aparecer no Modelo Conceitual de Dados do sistema.
Um exemplo tirado de um sistema governamental:

Contribuinte: a pessoa fsica ou jurdica responsvel pelo pagamento de um imposto.

A definio de um termo muitas vezes envolve uma relao com outros termos, como
no exemplo acima.
Um termo pode ser um tipo (uma classe) ou um literal (uma instncia). No caso de
regras de negcio costumamos trabalhar principalmente com tipos. Um tipo especial de tipo
um sensor, que representa algo que detecta e reporta valores que mudam constantemente no
ambiente (mundo externo). Existe um sensor especial, o relgio, que relata a passagem do
tempo, cujo valor sempre o instante corrente (data e hora corrente).
Os termos definidos so reunidos em um glossrio e em um dicionrio de dado.
Declarao de Fatos
A partir dos termos, devemos construir sentenas que descrevam o negcio a partir
das relaes entre termos e da estrutura criada por essas relaes. Normalmente esses fatos
so caracterizados nas entrevistas e reunies, a partir de declaraes do cliente de como o
negcio funciona.
Fatos relacionando termos so bastante fceis de serem encontrados. Muitas vezes
encontramos primeiro um fato e depois analisamos o significado dos seus termos.
As declaraes estruturais podem declarar atributos, generalizaes ou participaes.
Uma participao, por sua vez, pode ser um papel, uma agregao ou uma associao
simples.
27

No sendo necessariamente igual ao modelo conceitual de dados, mas podendo fornecer elementos para esse.

96

Exemplos:
Tipo de Fato

Exemplo

Atributo

DRE um atributo de aluno

Generalizao

Aluno de graduao um tipo de Aluno

Papel

Um aluno pode ser representante de

classe

Agregao

Uma turma precisa ter alunos

Associao
simples

Um aluno deve fazer provas

Tabela 6. Tipos de Fatos e exemplos

Declaraes estruturais e o modelo de dados

Termos e fatos estabelecem a estrutura de um negcio. Esta estrutura normalmente
descrita em um modelo de dados. Assim, a maior parte do trabalho inicial com as regras de
negcio estruturais pode ser descrita por meio de um modelo de dados conceitual, tema
tratado no prximo captulo.
Exemplos
A seguir damos alguns exemplos de declaraes estruturais, para um sistema
acadmico imaginrio:
Alunos so pessoas matriculadas em um curso
Um Aluno de Graduao um tipo de Aluno
Um Aluno de Ps-Graduao um tipo de Aluno
Um Curso construdo por um conjunto de Cadeiras
Uma Cadeira ministrada por um Professor
Um Professor um tipo de Funcionrio
Durante um Perodo, Alunos podem se matricular em Cadeiras
VI.6.2

Declaraes de Aes (ou Restries)

Representam as restries ou condies que as instituies colocam em suas aes.
Podem aparecer por fora de lei, prtica de mercado, de deciso da prpria empresa ou ainda
outros motivos.

Exemplos:

Um aluno deve ter um DRE

Um aluno no pode se registrar em dois cursos que acontecem no mesmo horrio

Uma Declarao de Ao pode ser uma condio, uma restrio de integridade ou

uma autorizao. Uma condio diz que se alguma coisa for verdade, ento outra regra deve
ser aplicada (se - ento). Uma restrio de integridade uma declarao que deve sempre ser
verdade. Uma autorizao d uma prerrogativa ou privilgio a um termo, normalmente
permitindo que uma pessoa possa realizar uma ao.
Declaraes de aes podem ser de uma variedade de outros tipos. Recomendamos a
leitura de

97

Uma declarao de ao pode dizer que precisa acontecer (controle) ou o que pode
acontecer (influncia).
VI.6.3

Derivaes
So regras que mostram como transformar conhecimento em uma forma para outro
tipo de conhecimento, possivelmente em outra forma, incluindo leis da natureza[B27].
Geralmente so regras ou procedimentos de clculo ou manipulao de dados.

Exemplo:

O valor a ser pago do imposto predial 3% do valor venal do imvel.

A lista de devedores inclui todos os devedores a mais de dois anos.

VI.6.4

Regras e Eventos
Cada regra de negcio tem a possibilidade de ser violada em um ou mais eventos do
sistema.

A questo do que um evento ser respondida mais a frente nesse texto, no Captulo
VII. porm, no momento, basta entendermos que um evento algo que exige que alteremos
os fatos conhecidos pelo sistema (ou seja, um evento exige a alterao de algum dado na base
de dados) ou que consultemos esses fatos a fim de inform-los, de alguma forma processada,
ao usurio.
Analisando uma regra podemos ver que tipos de eventos so provveis de
necessitarem de alguma ateno do sistema. Por exemplo, suponha que um sistema de vendas
para uma empresa possua as regras[B28]:

Um aluno cliente solicita um produto

Um vendedor designado para atender um cliente permanentemente

A descrio acima faz com que nos perguntemos:

O que acontece quando um cliente faz seu primeiro pedido(e no tem ainda um vendedor
associado)?

O que acontece quando um vendedor se desliga da empresa.

Em todo evento, um conjunto de regras deve ser ativado e cada erro deve ser
reportado ao usurio.
VI.6.5

Descrevendo Regras de Negcio

Existem muitas formas de descrever regras de negcio, de acordo com o grau de
formalismo e a necessidade de execuo (ou compreenso por serem humanos) que
desejamos. A tabela a seguir define quatro formas bsicas de descrio.

98

Fragmento de
conversao de
negcios

Verso em linguagem
natural

Verso em uma
linguagem de
especificao de
regras

Verso em uma
linguagem de
implementao de
regras

Pode no ser relevante

Pode no ser atmica
Pode no ser declarativa
Pode no ser precisa
Pode ser incompleta
Pode no ser confivel
Pode no ser autntica
Pode ser redundante
Pode ser inconsistente

Relevante
Atmica
Declarativa
No totalmente precisa
Pode ser incompleta
Confivel
Autntica
Pode ser redundante
Pode ser inconsistente

Relevante
Atmica
Declarativa
Precisa
Completa
Confivel
Autntica
nica
Consistente

Executvel
Pode ser procedural

Tabela 7. Formas de descrever regras de negcio e suas caractersticas

adaptado de [B29].

Halle[B29] prope uma classificao e um conjunto de templates que pode ser

utilizado para descrever regras de negcio (aqui adaptado para portugus), apresentado na
tabela a seguir.

99

Classificao

Descrio Detalhada

Termo

Nome ou sentena com uma definio

acordada que pode ser:

Fato

Template

Conceito, classe, entidade,

Propriedade,
atributo,

Valor,

Conjunto de valores

<termo> definido como <texto>

detalhe,

Sentena que relaciona termos em

observaes relevantes ao negcio

Relacionamentos
entidades

entre

Relacionamentos
entidades e atributos

entre

Relacionamentos de herana

<termo1> um <termo2>
<termo1> <verbo> <termo2>
<termo1> composto de <termo2>
<termo1> um papel de <termo2>
<termo1> tem a propriedade <termo2>

Computao

Sentena fornecendo um algoritmo para

calcular o valor de um termo

<termo> calculado como <formula>

Restrio
obrigatria

Sentena que indica restries que

devem ser verdade em informaes
fornecidas ao sistema (input)

<termo1> deve ter <no mnimo, no mximo,

exatamente n> <termo2>
<termo1> deve ser <comparao> <termo2> ou
<valor> ou <lista de valores>
<termo> deve ser um de <lista de valores>
<termo> no pode star em <lista de valores>
se <regra> ento <restrio>

Guideline

Sentena que indica restries que

deveriam ser verdade em informaes
fornecidas ao sistema (input)

<termo1> deveria ter <no mnimo, no mximo,

exatamente n> <termo2>
<termo1> deveria ser <comparao> <termo2> ou
<valor> ou <lista de valores>
<termo> deveria ser um de <lista de valores>
<termo> no poderia star em <lista de valores>
se <regra> ento <restrio>

Conhecimento
inferido

Sentenas
circunstncias
informaes

que
expressam
que levam a novas

se <termo1> <operador> <termo2, valor,

ou lista de valores> ...
ento <termo3> <operador> <termo4>
Onde operador pode ser: =, <>, =<, >=, <,>,
contm, no contm, tem no mximo, tem no
mnimo, tem exatamente, etc.

Iniciador de ao

Sentena expressando condies que

levam ao incio de uma ao

se <termo1> <operador> <termo2, valor,

ou lista de valores> ...
ento <ao>

Tabela 8. Classificao para regras, definio e templates adaptada de

(Halle, 2002).

Obviamente, como fizemos aqui, a forma textual bastante til. Uma maneira
bastante comum utilizar Diagramas de Entidades e Relacionamentos[B27].
Deve ficar claro, porm, que a utilizao de DER para definir regras
de negcio no igual utilizao de DER para definir o modelo
conceitual de dados de um sistema.

DERs, porm, no representam todas as caractersticas das regras de negcio. Ross

[B30], props uma notao mais complexa, incluindo (muitos) novos smbolos em um DER.
Essa notao, porm, foge do escopo desse texto.

100

Vejamos a descrio de duas regras para uma livraria (Figura 46):

Um cliente deve pedir livros.

Livros so entregues por distribuidoras.

Cliente

Solicita

Livro

Entrega

Distribuidora

Figura 46. Exemplo de duas regras de negcio descritas utilizando uma

notao de DER simplificada.

Alguns autores fazem uma descrio regra a regra, como na Figura 47.
Cliente

Solicita

Livro

Distribuidora

Entrega

Livro

Figura 47. Descrio das regras uma a uma.

As regras de negcio sero utilizadas nos prximos passos para definir modelos mais
formais do sistema. Mas podemos, por exemplo, definir a cardinalidade dos termos em cada
relacionamento descrito, como na Figura 48 e no texto a seguir:

Um cliente pede um ou mais livros,

Livros podem ser pedidos por nenhum, um ou mais clientes,

Uma distribuidora entrega um ou mais livros,

Um livro entregue por apenas uma distribuidora.

101

(1,N)

Solicita

(0,N)

Livro

(1,1)

Cliente

(1,N)

Entrega

Distribuidora

Figura 48. Regras com cardinalidades.

interessante notar que regras de negcio devem ser feitas de forma declarativa, no
indicando como vo ser implementadas, onde vo funcionar, quem ser responsvel ou
quando devem ser testadas. Desse jeito as regras sero flexveis o suficiente para ser
utilizadas na modelagem do negcio. Como devem ser declarativas, elas tambm no devem
ser escritas como um procedimento.

VI.7 Outras Ferramentas de Modelagem

O uso de tabelas permite relacionar informaes levantadas separadamente. Elas so
bastante importantes nas conferncias dos modelos.
VI.7.1

Responsveis por deciso (Processo x Organizao)

Essa tabela associa as pessoas da organizao, que foram representadas no
organograma, com as funes da empresa, que podem ter sido representadas anteriormente de
vrias formas, como o diagrama funcional.

O objetivo da tabela determinar o envolvimento dessas pessoas com as decises

relativas s funes da empresa. Esse envolvimento determinado em trs nveis: principal
responsvel pela deciso, grande envolvimento com a deciso e, finalmente, algum
envolvimento com a deciso.
Principal responsvel pela deciso
Grande envolvimento com a deciso
Algum envolvimento com a deciso
Tabela 9. Tipos de envolvimento com a deciso

102

Processos

Operao

Fornecimento

Planejamento

Pedidos de
Servio

Agendamento

Produo
Administrao

Venda

Gerncia do
Territrio

Vendas

VP de Vendas

Organizao

Gerente de
pedidos
Gerente de
vendas
VP Engenharia
VP Produo
Diretor da
Fbrica
Tabela 10 Exemplo de uma tabela Processo x Organizao

VI.7.2

Dados x Processos (CRUD)

Esta tabela uma das mais interessantes e relaciona as entidades (inicialmente do
modelo de conceitual de dados) com os processos que as utilizam, indicando pelas letras
CRUD se o processo Cria, l (Read), altera (Update) ou apaga (Delete) a entidade.

Uma de suas caractersticas principais que pode ser construda com vrios pares
linha x coluna, dependendo do tipo de abstrao que est sendo usado. No nosso caso
usaremos principalmente no mapeamento de aes (CRUD) entre eventos essenciais e
entidades (os dois temas sero tratados mais tardes), mas podem ser usados em modelos de
negcio (processo x dados utilizados) ou orientados a objetos (casos de uso x objetos). Na
prtica, uma tabela de trabalho muito interessante, que permite a visualizao rpida da
relao entre funcionalidade e dados.
Como usaremos esta tabela para relacionar eventos e entidades, deixaremos esse tema
para ser tratado mais tarde, na unificao dos modelos funcional e de dados.

Processo A

CRUD R

Processo B

CRUD R

Processo C

RUD

Processo D

Processo E

Processo F

Dado 6

Dado 5

Dado 4

Dado 3

Dado 2

Processos

Dado 1

Dados

RU C

Figura 49. Exemplo simplificado de uma Matriz CRUD

VI.7.3

Corrente/Planejado
Esta tabela indica que processos so correntes e que processos esto apenas
planejados. Pode ser feita tanto a nvel de negcios quanto a nvel de sistemas. No primeiro
103

caso estamos interessados nos processos correntes ou implementados no dia a dia da empresa.
No segundo caso estamos interessados em processos automatizados.
Corrente x Planejado
Funo

Situao

Cadastro de Cliente

Corrente

Cadastro de
Fornecedor

Corrente

Cadastro de Pedidos

Planejado

Criao de Pedidos

Planejado

Tabela 11. Exemplo de tabela Corrente x Planejado

VI.8 Resumo da Modelagem de Negcio

No h uma forma correta nica de se fazer a modelagem de negcio. Recomendamos
que sempre seja levantado o organograma da empresa. A seguir, os modelos podem ser
escolhidos e levantados de forma adequada a um processo ou projeto especfico.
No captulo vimos, em ordem decrescente de abstrao, mtodos que podem ser
utilizados tanto de forma isolada como unificada. Deve ser levado em considerao que o
mtodo IDEF0 faz parte de uma famlia de mtodos que podem ser utilizados juntos (no caso
de modelagem de processo existe o mtodo IDEF3, que no usaremos nesse texto por
considerarmos o EPC um mtodo superior).

VI.9 Exerccios
VI.9.1

Projeto 1: Livraria ABC

Faa todos os modelos de negcios descritos nesse captulo para a Livraria ABC, da
forma mais completa possvel.

104

Captulo VII. Modelo Conceitual de Dados

Models are to be used, not believed.
H. Theil `Principles of Econometrics'
Data is not information, Information is not knowledge, Knowledge is not understanding, Understanding is not
wisdom.
Cliff Stoll & Gary Schubert
Modelo de Dados
Entidades
Relacionamentos
Atributos
Chave Candidata, Chave Primria
Formas Normais

O Modelo Conceitual de Dados, como o nome diz, um modelo abstrato que

descreve as informaes contidas no sistema. O objetivo final do modelo de dados a criao
do banco de dados do sistema, seja ele por meio de simples arquivos ou sofisticados sistemas
de gerenciamento de banco de dados28. Em geral, as informaes contidas no modelo sero
aquelas que o sistema precisa ter para executar uma funo e que no so fornecidas pelo
mundo exterior no momento que a funo solicitada, mas sim anteriormente.
O modelo de dados um tipo de requisito do sistema, pois descreve tudo que o
sistema tem que saber[B28]. O modelo de dados estabelece um vocabulrio (termos e fatos
entidades e relacionamentos), indica que informao est sendo compartilhada e qual o
escopo de conhecimento que est sendo considerado pelo sistema.
importante notar que modelos de dados organizam representaes estticas do
sistema, isto , eles indicam como so registrados os resultados das operaes do sistema,
mas no como essas operaes so feitas.
A criao do modelo de dados um processo de especificaes sucessivas.
Inicialmente descrevemos um modelo do ambiente observado, normalmente descrevendo o
mundo como ele visto pelo usurio. Esse modelo conhecido como Modelo Conceitual de
Dados. No final devemos possuir uma descrio na viso do desenvolvedor, descrevendo o
mundo de uma forma especfica, otimizada para os dispositivos sendo utilizados na
implementao do sistema (linguagens de programao, SGDB, sistema operacional e
hardware), o Modelo Fsico de Dados. Entre o modelo conceitual e o modelo fsico devemos
passar por um passo intermedirio, onde assumimos compromissos com uma tecnologia
especfica, mas no com os produtos sendo utilizados. Este passo conhecido como Modelo
Lgico. Muitas metodologias de modelagem de dados, como a IDEF1X, utilizam apenas dois
passos, o modelo lgico e o fsico, assumindo j no primeiro modelo algumas regras tpicas
do modelo relacional.
A principal forma de modelagem de dados, e a forma adotada por esse texto, o Modelo
de Entidades e Relacionamentos, ou MER, por meio do Diagrama de Entidades e
28
Na anlise essencial discutiremos a necessidade de um sistema de ter uma memria que permite ao sistema
se lembrar de fatos passados ao atender um evento. A modelagem de dados a tcnica que nos permitir definir
como essa memria, isto , que informaes deve guardar.

105

Relacionamentos, ou DER. No mo Modelo de Entidades e Relacionamentos contamos com trs

abstraes para modelar o mundo: entidades, atributos e relacionamentos. De maneira simples,
podemos dizer que entidades representam as coisas e conceitos do mundo, atributos
representam as caractersticas dessas coisas e conceitos e relacionamentos representam as
relaes existentes entre essas coisas e conceitos.

1.1

Modelos de Dados e Regras de Negcio

Um modelo de dados se inicia de uma forma prxima ao negcio (modelo conceitual)

e vai se aproximando, com o decorrer do projeto, de uma forma com alta influncia da
tecnologia (modelo fsico).
O modelo de dados conceitual na forma de um diagrama de entidades e
relacionamento pode ser construdo diretamente sobre os termos e fatos levantados nas regras
de negcio ou, por outro lado, pode ser o mecanismo utilizado para levantar e documentar
essas regras.

Modelos e Abstraes

1.2

The human mind has first to construct forms, independently, before we can find them in things.
Einstein, Albert (1879-1955)
29

Todo modelo uma abstrao de algo que existe ou se imagina que possa existir no
mundo real. Abstrao o processo mental de separar um ou mais elementos de uma
totalidade complexa de forma a facilitar a sua compreenso por meio de um modelo.
Normalmente desejamos que o modelo seja, ao mesmo tempo, simples o bastante para
ser fcil de manipular e complexo o suficiente para resolver o problema em questo.
No nosso dia a dia utilizamos a abstrao para poder trabalhar com toda a informao
que o mundo nos fornece. Um mapa, por exemplo, um modelo de uma cidade. Dependendo
da informao que queremos, colocamos alguns smbolos e tiramos outros do mapa. Um
mapa tambm no pode ser perfeito, tem que abstrair as informaes que no so
necessrias naquele instante, ou teria que ter o mesmo tamanho da cidade.
No desenvolvimento de sistemas, utilizamos alguns processos de abstrao tpicos:

Classificao,

Composio,

Generalizao,

Identificao e

Normalizao

1.2.1 Classificao ( um membro de)

No processo de classificao eliminamos parte da individualidade do objeto ou
sistema analisado e o consideramos como um exemplar de uma classe padro. Quando
fazemos isso, aceitamos que esse objeto, agora uma instncia da classe, divide com todas as
outras instncias da classe um conjunto de caractersticas.

29

Um modelo tambm pode ser um exemplo.

106

Na classificao o que estamos fazendo imaginar uma idia nica que descreve, de
forma abstrata, todos os objetos de uma classe. Ao eliminar a necessidade de tratar cada
objeto de forma nica, simplificamos o problema em questo.
Exemplos tpicos de classificao:
Instncias

Classe

Flamengo, Fluminense, So Paulo

Times de Futebol

Brasil, Estados Unidos

Pas

Pel, Zidane, Romrio

Jogador de Futebol

Tabela 12. Exemplo de classificao

O processo reverso da classificao a instanciao. O conjunto de todas as

instncias de uma classe a extenso dessa classe.
A classificao um mecanismo bsico do raciocnio humano. Talvez seja o que nos
permita tratar de toda informao que recebemos diariamente.
importante notar que na vida real um objeto pode pertencer a vrias classes. Uma
pessoa pode ser um aluno, um professor, um policial, etc... Normalmente, em modelos
tericos como os que vamos usar, tentamos com que um objeto pertena, diretamente, a s
uma classe, de modo a facilitar a manipulao do modelo.
1.2.2 Composio ou Agregao ( feito de, parte de)
Na composio entendemos um objeto complexo formado de um conjunto de outros
objetos como um s objeto. como vemos uma bicicleta ou um carro. Ao eliminar a
necessidade de descrever as partes, simplificamos a compreenso do objeto analisado.
Exemplos tpicos de composio:
Partes

Objeto

Pneus, motor, etc.

Carro

Capa, centenas de folhas, etc.

Livro

Cabelo, pele, ossos, etc.

Homem

Tabela 13. Partes-Objeto na relao de composio

O processo reverso da composio a decomposio.

Normalmente, em modelagem de dados, usamos o conceito de composio para dizer
que uma classe (como endereo) uma caracterstica de outra classe, descrevendo um entre
seus atributos.
1.2.3 Generalizao ( um, como)
Com a generalizao ns somos capazes de entender como uma classe pode ser
descrita por outra classe, mais geral. importante ver a diferena entre a classificao e a
generalizao: a primeira trata da relao entre objeto e classes, enquanto a segunda trata da
relao entre classes.
Com a generalizao podemos compreender uma relao muito comum entre classes,
que a que permite que qualquer objeto de uma classe possa ser visto, de uma forma mais
geral, como um objeto de outra classe. Utilizando judiciosamente a generalizao podemos
simplificar a forma de tratar objetos de classes similares.

107

Exemplos tpicos de generalizao:

Classes

Classe mais geral

Funcionrio, Aluno, Professor

Pessoa

Automvel, Avio, Navio

Meio de Transporte

Computador, Rdio, Televiso

Aparelhos Eletrnicos

Tabela 14. Exemplo de generalizao

O processo reverso da generalizao a especializao.

1.2.4 Identificao ( identificado por)
Com a identificao ns somos capazes de entender como caracterizar unicamente
um objeto. Um nome identifica uma pessoa, por exemplo. Ao identificar unicamente um
objeto podemos separ-lo de outro objeto semelhante e atribuir a entidades especficas
atributos e caractersticas que s pertencem a ela, e no pertencem a outros elementos
daquela classe.

H uma diferena entre instanciar e identificar. Uma instncia deve possuir uma
identificao e uma identificao se aplica a uma instncia. A identificao permite a que
duas instncias sejam reconhecidas como distintas ou como representaes de um mesmo
objeto (normalmente devendo ser reunidas em uma).
1.2.5 Normalizao30
Toda aplicao, ao funcionar, deve tratar de casos especficos que ocorrem durante o
funcionamento normal. Porm, bem mais fcil discutir o funcionamento normal antes e
depois os casos especficos. A abstrao de iniciar pelo modo normal indica que devemos
comear a trabalhar pelo modo comum ou normal de funcionamento, ou ainda melhor, o
modo onde tudo ocorre da forma mais simples e depois ir inserindo mecanismos para tratar
das variaes possveis.
1.2.6 Trabalhando com as abstraes
Imagine que precisamos descrever comprar um carro. bvio que todo carro possui
quatro pneus, um motor, etc. Isso uma classe bastante geral. Porm, desejamos ainda falar
sobre um modelo especfico: uma Ferrari Testarossa, por exemplo. Logo, acabamos de
especializar nosso modelo, mas ainda no chegamos ao nvel de objeto. Quando vemos o
carro especfico, a temos o objeto. Ele identificvel como instncia daquela classe porque
apesar de dividir vrias caractersticas em comum com outros objetos da classe, tambm tem
algumas caractersticas nicas, como o nmero de srie do chassi. Finalmente, desejamos
trocar a cor do assento do carro. Nesse instante, j estamos vendo uma parte do carro,
decompondo-o em suas partes.

1.3

A Memria do Sistema

Na anlise essencial importante compreender o conceito de memria do sistema.

Para cada necessidade do cliente, como relatrios e tomadas de deciso, o sistema precisa de
certa quantidade de dados. Esses dados so sempre fornecidos pelo mundo exterior (pois o
sistema no pode inventar dados), porm nem sempre no mesmo momento em que a
funo necessria realizada. Normalmente, por sinal, um sistema de informaes
30

No confundir com a operao de normalizao relativa as formas normais.

108

composto por funes que coletam dados para que sejam, mais tarde, utilizados por funes
que fornecem relatrios.
Dessa forma, esses dados necessrios para realizar uma funo precisam estar em
algum lugar. Na anlise essencial ns abstramos a localizao e forma fsica dos dados,
supondo que o sistema possui uma memria. Com a Modelagem Conceitual de Dados damos
a forma abstrata a essa memria, de maneira a entender o que deve estar guardado na
memria sem decidir, prematuramente, sua localizao e estrutura.
1.3.1 Modelo Conceitual (MC)
O objetivo da modelagem conceitual fornecer aos desenvolvedores uma descrio
abstrata de alto nvel, independente de tecnologia, da informao contida no sistema. Essa
descrio conhecida como o esquema conceitual da base de dados.

A Modelagem Conceitual de Dados pode ser feita de muitas formas, algumas vezes
com sutis diferenas. Alguns autores defendem a modelagem do domnio, onde tentamos
descrever o domnio de aplicao sendo utilizados, outros tratam diretamente do sistema
sendo desenvolvido. Neste texto trabalharemos com uma abordagem mais prxima do
sistema sendo desenvolvido, pois estamos buscando uma ferramenta que se encaixe com a
anlise essencial.
O modelo conceitual construdo a partir da anlise de requisitos, em geral
simultaneamente ao desenvolvimento da anlise essencial. Na prtica, o primeiro modelo
essencial usar como memrias os objetos descritos no DER.
Mundo
Observado

Requisitos

Modelo
Conceitual

Esquema Conceitual

Modelo
Lgico

Esquema Lgico

Modelo
Fsico

Esquema Fsico

Figura 50. Etapas da Modelagem de Dados

Um dos subsdios mais importantes para a criao do DER o conjunto de regras de

negcio levantadas. Muitas das regras de negcio so representadas diretamente no modelo
conceitual. Veremos mais tarde que termos e fatos so candidatos naturais para serem objetos

109

nos nossos modelos conceituais. No devemos confundir, porm, regras de negcio com
modelos de dados. Um relacionamento em uma regra de negcio pode representar uma
funo do sistema, enquanto um relacionamento no MER representa algo que deve pertencer
memria do sistema.
1.3.2 Modelo Lgico
O modelo lgico descreve a informao contida no sistema de acordo com uma
tecnologia adotada, sem utilizar, porm, detalhes de implementao. Ele descreve a estrutura
do banco de dados que ser processado por um SGDB.

Atualmente, o modelo mais utilizado o modelo relacional, porm existe uma

tendncia utilizao do modelo relacional-objeto ou de outros modelos relacionais
estendidos. Alm disso, alguns modelos distintos podem ser encontrados em aplicaes
especiais, como data-warehousing e sistemas de informao geogrfica. O modelo de objetos,
considerado por muitos o mais moderno, no tem no momento grande aceitao no mercado.
1.3.3 Modelo Fsico
No modelo fsico devemos levar em conta no s a tecnologia sendo utilizada, mas
tambm os produtos especficos e a interao do sistema com o ambiente de desenvolvimento
e operao.

nessa etapa que nos preocupamos com as principais questes de desempenho, como
escolha de ndices, particionamento, etc.

1.4

Modelo de Entidades e Relacionamentos

O Modelo de Entidades Relacionamentos, segundo Paulo Cougo [B31], descreve o

mundo como: ...cheio de coisas que possuem caractersticas prprias e que se relacionam
entre si.
Essas coisas podem ser pessoas, objetos, conceitos, eventos, etc. Elas so as
entidades. A priori, s exigimos de uma entidade que ela possa ser identificada distintamente,
isso , tenha identidade prpria. Cada coisa distintamente identificada uma instncia. Por
exemplo, o funcionrio Jos uma instncia da entidade funcionrio, a aluna Maria uma
instncia da entidade aluna.
As entidades, ou melhor, suas instncias, so classificadas em tipos (ou classes). No
nosso caso, funcionrio e aluno so os tipos de entidade. Estamos usando nesse momento a
abstrao de classificao: resumir uma quantidade de caractersticas comuns por meio da
criao de uma classe. Assim sabemos que o funcionrio Jos e o funcionrio Joaquim, por
serem instncias de um mesmo tipo, possuem caractersticas comuns (como trabalhar na
empresa, ter um salrio, etc.).
No diagrama de entidade e relacionamentos cada tipo de entidade representado por
um retngulo identificado pelo nome do tipo. Normalmente confundimos o termo entidade
com o tipo da entidade, deixando o termo instncia (e algumas vezes registro) para falar de
uma entidade identificada.
Apenas algumas entidades do mundo real (ou imaginrio) so de interesse para o
sistema. Durante a modelagem conceitual nos preocupamos com as coisas que o sistema
deve lembrar e colocamos essas coisas no modelo de entidade e relacionamentos. Uma
entidade deve ser relevante para o objetivo do negcio e necessria para a sua operao.

110

Cada entidade tem dois tipos de caractersticas importantes: seus atributos e seus
relacionamentos. Os atributos so caractersticas que toda a instncia de um tipo possui, mas
que podem variar entre as instncias. Uma instncia do tipo aluno tem os atributos nome
e ano de matrcula, por exemplo. Atributos caracterizam a informao que deve ser
guardada sobre uma entidade. S devemos colocar como atributos aquelas informaes que o
sistema precisa lembrar em algum momento. Assim, uma instncia de aluno no precisa ter
o atributo nome do animal de estimao em um sistema acadmico, pois apesar de ser algo
importante para o aluno propriamente dito, no tem importncia alguma para o sistema.
Cada caracterstica deve possuir um domnio. O domnio indica o conjunto de valores
vlidos para a caracterstica. No caso de nome, geralmente aceitamos qualquer seqncia
de caracteres, enquanto no caso de altura podemos aceitar apenas valores reais positivos
menores que 2,5.
Atributos eram originalmente descritos por crculos no modelo E-R. As notaes mais
modernas anotam os atributos dentro dos retngulos da entidade a que pertencem.
Finalmente, como indica o nome do modelo, entidades podem se relacionar entre si.
Essa caracterstica a principal fora do modelo de entidades e relacionamentos, pois permite
que, de certa forma, naveguemos no modelo.
Podemos indicar relacionamentos apenas pelas entidades envolvidas, como clientepedido, ou usar um termo que descreva o relacionamento cliente solicita pedido.
Modelos de Entidades e Relacionamentos para serem completos exigem tambm um
conjunto de restries. Algumas dessas restries, como a cardinalidade dos relacionamentos
que veremos a seguir, podem ser descritas em algumas (ou todas) notaes. Porm, a maioria
das descries muito complexa para ser descrita em um diagrama. Nesse caso so
necessrias anotaes ao diagrama descrevendo as descries. Isso pode ser feito em
linguagem natural ou em alguma notao formal especfica, dependendo de escolhas da
equipe de projeto ou do mtodo utilizado.

1.5

O Diagrama de Entidades e Relacionamentos

Diagramas de Entidades e Relacionamentos descrevem o mundo em geral ou um

sistema em particular de acordo com os objetos que o compe e os relacionamentos entre
esses objetos.

111

Figura

Significado

Entity name

Entidade

Relacionamento

1
Me

Ligao entre entidades, por

meio de um relacionamento,
com a descrio da
cardinalidade.

Value

Atributo

Tabela 15. Figuras bsicas de um diagrama de Entidades e

Relacionamentos segundo Peter Chen

Existem muitas notaes para Diagrama de Entidades e Relacionamentos. A notao

original foi proposta por Chen e composta de entidades (retngulos), relacionamentos
(losangos), atributos (crculos) e linhas de conexo (linhas) que indicam a cardinalidade de
uma entidade em um relacionamento. Chen ainda prope smbolos para entidades fracas31e
entidades associativas.
As notaes modernas abandonaram o uso de smbolos especiais para atributos,
incluindo a lista de atributo, de alguma forma, no smbolo da entidade. Consideramos as
notaes como as mais interessantes na atualidade:

IDEF1X, utilizada pela ferramenta ERWIN, bastante difundida no mercado

Engenharia de Informao, bastante difundida e tambm presente como notao

alternativa no ERWIN.

Notao de Setzer, difundida no Brasil por seu autor.

Notao de Ceri, Bertini e Navathe [B32], pouco difundida, mas com aspectos
tericos interessantes.

Uso da UML para representar modelos de dados no-orientados a objetos.

Toda a notao moderna tem como caracterstica importante definir a cardinalidade

mnima e mxima em uma relao, no utilizar um smbolo especial para relacionamentos,
mas sim a linha, e descrever atributos dentro do smbolo de entidades.

31

Deploramos o termo entidade fraca, que leva os alunos a acreditar que no devem existir entidades fracas
em um DER, associando o termo fraco ao conceito de errado,

112

Nome da
Entidade

Atributos
Identificadores
(Chave)

Empresa
CNPJ
NomeFantasia
NomeRegistro
Endereco
Telefone
Contato

Atributos

Figura 51. Uma entidade pode ser representada tambm dessa forma, bem
mais moderna e compacta que a proposta original. Esta a notao
utilizada no software Erwin (tanto no modelo IDEF1X e quanto na
Engenharia da Informao). Os atributos identificadores ficam acima de
uma linha divisria.

Figura 52. Um exemplo simples de DER, sem atributos.

Figura 53. Um exemplo de DER usando a Notao da Engenharia da

Informao, feita com o software ERWIN. Os cones ajudam a identificar
as chaves (j identificadas pela sua posio sobre a linha divisria).

1.5.1 Exemplo de Modelo E-R

O modelo a seguir, utilizando a notao de Bertini et al. [B32], pode ser lido da
seguinte forma:

113

Entidades do modelo: Diretor, Novela, Captulo, Ator, Ator Horista e Hora

Um diretor dirige no mximo uma novela, podendo no dirigir nenhuma, e uma

novela dirigida por um e apenas um diretor.

Um captulo compe uma e apenas uma novela e uma novela tem no mnimo um
captulo, podendo ter um nmero ilimitado deles.

Um ator atua em uma novela, podendo no atuar em nenhuma e uma novela tem
ao menos um ator, podendo ter vrios.

Um ator pode ser um ator horista e um ator horista obrigatoriamente um ator.

Um ator horista trabalha de zero a vrias quantidade de horas, mas uma

quantidade de horas trabalhada por apenas um ator.

Figura 54. Exemplo de modelo conceitual

No modelo anterior no apresentamos nenhum atributo. A notao original para

atributos, o uso de crculos ligados aos retngulos que representam as entidades, complica
muito o diagrama. As notaes mais modernas anotam os atributos dentro dos retngulos.

1.6

Desenvolvendo o Modelo Conceitual

Desenvolver um modelo conceitual correto para um sistema, completo e consistente,

no uma tarefa fcil. J desenvolver um modelo conceitual razoavelmente correto, que d
uma idia do sistema e do negcio e que, de forma evolutiva, resulte em um modelo
conceitual correto, uma tarefa razoavelmente fcil para um analista experiente. Para o
analista de sistemas iniciante, porm, parece uma tarefa extremamente difcil.
Isso acontece porque o modelo conceitual de dados exige duas coisas: um alto grau de
abstrao e a internalizao, pelo analista, de conceitos bastante vagos, como entidades e
relacionamentos. Assim, o analista iniciante precisa seguir algumas estratgias para
entender melhor como desenvolver um modelo conceitual.
A primeira estratgia a estratgia dos exerccios e exemplos. Nada to til ao
aprendizado como colocar a mo na massa. Os exemplos, por seu lado, servem no s como
orientao geral, mas tambm como exemplos de pontos especficos da modelagem e de
como especialistas resolvem problemas de modelagem, sejam eles simples ou complicados.

114

A segunda estratgia desenvolver uma lista de dicas de trabalho. Essas dicas

funcionam para o analista como as pistas funcionam para um detetive, mostrando que
caminho seguir at encontrar a soluo do problema.

1.7

Entidades
Uma entidade uma pessoa, objeto, local, animal, acontecimento,
organizao ou outra idia abstrata sobre a qual o sistema deve se
lembrar alguma coisa.
Cada instncia de uma determinada entidade tem caractersticas
similares (mas no iguais), o mesmo comportamento e uma
identidade prpria.

O primeiro passo na determinao das entidades o levantamento dos candidatos

entidade. Durante as entrevistas e reunies de anlise de sistema, vrios objetos e conceitos
sero descritos como parte do sistema. Algumas vezes esses objetos so bastante concretos,
como um produto dentro de um estoque, outras vezes so descritos como documentos
que guardam alguma informao, como uma nota fiscal, outras vezes so abstratos, como
um curso.
No discurso fluente durante uma entrevista, entidades so geralmente substantivos
ocupando o papel de sujeito ou objeto, enquanto relacionamentos geralmente so encontrados
na forma de verbo. Muitas vezes uma regra de negcio, como alunos cursam turmas ou
clientes fazem pedidos nos indica entidades e relacionamentos32.
Outro sinal importante da necessidade de uma entidade o fato de algo que precisa
ser lembrado representar um conceito ou idia completa. Em um sistema acadmico
precisamos nos lembrar do nome do aluno, da data de matrcula do aluno, do curso em que
est o aluno, etc. O aluno a nossa idia completa que aparece vrias vezes, algumas vezes
caracterizado por seu nome, outras vezes por seu curso. um bom candidato a entidade.
Alguns autores propem uma determinao bottom-up das entidades, sugerindo que
elas sejam construdas pela partio de todos os dados atmicos que o sistema deve lembrar
(nome de aluno, data de matrcula do aluno, etc.). Assim, construiramos uma lista de
atributos para depois agrup-los em entidades.
Preferimos, porm, uma abordagem de busca direta das entidades. Um sistema com
poucas dezenas de entidades pode ter centenas de atributos, o que torna tudo bem mais
confuso.
Segundo Shlaer e Mellor [B33], uma entidade pode estar em cinco grandes categorias:

Objetos tangveis

Papis exercidos

Eventos

Interaes

Especificaes

32
Novamente, lembro que apesar de usarmos a notao E-R para descrever regras de negcio, estamos falando
de duas atividades diferentes e que tem resultados diferentes (apesar de poderem, por coincidncia terem o mesmo
resultado).

115

Podemos facilmente ver porque objetos tangveis so bons candidatos a entidades:

normalmente, sistemas de informao falam em algum momento de objetos tangveis, como
produtos e equipamentos. Algumas vezes, porm, um objeto tangvel, como uma pessoa,
assume uma funo ou papel especfico, como aluno ou professor.
Eventos, ou interaes, acontecem em algum momento do tempo e representam
classes importantes de entidades. Um exemplo de evento uma reunio em uma agenda .
Normalmente eventos exigem atributos como data e durao.
Exemplos tpicos de interaes so: contratao de servio ou venda de produto.
Interaes so semelhantes a relacionamentos ou a objetos tangveis ou eventos, sendo muitas
vezes representadas dessa forma.
Finalmente, especificao so tipos especiais de entidades que classificam outra
entidade. Um bom exemplo fbrica, que uma especificao para automvel.
Geralmente, especificaes tambm podem ser implementadas como um atributo na entidade
especificada, sendo essa uma deciso de anlise.
J Coad, ao buscar uma forma mais objetiva de modelar objetos, sugere que
busquemos inicialmente 4 tipos de objetos (que podemos entender como entidades):

Momentos ou Intervalos: um momento ou um intervalo representa qualquer coisa

que precisa ser acompanhada, por motivos de negcio ou legais, e que acontecem
em um instante de tempo ou por um perodo de tempo. Muitas vezes pode ser
mais fcil comear nossa anlise por esse tipo de entidade, pois estamos tratando
de atividades de negcio que devem exigir a participao das outras entidades.
Exemplos so: aulas, consultas, contratao, etc.

Papis: representam papis assumidos pelas pessoas que esto envolvidas com o
sistema sendo analisado. Cuidado, pois no so apenas os usurios, nem
representam os cargos que as pessoas ocupam nas empresas necessariamente.
Exemplos so: aluno, professor.

Pessoas, Locais ou Coisas: representam os objetos tangveis e localidades.

Exemplos so: sala, automvel.

Descries: so basicamente as especificaes propostas por Shlaer e Mellor.

Modelos de um produto um bom exemplo.

Ross [B28] sugere trs tipos de entidade:

Entidades Ncleo (Kernel): que representam is conceitos mais bsicos do domnio

do problema e que no dependem de outras entidades para existir.

Entidades Dependentes: que representam conceitos que so naturalmente

dependentes de outra entidade especfica (e apenas uma) para sua existncia,
normalmente associados a aspectos de outra entidade que so multi-valorados
(como produtos e suas quantidades em um pedido).

Entidades de Associao: que representam conceitos que so naturalmente

dependentes de mais de uma entidade para sua existncia.

James e Suzanne Robertson [B34] sugerem algumas regras para que verifiquemos se
um conceito deve ser realmente escolhido como uma entidade:

Toda entidade deve ter um papel nico e definido no negcio, se voc no pode
explic-la, provavelmente no precisa se lembrar dela.

116

Entidades devem ter ao menos um atributo que as descrevam, e prefervel que

tenham vrios.

Entidades devem ter mais de uma instncia. Se a instncia nica, ento no deve
ser uma entidade, mas uma informao constante, que parte do negcio da
empresa (uma regra de negcio?).

Entidades devem possuir instncias unicamente identificveis.

Entidades no possuem valores, apenas atributos possuem valores.

Pessoas e organizaes que interagem com o sistema so candidatos a entidade

quando precisamos nos lembrar alguma coisa especfica sobre elas, para gerar
relatrios ou processar dados entrados. Isso no se aplica a logons ou
passwords utilizados para a segurana do sistema, pois segurana um
problema tratado no projeto fsico. Devemos aplicar essa regra em relao
necessidade de identificao e endereamento, por exemplo.

Relatrios raramente so entidades. Normalmente eles so apenas os resultados de

um processo que acessa vrias entidades.

Linhas de relatrio geralmente so entidades. Nomes de colunas indicam

entidades ou seus atributos. Porm, nenhum valor calculado ou derivado
atributo ou entidade.

Substantivos em regras de negcio so normalmente entidades

Produtos, quando no so nicos, so normalmente entidades.

Papis, como funcionrio, atendente, apostador, etc., so bons candidatos para

entidades.

Um grupo de dados que se repete em uma entrada ou sada de dados

normalmente uma entidade (ou mais).

1.7.1 Onde encontr-las

Alm de encontr-las em entrevistas e em regras de negcio, podemos utilizar alguns
documentos para encontrar entidades:

Relatrios

Formulrios de entrada de dados

Arquivos, tanto de papel quanto no computador.

Fichas, como fichas de cadastro, de emprstimo, etc.

Pedidos, requisies e documentos do gnero.

Documentos contbeis e fiscais, como nota fiscal.

Planilhas de dados, em papel ou eletrnicas.

Listagens, registros, agendas, protocolos e outros documentos de trabalho.

Sistemas j existentes

Bancos de dados j existentes

117

Outra forma de encontrar entidades buscar sistemas semelhantes j resolvidos e

padres de projeto33 ou padres internacionais sobre o assunto sendo tratado.
1.7.2 Descrevendo Entidades
extremamente importante a descrio precisa de cada entidade34, pois sua descrio
no serve s de documentao, mas tambm de teste para verificar se entendemos realmente
sua presena no sistema.

Uma boa descrio de entidade conter os seguintes itens:

Nome, incluindo uma listagem de sinnimos e homnimos35

Definio

Exemplos

Atributos (veremos a seguir)

Relacionamentos (veremos a seguir)

Eventos que a utilizam (veremos no prximo captulo)

Correlao, descrevendo outras partes da anlise que se referem a ela.

Regras e excees relacionadas a essa entidade, incluindo regras de negcio.

Outros comentrios e observaes

Uma idia da quantidade esperada de instncias no sistema

Durante a definio devemos tentar responder vrias perguntas, procurando deixar

claro o porqu dessa entidade fazer parte do sistema. Assim devemos nos preocupar em dizer
o que essa entidade, o que faz e para que est no sistema, quando algo ou no uma
dessas entidades, quando passa a ser ou deixa de ser, ou se permanentemente.
Quando algum elemento passa de uma entidade para outra devemos tomar bastante
cuidado para descrever as aes necessrias para tal fato.

Figura 55. No incio da modelagem podemos ter apenas entidades

isoladas

33

Como no excelente livro Princpios de Modelagem de Dados de David Hay[B35].

34

Devemos confessar que no temos a mesma preocupao com atributos, por exemplo.

35

Homnimos so objetos diferentes porm com o mesmo nome

118

Figura 56. Uma tela descrevendo uma entidade no software ERWIN 3.5.
Ateno para o fato que apesar de no cumprir todos os nossos
requisitos em campos distintos, apresenta vrios campos de anotao.

Aluno
Escola
NomeEscola
EnderecoEscola

CPF
NomeAluno
EnderecoAluno
NomePai
NomeMae

Figura 57. Como veremos mais adiante, segundo a notao da Engenharia

da Informao, apresentamos nessa figura duas entidades que se
relacionam: Escola e Aluno.

1.8

Relacionamentos

A principal caracterstica das entidades que compe um sistema se relacionarem

umas com as outras. impossvel imaginar uma entidade isolada em um sistema de
informao. Toda entidade deve possuir ao menos um relacionamento que a coloque em
contato com as outras entidades do sistema.
Relacionamentos representam que existe alguma conexo entre entidades dentro do
negcio sendo analisado [B34]. Cada relacionamento deve ser tambm uma regra de negcio
e utilizado em pelo menos um processo que lida com as entidades envolvidas.
Relacionamentos indicam a possibilidade de buscar um grupo de entidades a partir de
outra entidade. Assim, permite encontrar os visitantes que emprestaram um livro
especfico (navegando de livro para clientes), ou descobrir que produtos um cliente
pediu (navegando de clientes para livros). Indicam tambm que precisamos nos lembrar de
algo que envolve, simultaneamente, duas ou mais entidades do sistema, e que essa lembrana
s faz sentido quando todas as instncias envolvidas so recuperveis simultaneamente ou
seqencialmente.
Existem muitos relacionamentos comuns, encontrados em muitos sistemas, como
compe (peas compe mquinas), um (bicicleta um meio de transporte), faz ou
gera (cliente faz ou gera pedido), atende (visita atende solicitao de reparo), usa
(cliente usa produto), etc.

119

O relacionamento um to comum, e to til, que foi escolhido como um

relacionamento especial em muitos mtodos derivados da Modelagem Entidade e
Relacionamento original. a relao de herana, onde dizemos que uma entidade herda
todas as caractersticas de outra entidade. A herana equivale abstrao de generalizao/
especificao.
Existem duas formas bsicas de herana. Na herana exclusiva dividimos uma classe
em categorias. Essa forma de herana traz poucas dificuldades na modelagem e conhecida
como separao em categorias. Uma pessoa, por exemplo, pode ser dividida em duas
categorias, a dos homens e a das mulheres. Quando a diviso no exclusiva, ou seja, quando
possvel que uma instncia de uma entidade especfica seja classificada em duas (ou mais)
de suas subclasses, temos alguns problemas que devem ser resolvidos na modelagem lgica.
Por exemplo, uma pessoa pode ser aluno e professor simultaneamente em uma faculdade.
Tambm possvel que existam instncias que no fazem parte de nenhum dos tipos
de entidade especializados, mas fazem parte do tipo geral. Isso tambm exige um tratamento
especial durante a modelagem lgica.
Ns dizemos ento que:

A cobertura total, se cada elemento da classe genrica mapeado em ao menos

um elemento das subclasses.

A cobertura parcial, se existe ao menos um elemento da classe genrica no

mapeado nas estruturas das subclasses.

A cobertura exclusiva, se cada elemento da superclasse mapeado em no

mximo um elemento das subclasses.

A cobertura sobreposta, se existe um elemento da superclasse mapeado em mais

de um elemento das subclasses.

Devemos tentar obter apenas heranas totais e exclusivas, pois so mais fceis de
serem tratadas.
Dado um grupo de entidades candidatas a construir um relacionamento de herana,
devemos analisar se existe um atributo ou relacionamento que aplicvel a apenas um
subconjunto dessas entidades, se simplificamos o modelo e se aumentamos sua compreenso.
Ou seja, devemos usar a herana para aumentar a semntica do modelo sem causar excesso
de informao.
Outro relacionamento to comum que mereceu um tratamento especial em muitos
mtodos o relacionamento parte de. Esse relacionamento equivale abstrao de
composio. normal que utilizemos esse relacionamento apenas quando a parte s existe
em funo do todo, porm no uma exigncia muito forte.
Relacionamentos podem unir indiferentemente entidades do mesmo tipo ou entidades
de tipos diferentes. Quando relaciona entidades do mesmo tipo dizemos que um autorelacionamento. Ao especificar um auto-relacionamento devemos ter mais cuidado em
declarar os papis das entidades no relacionamento, alm de atentar para no produzir um
loop infinito no relacionamento.
Normalmente trabalhamos apenas com relacionamentos entre duas entidades. O
mtodo original de Chen permitia relacionamentos mltiplos. Atualmente transformamos
relacionamentos mltiplos em entidades.
O mesmo acontece com o uso de atributos no relacionamento. Apesar do mtodo
original permitir, atualmente criamos uma entidade para representar esse relacionamento.
120

Bertini et al. [B32] mostram algumas operaes que, aplicadas a um modelo e-r,
criam diagramas diferentes que podem representar uma mesma realidade. Assim, algo que foi
representado como uma entidade em um modelo pode ser representado como duas em outro,
ou um relacionamento em um modelo pode ser transformado em uma entidade que se
relaciona com as entidades originais (ou vice-versa) sem que haja uma representao falsa da
realidade. Pode acontecer de uma ou outra representao ser mais interessante em um
contexto.
Relacionamentos podem ser condicionais ou incondicionais, isto , uma entidade pode
ser obrigada a ter um relacionamento com outra ou no. Por exemplo: um automvel
obrigatoriamente fabricado em uma fbrica, mas nem todos os livros em uma livraria j
foram vendidos. Como veremos adiante, o fato de um relacionamento ser opcional
representado pela definio da cardinalidade mnima do relacionamento, que pode ser 0 ou 1.
Tambm importante notar que existem tambm relaes que ocorrem entre
relacionamentos. Dois relacionamentos podem ocorrer sempre juntos (contingentes) ou nunca
ocorrer juntos (mutuamente exclusivos). Existem mtodos que permitem anotar diretamente
no diagrama essas caractersticas, porm so pouco utilizados.
Tudo que no puder ser anotado no diagrama dever ser anotado em um
documento associado. O principal tipo de anotaes so as regras de negcio que funcionam
como restries, como um professor s pode dar aulas para alunos da escola em que
trabalha. Restries so geralmente impossveis de desenhar diretamente no diagrama36.
Normalmente associamos restries a ciclos no diagrama. Por exemplo, se temos que
fazer pedidos de livros para uma editora, ento temos um relacionamento entre livro e pedido,
um entre livro e editora e um entre editora e pedido, formando um ciclo. A restrio que
um pedido s pode conter livros da editora indicada no pedido. possvel desenhar o
diagrama sem ciclos, eliminado, por exemplo, a ligao entre pedido e editora, porm
aconteceriam duas coisas: primeiro teramos que escrever uma restrio que possivelmente
mais complexa (um pedido s pode conter livros da mesma editora), segundo no teramos
nenhuma indicao no diagrama que o pedido feito para a editora, exigindo uma nova regra.
Finalmente, a falta do ciclo funciona tambm como falta de indicao que existe uma
restrio, pois todo ciclo um aviso de restrio37.
1.8.1 Cardinalidade
Para bem representar um relacionamento, devemos indicar a cardinalidade desse
relacionamento, isto , quantas vezes uma instncia da entidade pode se relacionar com
instncias de outras entidades.

Veja por exemplo o relacionamento me-filha. Uma filha s pode ter uma me, mas
uma me pode ter vrias filhas.
Existem trs tipos bsicos de relacionamentos: o 1:1, um para um, o 1:N, um para
muitos, e o N:M, muitos para muitos. Nesse caso s estamos falando da cardinalidade
mxima. A cardinalidade mxima indica quantas vezes uma entidade pode aparecer em um
relacionamento.

36

Ross, porm, prope uma linguagem grfica que permite a definio de restries. A linguagem muito
complexa e no existe ainda nenhuma ferramenta CASE que a suporte.

37

Mas a ausncia de um ciclo no significa que no existe restrio.

121

No relacionamento 1:1 cada entidade s pode se relacionar com uma entidade do

outro conjunto. Geralmente indica semelhana, igualdade, utilizao conjunta, etc.
No relacionamento 1:N cada entidade de um conjunto pode ser relacionar com vrias
entidades do outro conjunto, mas as entidades do segundo conjunto s podem se relacionar
com uma entidade do primeiro conjunto. Geralmente indicam relaes de posse, hierarquia
ou de composio.
No relacionamento N:M qualquer nmero de relacionamentos vlido. Podem indicar
vrias coisas, como eventos, contratos, acordos, ligaes temporrias como emprstimos e
aluguis, etc. normal aparecerem tambm quando o relacionamento do tipo 1:1 ou 1:N
em certo momento ou perodo (como o aluguel de uma fita de vdeo), mas se deseja manter a
histria de todos os relacionamentos.
Quando falamos tambm da cardinalidade mnima usamos notao de par ordenado,
(0,1):(1,N) por exemplo, onde o primeiro nmero do par indica a cardinalidade mnima e o
segundo a mxima. A cardinalidade mnima indica uma exigncia da participao de uma
instncia da entidade em relacionamentos. A cardinalidade mnima 0 em ambos os lados
indica a existncia prpria de ambos os objetos. A cardinalidade mnima 1 pode indicar a
necessidade de um objeto pertencer ou ser criado por outro.
comum evitarmos relacionamentos onde ambos os lados exijam como cardinalidade
mnima 1. O motivo que um par de entidades s pode ser colocado na memria do
sistema em uma mesma transao, no permitindo que primeiro coloquemos a instncia de
uma entidade na memria e depois uma instncia relacionada da outra entidade.
Temos ento os seguintes tipos de relacionamentos:

Relacionamentos um para um.

o (0,1):(0,1)

Esse relacionamento significa que uma instncia do primeiro

conjunto pode ou no se relacionar com uma instncia do segundo
conjunto, porm pode ter apenas um relacionamento. O mesmo
vale do segundo conjunto para o primeiro.

Esse relacionamento encontrado quando possvel formar pares

entre duas entidades, mas esses pares so opcionais.

Um exemplo seria o caso da alocao cabines e reboques de

caminhes em uma empresa de aluguel de viaturas. Cabines e
reboques podem ser trocados arbitrariamente. Em certo momento,
cada cabine s pode ter um reboque e vice-versa. Alm disso,
algumas vezes uma das partes fica guardada na garagem enquanto
a outra utilizada.

Outro caso que podem mostrar so auto-relacionamentos desse

tipo. Uma igreja ou um templo, por exemplo, pode ter um
catlogo de freqentadores e querer saber quem casado com
quem (e quem solteiro, ou seja, no tem nenhum
relacionamento).

o (1,1) :(0,1)

122

Esse relacionamento significa que a primeira entidade

obrigatoriamente tem um relacionamento, mas ele opcional para
a segunda entidade. Em ambos os casos apenas um
relacionamento permitido.

Esse relacionamento encontrado quando uma entidade possui ou

controla de alguma forma outra. Em alguns casos as duas
entidades podem ser unidas em uma s.

Ele menos comum que o relacionamento (1,1):(0,N).

Um exemplo seria uma distribuio de papis de uma pea de

teatro em uma companhia de atores. Cada ator s pode fazer um
papel, alguns atores podem no ter papel, mas todos os papis tm
um ator, e apenas um ator.

o (0,1):(1,1), similar ao anterior

o (1,1):(1,1)

Esse relacionamento pouco comum, pois indica que uma

entidade no pode existir sem estar relacionada com outra, e tudo
isso apenas uma vez. Normalmente pode ser substitudo pela
unificao das duas entidades em uma s.

Algumas vezes utilizado para diferenciar aspectos diferentes da

mesma entidade. Por exemplo, um avio uma entidade que tem
vises comerciais, de mecnica, de operao, etc. Fica muito
complicado, em um modelo ER, colocar todos os atributos, que
chegam a centenas, em uma s entidade, assim podem ser criados
relacionamentos (1,1):(1,1) para tratar essa modelagem.

Esse relacionamento no recomendado, pois exige que ambas as

entidades sejam sempre criadas juntas.

Relacionamentos 1 para N
o

(0,1):(0,N)

A primeira entidade pode ou no participar do relacionamento,

mas apenas uma vez. A segunda entidade pode ou no participar
do relacionamento, e ainda pode faz-lo vrias vezes.

Esse um relacionamento muito comum. Normalmente significa

que dois objetos que no possuem nenhum relacionamento de
propriedade ou restrio de existncia podem ser colocados em
uma relao hierrquica.

Exemplo: esse tipo de relacionamento pode ser encontrado em

locais onde temos um estoque de objetos que so alocados a
departamentos da empresa, por exemplo, computadores. Um
computador s pode estar alocado em um departamento ou pode
estar no estoque (sem alocao). Um departamento pode ter 0, 1
ou vrios computadores alocados para si.

o (0,N):(0,1), similar ao anterior

o (0,1):(1,N)

123

Esse relacionamento normalmente tambm indica uma relao

hierquica.. O primeiro objeto pode opcionalmente pertencer a
essa relao, enquanto o segundo objeto obrigatoriamente
pertence a relao.

No muito comum, pois exige que uma instncia tenha no

mnimo uma filha, mas as filhas podem existir de forma
independente.

Pode ser usado quando algo para existir deve ter ao menos uma
parte, mas estas partes tem vida prpria, mesmo s podendo ser
usadas em um lugar.

Isso pode ser encontrado, por exemplo, no relacionamento entre

uma venda e os itens (quando nicos) vendidos. Uma loja de
carros novos, por exemplo, pode em uma mesma venda negociar
vrios carros, mas necessariamente a venda contm um carro. J o
carro pode ter sido vendido ou no.

o (1,N): (0,1), similar ao anterior

o (1,1):(0,N)

Indica uma maternidade da segunda entidade em relao

primeira, ou seja, cada instncia da primeira entidade obrigada a
possuir uma me, e apenas uma, que seja instncia da segunda
entidade.

um dos relacionamentos mais comuns.

Pode ser encontrado, por exemplo, na relao entre automveis de

uma empresa e multas recebidas. Cada multa de apenas um
automvel, mas podem existir automveis com 0, 1 ou mais
multas.

o (0,N) :(1,1), similar ao anterior

o (1,1):(1,N)

Indica uma maternidade da segunda entidade em relao

primeira, ou seja, cada instncia da primeira entidade obrigada a
possuir uma me, e apenas uma, que seja instncia da segunda
entidade. Alm disso, obrigatoriamente a me deve possuir uma
filha.

Esse relacionamento apresenta o inconveniente de exigir criar uma

entidade filha para criar a entidade me.

Pode ser encontrado, por exemplo, em um cadastro de pessoas

jurdicas, que devem possuir um endereo, mas podem possuir
mais de um.

Tambm encontrado na modelagem normatizada de objetos que

contm listas que obrigatoriamente possuem um item, como uma
nota fiscal.

o (1,N):(1,1) , similar ao anterior

Relacionamentos N para M
o (0,N):(0,N)

124

Esse relacionamento muito comum. Representa a forma mais

geral de relacionamento, opcional e com todas as possibilidades
para ambos os lados.

Pode ser encontrado, por exemplo, na relao entre alunos e

cursos oferecidos em um semestre em uma universidade. Alguns
cursos no recebem inscrio, alguns alunos no fazem inscrio
em nenhum curso.

o (0,N):(1,N)

Semelhante ao (0,N):(0,N). Tambm muito comum, porm agora

exigimos que haja pelo menos um relacionamento na segunda
entidade.

Pode ser encontrado, por exemplo, na relao entre msicas e CDs

onde esto gravadas, para controle de uma discoteca. Uma mesma
msica pode estar em vrios CDs, mas no possvel registrar um
CD sem msicas (deve existir pelo menos uma). Porm uma
msica pode nunca ter sido gravada.

o (1,N):(0,N), similar ao anterior

o (1,N):(1,N)

Aqui temos um relacionamento mltiplo que deve existir pelo

menos uma vez.

Um exemplo o relacionamento entre salas de uma empresa e

mveis colocados nessa sala.

Essa representao muitas vezes verdadeira, mas evitada,

sendo trocada pelo relacionamento (0,N):(1,N), pois exige que
ambas as entidades, quando esto sendo criadas, sejam sempre
criadas juntas, ou que existam algumas entidades na base como
semente.

125

(0,1)

(0,1)

(0,1)

(1,1)

(1,1)

(0,N)

(0,N)

(0,N)

(1,1)

(1,N)

(1,N)

(0,N)

(1,N)

(1,N)

(0,1)

(1,N)

(1,1)

(0,1)

(0,N)

(1,1)

Figura 58. Tipos de relacionamentos entre entidades, baseado no conceito

que uma entidade um conjunto de instncias.

1.8.2 Descrevendo Relacionamentos

Relacionamentos podem ser descritos por linhas ligando duas entidades ou por um
losango ligado por linhas s entidades. Em ambos os casos possvel anotar os
relacionamentos com nomes e com a sua cardinalidade (ver exemplos mais a frente).

O nome escolhido para o relacionamento pode estar na voz ativa (me gera filho) ou
na voz passiva (filho gerado por me). Algumas notaes permitem que se usem os dois
nomes (um por cima e um por baixo da linha de relacionamento). Geralmente se usa o nome
que permite a leitura do relacionamento da esquerda para a direta na parte de cima da linha
(ou se d preferncia a esse nome quando apenas um pode ser utilizado).

126

Relacionamentos tambm devem ser descritos e comentados, sendo importante

responder qual sua funo no sistema, o que eles representam, como e quando so
estabelecidos ou destrudos.
Aluno
Escola
NomeEscola
EnderecoEscola

CPF
NomeAluno
EnderecoAluno
NomePai
NomeMae

Figura 59. Um relacionamento entre escola e alunos. Como veremos mais

adiante, segundo a notao da Engenharia da Informao, uma escola
pode ter 0,1 ou mais alunos, enquanto um aluno est em uma escola ou
em nenhuma escola.

1.9

Atributos

Todo atributo descreve de alguma forma a instncia da entidade. Alguns atributos so

especiais e definem a entidade, mesmo que no de forma unvoca. Esses so os atributos
nominativos. Outros atributos permitem definir outro objeto que no o sendo tratado, so ou
atributos referenciais. Um exemplo de atributo referencial fbrica para automvel,
referenciando a fbrica onde foi construdo. uma opo do analista criar ou no entidades
que permitem a substituio de um atributo referencial por um relacionamento38.
1.9.1 Descrevendo Atributos
Devemos definir as seguintes caractersticas:

Nome

Descrio

Domnio (valores vlidos, como inteiro, real, string ou uma lista de valores, ou
ainda tipos criados pelo projetista).

Tipos de nulos aceitos

Exemplos

Na descrio devemos nos preocupar em explicar qual a finalidade do atributo, como

so atribudos os valores, o que significa cada valor, quem define a escolha do valor, quando,
por que e por quem o valor atribudo ou alterado, etc.
Atributos so atualmente denotados no mesmo retngulo da entidade, como mostrado
nos exemplos a seguir.

1.10

Identificando Entidades

Como vimos no incio do captulo, uma abstrao importante a identificao. No

caso de modelos ER, essencial que cada instncia de uma entidade possa ser identificada
unicamente com um objeto ou conceito do mundo real. Para fazer essa identificao so
utilizados atributos e relacionamentos identificadores.

38

Especificaes ou descries

127

Algumas vezes mais de um atributo, ou relacionamento, serve como identificador

nico, porm de forma independente. No Brasil, esse o caso das placas de carro e dos
nmeros de chassi. Definido um, o outro est automaticamente definido, mas ambos podem
ser escolhidos de forma independente como identificador principal. Dizemos que ambos so
chaves candidatas. Uma chave candidata no pode conter atributo que no auxiliam na
identificao nica da instncia. O que for escolhido ser a chave primria, ou outros so
conhecidos como chaves alternativas.
1.10.1

Atributos Identificadores (Chaves Candidatas e Chaves Primrias)

Alguns atributos tm o poder de distinguir as ocorrncias das entidades, isto , servem
para identificar univocamente uma instncia de entidade instncia do mundo real39.
Definido o valor desse atributo, os outros valores so dependentes e no podem ser
escolhidos, mas sim devem possuir um valor exato seguindo a realidade.

Um atributo identificador tpico em sistemas financeiros o CPF de uma pessoa fsica

ou o CNPJ de uma pessoa jurdica. Definido o CNPJ, a empresa, e todos os seus dados, esto
univocamente definidos (nome fantasia, endereo, etc.) no mundo real, e assim deve seguir o
sistema que estamos construindo.
Muitas vezes precisamos de mais de um atributo identificador para realmente
identificar uma instncia. Dizemos ento que a chave primria composta. Se usarmos
apenas um atributo como identificador, ento dizemos que a chave primria simples.
Aluno
CPF
NomeAluno
EnderecoAluno
NomePai
NomeMae
EscolaOrigem
EnderecoEscolaOrigem
Figura 60. Entidade Aluno, identificada pelo atributo CPF, na notao da
Engenharia da Informao.

Automvel

Automvel

Placa

Chassis

Chassis (AK1.1)
Modelo
Ano

Placa (AK1.1)
Modelo
Ano

Figura 61. A entidade automvel pode ser identificada unicamente tanto

pela placa como pelo Chassi, levando a dois modelos diferentes como
mostrado nesta figura. A notao fornecida pela ferramenta Erwin permite
a identificao das chaves alternativas (AK Alternate Key).

1.10.2

Relacionamentos Identificadores
Algumas instncias so identificadas tambm, ou at mesmo unicamente, por seus
relacionamentos. Uma forma de denotar isso utilizar uma linha mais grossa no
relacionamento ou algum smbolo especfico.40
39

Ou seja, servem para modelar a abstrao de identificao

40

A notao IDEF1X, por exemplo, usa um crculo negro.

128

Alguns autores chamam as entidades que so identificadas por seu relacionamento

com outras entidades de entidades fracas ou entidades dependentes. Atualmente esses
nomes so considerados derrogatrios para entidades que podem ser muito importantes em
um modelo. Os alunos tambm, muitas vezes, tendem a achar que no devemos modelar
entidades fracas, concluso que est absolutamente errada.
Chaves Estrangeiras
No modelo conceitual no existe o conceito de chave estrangeira, que uma
caracterstica do modelo relacional. Uma chave estrangeira uma chave de outra tabela que
usamos em uma tabela para indicar o relacionamento. Porm, comum que as ferramentas de
modelagem copiem as chaves estrangeiras automaticamente41. Em benefcio da prtica atual,
e em detrimento da pureza terica, mostramos a seguir algumas possibilidades da notao de
relacionamento.
Empresa
CNPJ

Produto
Nome

NomeFantasia
NomeRegistro
Telefone
Contato

Preco
Descrio

Figura 62 Entidades identificadas por um relacionamento (Produto) podem

ser denotadas de uma forma diferenciada, para declarar que sua
existncia dependente da existncia de outra entidade. Software Erwin.

Empresa
CNPJ

Produto
Nome

NomeFantasia
NomeRegistro
Telefone
Contato

Preco
Descrio

Figura 63. O mesmo relacionamento, agora no identificador. Percebemos

que a entidade Produto agora tem o seu smbolo normal. Software Erwin.
Empresa

Empresa
Produto

CNPJ
NomeFantasia
NomeRegistro
Telefone
Contato

produz

Nome
CNPJ (FK)
Preco
Descrio

Produto

CNPJ
NomeFantasia
NomeRegistro
Telefone
Contato

Nome
produz

CNPJ (FK)
Preco
Descrio

Figura 64. Uma viso do modelo lgico ainda do mesmo relacionamento,

agora recebendo um nome. Perceba que, dependendo do relacionamento
ser identificador ou no, a chave da entidade me copiada para a
chave ou para os atributos comuns da entidade filha. Software Erwin

1.11

Descrio Grfica do Modelo

Vrias so as notaes existentes para o modelo de entidade e relacionamento.

Usaremos nesse texto a notao de Martin, tambm conhecida como Information
Engineering, fornecida pelo software Erwin.
41

No Erwin essa cpia chamada migrao e opcional no modelo lgico.

129

Nessa notao no temos um smbolo para relacionamentos, apenas um retngulo para

entidades. Os relacionamentos so indicados por linhas. Uma linha cheia indica um
relacionamento identificador. Uma linha tracejada indica um relacionamento no
identificador. Por isso, no podemos usar relacionamentos com atributos, necessitando de
uma nova entidade nesse caso. Tambm no podemos criar relacionamentos mltiplos,
necessitando de criar entidades para represent-los.
Apesar de parecer que temos um modelo menos poderoso, temos na verdade apenas
uma sintaxe mais simples, com o mesmo poder de modelagem. Algumas decises tambm
ficam tomadas automaticamente tambm. Por exemplo, no precisamos decidir se um objeto
com atributo um relacionamento ou uma entidade, pois relacionamentos no tm atributos
em nosso modelo. Acreditamos que a modelagem segundo as regras do IDEF1X ou da
Engenharia de Informao possibilita encontrar mais facilmente um modelo essencial do
sistema que as regras tradicionais de Chen ou ainda extenses as mesmas.

um ou mais

zero ou mais

zero ou um

um e apenas um

Figura 65. Notao para a cardinalidade

possui
Pessoa

Apartamento
possudo

Figura 66. Uma pessoa possui zero ou mais apartamentos e um

apartamento possudo por pelo menos uma pessoa ou mais

possui
Pessoa

Apartamento
possudo

Figura 67. As setas indicam a forma de leitura do diagrama

A cardinalidade indicada por trs smbolos usados na ponta da linha que indica o
relacionamento: uma linha indica 1, um crculo indica 0 (zero), e um p-de-galinha indica
130

n. Dessa forma podemos anotar o mnimo e o mximo da cardinalidade usando dois smbolos
em cada ponta.
O nome do relacionamento colocado acima ( esquerda) da linha que o indica,
sendo o nome do relacionamento inverso colocado abaixo ( direita). Normalmente se l a
notao partindo de uma entidade, lendo o nome do relacionamento, lendo a cardinalidade da
ponta oposta e finalmente o nome da segunda entidade.
Nessa notao os atributos podem ser colocados dentro da caixa que representa as
entidades, como apresentado na prxima seo.
1.11.1

Exemplos de notaes
Vamos descrever a seguir o seguinte modelo em vrias notaes:

Apresentaremos o modelo de uma locadora de vdeo. A locadora trabalha com fitas

de vdeo. Cada fita de vdeo contm um filme, porm cada fita deve ser identificada
unicamente, pois elas podem ser dubladas ou legendadas. As fitas so emprestadas para
clientes em um dia e hora especfico. Um cliente pode ficar com vrias fitas, ou nenhuma.
Uma fita pode estar com apenas um cliente, ou estar na loja e no estar com cliente nenhum.
importante saber para quem cada fita especfica foi emprestada, para auditar clientes que
estragam fitas, por isso todas as fitas so numeradas com um cdigo nico. Os filmes so
dirigidos por diretores e contm atores.
Observamos que o cliente um papel assumido por uma pessoa, a fita de vdeo um
objeto fsico, existente, o filme uma obra de arte que est representada na fita (um
conceito), diretor e ator so tambm papis assumidos por pessoas dentro da idia de filme e
que um aluguel um contrato entre o cliente e a locadora.
Ateno para outro detalhe: no existe a entidade locadora, pois este sistema
destinado a uma s locadora. Seria uma entidade nica, que claramente uma constante do
sistema. A presena de entidades desse tipo um erro comum nos modelos feitos por
principiantes. Porm, se tivssemos um software para uma rede de locadoras, seria
interessante guardar em que locadora est cada fita, o que exigiria essa entidade.

Figura 68. Modelo inicial da locadora, notao Information Engineering,

software ERWIN 3.5.

131

Figura 69. Modelo da locadora, com atributos e os tipos (com cones) dos
atributos, notao EI, software ERWIN 3.5.

Figura 70. Modelo da locadora, mostrando chaves primrias e chaves

estrangeiras (FK) (que no deviam estar em um modelo conceitual!),
notao EI, software ERWIN 3.5.

Figura 71. O mesmo modelo anterior, com a notao IDEF1X, software

ERWIN 3.5.

A Cardinalidade nas Notaes

Podemos identificar pelo menos trs escolas quanto maneira de denotar a
cardinalidade das notaes.

132

A primeira, e original, chamada associativa, e indica junto entidade quantas

ocorrncias da mesma podem estar associadas a uma determinada entidade. Veja na Figura 72
que um filme est associado a vrias fitas.
a que encontramos na notao da Engenharia da Informao. A segundo a
participativa, que indica quantas vezes uma entidade participa de um relacionamento. Na
Figura 73 um filme participa at vrias vezes do relacionamento. Essa interpretao est mais
perto da idia matemtica que o relacionamento um conjunto de pares ordenados.
Finalmente, modelos com IDEF1X usam uma notao prpria, com significado
dependente de uma combinao especial de smbolos.

Fita

Aluga

Cliente

Contm

Filme

Atua

Dirige

Ator

Diretor

Figura 72. O mesmo modelo, segundo a notao original de Peter Chen,

associativa. Note que escolhemos manter o aluguel como um
relacionamento nesse modelo, que permite relacionamentos com
atributos, software Visio 2000.

133

Fita

(0,n)

Aluga

(0,n)

Cliente

(1,1)

Contm

(1,n)

(1,n)

Atua
(1,n)
Ator

Filme

(1,n)

Dirige
(1,n)
Diretor

Figura 73. Mesma figura anterior, agora usando a notao participativa,

com mnimos e mximos de cardinalidade proposta por Ceri. Ateno que
as cardinalidades ficam na posio contrria notao anterior, software
Visio 2000.

1.11.2

Notao adotada
Podemos adotar qualquer notao, contanto que seja utilizada de forma consistente
em um projeto ou em uma empresa. No curso que ministramos, porm, sugerimos as
seguintes notaes: IDEF1X ou IE. No recomendamos mais o uso de notaes com
losangos.

Se escolher a ferramenta Erwin, utilize a notao de information engineering.

Se escolher o Visio 2002, utilize a notao que utiliza crow-foot. Apresente os tipos
dos atributos e as chaves primrias, mas no represente as chaves estrangeiras.
Na prova: Muitas vezes melhor representar os atributos como crculos do que dentro
das caixas.

1.12

Tcnicas de Desenvolvimento do Modelo

A seguir apresentamos quatro estratgicas bsicas para desenvolver o modelo ER de

um sistema. Nenhuma estratgia melhor que as outras em todos os casos, nem todas as
estratgias vo levar a mesma soluo.
1.12.1

Tcnica Top-Down
Na tcnica top-down, desenvolvemos o modelo ER partindo de entidades altamente
abstratas e aplicando transformadas que permitem encontrar entidades menos abstratas e mais
representativas do sistema sendo desenvolvido. O processo termina quando todos os
requisitos foram representados.

Essa tcnica necessita que o analista possa construir um modelo abstrato em sua
mente, o que pode ser difcil em grandes sistemas.
Heuser [B36] sugere os seguintes passos para essa tcnica:

134

1. Construo de um modelo superficial

Levantamento das entidades

Identificao dos relacionamentos, com cardinalidades mximas.

Identificao dos atributos

Determinao dos atributos identificadores

Verificao do aspecto temporal

Construo do modelo detalhado

Determinao dos domnios dos atributos

Determinao das cardinalidades mnimas dos relacionamentos

Levantamento das restries de integridade no representveis no modelo

Verificao do modelo, buscando construes redundantes ou derivveis

Validao junto ao usurio

A seguir veremos essas transformaes, tratando algumas vezes de uma questo que
s abordada um pouco mais tarde, as formas normais.
Transformar uma entidade em duas entidades relacionadas: muitas vezes dentro de uma
entidade estamos na realidade olhando duas entidades mais especficas. Duas formas so
possveis: a entidade original existe, mas contm dentro dela outra entidade, ou a entidade
original na verdade dividida em duas entidades. No primeiro caso estamos extraindo a nova
entidade da entidade original. No segundo caso estamos detalhando parte do nosso modelo. O
primeiro caso pode se confundir naturalmente com o caso a seguir, onde um atributo
transformado em uma entidade, dependendo do momento da especificao. Muitas vezes uma
entidade na verdade contm dados que compe duas entidades.
Transforma atributo, ou conjunto de atributos, em entidade e relacionamento: isso pode
acontecer quando um atributo mltiplo (quebrando a primeira forma normal), uma
especificao (por exemplo, uma marca), ou ainda em casos que quebram a segunda e terceira
forma normal.
Criao de entidades mais especficas: algumas vezes identificamos inicialmente uma
entidade que um tipo muito geral e mais tarde descobrimos tipos especficos que representam
melhor o domnio da aplicao.
Transformar uma entidade em vrias entidades no relacionadas: isso no muito normal,
pois entidades no relacionadas normalmente no se encontram modeladas dentro de uma mesma
entidade, mesmo que temporariamente. Mesmo assim, pode ser um primeiro passo para depois
descobrirmos qual o relacionamento que as une.
Transformar um relacionamento em dois relacionamentos em paralelo: apesar de no
acontecer muitas vezes em um mesmo sistema, uma transformao comum. Acontece quando
entendemos que duas entidades so relacionadas e apenas mais tarde compreendemos que elas
so relacionadas de vrias formas diferentes e no de uma s forma.
Transformar um relacionamento em uma entidade: essa modificao muito comum. Muitas
vezes nossa compreenso inicial de um evento ou de uma relao qualquer entre duas entidades
muito simples. Mais tarde, compreendendo melhor esse relacionamento, entendemos que mais
interessante represent-lo como uma entidade.

135

 Criao de atributos: a modificao mais simples e comum. S estamos citando para

completar o conjunto de operadores top-down.

Uma entidade pode ser

transformada em duas
entidades relacionadas

Um atributo de uma
entidade pode ser
transformado em uma
entidade relacionada

Uma entidade pode ser

transformada em uma
entidade e um conjunto de
especializaes.

Uma entidade pode ser

transformada em um
nmero de entidades no
relacionadas

Um relacionamento pode
ser transformado em dois
relacionamentos em
paralelo

Um relacionamento pode
ser transformado em uma
entidade relacionada com
as duas entidades ligadas
pelo relacionamento

Um entidade pode receber

um atributo

Um relacionamento pode
receber um
relacionamento

Figura 74. Transformadas Top-Down

Como escolher entre um atributo ou Entidade e Relacionamento

Se o conjunto de valores for fixo durante toda a vida do sistema, pode ser modelado
como atributo. Se for varivel, ento deve ser um relacionamento com outra entidade.
Se tiver relao com outro objeto deve ser um relacionamento. Caso contrrio, pode
ser um atributo.

136

1.12.2

Tcnica Bottom-Up
Na tcnica Bottom-Up, partimos das partes para construir o todo, partindo dos
conceitos mais elementares para construir conceitos mais complexos. Os requisitos so
decompostos, analisados de forma independente e agregados em um esquema global [B32].

Criao de entidade ou atributo: so as operaes bsicas da tcnica bottom-up.

Unificao de atributos em uma entidade:

Organizao de entidades em uma hierarquia de herana:

Criao de relacionamento entre entidades

Uma entidade pode ser

criada para satisfazer uma
necessidade

Atributos levantados
podem formar uma
entidade

Entidades j levantadas
podem ser unificadas em
uma estrutura de
generalizao/
especializao

Entidades no
relacionadas podem
necessitar de um
relacionamento entre elas

Figura 75. Transformadas Bottom-Up

1.12.3

Tcnica Inside-Out
Inicia nos conceitos mais importantes e navega em direo aos menos importantes.
comum que modelos E-R se desenvolvem em torno de algumas entidades que representam os
conceitos mais importantes de um domnio ou aplicao. A partir desses conceitos buscam-se
entidades relacionadas, possivelmente usando tanto operaes das tcnicas top-down como
bottom-up.
1.12.4

Tcnica Mista
Normalmente, modelos E-R no so desenvolvidos de forma Top-Down ou Bottomup, mas sim de uma forma mista, principalmente quando a uma grande quantidade de
entidades no esquema. Dessa forma, um esquema inicial de alto nvel dividido, de forma
que cada partio possa ser considerada separadamente.
137

1.12.5

Que tcnica usar

Desaconselhamos o uso da tcnica bottom-up. Acreditamos que a verdadeira
modelagem E-R deve seguir uma tcnica mista, a partir da compreenso do analista do que
so as entidades e seus atributos, mais parecida com a tcnica inside-out.
1.12.6

Equivalncia de modelos
Dois modelos so equivalentes quando representam uma mesma realidade.

Algumas equivalncias so facilmente identificveis:

1.13

Relacionamentos n x m podem ser substitudos por uma entidade42.

Relacionamentos 1x1 podem ser eliminados, unificando-se as entidades43.

Representando o Aspecto Temporal

Muitas vezes uma aplicao necessita que sejam representados aspectos temporais.
Isso acontece, por exemplo, quando o preo de um contrato depende de sua data de
contratao, de acordo com vrios planos.
Dois efeitos so interessantes de serem discutidos: a necessidade de manter um
histrico do valor de um atributo (por exemplo, para responder a perguntas como quanto
custava uma ligao telefnica no dia 14 de novembro de 2001), como manter um histrico
de relacionamentos (por exemplo, para saber quais fitas o cliente alugou no passado,
permitindo que uma fita seja alugada vrias vezes).
No caso de necessitarmos de um histrico do valor do atributo, necessrio criar uma
nova entidade que represente o valor e a data de validade desse valor, sendo que essa
entidade se relaciona com a entidade original.
No caso de necessitarmos que um relacionamento seja mantido no histrico,
necessrio criar atributos que indiquem a validade desse relacionamento. Na prtica, o
relacionamento se torna uma entidade.

1.14

Formas Normais

As formas normais foram criadas para o modelo relacional44, para serem aplicadas no
modelo lgico, porm existem vantagens em utiliz-las no modelo conceitual, pois melhoram
a qualidade do modelo em relao a alguns quesitos45. O ato de normalizar implica na criao
de algumas tabelas que no so necessariamente criadas pelo analista preocupado apenas com
o modelo conceitual, influenciando sua longevidade e simplicidade total, diminuindo a

42

Mas no precisam ser obrigatoriamente substitudos. Modelos conceituais admitem e at ficam mais claros
com a presena de relacionamentos nxm.
43

Principalmente relacionamentos (1,1):(1,1). Qual o motivo de ter um par de entidades que s podem existir
juntas no sistema e considerar como entidades distintas?
44
Se voc tem dvidas sobre a diferena entre o modelo relacional e o modelo de entidades e
relacionamentos: o modelo relacional fala sobre a representao de dados como tuplas (relaes matemticas) em
tabelas, o modelo de entidades e relacionamentos fala da representao do mundo real em um modelo abstrato
composto de tipos de entidades e relacionamentos entre essas entidades.
45
Alguns autores no sugerem as formas normais em seus modelos conceituais e normalizam apenas seus
modelos lgicos. Essa prtica pode ser prejudicial ao entendimento do problema, pois as formas normais nos auxiliam
a desenvolver um modelo mais correto.

138

redundncia e favorecendo a possibilidade de dois analistas chegarem ao mesmo modelo por

vias independentes, ou concordarem em adotar um modelo nico. Tambm permitem que
algumas discusses, do tipo X entidade ou atributo sejam decididas imediatamente. Essas
caractersticas so objetivos claros da modelagem essencial e por isso nos parece bastante
adequado utilizar modelos conceituais normalizados.
O tratamento dado s formas normais nesse texto apenas introdutrio devendo o
leitor se referir a livros de bancos de dados ou de modelagem de dados para uma abordagem
mais completa.

1.14.1
Primeira Forma Normal (1FN)46
Algumas definies equivalentes, prprias do modelo relacional:

Diz-se que uma tabela est na primeira forma normal quando todos os seus
atributos so atmicos.

Diz-se que uma tabela est na primeira forma normal se cada coluna contm
apenas um valor e se cada linha contm as mesmas colunas.

Diz-se que uma tabela est na primeira forma normal quando no contm tabelas
aninhadas.

Diz-se que um modelo est na primeira forma normal se:

o Est integrado por tabelas
o As linhas da tabela so unvocas
o A linha no contm itens repetitivos
o Os atributos so atmicos

O atributo no contm valores nulos47

A seguinte tabela no est na 1FN:

Gerente

Empregado

Jim

Susan, Rob, Beth

Mary

Alice, John, Asim

Renee

Mike

Joe

Alan, Tim

Tabela 16. Tabela que no est na 1FN

46

Uma tabela (ou entidade) que no est na primeira forma normal denotada como N (no normalizada) ou
NFNF (Non-first normal form), ou ainda NF2

47

Essa regra foi abandonada na prtica pela necessidade que temos de trabalhar com esses tipos de valores.

139

Gerente

Empregado

Jim

Susan

Jim

Rob

Jim

Beth

Mary

Alice

Mary

John

Mary

Asim

Renee

Mike

Joe

Alan

Joe

Tim

Tabela 17. A mesma informao da tabela anterior normalizada em 1FN

Turma
Cdigo

smallint

Nome
Horrio
Alunos

String
smalldatetime
Lista de Alunos

Figura 76. Uma tabela no normalizada pode conter uma lista em um dos
campos.
FIGURA A SER RECUPERADA
Figura 77. Normalizando a tabela turma, aparece a tabela aluno, que
estava escondida em um atributo no atmico.

Recomendamos enfaticamente o uso da primeira forma normal, ou seja, a no

utilizao de atributos multivalorados, no modelo conceitual. Dessa forma evitamos a
ocultao de entidades e relacionamentos dentro de outras entidades, o que pode causar um
grande desnivelamento entre o modelo conceitual e a real dificuldade de implementao.
Um modelo de entidades e relacionamentos est na primeira forma
normal se todos seus atributos so tipos atmicos.
1.14.2

Algumas Anomalias Resolvidas pelas Formas Normais

Imaginemos a seguinte tabela, apenas na 1FN.

140

Ttulo

Ano

Durao

Tipo

Estdio

Estrela

Guerra nas
Estrelas

1977

124

Cor

Fox

Carrie Fisher

Guerra nas
Estrelas

1977

124

Cor

Fox

Carrie Fisher

Guerra nas
Estrelas

1977

124

Cor

Fox

Carrie Fisher

Might Ducks

1991

104

Cor

Disney

Emilio Estevez

Waynes
World

1992

95

Cor

Paramount

Dana Carvey

Waynes
World

1992

95

Cor

Paramount

Mike Meyers

Tabela 18. Uma tabela na 1FN, adaptada de [XXX Batini].

Podemos verificar que essa tabela est na 1FN, porm ainda apresenta os seguintes
problemas, que sero resolvidos pelas prximas duas formas normais:

Redundncia

o Muita informao est repetida desnecessariamente em vrias tuplas.

Por exemplo, o fato que o Estdio Fox fez Guerra nas Estrelas aparece
3 vezes.

Atualizao

o Se precisarmos alterar um dado de Guerra nas Estrelas, sua durao,

por exemplo, teremos que fazer isso vrias vezes.

Eliminao

o Se precisarmos apagar um filme, por exemplo, Might Ducks,

perdemos a informao que existe um estdio chamado Disney.

Incluso

o S podemos incluir um estdio se tivermos tambm um filme para

incluir.
1.14.3

Segunda Forma Normal (2FN)

Uma modelo de entidades e relacionamentos est na segunda forma
normal quando, alm de estar na primeira forma normal, no
contm dependncias parciais da chave, incluindo-se nessa chave
atributos e relacionamentos identificadores.

Uma dependncia (funcional) parcial ocorre quando uma coluna depende apenas de
parte de uma chave primria composta.48
Se A dependente funcional de X, usamos a notao X -> A.
Uma tabela est 2FN se est na 1FN e cada uma das colunas no pertencentes chave
primria no for dependente parcialmente dessa chave.
48

Logo se a chave primria for simples, a tabela na 1FN est automaticamente na 2FN.

141

Primeiro devemos notar que isso significa que uma tabela cuja chave seja formada por
um nico atributo est automaticamente na 2FN.
1.14.4

Terceira Forma Normal

Uma modelo de entidades e relacionamentos est na terceira forma
normal quando, alm de estar na 2FN, no contm dependncias
transitivas.

Uma dependncia funcional transitiva ocorre quando um atributo, alm de depender

da chave primria da entidade, depende de outro atributo ou conjunto de outros atributos no
identificadores da entidade.
Um exemplo de dependncia transitiva pode ser encontrado em um sistema
acadmico universitrio hipottico onde em uma entidade aluno fosse mantida a
informao escola de origem e endereo da escola de origem. O endereo dependente
da escola, que depende do identificador do aluno. Assim, para normalizar, criamos a entidade
escola, contendo nome e endereo (e outros campos necessrio), eliminamos esses campos da
entidade aluno, e finalmente criamos o relacionamento entre aluno e escola.
Aluno
CPF
NomeAluno
EnderecoAluno
NomePai
NomeMae
EscolaOrigem
EnderecoEscolaOrigem

Aluno
Escola
NomeEscola
EnderecoEscola

CPF
NomeAluno
EnderecoAluno
NomePai
NomeMae

Figura 78. Transformando a entidade aluno para a 3FN

Uma entidade est na terceira forma normal se est na 2FN e se nenhum atributo no
pertencente chave fica determinado transitivamente por esta.
A segunda e terceira formas normais fazem com que cada atributo que no seja
identificador fornea um fato sobre a entidade indicada pela chave e apenas pela chave [XXX
Kent 83]. Normalizar corresponde a criar relacionamentos 1:N ou 1:1.
1.14.5

Outras formas normais

Existem ainda outras formas normais, que so praticamente abandonadas no dia a dia.
A 4NF, a 5NF e a Boyce/Codd (BCNF). Todas elas lidam com fatos multivalorados, que
devem corresponder a relacionamentos N:M ou N:1. De acordo com o modelo relacional
temos as definies (e explicaes) que se seguem.

142

Uma tabela est na 4NF se, alm de estar na 3NF, no contm

dependncias multivaloradas.

Uma dependncia funcional multivalorada ocorre quando um atributo de uma tabela

implica na existncia de uma lista de valores para outro atributo na mesma tabela (coluna
dependente).
Uma relao R est na BCNF se sempre que X -> A for verdade em
R, e A no estiver contido em X, ento X uma chave candidata
para R..

Finalmente, a quinta forma normal trata da possibilidade de reconstruir uma

informao a partir de um modelo composto de partes menores com chaves primrias
diferentes. Se isso no for possvel, e o modelo est na 4NF, ento estar tambm na 5NF.
Por exemplo, a tabela a seguir pode ser substituda por trs outras que a seguem.
Vendedor
Empresa
Modelo
Joo
Ford
Caminho
Joo
Ford
Automvel
Joo
GM
Caminho
Joo
GM
Automvel
Jos
Ford
Automvel
Tabela 19. Relao que no est na 5NF

Vendedor
Joo
Joo
Jos

Empresa
Ford
GM
Ford

Empresa
Ford
Ford
GM
GM

Produto
Caminho
Automvel
Caminho
Automvel

Vendedor
Joo
Joo
Jos

Produto
Caminho
Automvel
Automvel

Tabela 20. Trs tabelas que substituem a tabela anterior

1.14.6

Formas Normais e o Modelo E-R

Podemos ver que as formas normais podem ser facilmente aplicadas ao modelo de
entidades e relacionamento simplesmente substituindo a palavra tabela pela palavra
entidade

1.15

Outros termos

Entidade Associativa: transformao de um relacionamento em entidade para permitir

relacion-lo em outro relacionamento.
Entidade Fraca: entidade que no possui identificador por si mesma, dependendo de
outra para sua existncia. No aprovamos essa classificao pelo peso do nome fraca. Muitas
vezes as entidades fracas so as mais importantes em um sistema.

1.16

Verificando o Modelo
Alguns erros comuns:

Estabelecimento de associaes desnecessrias

Usar uma entidade como atributo em outra entidade (e no fazer o relacionamento, que
seria o correto).
143

Modelar entidades nicas, principalmente uma que represente o sistema.

Permitir redundncias, como relacionamentos redundantes, principalmente os que podem

ser resolvidos por uma navegao em uma seqncia de relacionamentos. Tambm
atributos redundantes, com a cpia de um atributo que j pode ser alcanado por meio de
um relacionamento.

Esquecimento do aspecto temporal, isto , dos histricos das transaes, como atributos
que mudam de valor com o tempo ou relacionamentos que so alterados com o tempo.
Nesse caso, pode ser necessrio criar novas entidades.

Entidades isoladas, em geral incorretas, apesar de no necessariamente incorretas. Muito

mais raramente no modelo conceitual. Entidades isoladas podem algumas vezes aparecer
no modelo relacional para guardar constantes do sistema.

Entidades nicas, entidades que possuem apenas uma instncia esto geralmente erradas.

Entidades sem atributos: geralmente erradas, a menos que estejam sendo usadas no lugar
de um relacionamento n x m (mesmo assim, no seriam necessrias na modelagem
conceitual).

Eliminar uma entidade por ser fraca.

1.17

Leitura Complementar

Aconselhamos avidamente o livro de Paulo Cougo, Modelagem Conceitual de Dados

[B31] e o livro de Bertini, Ceri e Navathe, [B32], Conceptual Modelling. O tratamento
extensivo dado ao problema da modelagem conceitual de dados nesses dois livros pode ser de
grande ajuda ao analista iniciante ou experiente.
Outro livro nacional importante Projeto de Banco de Dados, de Carlos Alberto
Heuser. Muito bom mesmo.
Para a obteno de padres de projeto, o livro de David Hay, que em portugus
recebeu o nome de Princpios de Modelagem de Dados, mas em ingls se chama Data
Patterns, ou seja, Padres de Dados, tambm excelente. Ele tambm leva o leitor a
compreender seus padres por meio de uma modelagem Top-down, o que pode ser utilizado
como exemplos no aprendizado.
Para verificar como a modelagem de dados pode ser usada junto com a anlise
essencial, recomendamos o livro Complete System Analysis, de James e Suzanne Robertson
[B34], um dos melhores livros de anlise no mercado, contando com um longo exemplo
completo e exerccios. Dois outros autores brasileiros trataram desse assunto, Pompilho
[B37] e Barbieri [B38].
Para uma abordagem mais prtica, considerando desde o incio alguns fatores
tecnolgicos, o livro de Ruble, Practical Analysis & Design for Cliente/Server and GUI
Systems [B39] bastante til.

144

Captulo VIII. Modelo Funcional Essencial

Modelagem Estruturada
Modelagem Essencial
Atividades Essenciais
Eventos Essenciais (Externo, Temporal, No-Evento,
Esperado, No-esperado)
Memria Essencial

O Modelo Funcional tem como objetivo definir o que49 o sistema deve fazer, ou
seja, as funes que deve realizar para atender seus usurios.
Na Anlise Essencial fazemos essa definio de acordo com um conjunto de
princpios que nos permite escolher um modelo funcional especfico entre vrios possveis, o
Modelo Essencial.

VIII.1

Perspectiva Histrica

A modelagem funcional de sistemas teve grande desenvolvimento a partir da criao

das metodologias estruturadas de anlise e projeto. Entre diferentes propostas, a Anlise
Estruturada foi a que teve maior repercusso, sendo que o Diagrama de Fluxo de Dados
(DFD) se tornou uma ferramenta obrigatria em todos os cursos de anlise de sistemas. Em
um DFD, o sistema descrito pela composio de quatro objetos bsicos: agentes externos50,
que interagem com o sistema, processos (ou funes), que caracterizam o sistema,
memrias51, que contm os dados necessrios o sistema funcionar, e fluxos de dados entre
esses objetos.
A Anlise Estruturada, e outras tcnicas equivalentes, se propunham a tratar das
questes lgicas do desenvolvimento do sistema, em detrimento das questes fsicas, que
seriam tratadas na fase de projeto. O problema que nenhuma tcnica deixava claro quais
eram essas questes, ou melhor, como diferenciar o fsico do lgico. Alm disso, ainda
foram encontrados vrios problemas na Anlise Estruturada, entre eles: a dificuldade de
manter o modelo atualizado e a possibilidade de vrias pessoas fazerem modelos diferentes
de um mesmo sistema.
O primeiro problema atendido pelo uso de ferramentas CASE. importante deixar
claro que impossvel desenvolver uma verdadeira Anlise Estruturada sem o uso de
software para manter essa anlise atualizada e correta. O segundo problema, porm, muito
mais grave, pois ele no trata da forma de uso, mas do mtodo propriamente dito.

49

Devemos entender que quando nos propomos a descobrir o que o sistema deve fazer, estamos simultaneamente
evitando nos preocupar com como o sistema deve fazer, o que ser feito nas fases mais avanadas do
desenvolvimento.
50

Originalmente chamadas de entidades externas. Esse nome no utilizado neste texto para no confundir com o
conceito de entidade (de dados). Atualmente, nos modelos orientados a objeto, conhecido como ator.
51

Originalmente chamadas de depsitos de dados.

145

Em 1984, dezesseis anos antes de este texto ser escrito52, McMenamim e Palmer
[B17] conseguiram definir de forma clara um mtodo de desenvolvimento que permite
dividir, sem sombra de dvidas, o que essencial do que encarnao. Essencial e
Encarnao podem ser vistos como uma nova maneira de definir o que lgico ou
fsico, mas vamos ficar com os nomes dados por Palmer e McMenamim para evitar toda
carga cognitiva trazida pelos nomes lgico e fsico. Eles tambm permitiram que
descobrssemos, com perguntas simples, se um requisito do sistema verdadeiro ou falso.
Esse mtodo uma evoluo da Anlise Estruturada e conhecido como Anlise Essencial.
Yourdon, mais tarde, vai denominar uma nova verso da Anlise Estruturada, baseada na
Anlise Essencial, de Anlise Estruturada Moderna. Existem pequenas diferenas na forma
de Palmer e McMenamim e Yourdon. Esse texto baseado em verses ainda mais modernas,
principalmente nos textos de [B34] e Ruble [B39], mas ainda mantendo a essncia da
Anlise Essencial.

VIII.2

A Anlise Essencial

O objetivo da Anlise Essencial descobrir, e documentar, todos os requisitos

funcionais verdadeiros de um sistema e apenas esses requisitos. Para que isso seja possvel,
adotamos um conjunto de princpios e conceitos que nos permitem identificar esses requisitos
dentro de toda a informao levantada durante um processo de anlise.
O Mtodo Essencial no eficaz em qualquer tipo de projeto. Na verdade, estamos
preocupados basicamente com sistemas de informao que sejam sistemas interativos de
respostas planejadas. Esses sistemas funcionam sempre em resposta a algum evento fora do
seu controle para o qual possamos definir uma resposta planejada. Deve ficar claro que no
estamos interessados em eventos que exigem respostas ad-hoc, isto , caso a caso. Usaremos
o exemplo clssico do vendedor de passagens de avio: podemos fazer um sistema capaz de
responder as perguntas tpicas como qual o preo da passagem para So Paulo ou Quando
sai o prximo vo para Braslia, porm no podemos considerar com esse mtodo um
sistema que responda a absolutamente todas as perguntas que um ser humano poderia
responder, como Qual foi o resultado do ltimo jogo do Amrica?.

VIII.3

Os princpios da Modelagem Essencial

Os princpios da modelagem essencial sero os nossos guias no processo de anlise. O

que acontece nesse processo que vrias vezes temos a opo de tomar dois ou mais
caminhos. Na modelagem estruturada tradicional temos apenas vagas recomendaes que nos
auxiliam a escolher esse caminho, na modelagem essencial temos princpios especficos que
nos orientam nessa escolha.
Os princpios da Anlise Essencial so:

O oramento para a complexidade

A neutralidade tecnolgica

A tecnologia interna perfeita

O modelo essencial mnimo

52
impressionante que tanto tempo depois da criao e divulgao da Modelagem Essencial e da Anlise Estruturada
Moderna, tantas pessoas ainda trabalhem com as tcnicas anteriores e, surpresos, declarem ser totalmente ineficazes.
o equivalente a esperar obter rendimento e velocidade de modelos atuais em automveis de 30 anos atrs!

146

A esses princpios somaremos um quinto, j apresentado, o princpio da ausncia de

surpresas, por acreditarmos que perfeitamente condizente com os princpios essenciais.

VIII.3.1
O Oramento para a Complexidade
Esse princpio nos orienta a modelar um sistema que possamos compreender. Para
isso devemos manipular a complexidade do modelo de forma a manter tanto o todo como
cada uma de suas partes em um nvel de complexidade compatvel com a inteligncia
humana.
Para isso utilizamos tcnicas de particionamento do sistema e o controle de
caractersticas que aumento a complexidade do modelo, entre elas:

Controle do nmero de componentes de cada parte do modelo;

Controle da complexidade interna de cada parte do modelo;

Controle da complexidade da interface entre componentes;

Manuteno da qualidade dos nomes utilizados no modelo, e

Manuteno da qualidade da representao do modelo, por exemplo, quanto clareza dos

diagramas.

Um das tcnicas mais citadas para controlar a complexidade a de manter o nmero

de componentes de cada modelo ou sub-modelo entre 5 e 9. Isso decorre de uma pesquisa
[B40] que determinou que o ser humano mdio tem a capacidade de se concentrar em 7
elementos, com variao de 2. O artigo interessante, apesar de antigo.

VIII.3.2
A Neutralidade Tecnolgica
O princpio da neutralidade tecnolgica exige que um modelo essencial no inclua em
nenhuma de suas partes indcios da tecnologia de implementao [B17].
Essa exigncia, apesar de importante, das mais quebradas pelos analistas. Isso
acontece por que geralmente j sabemos qual a tecnologia em que vamos implementar o
sistema. importante manter a neutralidade no s para permitir uma anlise mais objetiva
do verdadeiro problema do usurio, mas tambm para aumentar a durabilidade dessa anlise.
Alguns autores j criticam a neutralidade tecnolgica, ou simplesmente passam por
cima dessa questo, colocando preocupaes de tecnologia j nessa fase. A questo tem
relao com a necessidade de se assumir algumas premissas para obter solues mais
eficientes. Em todo caso, na definio de sistemas de informao, a metfora eventoatividade-memria fornecida pela anlise essencial na maioria dos casos suficiente para
fornecer todo o arcabouo necessrio para uma boa anlise de requisitos. Devemos ento no
s seguir esse princpio, mas tambm us-lo como ferramenta de conferncia em cada um dos
nossos passos, verificando se h ou no comprometimento com uma tecnologia especfica,
corrigindo cada ponto onde for encontrado esse comprometimento para uma especificao
tecnologicamente neutra.

VIII.3.3
A Tecnologia Interna Perfeita
O sistema deve ser modelado com a suposio que a tecnologia interna ao sistema
perfeita.
Por tecnologia interna perfeita queremos dizer que todos os recursos do sistema so
ideais. A velocidade do sistema perfeito infinita, significando que no h espera para
conseguir um resultado. A memria de um sistema perfeito tambm no possui limitaes,
podendo guardar qualquer quantidade de informao por um perodo indeterminado, sem
147

nenhum atraso no tempo de busco. O sistema perfeito nunca apresenta falhas ou necessidade
de manuteno.
Devemos, porm, lembrar que no fazemos essa suposio sobre a tecnologia externa
ao sistema, apenas sobre a tecnologia interna ao sistema. Alm disso, essa suposio s
feita na fase de anlise, sendo esquecida na fase de projeto, onde temas como velocidade,
tamanho de memria e gerncia de riscos passam a fazer parte de nossas preocupaes, junto
com outras caractersticas que, apesar de no fazer parte da suposio de um sistema perfeito,
tambm so postergadas para a fase de projeto, como controle de acesso (segurana).
Na prtica interessante imaginar o sistema como um gnio da lmpada, capaz de
fazer qualquer coisa em tempo zero, se possuir a informao necessria.

Figura 79. O sistema deve ser visto como um gnio todo-poderoso,

capaz de realizar qualquer pedido imediatamente, se tiver a informao
necessria.

VIII.3.4
O Modelo Essencial Mnimo
Os princpios anteriores vo definir claramente a nossa forma de trabalho, porm
muitas vezes sero inteis para ajudar a escolher qual o o modelo essencial entre dois
modelos possveis. Precisamos, porm, para garantir que nosso mtodo tem uma resposta
nica, ter uma forma de escolher, entre dois modelos, qual o modelo essencial, mesmo que
eles cumpram todos os requisitos anteriores.
O princpio do modelo essencial mnimo exige que, entre dois modelos possivelmente
essenciais, a definio menos complicada o modelo essencial. Assim possumos uma forma
clara de escolha.

VIII.3.5
O Princpio da Ausncia de Surpresas
Esse princpio no faz parte da anlise essencial, mas foi proposto pelo GUIDE MVS
group [B27] para auxiliar a anlise de negcios. Ele essencialmente auto-explanatrio. O
princpio conservado quando o produto:

Faz o que o usurio espera

Responde de forma previsvel e consistente aos estmulos.

Comporta-se de forma limitada a sua razo de existncia.

regular e mnimo, apesar de completo.

Quando falha, o faz de forma graciosa e recupervel.

148

 Quando a dificuldade de utiliz-lo ou modific-lo e compatvel com a

dificuldade da rea de aplicao.

Essa uma importante filosofia e que, junto com os princpios da modelagem

essencial apresentados mais tarde, servir de guia para todo o nosso processo de
desenvolvimento. Cada vez que tivermos que tomar uma deciso relacionada ao sistema, ser
nesses princpios que buscaremos a nossa resposta.

VIII.4

A Essncia

A essncia do sistema tudo que precisaria ser includo no sistema para que o mesmo
funcionasse quando implementado em um ambiente de tecnologia perfeita. Isso compreende
velocidade infinita no processador, tamanho infinito de memria, custo nulo para todas as
operaes, infalibilidade, etc.
Esse conceito ser de grande valia quando estivermos analisando se um requisito
verdadeiro ou falso. A primeira pergunta que faremos Esse requisito seria necessrio se
tivssemos um computador perfeito? Se a resposta for no, o requisito falso.
Um sistema de tecnologia perfeita como um gnio da lmpada. Se quisermos que o
gnio da lmpada pague nossos funcionrios, ainda teremos de alguma forma dizer quem so
nossos funcionrios, logo cadastrar funcionrios um requisito verdadeiro de um sistema
de pagamentos de funcionrios.
Sistemas essenciais possuem dois tipos de componentes: atividades e memrias.
Cada tarefa que o sistema de tecnologia perfeita tem que realizar para cumprir a finalidade do
sistema uma atividade essencial. Essas atividades existem em duas formas: as atividades
fundamentais e as atividades custodiais. As atividades essenciais, para poderem executar
suas tarefas, precisam guardar informao. Essa informao guardada em memrias. Da
forma que tratamos a anlise, a memria do sistema, vista como um todo, o modelo
conceitual de dados, discutido no Captulo VI. Cada atividade essencial, porm, pode ter
apenas uma viso parcial dessa memria, de acordo com suas necessidades.
As atividades fundamentais so aquelas que justificam a existncia do sistema
[B17]. Certamente, ao comprar um sistema, precisamos fundamentalmente das sadas que ele
nos disponibilizar. Assim, atividades fundamentais precisam incluir alguma sada para
agentes externos. Suponha que voc deseja comprar um sistema de controle de ponto para sua
empresa. Vrias atividades so necessrias ou possveis nesse sistema, porm poucas so
fundamentais. A atividade fundamental , certamente, informar a presena de cada
funcionrio, pois para saber disso que voc comprou o sistema. As atividades fundamentais
necessitam de dados para funcionar, que podem ser fornecidos diretamente por um agente
externo, um ser humano ou outro sistema que faz parte do ambiente, interagindo com o
sistema, ou estar guardada em uma memria.
As atividades custodiais se destinam a criar e manter as memrias necessrias para o
funcionamento das atividades fundamentais. Um sistema, mesmo de tecnologia perfeita, no
pode criar dados sozinho. Em ambos os exemplos, da folha de pagamento ou da lista de
presena, precisamos saber quem so nossos funcionrios. Manter essa lista de funcionrios
uma atividade custodial. Atividades custodiais, fique bem claro, so essenciais ao
funcionamento do sistema. Acontece que, enquanto o usurio conhece a grande maioria das
atividades fundamentais que precisa, muitas atividades custodiais ficam de fora de sua lista.
Assim, ao analisar um sistema, devemos estar sempre alerta para atividades custodiais
necessrias para manter nossas memrias em ordem.

149

Algumas atividades so custodiais e fundamentais simultaneamente, sendo ento

chamadas de compostas ou mistas.
possvel ter uma viso menos funcional e mais pragmtica, que perde muito da
qualidade filosfica, mas ganha em simplicidade: atividades fundamentais tm uma sada
para o mundo externo, enquanto atividades custodiais alteram memrias. Isso nos chama
ateno que no existem atividades que no sejam fundamentais ou custodiais, isso , uma
atividade deve pelo menos escrever em uma memria ou fazer um relatrio.
Abordagem
Filosfica
Pragmtica
Fundamental Requisito original do cliente
Emite informao
Custodial
Necessrio para o sistema Recebe informao
funcionar
Tabela 21. Tipos de Atividades Essenciais e como classific-las

Uma atividade essencial posta em funcionamento por meio de um estmulo, isto ,

um fluxo de dados ou um comando que provm de um agente externo. A esse estmulo
damos o nome de evento essencial.

VIII.5

Agentes Externos

Representamos as pessoas, departamentos, empresas, mquinas ou sistemas que

interagem com o sistema sendo analisado, enviando ou recebendo dados, por meio de agente
externos, indicado no DFD por meio de um quadrado53. Agentes externos, tambm so
chamados de entidades externas54 ou terminadores.
Normalmente agentes externos representam pessoas, pois a maioria das funes de
um sistema de informao se d por meio da interao com uma ou mais pessoas.
Eventualmente um sistema de informao interage com outro sistema, recebendo ou enviando
dados, ou ainda com sensor ou com um atuador.
Os agentes externos controlam o funcionamento do sistema. So eles que detm o
poder de iniciar as atividades essenciais, ao enviar um estmulo ao sistema. So eles tambm
que recebem todas as respostas emitidas pelo sistema.
O modelo essencial est interessado nos agentes externos que detm realmente o
controle dos estmulos ou que realmente recebem a informao. Usurios do sistema
implementado, como digitadores, no so modelados nos DFDs da anlise essencial.
Usurios do sistema que apenas servem como interlocutores dos verdadeiros agentes externos
so considerados transportadores de dados. Ao documentar um evento devemos
documentar a existncia de transportadores, como veremos no dicionrio de eventos55.
Essa distino entre agentes externos e transportadores algumas vezes muito difcil.
Devemos entender que a verdadeira essncia de um sistema est relacionada com sua funo
no negcio em que ele est inserido. Os usurios do sistema no so necessariamente os
agentes externos que interagem com o sistema. Devemos considerar como agentes externos
aquelas pessoas ou artefatos tecnolgicos que detm o poder de iniciar o evento. Por
53

Em alguns formatos de DFD, as entidades externas no possuem smbolo ou at mesmo no so indicadas.

54

No confundir com as entidades do modelo de entidades e relacionamento.

55

Modernamente, na tcnica de Casos de Uso, considera-se a possibilidade de dois modelos, o do negcio e o do

sistema. No modelo do sistema so utilizados os usurios reais.

150

exemplo, normalmente, em um sistema de vendas, o agente externo que inicia o evento o

comprador e no o vendedor que est usando o sistema. Por isso diferenciamos, na descrio
completa do evento, o iniciador, que o agente externo que inicia o sistema, do
transportador, que o usurio do sistema responsvel por introduzir os dados fornecidos
pelo iniciador.
Um bom teste para verificar se o agente externo o verdadeiro iniciador do evento ou
apenas um transportador, no contexto de um negcio, perguntar se ele pode realizar, por sua
vontade, aquele evento. Vemos que, no caso de um vendedor, ele no pode vender sem
receber um pedido de um comprador (a no ser no caso especfico onde ele estar pagando a
compra, sendo um comprador ele mesmo). Logo, o vendedor no o agente externo iniciador
(podendo, porm, receber alguma sada do sistema para ele destinada). Na verdade, de uma
forma mais essencial, porm pouco reconhecida, o vendedor parte do sistema, pois apenas
uma implementao da interface com o comprador56.
Ao fazer a anlise no estamos preocupados com os motivos dos agentes externos, ou
em modificar suas aes, ou com o que eles fazem com os dados que obtm do sistema. Por
isso eles no so estudados, definindo a fronteira do sistema e os limites do trabalho de
anlise.
Normalmente agentes externos so descritos por nomes que representam classes ou
tipos de usurio dentro de um negcio. Assim, um sistema para uma loja que apresenta os
usurios gerente, vendedor e cliente, ter agentes externos com esses nomes. Nunca
usamos o nome pessoal de um usurio, mas sim seu papel ao utilizar o sistema ou seu cargo
na empresa.
Outro tipo comum de agente externo aquele que representa uma instituio ou
departamento externo ao ambiente de uso do sistema. Nesse caso o agente externo nomeado
com o nome desse departamento ou da instituio (ou ainda, do tipo da instituio).
Finalmente, existem os agentes externos que so mquinas, como sensores, ou
sistemas, sendo nomeados diretamente com o nome dos mesmos.
importante perceber que muitos agentes devem ser representados no s fora do
sistema, mas tambm em sua memria. Isso acontece quando o sistema deve guardar dados
sobre um agente externo, de forma a poder reconhecer ou referenciar um agente externo, por
exemplo, enviando uma conta para o agente externo. Nesse caso, haver pelo menos uma
entidade no modelo de dados representando no total ou parcialmente o agente externo. Isso
no se aplica, porm, no caso da segurana, pois essa no tratada na anlise essencial.
Como exemplo podemos ver o caso de um sistema acadmico, onde os alunos so
agentes externos, pois solicitam boletins, e so entidades, pois devemos guardar dados sobre
os alunos. J os funcionrios da secretaria da escola so agentes externos, pois podem pedir
alguns documentos especficos guardados no sistema, mas o sistema no precisa saber quem
so57.

56

Atualmente fcil entender como o vendedor pode ser substitudo por uma interface Web e o sistema manter sua
essncia.
57

A modelagem essencial no est preocupada com questes como segurana, backup, etc.

151

VIII.6

Eventos Essenciais

Na modelagem essencial tudo ocorre em funo de eventos. Isso acontece porque

imaginamos que o sistema possui dois estados: em atividade ou esperando um evento. o
acontecimento do evento que faz com que o sistema entre em funcionamento e ento realize
todas as tarefas necessrias para atender aquele evento, ou seja, a atividade essencial
correspondente ao evento.
importante notar que o sistema s tem a oportunidade de funcionar quando acontece
um evento. Esses eventos, por definio, no so controlveis pelo sistema, ou seja: o
sistema incapaz de gerar um evento58.
Cada atividade iniciada com um nico evento, que define um estmulo, e
compreende todo o conjunto de aes efetuado pelo sistema para executar a atividade, ou
seja, a resposta planejada. A atividade relativa a um evento compreende toda a cadeia de
aes causada por esse evento, at que o sistema tenha que parar porque todos os fluxos de
dados atingiram seus objetivos (agentes ou memrias). Como apenas um evento inicia a
atividade, ento apenas um nico agente externo pode enviar informaes para uma
atividade59. Isso uma regra importante da anlise essencial, pois indica como o sistema ser
particionado.
O evento funciona como um gatilho, disparando uma reao em cadeia, que para
apenas pela impossibilidade de realizar qualquer outra atividade. Nessa reao em cadeia no
devemos nos preocupar no modo como as aes ocorrem no sistema existente, na encarnao
atual, pois elas podem sofrer interrupes esprias, que dividem um evento entre vrios
processadores.

Evento
Sadas
Sistema
Parado

Sistema em Funcionamento

Sistema
Parado

Sadas

Tempo
Figura 80. O esquema mostra como o sistema reage a um evento. Um
Sistema parado s pode comear a funcionar ao receber um evento. A
partir desse evento, realiza uma srie de processamentos que podem
envolver sadas para o mundo externo, at parar novamente. No podem
existir outros eventos ou entradas do mundo externo durante o
funcionamento, porm possvel consultar as memrias, que so internas
ao sistema.

Muitas vezes o iniciante na anlise essencial imagina que ser travado um dilogo
com o usurio durante a atividade. Esse dilogo interno a uma atividade no existe na anlise
essencial. O estmulo relacionado ao evento, isto , o fluxo de dados que parte do agente
58

No existem, logo, eventos essenciais internos ao sistema.

59

Yourdon no obedece essa regra, permitindo que algumas entidades externas forneam informaes sob demanda
de uma atividade essencial.

152

externo em direo atividade, possui toda a informao necessria para realizar a atividade,
incluindo partes opcionais. Caso o dilogo seja realmente necessrio para o funcionamento
do sistema, ento temos na verdade dois, ou mais, eventos e suas respectivas atividades. Isso
acontece porque uma atividade, por definio, no pode ficar esperando por uma entrada de
dados. A regra que usamos : se o sistema para, s pode voltar a funcionar com um
evento. O mesmo raciocnio se aplica quando falamos de vrios agentes externos.
Segundo a anlise essencial, no existem eventos internos ao sistema, isto , no
dizemos que um processo do sistema se inicia por causa de um evento causado por outro
processo. A anlise essencial parte do conceito que eventos iniciam atividades essenciais e
que essas atividades so executadas at que todas as respostas necessrias sejam geradas. O
sistema ento para e fica esperando pelo acontecimento de outro evento de essencial para
voltar a funcionar. Devemos ter bastante ateno regra que uma atividade contm a resposta
completa para um evento (e apenas para um nico evento), pois ela que vai definir o
particionamento do sistema sendo modelado.
Outra caracterstica da anlise essencial que os eventos so vistos por dentro do
sistema. Assim eles so descritos tendo como sujeito o agente externo que os iniciam, como
em Aluno solicita matrcula60.
Recapitulando, os eventos acontecem fora do sistema, correspondem a um estmulo
que cruza a fronteira do sistema de fora para dentro e so vistos e descritos na perspectiva de
um ser imaginrio que habita sistema.
Tambm importante frisar que atividades essenciais no se comunicam
diretamente, isto , no se comunicam por meio de fluxos de dados. Toda comunicao
entre atividades essenciais feita por meio do uso da memria do sistema

VIII.6.1
Propriedades dos eventos
Um evento pode ser caracterizados pelas seguintes propriedades61:

Um evento deve ocorrer em um momento especfico no tempo.

Um evento deveocorrer no ambiente e no dentro do sistema.

A ocorrncia do evento deve estar sob o controle do ambiente e no do

sistema.

O sistema pode detectar que o evento ocorre.

O evento relevante, isto , o sistema deve fazer alguma quando ele ocorre.

VIII.6.2
Tipos de Eventos
Cada evento pode ser externo ou temporal. Um evento externo quando parte do
ambiente para dentro do sistema. Um comando ou um pedido do usurio, por exemplo. Um
evento temporal quando provocado por uma mudana no tempo, como um alarme de
relgio ou uma data no calendrio.

60

A frase pode ser lida como significando Aluno solicita matrcula ao sistema.

61

Ruble, D.A. Use Cases that Work: Using Event Modelling to infuse rigor and discipline in Use Case Analysis.
White Paper. Olumpic Consulting Group.
http://www.ocgworld.com/doc/Use%20Cases%20that%20Work.pdf (29/9/2005)

153

Originalmente s tratvamos esses dois tipos de eventos (externos e temporais). Com

o tempo, porm, fomos aprendendo a trabalhar e a classific-los mais detalhadamente de
forma a melhorar nosso trabalho.
Eventos temporais podem ser absolutos ou relativos. Um evento relativo quando
definido em funo do decorrer de um prazo depois do acontecimento de outro evento.
Eventos absolutos ocorrem em funo unicamente do calendrio e do relgio62. Um evento
temporal ocorre porque o sistema tem um contrato para entregar informao a um agente em
um momento especfico [B34].
Eventos externos podem ser: esperados ou no-esperados. Um evento esperado
quando sabemos que ele vai acontecer em um instante especfico, ou que tem um limite de
prazo para acontecer. Ele pode tambm ser chamado de evento agendado. Um evento noesperado quando no podemos determinar momento ou limite para seu acontecimento. Eles
podem tambm ser chamados de eventos agendados ou no agendados. Os nomes
esperado e no-esperado podem causar alguma confuso. O sistema, na realidade, espera
que ambos os tipos de eventos ocorram. Porm, alguns tm um prazo ou data para ocorrer.
Por isso podemos usar, com mais preciso, o termo agendado.

No-Eventos
Eventos esperados formam uma categoria importante, pois sabemos que no mundo
real, quando um evento esperado no acontece (o pagamento de uma conta, por exemplo),
pode ser necessrio tomar uma atitude especfica. Dizemos ento que eventos esperados
podem necessitar que sejam definidos no-eventos. Esse o nome que damos para eventos
que acontecem em funo de outro no ter acontecido, possivelmente a partir de um prazo,
como na sentena: uma semana aps esgotar o prazo de pagamento, enviar lembrete.
Novamente, o nome no-evento pode causar confuso. Um no-evento um evento, em
especial, um evento temporal relativo.
Um s evento esperado pode necessitar de vrios no eventos, que ocorrem
normalmente em prazos distintos. Assim, se temos um evento esperado cliente paga conta,
at o dia 30 do ms, podemos ter vrios no eventos para os prazos de 1 dia, 1 semana, 1
ms, 3 meses e 1 ano, por exemplo.
Um no-evento um evento temporal relativo que deve acontecer se
um evento esperado (agendado) no ocorre, possivelmente
considerando um prazo.

62

eventos temporais podem ser implementados como eventos internos, mas no necessariamente. Isso costuma causar
confuso, pois temos o hbito imediato de pensar na implementao e de associar a proibio de eventos internos na
anlise como a proibio de eventos internos na implementao. Exigimos apenas, na anlise essencial, que no
existam eventos essenciais internos. A implementao no est limitada por essa regra.

154

Eventos Essenciais

Eventos Externos

Esperados

No Esperados

Eventos Temporais

Absolutos

Relativos

No-Evento

Figura 81. Tipos de eventos essenciais e seus subtipos.

VIII.6.3
Um Exemplo Esclarecedor
Vamos tentar entender melhor a motivao para termos uma regra to rgida sobre um
evento s receber dado de um agente externo.
Imagine um sistema para uma loja de automveis onde o mecnico, um agente
externo, faz um pedido de pea. Esse pedido anotado e repassado, pelo sistema, para outro
sistema, o sistema de estoque, que outro agente externo, que responder se a pea est
disponvel ou no. Quando o sistema de estoque responder, ento avisaremos o mecnico da
disponibilidade da pea.
Segundo nossa regra, temos os seguintes eventos:

Mecnico solicita pea

o Nesse evento enviado um pedido de pea para o Sistema de Estoque

Sistema de Estoque avisa disponibilidade de pea

o Nesse evento o mecnico recebe um aviso da disponibilidade

J segundo alguns autores, fazendo uma interpretao simplificada, mas, porm no
essencial, apenas o primeiro evento necessrio, pois nesse evento o Sistema de Estoque
consultado.
Agora vamos nos lembrar de nossos princpios da anlise essencial. No podemos
considerar a tecnologia do sistema. Tambm, seguindo nossa definio de evento, no
podemos controlar quando o mundo externo faz alguma coisa.
Dessa forma, no podemos controlar quando o Sistema de Estoque vai responder a
pergunta que fizemos. Isso , devemos esperar por um evento de resposta.
Quanto tecnologia, podemos usar vrias tecnologias como teste da essencialidade
de uma soluo. A soluo essencial deve permitir que o pedido seja enviado ao estoque com
qualquer tecnologia, por exemplo, cartas, telefone, pombo-correio ou computadores ligados
na Internet. Porm, fica claro ao analisar um pedido feito por cartas que o sistema ficar
parado esperando a resposta, logo a resposta outro evento, que faz com que o sistema volte
a funcionar.

155

VIII.6.4
Habilitando Eventos
Da mesma forma que um evento esperado pode precisar de um no-evento,
interessante tambm perceber que muitos eventos esperados s podem acontecer caso outro
evento acontea antes. Por exemplo, em um sistema de controle de prestaes, Cliente paga
parcela de prestao normalmente um evento esperado, porm ele s pode acontecer
depois que Cliente solicita crdito ocorre. Dizemos que um evento habilita o outro. Isso
equivale a uma mudana no estado do sistema que deve ser anotada em alguma memria.
Em muitos sistemas podemos ver eventos sendo habilitados por outros eventos.

Novamente, devemos tomar cuidado para no confundir o fato de um evento poder

habilitar outro evento com as respostas de um evento. Uma resposta algo que
essencialmente pode ser realizada em funo do acontecimento do evento. Um evento
habilitado necessita de um outro estmulo para acontecer, porm ele impossvel sem que
algum evento anterior o libere para funcionar. Um evento desse tipo altera o estado do
sistema.
No h uma notao especial para eventos que habilitam outros eventos, apenas a
consulta especificao da atividade ou ao dicionrio de eventos pode dar essa informao.
Algumas habilitaes podem ser anotadas em uma memria. Porm, cuidado, pois
pode ser que a memria no tenha sido desenvolvida no modelo de dados.

VIII.7

Descrevendo Eventos Essenciais

Um evento externo sempre caracterizado pela existncia de agente externo, que a

pessoa ou um outro sistema que faz com que o evento acontea, enviando para o sistema o
estmulo correspondente. Assim, na nossa descrio de um evento externo sempre devemos
colocar o nome do agente externo que o causa.
No caso de eventos temporais, devemos colocar o fato que faz o evento acontecer.
Eventos temporais no possuem um agente externo que fornea o estmulo.
Alguns estmulos so bastante complicados, contendo dezenas ou centenas de dados,
outros so bastante simples, contendo apenas um comando ou solicitao ao sistema. Eventos
cujo estmulo apenas um comando de execuo podem ser chamados eventos de
controle63.
A sintaxe para definir eventos externos :
<agente externo - sujeito> <verbo no presente> <objeto direto>

Como em: Cliente solicita lista de produtos.

Opcionalmente, no caso de um evento esperado, pode ser usado o seguinte padro:
<agente externo - sujeito> <verbo no presente> <objeto direto> , <prazo>

Onde prazo pode ser absoluto ou relativo a outro evento ou resposta de evento. Como
em: Fornecedor envia produtos pedidos, at 30 dias depois do pedido.
A sintaxe para definir eventos temporais :
<condio temporal>, (hora|dia|etc.) de <verbo no infinitivo> <objeto>

ou simplesmente
63

E possuem, em algumas variaes de DFD, uma notao especfica, utilizando uma seta tracejada em vez de slida.

156

<condio temporal>, <verbo no infinitivo> <objeto>

Como em: Todo dia 30, dia enviar declarao de vendas ou dia 30, enviar
declarao de vendas.
A sintaxe para um no evento :
<condio de no acontecimento de um evento>, <prazo ou condio temporal>, <verbo no
infinitivo>, <objeto>

Como em: Fornecedor no enviou produtos pedidos, depois de 30 dias do pedido,

avisar comprador.
O objeto da orao normalmente um objeto direto que, de alguma forma, representa
uma informao tratada pelo sistema, e possivelmente tambm um objeto indireto indicando
para quem ou para onde a informao enviada.
Vejamos alguns exemplos comuns, descritos de forma correta:

Cliente envia pedido de compra.

Fornecedor entrega mercadoria

Fornecedor entrega mercadoria, at 10 dias depois do pedido.

Vendedor solicita mercadoria.

Filial envia vendas dirias.

Cliente aluga fita.

Ao final do ms, imprimir folha de pagamento.

Ao fim do dia, imprimir resumo de vendas.

Gerente solicita relatrio de produo.

Caso o cliente no pague a conta, 20 dias depois, invocar departamento jurdico.

Caso o aluno no apresente o boletim assinado, 10 dias depois, enviar aviso aos pais.

Vejamos agora alguns eventos descritos de forma incorreta:

Enviar pedido (sem agente externo ou indicao de tempo)

Gerente imprime relatrio (quem imprime o sistema, o gerente solicita, alm disso,
relatrio um termo muito vago).

VIII.8

Levantando os Eventos Essenciais

A primeira e mais importante tarefa da modelagem funcional o levantamento dos

eventos essenciais. Isso feito, ns teremos uma idia bastante clara do tamanho do sistema.
Geralmente nossa estratgia deve ser: levantar uma lista inicial de eventos e refinar
essa lista enquanto analisa a resposta para cada evento. Duas so as formas bsicas de
levantamento de requisitos funcionais: entrevistas e reunies JAD.
Vrias so as formas de descrever uma lista de eventos. Uma maneira partir dos
eventos fundamentais e depois listar todos os eventos necessrios para que os eventos
fundamentais funcionem. Outra maneira seguir uma abordagem seqencial, partindo dos
eventos que geram dados para chegar aos eventos que geram relatrios no final.

157

Alguns sistemas so muito seqenciais, facilitando claramente a segunda abordagem.

Nesse caso importante numerar os eventos no tempo, para garantir que a seqncia ficou
bem clara e nenhum passo foi perdido.
Uma lista de eventos tem a seguinte aparncia:

1. Gerente cadastra distribuidora

2. Gerente cadastra livro
3. Cliente pede livros
4. Sexta-feira, hora de fazer requisies de livros para as distribuidoras.
5. Distribuidora entrega livros
6. Gerente solicita relatrio de vendas
7. Gerente solicita relatrio de livros em atraso
8. Se a distribuidora no entregar os livros pedidos, depois de 15 dias, cancelar pedido.
Figura 82. Exemplos de uma lista de eventos

VIII.8.1
Classificando os Eventos
Apesar de termos descrito os eventos como podendo ser de vrios tipos, no
extremamente necessrio identificar todos os eventos. Porm, fazer isso traz a vantagem de
podermos testar a forma como o evento est descrito. Aqui esto algumas perguntas de teste:

Eventos externos:
o So esperados ou agendados?

Se esperados, possuem um no-evento correspondente?

o So no-esperados ou no agendados?
o So uma solicitao ou possuem dados?

Eventos temporais:
o S ocorrem dessa forma?
o So realmente temporais ou podem ser calculados antes (sendo, nesse caso, uma
sada do sistema)?
o So Relativos?

So no-eventos?

Qual o evento original?

o O evento original existe sempre?

Opcionalmente, podemos construir uma tabela de classificao de eventos, como a

apresentada a seguir. Todo evento deve ser facilmente classificado. A dificuldade de
classificar um evento demonstra que ele no foi compreendido e indica que ele pode no estar
correto, tanto na sua interpretao ou na sua descrio, ou at que seja um requisito falso.
Alm disso, a tabela permite que verifiquemos se todos os eventos esperados possuem
um ou mais no eventos correspondentes.

158

Classificao
Externo

Temporal
Noevento

Nmero

Evento

Esperado

Gerente cadastra
distribuidora

Gerente cadastra livro

Cliente pede livros

Sexta-feira, hora de fazer

requisies de livros para as
distribuidoras

Distribuidora entrega livros

Gerente solicita relatrio de

vendas

Gerente solicita relatrio de

livros em atraso

A distribuidora no
entregou...

NoEsperado

Relativo

Absoluto

(p/
evento)








(5)

Tabela 22. Exemplo de uma tabela de classificao de eventos

VIII.8.2
Encontrando Eventos
Os principais eventos so os pedidos que so feitos ao sistema. Eles normalmente
podem ser encontrados em formulrios, memorandos, documentos que chegam e observando
o atendimento que os usurios do sistema prestam.
Relatrios devem ser gerados por algum evento. Eles, porm, so as respostas aos
eventos e no os eventos propriamente ditos. Todo evento externo esperado deve precisar de
um e pode precisar de mais no eventos.
No mundo real encontramos ainda outras caractersticas que indicam novos eventos:
Pedidos normalmente podem ser cancelados.
O que enviado pode retornar, exigindo uma ao especfica.
Documentos podem ser perdidos e segundas vias podem ser necessrias
Fiscais (ICMS, ISS, Trabalho,...) podem aparecer e solicitar relatrios (que podem
ser obrigatrios em um sistema).
Processos que ocorrem em uma ordem podem ter que ser acelerados para atender
um cliente preferencial.
159

Pagamentos podem ser feitos com o valor errado, para menos ou para mais, exigindo
emisso de novas cobranas ou de crditos.

VIII.8.3
Simplificando Eventos
Segundo a anlise essencial original, as operaes de incluir, eliminar e alterar uma
memria exigiriam pelo menos trs eventos distintos, como em:
Proprietrio cadastra produto
Proprietrio altera produto
Proprietrio apaga produto
Isso, porm, pode no representar a verdade e ser muito complicado em alguns
sistemas. Na vida real fcil termos um sistema com 30 a 40 entidades. Isso exigiria no
mnimo 90 eventos para cumprir as necessidades de manter a memria. No fazemos isso na
prtica.
Em primeiro lugar, no criamos atividades custodiais que no so necessrias. Isso
acontece quando a memria j gerenciada em uma atividade fundamental. Em segundo
lugar, quando uma memria necessita de uma funcionalidade que permita tratar esses trs
casos, podemos utilizar uma notao mais simples:
Proprietrio mantm produtos

VIII.9

As Respostas aos Eventos

Para cada evento o sistema deve executar uma resposta. Essa resposta representada
pela atividade essencial correspondente ao evento e produz dois tipos de resultados:
alteraes no estado do sistema e emisso de informao para o ambiente (alteraes do
estado do ambiente).
Uma alterao no estado do sistema significa que uma ou mais memrias foram
alteradas. Nisso inclumos a criao de registros, a mudana de valores dentro de registros e a
eliminao de registros.
Como emisso de informao temos vrias formas de emisso de relatrios, feedback
para os agentes externos e comandos para atuadores externos.
Cada evento pode exigir uma ou mais repostas, obrigatrias ou opcionais, do sistema.
O processamento de todas essas respostas, juntas a atividade essencial.
Algumas respostas a eventos so bvias a partir do nome do evento, como por
exemplo, em Gerente solicita relatrio de vendas. Uma resposta bvia relatrio de
vendas. Porm, poderamos, em um caso real, ter outras respostas, como por exemplo,
aviso ao diretor.
Logo aps levantar a lista de eventos importante levantar a lista de respostas para
cada evento. Apesar de no ser importante classificar cada resposta, recomendvel que o
analista saiba se a resposta opcional ou obrigatria, e, caso seja opcional, estar preparado
para fornecer, mais tarde, as regras que indicam sua necessidade.

VIII.9.1
Confundindo eventos e respostas
muito comum tambm que o iniciante confunda uma resposta a um evento com um
evento. Para isso podemos usar uma ttica de verificao: perguntar por que um evento
acontece. Se a resposta for Esse evento acontece porque o usurio X enviou um dado ou

160

porque se passaram X dias, estamos em um bom caminho e provavelmente temos um

evento. Porm, se respondermos com algo do tipo Esse evento acontece porque o sistema...
ou Esse evento acontece quando verdade que... ento estamos em um mau caminho, pois
no existem eventos gerados pelo sistema para o sistema.
Outra coisa importante verificar se existe algum motivo para o sistema comear a
funcionar sozinho (o evento). Se no existe, provavelmente escolhemos como evento algo
que resposta para outro evento.
Um exemplo muito comum acontece em casos especiais. Vamos supor que temos
um sistema que deve produzir um relatrio a cada 100 vendas informadas por cada vendedor.
A resposta correta ter um evento Vendedor informa venda, com uma sada (alm das
outras necessrias) Relatrio de Vendas. Geralmente analistas iniciantes inventam um
evento especial Vendedor faz centsima venda.
Vamos tentar aplicar nossos princpios. Temos um que diz No surpreenda o
usurio. Seria uma surpresa para o usurio ter que usar uma tela diferente e ele mesmo
controlar sua centsima venda. Muito mais natural seria que o sistema controlasse isso. Outro
princpio diz: tecnologia interna perfeita. Ora, se a tecnologia interna perfeita no nos custa
nada fazer toda a lgica necessria para esse controle, tambm um bom sinal. Finalmente, o
princpio da soluo mnima nos indica que melhor ter apenas um evento do que dois.
Esse raciocnio pode ser aplicado em todos os casos em que temos uma sada
opcional. interessante notar que, em um DFD, as sadas e entradas em um processo no so
obrigatrias, mas opcionais. a lgica do processo que vai decidir se elas existem ou no.
Assim, podemos incluir em um evento todos os casos especiais que so identificveis pelo
sistema. Obviamente, se o sistema no tiver um meio de descobrir que um caso especial,
ento devemos ter outro evento.

VIII.10

A Memria do Sistema

Como memria do modelo essencial deve ser utilizado o modelo de entidades e

relacionamentos, descrito no Captulo VI. .
Para cada evento e atividade essencial importante definir que memrias sero
utilizadas. Isso pode ser feito por meio de uma Matriz CRUD ou por meio de DFDs e miniespecificaes.

VIII.10.1
Eventos x Entidades (Matriz CRUD)
A Matriz CRUD uma tabela que relaciona processos e dados, podendo ser utilizada
em diferentes momentos do desenvolvimento de software. Nessa tabela representamos
processos nas linhas e dados nas colunas, preenchendo as clulas resultantes com uma ou
mais letras entre C, R, U e D, indicando que o processo Cria, Read ou L, Update ou
Altera, ou Delete ou Apaga um registro,
No caso da modelagem essencial, esta tabela se torna muito interessantes, pois
permite relacionar facilmente os eventos essenciais com as entidades do modelo ER. Mais
tarde, se necessrio na fase de projeto, essa tabela pode ser reconstruda utilizando os
processos sendo implementados e as tabelas do banco de dados.

161

Cadastrar Diretor

CRUD

Cadastrar Novela

Cadastrar Ator

CRUD

Receber Captulo

Captulo

Horas

CRUD
CRUD

Registrar Horas Trabalhadas R

Enviar Formulrio

Ator Horista

Novela

Diretor

Eventos ou Atividades

Ator

Entidades

R
R

CR
C

Tabela 23. A Matriz CRUD do sistema da Rede Bobo de Televiso.

VIII.10.2
Verificando a consistncia
Um dos principais usos da Matriz CRUD verificar a consistncia do modelo.
obrigatrio que cada entidade seja criada e lida por algum evento. Com a Matriz CRUD essa
verificao muito fcil, basta checar se todas as colunas possuem ao menos um C e um
R. Alm disso, interessante, mas no obrigatrio, que as entidades tambm possam ser
alteradas e apagadas. Assim, para cada coluna onde no h nenhum C ou R devemos
imediatamente questionar a necessidade da entidade ou buscar eventos que as justifiquem
junto ao usurio. Do mesmo jeito, para cada coluna sem U ou D devemos verificar se
essa entidade foi tratada de forma completa em relao aos desejos do usurio.
Existe uma exceo obrigatoriedade de leitura de uma entidade, que quando ela
est sendo criada para guardar dados que s sero utilizados em uma verso futura do
sistema.

VIII.10.3
Manipulando a Matriz CRUD
Manipula-se a Matriz CRUD para se obter subsistemas. Um subsistema identificado
pela formao de um cluster, isto , um grupo de clulas prximas com as mesmas
caractersticas, que no nosso caso estarem sendo usadas.
A manipulao feita alterando-se as posies das linhas e das colunas. Com isso
possvel agrupar atividades e entidades que se relacionam mais fortemente em grupos,
permitindo a identificao de subsistemas. Os subsistemas interagem normalmente por meio
da leitura, por um processo, de uma entidade mantida em outro processo.
A Figura 83 tenta mostrar a dinmica da manipulao da Matriz CRUD com objetivo de
encontrar subsistemas. Essas operaes so facilmente feitas em uma planilha eletrnica. As
operaes de transposio de linha ou coluna podem ser feitas em qualquer ordem. O
objetivo obter uma matriz onde as clulas prximas a diagonal sejam bem preenchidas,
formando os grupos que caracterizam os subsistemas, enquanto as outras clulas esto
normalmente vazias, apresentando eventualmente operaes que indicam a interao entre
dois subsistemas.
De certa forma, manipular a Matriz CRUD dessa forma uma ao equivalente a
manipular o DFD Global para se obter o DFD Hierrquico. A diferena bsica que ao tratar
a Matriz CRUD estamos em busca de achar configuraes da mesma que definam
162

subsistemas de maneira clara, enquanto quando estamos grupando processos em DFD Global
buscamos apenas uma forma de organizar o DFD que facilite sua leitura e compreenso.

CRUD R

Processo B

R
C

Processo A

CRUD

Processo B

RU

R
C

Processo F

Processo C

RUD

R
RU

Processo E

Posio inicial

Passo 1: Posio aps troca da posio da coluna

Coluna "Entidade 2" ser trocada de posio

Linha "Processo E" ser trocada de posio

Processo A
Processo B

CRUD R

Processo D
Processo E

Processo C

RUD

CRUD R

Processo B

CRUD R

Processo C

RUD

C
C

Entidade 5

RU

Entidade 4

Entidade 3

Entidade 2

Entidade 1

Entidade 6

Processos
Processo A

C
R

Entidade 5

CRUD R

Processo F

Entidades

Entidade 4

Entidade 3

Entidade 2

Entidade 1

Entidades

Processos

Entidade 6

Entidade 5

CRUD R

RUD
C

Entidade 4

Entidade 3

Entidade 2

Entidade 1
CRUD R

Processo D

C
R

Processos

R
R

Processo F
Processo E

Entidade 2

Entidade 6

Entidade 5
R

Processo D
Processo C

Entidades

Processo D

Processo E

Processo F

Entidade 6

Processo A

Entidade 4

Entidade 3

Processos

Entidade 1

Entidades

RU

Passo 2: Posio aps troca da posio da linha

Passo 3: Posio aps troca da posio da linha

Linha "Processo C" ser trocada de posio

Posio final, com subsistemas marcardos

Figura 83. Exemplo da manipulao de uma Matriz CRUD em busca de

encontrar subsistemas.

VIII.10.4
Extenses da Matriz CRUD
possvel estender a Matriz CRUD para incluir outros conceitos. Uma idia
transform-la em uma Matriz CRUDL, onde L significa Listar (List). claro que para listar
precisamos ler, mas isso faz uma diferenciao entre consultas que retornam muitos registros
(e que possivelmente retornam apenas parte desses registros) e consultas que retornam um
registro inteiro.
Sulaiman64 et al. prope a criao, originalmente em modelos onde se est fazendo a
anlise reversa de uma aplicao em operao, da criao de Cubos CRUD, onde a dimenso
adicional representa o tempo, ou seja, as clulas passam a ser vetores, indexados por
intervalos de tempo ligados as fases do negcio.

Outros usos da Matriz CRUD

A Matriz CRUD, na verdade, pode ser utilizada em vrias fases do
projeto. Antes de termos um modelo de dados e uma lista de eventos, por
exemplo, podemos construir tabelas CRUD a partir dos requisitos
originais do projeto.

64

www.cos.ufrj.br/publicacoes/reltec/es61603.pdf

163

VIII.11

Entendendo um Evento

Para garantir que entendemos completamente um evento, devemos nos perguntar as

sete perguntas do mtodo 5W2H: Who, When, Where, What, Why, How, How Much.

Who? Ou Quem?

Quem so os agentes externos?

Quem o iniciador?

Quem o transportador?

Existem outras pessoas ou sistemas envolvidos nesse evento?

Essa atividade precisa de mais agentes externos?

When? Quando?

Quando ocorre essa atividade?

Alguma coisa precisa acontecer antes dessa atividade?

Alguma coisa deve acontecer depois dessa atividade?

 Essa atividade est limitada no tempo por algum outro evento? Por exemplo, s podemos
vender aps a loja abrir e at a loja fechar.


Quando os dados (de entrada ou de sada) so necessrios?

Where? Onde?

Onde ocorre a atividade, em que setor ou departamento?

De onde vem o estmulo?

Para onde vai cada sada?

What? O que?

O que deve ser feito pela atividade?

Que dados devem vir no evento externo?

Que sadas devem ser feitas?

Que dados so necessrios?

Why? Por que?

Porque o evento acontece?

Porque alguns dados so necessrios?

How? Como?

Como a atividade acontece detalhadamente?

Como so as sadas (relatrios) e entradas?

How much? Qual o valor? Quanto custa?

Quanto custa implementar o evento?

Quanto custa o evento para a empresa cliente?

Quanto custa um erro na atividade que realiza o evento?

O Diagrama de Fluxo de Dados

164

VIII.12

O Dicionrio de Eventos

Com o tempo, a Lista de Eventos entendida para um dicionrio de eventos, que

descreve detalhadamente as caractersticas de cada evento.
Cada entrada no Dicionrio de Eventos composta de:

Identificador do evento, um nmero nico identificar do evento. Esse nmero obrigatrio.

Nmero de seqncia do evento no tempo, se existe. Novamente um nmero, porm

indicando a ordem do evento no tempo, se existir. O nmero opcional. Vrios eventos podem
possuir a mesma ordem (pois aconteceriam no mesmo intervalo de tempo).
Nome do evento, uma sentena que identifica o evento, de acordo com as regras anlise
essencial.
Descrio do evento, uma descrio mais longa do evento, possivelmente contendo
informaes no essenciais (como a motivao do agente externo), porm que aumentam a
compreenso do evento. um resumo do que o evento.

Classificao do evento (externo (E/NE), temporal (R/A), No-evento.

Iniciador, o agente externo que envia o estmulo.

Transportador, i.e., quem inserir os dados no sistema

Dados presentes no estmulo, descritos segundo alguma linguagem de dicionrio de dados,

como a descrita nesse texto.
Atividade, descrio sucinta da atividade, por meio de alguma linguagem. Possivelmente
uma descrio algortmica em portugus estruturado ou como uma seqncia de passos. Uma
soluo interessante e descrever a atividade de acordo com suas pr-condies e ps-condies,
possivelmente em uma linguagem formal como VDM ou Z.
Informao emitida na atividade, efeito da atividade no ambiente, descrio de cada sada
do sistema de acordo com uma linguagem de dicionrio de dados ou equivalente.
Efeito da atividade no sistema, descrio em linguagem natural ou em outra linguagem das
modificaes que ocorrem no estado global do sistema, ou com entidades especficas, com a
execuo da atividade. Efeitos colaterais das atividades so descritos aqui. Por exemplo: a
atividade pode cadastrar um cliente na lista de clientes inadimplentes, um efeito seria o cliente
est proibido de realizar outros gastos na empresa.

Tempo, limites de tempo do evento, ligado aos eventos esperados, quando devem acontecer.

Lista de entidades utilizadas (tiradas do modelo conceitual de dados), ou Matriz CRUD.

Esse texto acompanhado de um software que permite a criao de um dicionrio de

eventos. Na figura a seguir apresentamos a tela para o dicionrio.

165

Figura 84. Tela de um dicionrio de eventos

Figura 85. Tela complementar, indicando as entidades (memrias)

envolvidas em cada evento.

VIII.13

Especificando Processos

O nome de cada processo, incluindo as atividades essenciais, formado de um verbo

no infinitivo e de um objeto direto, que indicam como o sistema responde ao evento.
Exemplos:

166

Evento

Atividade

Gerente solicita relatrio de Vendas

Emitir Relatrio de Vendas

Aluno solicita boletim

Emitir Boletim

Fornecedor entrega mercadoria

Receber mercadoria

Tabela 24. Nomes de atividades para alguns eventos

VIII.13.1
Especificao do Tipo Caixa Preta
A primeira especificao que devemos fazer de um processo ou atividade essencial
deve enxergar esse processo ou atividade como uma caixa preta. Dessa forma, a descrio
deve discutir apenas seus efeitos nas memrias e as entradas e sadas dos agentes externos.
Esta especificao inicial deve ser feita utilizando a linguagem do cliente.
Por exemplo:

Especificao do Processo Cadastrar Cliente:

Aps conferir se o CGC vlido, deve registrar as informaes passadas pelo cliente na
memria CLIENTE.

VIII.13.2
Especificao do Tipo Caixa Branca
A especificao de processo, na modelagem essencial, chamada de miniespecificao. Cada processo, e nisso se incluem as atividades essenciais, deve ser
especificados por meio de uma mini-especificao ou refinado por meio de outro DFD.
Uma mini-especificao pode ser escrita em portugus estruturado, usando tabelas ou
rvores de deciso. Qualquer que seja a linguagem escolhida, deve permitir o entendimento
claro do que deve ser feito durante aquele processo.
Por exemplo:
Especificao do Processo Cadastrar Cliente:
o Se CGC Vlido Ento
o

Salvar Cliente.

VIII.13.3
Mini-especificaes
Uma especificao de um processo (mini-especificao) tem como objetivo
especificar o que o processo deve fazer (e no como). Uma especificao em portugus
estruturado deve ser clara. Em geral, cada empresa ou projeto deve determinar como escrever
sua mini-especificao.
Portugus Estruturado
Algumas regras bsicas:
Toda a lgica deve ser expressa na forma de estruturas seqenciais, estruturas de deciso,
estruturas de case, ou iteraes.

As palavras chaves devem ser destacadas (negrito ou letras maisculas).

Identar claramente os blocos de comando, mostrando sua hierarquia.

Destaque as palavras ou frases definidas no dicionrio de dados, para indicar que tm um

significado especfico (sublinhe ou itlico).

Seja atento no uso das condies ou, e, maior, maior ou igual".

167

Sintaticamente falando:

Uma mini-especificao composta de uma seqncia de comandos.

Um comando pode ser um comando estruturado ou um comando simples

Um comando estruturado pode ser

Um bloco

Um comando se - ento

Um comando se - ento - seno

Um comando faa - caso

Um comando faa - enquanto

Um comando repita - at

Um comando para_cada - faa

Outro comando acertado entre o grupo

Um comando simples pode ser

Um comando de atribuio

Um comando de busca em memria

Um comando de escrita em memria

Um comando de leitura na interface

Um comando de escrita na interface

Outro comando acertado entre o grupo

O importante manter a consistncia. Veja o exemplo a seguir:

PROCESSO Preparar_Segunda_Via
INCIO
LER tipo_pessoa
SE tipo_pessoa=FISICA ENTO
INCIO
LER cpf_pessoa
BUSCAR quem EM Contribuinte COM quem.cpf=cpf_pessoa
codigo_cont := quem.codigo
FIM
SENO
INCIO
LER cgc_empresa
BUSCAR empresa EM Contribuinte COM empresa.cgc=cgc_empresa
codigo_cont := empresa.codigo
FIM
FIM_DO_SE
LER ano
BUSCAR iptu EM impostos COM iptu.ano=ano E iptu.codigo=codigo_cont

168

IMPRIMIR iptu
FIM

VIII.13.4
O Diagrama de Transio de Estados
Um diagrama de transio de estados, ou simplesmente diagrama de estados, ou ainda
DTE, uma das abstraes mais gerais que temos para um sistema ou objeto. O objetivo de
um DTE descrever como um sistema ou objeto muda de estado em funo de eventos que
ocorrem no ambiente, e que respostas esto associadas a cada mudana de estado.
Diagramas de estados so compostos de dois smbolos bsicos: estados (crculos ou
caixas) e transies (setas). Os estados tm um nome ou um nmero, enquanto as transies
so indicadas com um evento, que ativa a transio, e uma sada, provocada pela transio.
Apesar de sua simplicidade, DTEs so ferramentas muito poderosas para modelagem.
Podem ser usados de diferentes formas na modelagem essencial: para descrever o
funcionamento do sistema como um todo ou de parte dele, para descrever os estados
possveis de uma entidade. Mesmo uma mini-especificao pode, em alguns casos, ser mais
bem representada por um diagrama de estados.
Yourdon [B43] sugere que as seguintes perguntas devem ser feitas para verificar um
DTE:
Todos os estados foram definidos?
Todos os estados podem ser atingidos?
Todos os estados tm uma sada?
Em cada estado o sistema reage adequadamente a todos os eventos?
Existem no mercado diferentes ferramentas, gratuitas ou comerciais, de desenho e
verificao de DTEs. Existem tambm outras formas similares de modelagem, como Redes
de Petri e StateCharts.

Incio

Evento a
Sada 1
Evento c
Sada 2

Evento b
Estado 1

Estado2

Evento d

Fim

Figura 86. Um diagrama de estados simples

No existe uma notao padro para diagramas de estado, mas a notao utilizada na
com smbolos especiais para os estados iniciais e finais, ser a adotada nesse texto.

Figura 86,

Diagramas de estados podem ser representados por tabelas, como a seguir:

169

Estado Atual

Evento

Resposta

Prximo Estado

Incio

Evento a

Sada 1

Estado 1

Estado 1

Evento b

Estado 2

Estado 2

Evento c

Sada 2

Estado 2

Estado 2

Evento d

Fim

Tabela 25. Tabela representando o diagrama da Figura 86

Resp
ostas
ou
Aes

Eventos
ou fatos

VIII.13.5
Tabelas de Deciso
Uma tabela de deciso descreve que aes devem ser tomadas quando uma srie de
fatos acontece. Uma tabela de deciso tem duas partes. Na primeira parte cada linha
representa um fato. Na segunda parte, cada linha representa uma ao. As colunas significam
combinaes de fatos, determinados pelos valores: verdadeiro, falso e no aplicvel.
Livro Existe na Base
Cliente Cadastrado
Cliente deve dinheiro

Cadastra cliente
Prepara pedido
Recusa pedido
Tabela 26. Uma tabela de decises

VIII.13.6
Pr-condies e ps-condies
Baseadas em linguagens formais de especificao e implementadas em algumas
linguagens, como Eiffel, pr-condies (e ps-condies) so declaraes que devem ser
verdade antes (e depois) do cdigo ser executado.
Por exemplo, um cadastro poderia ser especificado (de forma bastante simplificada)
como:
pr
input = (x,y,z) onde x Nome , y Endereo, z Telefone
ps
(x,y,z) Aluno

VIII.14

Dicionrio de Dados

O Dicionrio de Dados uma definio formal e estruturada dos fluxos de dados,

elementos de dados, memrias, entidades e relacionamentos [B34]. Funciona, para os dados
um sistema sendo descrito, como um dicionrio funciona para a lngua que falamos.
Existem vrias notaes diferentes para construir dicionrios de dados, mas todas so
equivalentes. Nossa notao ter o seguinte formato bsico:
<termo definido> = <definio do termo>
170

O DD deve conter a descrio de todos os fluxos e de todas as memrias (entidades)

do sistema.
O termo definido normalmente uma palavra, enquanto a definio do termo pode
assumir vrias formas:

Combinao de outros termos (uso do +)

<termo> + <termo> ...

Repetio de termos (uso das chaves, possivelmente com limites mnimos e mximos)

{<termo>}
1:3{<termo>}

Termos opcionais (uso dos parnteses)

(<termo>)

Uma escolha entre termos (uso dos colchetes)

[<termo1> | <termo2> ...]

Valores possveis (uso de aspas)

valor1

Comentrios (uso de asteriscos)

*um nome de pessoa*

A seguinte definio vlida:

comprador
=
nome
(pessoa_de_contato)

[cgc

cnpj]

endereo

0:2{telefone}

Significando que um comprador deve ser representado por um nome, um CGC ou

CNPJ, o endereo, entre 0 e 2 telefones e, opcionalmente, uma pessoa de contato.
Itens simples sero descritos por um comentrio. Quando o significado bvio, usa-se
o comentrio * dado elementar *.
Tambm comum usar o smbolo @ para marcar os termos que compe a chave de
outro termo.
Podemos guardar tambm regras de clculo (e regras de negcio) no dicionrio de
dados.
Modelos de Yourdon
Yourdon definiu dois modelos como objetivos do processo de anlise, o
modelo ambiental e o modelo comportamental.
O Modelo Ambiental65 composto de: Objetivos, Lista de Eventos e
Diagrama de Contexto.
O Modelo Comportamental66 composto de: Diagrama de Contexto, Lista
de Eventos, Declarao de Objetivos, DFD hierrquico completo, Miniespecificaes para todos os processos que no forem expandidos em um
DFD, Diagrama de Entidades e Relacionamentos completo, Conjunto completo
de diagramas de transies de estado e Dicionrio de dados completo.

65

O modelo ambiental foi definido por Yourdon[B43], sendo questo tpica de concurso.

66

O modelo comportamental foi definido por Yourdon [B43], sendo questo tpica de concurso.

171

VIII.15

Exerccio

VIII.15.1
Rede Bobo de Televiso
O Ncleo de Novelas da Rede Bobo de Televiso contratou voc para fazer um
sistema para controlar suas novelas. O sistema deve permitir que um operador cadastre, em
separado, novelas, atores e diretores. Os atores podem ser contratados ou horistas. Os atores e
diretores s podem trabalhar em uma novela, mas uma novela pode ter vrios atores e apenas
um diretor.
Quando um ator passa a trabalhar em uma novela, isso deve ser registrado no sistema.
Se ele for ator contratado, deve ser impresso um aviso para o departamento de pessoal,
dizendo que ele est alocado na novela.
Quando um autor envia um captulo (com resumo), o sistema deve cadastrar esse
captulo e produzir uma cpia para cada ator e diretor da novela.
Toda segunda feira, o sistema deve emitir cpias, para a imprensa, dos 6 resumos dos
captulos da semana.
No final do ms (dia 25), o sistema deve gerar, para a pagadoria, uma listagem dos
atores horistas que devem ser pagos. Para isso, dia 15 deve ser enviado um formulrio aos
diretores, com o nome de todos os atores horistas associados novela com um espao para
marcar. Os diretores devem devolver esses relatrios preenchidos, com o registro de horas
trabalhadas por ator horista, que so registrados no sistema. Se dia 23 existir um diretor que
no devolveu o relatrio, deve ser enviada uma carta de notificao ao diretor.
Lista de Eventos67:

Operador Cadastra Diretor (custodial, externo, no esperado)

Operador Cadastra Novela (custodial, externo, no esperado)

Operador Cadastra Ator (custodial, externo, no esperado)

Autor Envia Captulo (composto, externo, no esperado, na prtica deveria ser esperado, mas
no assim que foi descrito)

dia de enviar formulrio (composto, temporal)

Diretor envia formulrio preenchido (composto, externo, esperado, tem um no evento)

dia de enviar carta de notificao ao diretor (no evento) (esse evento no est no diagrama
por um defeito de fabricao do mesmo, mas aparecer na prxima verso).

67

Ateno para a forma como cada evento descrito

172

dados de diretor

dados de novela + diretor

operador

operador
novela
cadastrar
diretor

cadastrar
novela
diretor

dados de ator + tipo

operador

diretor
captulo + resumo
autor

cadastrar
ator

ator

aviso de alocao
captulo
dep.
pessoal

ator

receber
captulo

ator

captulo
captulo

diretor
ator horista

diretor
novela

ator horista
horas
novela
diretor

enviar
formulrio

registrar
horas
trabalh.

form. ator/horas

ator

diretor

diretor

ator

ator horista
ator hor + horas

Figura 87. Todos os componentes do DFD particionado do sistema para

Rede Bobo de Televiso68 em uma s imagem

VIII.16

Modelos Adicionais

VIII.16.1
Finalizando a Anlise
Um dos trabalhos mais importantes e aborrecidos da fase de anlise manter todos os
documentos consistentes. Isso fica mais difcil quando estamos usando mtodos diferentes em
ferramentas distintas.
Assim, se temos em uma mesma ferramenta CASE o diagrama de entidades e
relacionamentos e todos os nossos eventos, provvel que seja possvel nunca conseguir
escrever uma especificao inconsistente ou pelo menos verificar se existe alguma
inconsistncia. Porm, se utilizamos mais de uma ferramenta CASE69, fica mais difcil
manter essa consistncia.

68

Esse DFD particionado uma figura inexistente durante o projeto. Em um documento real, cada diagrama
apareceria em uma pgina, e no todos agrupados. Alm disso, devemos notar a ausncia de um no evento possvel.
69

Se no utilizamos ferramentas CASE estamos incorrendo em um erro grave.

173

Captulo IX. Casos de Uso

We succeed only as we identify in life, or in war, or in anything else, a single overriding objective, and make all
other considerations bend to that one objective.
Dwight D. Eisenhower
Ator
Casos de Uso
Cenrios
Fluxo Principal
Fluxo Alternativo

IX.1 Conceituao
Um caso de uso uma especificao, em forma de narrativa, de uma seqncia de
interaes entre um sistema e os atores (agentes externos) que o usam. Casos de uso podem
ser simples ou complexos, devendo descrever, em um nvel de detalhe desejado, algo que um
usurio ou cliente quer que o sistema faa. Eles descrevem e definem parte da funcionalidade
de um sistema.
Casos de uso foram criados por Ivar Jacobson em 1986. Uma das melhores descries
de seu uso foi feita por Alistair Cockburn, no livro Effective Use Cases.
Um caso de uso bem escrito deve descrever, de forma completa, um processo
executado pelo sistema, contando uma histria, completa, de como o usurio tenta alcanar
um objetivo especfico ao usar o sistema. Na sua forma mais completa, um caso de uso
apresenta vrios cenrios possveis de sucesso ou falha na busca por esse objetivo.
Os casos de uso formam a especificao funcional de um sistema. Essa especificao
facilmente legvel por usurios ou desenvolvedores, permitindo tambm sua validao e
verificao. importante notar que os diagramas de caso de uso tm um valor muito pequeno
frente ao documento textual que o caso de uso.
Casos de uso tratam o sistema sendo descrito como uma caixa preta. As interaes
entre os usurios e o sistema so descritas como percebidas pelo usurio.
Um caso de uso deve:

Descrever um tarefa de negcio que serve a um nico objetivo de negcio

No ser orientado a uma linguagem de programao

Ter o nvel de detalhe apropriado

Ser curto o suficiente para ser implementado por um desenvolvedor de

software em um verso do produto

IX.2 Ator
Um ator uma entidade externa ao sistema com comportamento prprio. Os atores
interagem com o sistema para alcanar seus objetivos. Em cada Caso de Uso, um ator o ator
principal, que visa um objetivo principal naquele caso de uso. Muitas vezes, o sistema

174

invocar outros atores, que devero cumprir suas responsabilidades para que o ator principal
alcanar seu objetivo.
Os principais tipos de atores so:

pessoas,

organizaes,

equipamentos, e

outros sistemas.

Genericamente falando, o sistema sendo descrito tambm um ator. No normal,

porm, represent-lo dessa forma. Outro ator muitas vezes usado o tempo, mas muitos
autores no recomendam seu uso.
Um usurio no a mesma coisa que um ator. Um ator representa um papel dos
usurios de um sistema. Tanto um ator pode representar um papel assumido por vrios
usurios, como o papel de Cliente em um banco, quanto um usurio (pessoa real) pode ser
representado por vrios atores, como no caso de um funcionrio de uma Universidade que
simultaneamente aluno.

IX.2.1 Objetivos
Todo ator possui um ou mais objetivos ao usar o sistema. Cada objetivo define e d
nome a um caso de uso.
IX.2.2 Cenrios
Um caso de uso pode acontecer de acordo com vrios cenrios. Cada cenrio descreve
como uma instncia especfica do caso de uso pode acontecer, ou seja, que seqncias
especficas de interaes entre o sistema e os atores.
Um desses cenrios o cenrio principal, conhecido como cenrio principal ou
cenrio feliz (happy day), que narra como um ator alcana seu objetivo da forma mais fcil
ou comum. O cenrio principal descrito de forma integral em todos os casos de uso.
Na maior parte das vezes, os casos de uso tambm possuem vrios cenrios
alternativos, alguns que tambm levam ao objetivo desejado, outros que levam a verses
parciais desse objetivo e ainda cenrios de falhas. Todos esses cenrios tambm so descritos
nos casos de uso, porm normalmente de forma compactada, sendo mostrado apenas como
eles diferem do caso de uso principal.
Os cenrios diferem em funes de condies especficas que podem acontecer na
execuo de uma instncia do caso de uso. Por exemplo, se o caso de uso descreve uma
retirada de dinheiro de uma conta bancria, o cenrio principal considera que existe saldo na
banca, enquanto cenrios alternativos podem considerar que no existe saldo suficiente ou
que tarde demais para retirar a quantia pedida70.
A figura a seguir ilustra o conceito de um caso de uso contendo um caminho principal
e quatro condies que podem alterar a execuo de uma instncia do caso de uso. A figura
seguinte mostra possveis cenrios de execuo desse caso de uso.

70

No Rio de Janeiro h um limite de retirada nos caixas automticos a partir de certa hora da noite, por medida
de segurana.

175

Fig. 88 Representao abstrata de um caso de uso mostrando um

caminho principal e algumas condies e alternativas.

Fig. 89 Representao abstrata da execuo de diferentes cenrios

possveis no caso de uso da figura anterior.

Fig. 90 Representao abstrata alternativa da execuo de diferentes

cenrios possveis.

Cenrios, alm do fluxo principal, podem representar variantes normais do fluxo

principal, casos raros, excees e erros. Dessa maneira, podemos compreender um caso de
uso como a descrio de uma coleo de cenrios de sucesso ou falha que descrevem um
determinado processo do sistema com a finalidade de atender um objetivo do usurio.

176

Fig. 91 Principais conceitos envolvidos em casos de uso, baseado em

[1]

IX.3 Formas de narrativa

A narrativa a forma de bsica de descrio dos cenrios do caso de uso. A forma de
narrativa apresenta vrias vantagens sobre outras formas j utilizadas de modelagem de
processos, como manter o contexto visvel, eliminar dificuldades de compreenso para o
usurio (causadas por linguagens tcnicas com forte grau de abstrao) e deixar claro qual o
valor de cada funo para os usurios.
Um caso de uso pode ser descrito, como um texto, de vrias formas, porm podemos
considerar que trs dessas formas so as principais:
1. Descrio contnua
2. Descrio numerada
3. Descrio particionada

IX.3.1 Descrio contnua

Na descrio contnua o caso de uso descrito como um texto tradicional da lngua
corrente. Um exemplo simples pode ser visto na figura a seguir.
O Cliente chega ao caixa eletrnico e insere seu carto. O Sistema
requisita a senha ao Cliente. Aps o Cliente fornecer sua senha e esta
ser validade, o Sistema exibe as opes de operaes possveis. O
Cliente opta por realizar um saque. Ento o Sistema requisita o total a
ser sacado. O Sistema fornece a quantia desejada e imprime o recibo
para o Cliente
Fig. 92 Um caso de uso descrito como uma narrativa

A descrio contnua bastante adequada para a fase inicial dos projetos, pois pode
ser retirada diretamente de entrevistas e facilmente validade pelo usurio. Em fase mais
avanadas apresenta problemas por se tornar muito confusa com a adio de detalhes e a falta
de estrutura. Outro problema acontece quando forem criados os passos alternativos referente
a cenrios possveis, que no tero como se referir ao ponto onde pode acontecer a diferena
para o cenrio principal.

177

IX.3.2 Descrio numerada

Na descrio numerada ou itemizada, a narrativa feita na forma de passos simples
numerados sequencialmente. Existem duas formas bsicas de construir uma narrativa
numerada. Na primeira forma, cada passo representa uma interao completa entre o ator e o
sistema. Na segunda forma, cada passo representa uma ao simples do ator ou do sistema.
1. Cliente passa seu carto no caixa eletrnico e o sistema
apresenta solicitao de senha
2. Cliente digita senha e o sistema exibe menu de operaes
disponveis
3. Cliente indica que deseja realizar um saque e o sistema
requisita quantia a ser sacada
4. Cliente informa quantia a ser sacada e o sistema fornece
dinheiro e recibo
Fig. 93 Caso de uso descrito na forma de uma narrao numerada
onde cada passo uma interao

1. Cliente passa seu carto no caixa eletrnico

2. Sistema apresenta solicitao de senha
3. Cliente digita senha
4. Sistema exibe menu de operaes disponveis
5. Cliente indica que deseja realizar um saque
6. Sistema requisita quantia a ser sacada
7. Cliente informa quantia a ser sacada
8. Sistema fornece dinheiro
9. Sistema imprime recibo
Fig. 94 Caso de uso descrito na forma de uma narrao numerada
onde cada passo uma ao

IX.3.3 Descrio particionada

Na narrativa particionada o caso de uso descrito em uma tabela, onde cada coluna
representa um ator ou o sistema e cada linha representa uma ao.
Tab. 27Caso de uso descrito na forma de uma narrao particionada

Cliente

Sistema

Passa o carto

Solicita senha

Digita senha

Exibe menu de opes disponveis

Requisita quantia a ser sacada

Fornece dinheiro e recibo

178

IX.4 Tipos de detalhamento

Os casos de uso podem ser descritos em diversos nveis de detalhe, do mais abstrato e
geral at detalhes passo a passo. De modo geral, podemos considerar trs nveis de detalhes,
adequados em fases diferentes do projeto:

Breve, onde usamos apenas uma frase ou pargrafo descrevendo o processo principal e
tpico.
Casual, onde descrevemos diferentes cenrios, mas cada descrio composta por
apenas um pargrafo.
Expandido, todos os passos e variaes so detalhadamente descritos, incluindo prcondies e ps-condies de sucesso.
IX.4.1 Exemplo de caso de uso Breve
Caso de uso: Alugar Fitas
Um cliente solicita a locao de algumas fitas. Aps identificar-se e
identificar as fitas ele pode lev-las para casa, ciente do prazo de
devoluo e do valor a ser pago.

IX.4.2 Exemplo de caso de uso casual

Caso de uso: Alugar Fitas
Um cliente solicita a locao de algumas fitas. Aps identificar-se e
identificar as fitas, se no houver problemas no seu cadastro e se as
fitas no estiverem reservadas para outro cliente, ele pode lev-las
para casa, ciente do prazo de devoluo e do valor a ser pago.

IX.4.3 Exemplo de caso de uso expandido

Caso de Uso: Alugar Fitas
Fluxo Principal:
1. O cliente chega ao balco com as fitas que deseja alugar .
2. O cliente informa seu nome e entrega as fitas ao funcionrio.
3. O funcionrio registra o nome do cliente e inicia a locao.
4. O funcionrio registra cada uma das fitas.
5. O funcionrio finaliza a locao, devolve as fitas ao cliente e lhe
informa a data de devoluo e o valor total da locao.
6. O cliente vai embora com as fitas.

Fluxos Alternativos:
3a. O cliente no possui cadastro.
3a.1 O cliente deve informar seus dados para cadastro.
3a.2 O funcionrio registra o cadastro.
3a.3 Retorna ao fluxo principal no passo 3.

179

3b. O cliente possui pendncias no cadastro (locao anterior no foi

paga).
3b.1 O cliente paga seu dbito.
3b.2 O funcionrio registra a quitao do dbito, eliminando assim
a pendncia.
3b.3 Retorna ao passo 3.
4a. Uma fita est reservada para outro cliente.
4a.1 O funcionrio informa que a fita no est disponvel para
locao.
4a.2 Prossegue a locao do passo 4 sem incluir a fita reservada.
4b. Uma fita est danificada.
4b.1 O funcionrio informa que a fita est danificada.
4b.2 O funcionrio registra que a fita est danificada.
4b.2 O funcionrio verifica se existe outra fita disponvel com o
mesmo filme.
4b.3 Se existir, o funcionrio substitui a fita e segue no passo 4,
seno segue do passo 4 sem incluir a fita danificada.

IX.5 Diagramas de Caso de Uso

Um diagrama de caso de uso representa de forma muito abstrata o fato de que um ator
usa um caso de uso de um sistema. Seus principais componentes so atores e casos de uso.
Atores so representados por bonecos e casos de uso por elipses.
Nas figuras a seguir exemplificamos os objetos bsicos utilizados no desenho de um
diagrama de caso de uso.

Fig. 95 Artefatos grficos usados na criao de um diagrama de casos

de uso

180

Fig. 96 Exemplo de um diagrama de caso de uso

IX.6 Relaes entre casos de uso

Os objetos que compe um diagrama de caso de uso podem se relacionar de diferentes
formas., como descrito na figura a seguir.

Fig. 97 Tipos de relacionamentos entre objetos do diagrama de casos

de uso

IX.6.1 Generalizao entre Atores

Muitas vezes diferentes atores tem caractersticas comuns. Se estas caractersticas
comuns puderem ser descritas como uma relao de especializao/generalizao, podemos
representar isso diretamente em um diagrama de caso de uso por meio da relao de
generalizao (usando uma seta com ponta triangular e linha cheia).
Mltiplos atores podem ter papis comuns ao interagir com um caso de uso. A relao
de generalizao pode ser usada para simplificar relaes entre muitos atores e um caso de
uso. Ela tambm mostra que uma instncia de um ator especializado por fazer tudo que outro
tipo de ator faz.
Um exemplo tpico o da existncia, em uma organizao, de funcionrios e
gerentes. Normalmente, tudo que um funcionrio pode fazer um gerente tambm pode fazer,
mas a recproca no verdadeira. Assim, possvel criar vrios casos de uso para o ator
181

funcionrio e fazer o ator gerente herdar de funcionrio, adicionando-se ento os casos

de uso exclusivos de gerente.
Tambm possvel usar a relao de generalizao para criar atores abstratos, que
representam um comportamento comum entre vrios atores concreto. Um ator abstrato no
existe na prtica no mundo real, como o que demonstrado no exemplo a seguir.

Fig. 98 Demonstrao do relacionamento de herana sendo usado

para descrever que vrios atores (concretos) usam um caso de uso,
criando um ator abstrato (Profissional de Sade)

IX.6.2 Relaes entre Casos de Uso

Casos de uso podem se relacionar de 3 formas:

Pela incluso de outro caso de uso,

Pela extenso de outro caso de uso, e

Pela generalizao/especializao de outro caso de uso.

Em UML, esses relacionamentos so conhecidos como include, extend, e a

generalizao propriamente dita, sendo representados como na figura a seguir.

Fig. 99 Relacionamentos possveis entre casos de uso: generalizao,

extenso e incluso.

IX.6.3 Incluso de Casos de Uso

O relacionamento de incluso o mais simples de se compreender, pois representa
uma relao entre um caso de uso bsico e um caso de uso includo. Isso significa que caso
de uso includo explicitamente inserido no caso de uso base, de forma semelhante a uma
chamada de funo.
182

O diagrama a seguir demonstra o uso da relao de incluso.

Fig. 100 Exemplo do uso do relacionamento de incluso

O relacionamento de incluso usado para fatorar um comportamento comum entre

dois ou mais casos de uso. Ele evita que tenhamos que descrever o mesmo comportamento
duas vezes dentro dos respectivos casos de uso, aumentando a consistncia e permitindo o
reuso.
Tambm possvel usar o relacionamento de incluso apenas para fatorar e
encapsular comportamento de um caso de uso base, de forma a simplificar fluxo complexo de
eventos ou remover da parte principal do caso de uso um comportamento que no parte do
objetivo primrio.
importante entender que um caso de uso includo executado totalmente quando
chamado e, se no deve ser executado, a deciso do caso de uso chamador. Alguns autores
dizem que o caso de uso includo obrigatrio, mas isso s verdade dentro do fluxo onde
ele ocorre.

IX.6.4 Extenso de Casos de Uso

A relao de extenso descreve que um caso de uso extende o comportamento e seu
caso base, o que acontece apenas se uma condio de extenso for verdade. A relao de
extenso originria do uso de patches em sistemas que no podiam ter seus casos de uso
originais alterados para aceitar novos comportamentos e pode ser compreendida como uma
forma de patch, do mesmo jeito que a relao de incluso pode ser compreendida como uma
chamada de funo. A figura a seguir apresenta um exemplo de relao de extenso em um
caso de uso.

Fig. 101 Exemplo de relacionamento de extenso

183

A relao de extenso deve ser utilizada quando queremos fatorar de um caso de uso
um comportamento excepcional ou opcional que executado apenas em algumas condies
especficas, de forma a simplificar o evento base. Tambm usada para criar um
comportamento adicional a um caso de uso j existente.

IX.6.5 Generalizao de Casos de Uso

O relacionamento de generalizao, como estamos habituados, descreve um
comportamento geral compartilhado pelo caso de uso que herda (filho) com o seu parente.
Ela descreve que o filho tem o mesmo comportamento geral do pai, porm com alguma
diferenciao (especializao).
Esse relacionamento deve ser utilizado para mostrar comportamento, estrutura ou
objetivos comuns entre diferentes casos de uso; para mostrar que os casos de uso filhos
formam uma famlia de casos de uso com alguma similaridade; ou para assegurar que o
comportamento comum se mantm consistente. A figura a seguir mostra um exemplo de
herana.

Fig. 102 Exemplo de um relacionamento de herana entre casos de

uso

Uma instncia de caso de uso executando um caso especializado vai seguir o fluxo de
eventos descritos pelo caso parente, inserindo comportamento adicional e modificando seu
comportamento como definido no fluxo de eventos do caso especializado.

IX.7 Tipos de Caso de Uso

Um caso de uso pode ser concreto ou abstrato. Casos de uso concretos tem que ser
completos e teis, podendo ser instanciados, isto , executados, diretamente. So casos de uso
que existem na prtica.
Casos de uso abstrato existem apenas para ajudar outros casos de uso, no precisam
ser completos e nunca so instanciados. Se eliminarmos todos os casos de uso abstratos ainda
teremos uma viso bastante precisa da funcionalidade do sistema.

184

Fig. 103 Exemplo de casos de uso abstratos e concretos.

IX.8 Nveis de Abstrao de Um Caso de Uso

Uma das formas mais interessantes de entender como desenvolver casos de uso
entender que eles podem ser descritos em diferentes nveis de abstrao, desde um nvel
bastante abstrato at um nvel detalhado em seus mnimos detalhes.
A idia bsica em torno desse conceito que casos de uso de um nvel mais abstrato
explicam o porqu de um caso de uso de um nvel mais baixo, enquanto o caso de uso de um
nvel mais baixo explica como o caso de uso do nvel mais abstrato realizado.
Podemos identificar cinco nveis de abstrao para casos de uso:

Sumrio de alto nvel

Sumrio

Objetivo do Usurio

Sub-Funo

Muito detalhado
Cada nvel de abstrao pode ser associado um cone que o representa:

Nvel

cone

Sumrio de Alto Nvel

Sumrio
Objetivo do Usurio
Sub-Funo
Nvel Muito Detalhado
Tabela 28. cones que representam o nvel de abstrao dos casos de
uso, segundo [1]

185

IX.9 Escopo de um Caso de Uso

Da mesma forma que definimos o nvel de abstrao de um caso de uso, podemos
tambm definir o escopo do caso de uso em relao a organizao ou sistema que ele
descreve

Organizao, caixa preta

Organizao, caixa branca

Sistema, caixa preta

Sistema, caixa branca

Componente

Escopo

cone

Organizao, caixa preta

Organizao, caixa branca

Sistema, caixa preta

Sistema, caixa branca
Componente
Tabela 29. cones que representam o escopo dos casos de uso,
segundo [1]

Fig. 104 Diferentes fronteiras de um sistema levam a diferentes

escopos, segundo [1].

186

IX.10

Escopo x Abstrao

Fig. 105 Compatibilidade entre as combinaes entre escopo e

abstrao de um caso de uso

Fig. 106 Smbolos mais adequados a utilizao, de acordo com a

compatibilidade, na descrio de casos de uso

IX.11
IX.11.1

Partes de Um Caso de Uso

Possveis Sees para um Caso de Uso Expandido

Atores

Interessados

Pr-condies
187

Ps-condies de sucesso

Cenrio principal de sucesso ou fluxo principal

Extenses ou fluxos alternativos

Requisitos Especiais

Variaes tecnolgicas e de dados

Freqncia

Questes em aberto

IX.11.2
Atores
So as classes de pessoas e sistemas externos que interagem com o sistema de alguma
forma
IX.11.3

IX.11.4

IX.11.5

IX.11.6

Interessados - Stakeholders
A quem serve o caso de uso?

Quem tira proveito de seus resultados?

Muitas vezes no so apenas os atores

Pr-condies
O que deveria ser sempre verdadeiro para que o caso de uso possa acontecer

Pr-condies NO so testadas dentro do caso de uso.

Elas so assumidas como verdadeiras antes do incio dele.

Devem comunicar APENAS questes dignas de nota, que constituam

informao til sobre o funcionamento do sistema

Ps-Condies ou Garantias de Sucesso

Estabelecem o que deve ser verdadeiro APS o caso de uso.

Todos os interessados devem ser satisfeitos

O Caminho Feliz ou Fluxo Principal

Apresenta uma seqncia de passos

Normalmente NO tem condies ou ramificaes

Excees so tratadas como seqncias alternativas

Os passos devem descrever trocas de informao (interao), validao ou

mudana de estado.

Tipos de Passos

o Obrigatrios Fluxo de informao

o Complementares Contextualizao
o No-recomendados Controle e execuo (passos internos ao sistema)
IX.11.7

Extenses ou Fluxos Alternativos

Esto associadas aos passos do fluxo principal

188

Identificam um erro, a forma de trata-lo e como retornar ao fluxo principal, se

for possvel

Um fluxo alternativo tem pelo menos quatro partes

o Identificao o nmero da linha do fluxo principal onde a exceo

ocorre e um identificador para a prpria exceo na lista (por exemplo,
1a, 1b, ..., 2a, 2b, ...)
o Identificao da exceo necessrio identificar qual a exceo que
ocorreu, pois em uma mesma linha do fluxo principal podem ocorrer
diferentes tipos de excees. Por exemplo, fita danificada, fita
reservada, etc.
o Aes corretivas deve-se identificar a seqncia de aes que
deveriam ser executadas para corrigir a exceo.
o Finalizao - Se o caso de uso retorna ao fluxo principal depois das
aes corretivas ou no.

Finalizao de uma exceo

o Voltar ao incio do caso de uso, o que no muito comum;

o Voltar ao incio do passo que causou a exceo e execut-lo
novamente, o que mais comum.
o Depois das aes corretivas, ao invs de voltar para o mesmo passo, ir
para o passo seguinte. Isso pode ser feito quando as aes corretivas
realizam a operao que o passo deveria ter executado. Porm deve-se
verificar se novas excees no poderiam ainda ocorrer neste mesmo
passo.
o Abortar o caso de uso. Neste caso, no se retorna ao fluxo principal.
IX.11.8

IX.11.9

IX.11.10

Requisitos Especiais
Requisitos no funcionais associados ao caso de uso, como

eficincia desejada,

tecnologia de implementao,

etc.

Variaes Tecnolgicas e de Dados

Se for o caso, indique as diferentes formas de realizar tecnologicamente os
diferentes passos do caso de uso

Questes em aberto
Tudo o que deve ser esclarecido posteriormente

IX.12

Um BOM caso de uso...

Corresponde a um processo elementar da empresa

NO um passo nico como deletar um item ou imprimir um relatrio.

189

NO leva dias ou mltiplas sesses, como negociar um contrato.

uma tarefa concluda em uma sesso e que produz um resultado mensurvel

deixando as informaes em um estado consistente.

IX.13

Como descobrir casos de uso?

Estabelea o limite do sistema: o que est fora e o que est dentro?

Descubra os atores (externos ao limite do sistema) que realizam os processo

bsicos

Entreviste-os para descobrir mais informaes sobre seus objetivos

Possivelmente a cada objetivo corresponder um caso de uso

O principal problema com casos de uso o excesso de decomposio Funcional. Seus

sintomas so:

Casos de Uso pequenos

Muitos Casos de Uso

Dificuldade de entender o modelo

Nomes com operaes de baixo nvel

o Operao+objecto
o Funo+dados
o Exemplo: Inserir Carto
As aes corretivas que podem ser tomadas so:

Busque um contexto mais amplo

o Por que o sistema est sendo feito?

Se coloque no papel do usurio

o O que o usurio quer alcanar?

o Que valor esse caso de uso adiciona?

IX.14

Como fazer casos de uso

1. Identifique os atores e seus objetivos
2. Para cada caso: escreva um caso simples
3. Para cada caso: escreva as condies de falha e extenses
4. Para cada condio de falha: descreva o que acontece at que volte ao
norma ou acabe (em falha) Resolva as falhas
5. Detalhe as variaes de dados

IX.14.1

Identifique os atores e seus objetivos

Quais computadores, subsistemas e pessoas vo dirigir o sistema
o Um ator qualquer coisa com comportamento
190

O que cada ator precisa que o sistema faa

o Cada necessidade mostra um gatilho do sistema

Resultado

o Lista de casos de uso

o Viso geral do sistema
o Lista pequena e usvel das funes do sistema
IX.14.2

2) Para cada caso: escreva um caso simples

O objetivo alcanado
o O cenrio principal de sucesso
o caso do dia feliz
o Mais fcil de ler e entender
o Qualquer coisa a mais uma complicao

Capture a inteno e responsabilidade de cada ator, da ativao at alcanar o

objetivo

Diga que informao passada entre atores

Numere cada linha

Resultado

o Descrio legvel das funes do sistema

IX.14.3

3) Escreva as condies de falha e extenses

Normalmente, cada passo pode falhar

Anote cada condio de falha separadamente aps o cenrio principal de

sucesso

Resultado:

o Lista de cenrios alternativos

IX.14.4

4) Resolva as falhas.
Extenses recuperveis voltam ao caso principal

Extenses no-recuperveis falham

Cada cenrio vai do gatilho ao fim

Extenses so apenas uma forma resumida de escrever

Pode escrever se

Pode escrever cenrio do incio ao fim

Resultado:

o Casos de uso completos

IX.14.5

5) Detalhe as variaes de dados

Algumas extenses so muito baixo nvel para fazer agora
191

IX.14.6

IX.14.7

IX.14.8

Ex: Reembolse comprador

Como? Cheque, dinheiro, etc.?

Adie variaes que podem ser tratadas por casos de uso de menor abstrao

Boas Perguntas
Quais so as tarefas de um ator?

O ator precisa ser informador de certas ocorrncias dentro do sistema?

O ator precisa informar o sistema de mudanas externas?

O sistema fornece ao negcio o comportamento adequado?

Todos os requisitos funcionais foram atendidos pelos casos de uso?

Que casos de uso vo suportar e manter o sistema?

Que informao precisa ser modificada ou criada?

Casos de Uso Especiais

Incio e Parada do sistema

Manuteno do sistema

Manuteno da informao

Normalmente aparece mais tarde

Adicionar nova funcionalidade a sistema funcionando

Sistemas que no podem parar

Portar o sistema rodando para um novo ambiente

Quando o ator a organizao desenvolvedora

Comentrios
O valor dos casos de falha detectar situaes anormais e manter a
completude

Todo cenrio vai do incio ao fim (sem ses), mas a descrio pode ser
abreviada

Os requisitos cobrem as falhas recuperveis ou no

Mas no so falhas do sistema interno, mas do ambiente

O cenrio ideal ajuda a descrever as falhas

Um cenrio pode se referir a objetivos de nvel inferior

Caso de uso subordinados

Funes comuns

Um caso de uso superior s se interessa se o caso de uso inferior alcana o

sucesso ou falha

No analisa os detalhes

Cada passo de um cenrio um sub-objetivo

192

IX.14.9

Esconde um sub caso de uso

Pode ser to profundo que no descrito

Cada sentena em cada nvel um objetivo

Casos de uso NO
Mostram requisitos de interface
o Colete por caso de uso

Mostram requisitos de desempenho

o Conecte-os ao caso de uso

Coletam frmulas, estados, cardinalidades

o Capture separadametne
IX.14.10

IX.14.11

O Processo de Escrita
Defina o escopo e as fronteiras

Determine mudanas no contexto inicial criado com listas in/out

Faa um brainstorm e liste os atores primrios

Priorizando Casos de Uso

Que casos de uso devem ser implementados?

Associar os casos de uso aos requisitos originais

Em que seqncia devem ser implementados?

Selecionar os casos de uso para iteraes de arquitetura

Que representem funcionalidade central significante

Que cubram grande parte da arquitetura

Que forcem ou ilustrem um ponto especfico e delicado da arquitetura

Priorize os casos de uso/cenrios para iteraes futuras

IX.15

Casos de Uso Essenciais e Reais

Casos de uso essenciais no levam em considerao a tecnologia

Casos de Uso Reais levam tudo em considerao

IX.15.1
Aparncia - Essencial
1. Cliente fornece a sua identificao
2. Sistema identifica usurio
3. Sistema oferece operaes disponveis
4. Cliente solicita saque de uma determinada quantia
5. Sistema fornece a quantia desejada da conta do cliente
6. Cliente recebe dinheiro e recibo

193

IX.15.2
Aparncia Real
1. Cliente passa seu carto no caixa eletrnico
2. Sistema apresenta solicitao de senha
3. Cliente digita senha
4. Sistema exibe menu de operaes disponveis
5. Cliente indica que deseja realizar um saque
6. Sistema requisita quantia a ser sacada
7. Cliente informa quantia a ser sacada
8. Sistema solicita re-insero do carto
9. Cliente insere o carto
10. Sistema fornece dinheiro
11. Cliente retira dinheiro
12. Sistema fornece recibo
13. Cliente retira recibo
14. Sistema libera carto
15. Cliente recupera carto

194

IX.16

Verbos para usar em casos de uso

Verbos Informativos

Analisar
Descobrir
Buscar
Identificar
Informar
Monitorar

Notificar
Encontrar
Consultar
Requisitar
Selecionar
Especificar
Ver

12

Verbos Performativos

Conseguir
Permitir
Arranjar
Mudar
Classificar
Definr
Entregar
Projetar
Garantir
Estabelecer
Alcanar
Avaliar

Questionar
Fazer
Realizar
Executar
Providenciar
Preencher
Solicitar
Aprontar
Preparar
Especificar
Recuperar
Completar
13

IX.17

Uma soluo para o Problema da Livraria

UCD1:

UCD2:

28

29

195

UC1: Cliente usa Livraria

UC2: Comprar Livro

Ator Principal: Colecionador

Nvel:
Cenrio Principal:

Colecionador solicita Cadastro

Colecionador compra Livro

Colecionador pede Livro

Livraria ABC aprova Pedido
Livraria ABC solicita Livro ao Fornecedor
Fornecedor entrega Encomenda
Livraria ABC atende Colecionador

22

23

UC3: Pedir Livro

UC4: Receber Pedido

1. Colecionador envia um pedido

1. Colecionador envia Fax
2. Colecionador envia Carta
3. Colecionador faz Ligao

includo

2. Vendedor recebe o Pedido

3. Vendedor envia estimativa ao
Colecionador
4. Colecionador confirma proposta
Aceita estimativa?

24

UC5: Preparar Estimativa

25

UC6: Preparar Estimativa

1. O Vendedor cria uma Estimativa
2. Os seguintes passos so repetidos

1. O Vendedor repete os seguintes

passos

1.
2.
3.
4.
5.
6.

1. O Vendedor indica um Livro

2. O Sistema lista Livros do Catlogo
Completo
3. O Vendedor escolhe um Livro
4. O Vendedor indica o preo do Livro

2. O Vendedor fecha a Estimativa

3. O Sistema imprime a Estimativa

Vendedor lista os Livros

Vendedor investiga os Preos
Vendedor envia proposta para Funcionria
Funcionria aprova a Proposta
Vendedor prepara a estimativa

O Sistema oferece a tela de busca

O Vendedor indica um Livro
O Sistema lista Livros do Catlogo Completo
O Vendedor adiciona o Livro a Estimativa
O Sistema apresenta os dados bsicos do Livro
O Vendedor indica o preo do Livro

3. O Vendedor fecha a Estimativa

4. O Sistema calcula os valores totais e impostos
5. O Sistema imprime a Estimativa
26

27

Bibliography
[1] A. Cockburn, Writing Effective Use Cases Addison Wesley, 2001.

196

Captulo X. Modelo de Interface

Muitos autores consideram que a modelagem da interface com o usurio uma ao
caracterstica da fase de projeto de um sistema. Porm, a prtica de desenvolvimento de
sistemas mostra que o usurio s tem uma verdadeira viso da funcionalidade do sistema
quando pode ter alguma amostra do seu funcionamento. Sem essa viso, muito difcil para o
usurio validar uma anlise. Em decorrncia disso, muito comum que um modelo de dados
ou um modelo funcional desenvolvido e validado com o usurio contenha falhas. Isso
acontece porque estes modelos so modelos abstratos criados em uma linguagem mais
prxima e conhecida do desenvolvedor do que do cliente.
Este captulo no fala profundamente sobre a questo de como deve ser uma interface
com o usurio, apenas apresenta alguns mtodos de modelagem para a mesma, com o intuito
de fornecer aos interessados em um sistema uma viso do seu comportamento,
funcionamento e aparncia.
O leitor interessado nestas questes deve procurar textos prprios das seguintes reas:
Interao Homem-Computador (Human-Computer Interaction, HCI), Projeto centrado no
usurio (user centered design), Interface com o Usurio (User-Interface, UI), Engenharia
Cognitiva, Projeto Participativo (Participatory Design), Ergonomia, Avaliao de Interfaces
com o Usurio e ainda outras. Uma boa dica consultar o site http://www.hcibib.org/

X.1 A Interao Homem Computador (IHC)

Um sistema no composto apenas pelo programa de computador, mas tambm por
aqueles que se comunicam de programa, sejam eles humanos ou outros programas. Podemos
mudar o projeto de um computador ou de um programa, mas no podemos mudar os seres
humanos. Precisamos, ento, compreend-los melhor para poder desenhar interfaces
melhores.
A interao homem computador corresponde a um ciclo, onde cada parte recebe
informaes, as processas e emite novas informaes. Uma das partes um ser humano, a
outra um computador. Cada uma possui caractersticas prprias para cada uma dessas
atividades. No caso do processamento, por exemplo, computadores (bem programados) tm
uma capacidade de clculo inigualvel pelo ser humano, enquanto seres humanos so capazes
de proezas no reconhecimento de padres.
Deve ficar claro que no estamos aqui nem humanizando o computador, nem vendo o
homem como uma mquina. Apenas procuramos uma metfora que nos permita entender
melhor como se realiza a interface entre eles. Tambm no esquecemos que computadores
foram programados por seres humanos. Uma das formas interessantes de ver a IHC como
um dilogo entre o desenvolvedor e o analista, porm no trataremos desse assunto aqui.

197

Ler

Responder

Pensar

HOMEM

Ler

I
n
t
e
r
f
a
c
e

COMPU
TADOR

Pensar

Responder

Figura 107. A Interao Homem Computador

X.1.1 Projetando a Interface com o Usurio

As escolhas feitas na modelagem de interface com o usurio so um problema ainda
em aberto e que envolvem muitos fatores, sendo estudados por muitos autores nos campos de
interao homem computador e projeto (design) de interface.
Entre os principais fatores envolvidos esto aqueles que envolvem aspectos humanos.
A cincia cognitiva uma das ferramentas utilizadas, pois estuda o conjunto de processos
mentais relacionados ao pensamento, a percepo e a tarefas como reconhecimento e
classificao. A ergonomia outro fator importante.
Outros fatores importantes em projetos reais so as ferramentas disponveis e o hbito
e a cultura do usurio. Enquanto um projeto acadmico, ou um web-site de propaganda, pode
ousar muito na sua concepo de interface, projetos empresariais muitas vezes devem seguir
padres ou se adaptar a condies de uso que no so as ideais. Projetos internacionais ainda
tm outros problemas, pois a variao de cultura de um local para o outro pode invalidar
premissas do desenvolvedor. Como exemplo simples, enquanto as lnguas como portugus e
ingls so escritas da esquerda para direita, rabe e hebraico so escritas da direita para
esquerda. Isso afeta toda uma forma de entender a interface com o usurio.
Dentro do fator humano e cognitivo, uma questo que sempre deve ser levada em
conta que o usurio faz um modelo mental do sistema, fazendo suposies sobre o que deve
ocorrer em uma parte do sistema baseado no aprendizado que teve em outra parte do mesmo.
Vamos dar um exemplo simples: se em uma parte do sistema ao tentar apagar um objeto o
usurio tem a oportunidade de desistir ou voltar atrs, vai esperar que o mesmo acontea em
todo o sistema. Quando por algum motivo essa regra quebrada o usurio fica surpreso, pois
h uma quebra do seu modelo mental apagar permite desistir ou voltar atrs. Isso faz com
que nossos modelos de interao com usurio busquem no s a consistncia, mas tambm
facilitar a criao do modelo mental do usurio por meio do uso de metforas ou outras
formas de indicao.
Cabe ao projetista da interface lidar com todas as caractersticas do ser humano, e
tambm das infinitas variedades entre os seres humanos. O projetista tem um modelo mental
que representa na imagem do sistema. O usurio v essa imagem e gera um novo modelo
mental. Os problemas das interfaces homem computador aparecem nas diferenas entre esses
trs modelos: o modelo mental do projetista, a imagem do sistema e o modelo mental do
usurio[B44].

198

X.1.2 Introduo ao Modelo Cognitivo usado em IHC

Como vimos anteriormente, podemos fazer um modelo do ser humano (e do
computador) dividindo suas atividades ao usar o computador em trs tipos: percepo
(responsvel pela leitura de informaes), atividades cognitivas (memria e
processamento) e sistema motor (responsvel pela sada de informaes).
Uma caracterstica importante de seres humanos que eles podem ser modelados
efetivamente como possuindo duas memrias: uma memria de curto prazo (MCP) e uma
memria de longo prazo (MLP). A primeira rpida e limitada, com pequena durao. A
segunda infinita, faz associaes muito complexas e no tem acesso confivel. Alm disso,
o sistema cognitivo humano tem um processamento lento, apesar de ser poderoso em algumas
atividades, como o reconhecimento de padres visuais.

X.1.3 As Aes dos Usurios

Segundo Donald Norman[B44], para executar uma ao passamos por sete estgios:
15) Formar o objetivo, o que se deseja no sentido mais amplo (por exemplo,
matar a sede).
23. A Execuo, dividida em 3 passos:
24. Formar a inteno, o que se far (por exemplo, beber gua ou beber um suco).
25. Especificar a ao, (algo como ir a geladeira, pegar uma garrafa de gua, ir ao armrio,
pegar um copo, colocar gua no copo e beber)71.
26. Executar a ao,
27. A Avaliao, dividida tambm em 3 passos
28. Perceber o estado do mundo,
29. Interpretar o estado do mundo e
30. Avaliar o resultado (em relao aos objetivos originais).
Entender como um usurio constri seu modelo mental tambm entender como
executar sua atividade. Fazendo perguntas especficas sobre como as fazes sero realizadas
ou modeladas permite ao projetista alcanar um resultado mais adequado.

X.2 Coletando Informaes Sobre o Usurio

Uma das mais importantes atribuies do analista ou designer ao projetar uma
interface conhecer seu usurio. Usurios diferentes tm demandas diferentes para um
mesmo sistema.
Um modelo simplificado de usurios admite trs tipos de usurios: um usurio que
no conhece a aplicao e nem o sistema (novato), um usurio que conhece a aplicao e o
sistema (experiente) e o usurio que conhece bem a aplicao, mas pouco o sistema
(eventual). Normalmente um sistema tem que atender simultaneamente a todos esses tipos de
usurio e ainda ajudar a transformar um usurio novato em experiente.
necessrio, ento, coletar informaes sobre os usurios do sistema. Isso pode ser
feito por meio de formulrios. Esses formulrios devem levantar a formao do usurio, seu
71

O exemplo escolhido bastante complicado e envolve sub-objetivos e sub-intenes, em uma atividade longa e
composta.

199

tempo no cargo e na empresa, sua experincia com computadores, Internet, outros sistemas
da empresa ou sistemas semelhantes. Alm disso, interessante conhecer que atividades o
usurio faz em seu trabalho e com que freqncia (diria, semanal, mensal, raramente).
Outras informaes podem ser levantadas, como impossibilidades de usar uma ferramenta
especfica ou incapacidades fsicas. Existem vrios modelos de formulrios que podem ser
utilizados como referncia na literatura e na Internet, a seguir apresentamos um exemplo
muito simples.

X.2.1 Questionrio para identificao de usurios

Pergunta
Formao

Tempo na empresa

Tempo no cargo

Tempo de uso de
computador
Tempo de uso da Internet

Sem
educao
formal
Menos
de 6
meses
Menos
de 6
meses
Nunca
usou
Nunca
usou

Liste suas tarefas no cargo

Qualidade do ambiente de
trabalho
Iluminao

1 grau

2 grau

3
grau

Entre 6 Entre 1 e
Entre Mais de 5
meses e
2 anos
2e5
anos
1 ano
anos
Entre 6 Entre 1 e
Entre Mais de 5
meses e
2 anos
2e5
anos
1 ano
anos
Menos
Entre 6
Entre Mais de 5
de 6
meses e
2e5
anos
meses
2 ano
anos
Menos
Entre 6
Entre Mais de 5
de 6
meses e
2e5
anos
meses
2 ano
anos
Indique a freqncia de realizao

Diria Semanal

Mensal

Rara

Diria Semanal

Mensal

Rara

Diria Semanal

Mensal

Rara

Diria Semanal

Mensal

Rara

Diria Semanal

Mensal

Rara

Diria Semanal

Mensal

Rara

Diria Semanal

Mensal

Rara

Diria Semanal

Mensal

Rara

Ruim Razovel

Boa

Muito
ruim

Respostas
Psgraduado

Outra
_____
Outra
_____
Outra
_____
Outra
_____
Outra
_____
Outra
_____
Outra
_____
Outra
_____

tima

200

Pergunta
Rudo
Postura ao trabalhar
Risco ao trabalhar
(venenos, exploses...

Muito
alto
Muito
ruim
Muito
alto

Alto Aceitvel

Pouco

Ruim Aceitvel

Boa

Respostas
Quase
nenhum
tima

Baixo

Nenhum

Alto

Pouco

X.3 Prottipos
Levando em conta a necessidade de mostrar algo menos abstrato do que modelos aos
clientes, qualquer processo de desenvolvimento atual tem a tendncia de acelerar a criao da
interface com o usurio, que representada pelas telas ou formulrios com o qual o usurio
interage e os relatrios e outras formas de aviso que recebe do sistema.
Um prottipo uma implementao simplificada do sistema, podendo inclusive ser
descartvel, com diferentes finalidades, como validar um modelo de interface ou um modelo
de funcionamento ou ainda um algoritmo. Normalmente prottipos so construdos utilizando
a ferramenta em que o sistema est ou ser desenvolvido (podendo servir inclusive para
validar essa ferramenta) e apresentam algum comportamento, mesmo que simulado.
Um mock-up uma representao da interface que no cumpre nenhuma finalidade a
no ser demonstrar a uma proposta para a aparncia final do sistema, sem a capacidade de
simular seu comportamento (a no ser, possivelmente, a navegao entre telas). Um mock-up
no precisa ser feito com uma ferramenta de programao, podendo ser feito com ferramentas
de desenho, como os softwares Visio ou SmartDraw. Um prottipo de baixa fidelidade
um mock-up feito a mo da interface, basicamente um conjunto de desenhos, com a
finalidade de demonstrar a aparncia bsica e simular, manualmente, o comportamento do
sistema. Um prottipo de alta fidelidade um mock-up feito de forma a se assemelhar ao
software final, sendo normalmente construdo na linguagem de desenvolvimento ou em uma
ferramenta com resultados similares. Prottipos de alta fidelidade so executados pelo
computador.

201

Figura 108. Um prottipo de baixa fidelidade (acima) e um prottipo de alta

fidelidade correspondente (Landay)72.

O uso de prottipos desde o incio do desenvolvimento permite ao desenvolvedor

experimentar diferentes abordagens e discuti-las com o usurio, obtendo feedback mais cedo
durante o ciclo de desenvolvimento e tambm antecipando a indicao, pelo usurio, de erros
de anlise e projeto.
Segundo McConnel73, a prototipagem de interface com o usurio tem um bom
potencial de reduo do tempo do projeto, diminui o risco de insucesso e um excelente fator
para o sucesso a curto (primeira-vez) e longo prazo de um sistema. Os maiores riscos
associados a essa tcnica, ainda segundo McConnel, seriam a possibilidade de perder tempo
fazendo melhorias de baixa importncia no prottipo, alm de outros riscos de qualidade
historicamente associados aos prottipos, como a utilizao no cdigo final de cdigo que foi
criado para ser jogado fora, e conseqentemente sem seguir regras e padres de
desenvolvimento.
O uso de prottipos pode ser um motivador para a participao dos usurios no
sistema, diminuindo o antagonismo e aumentando a cooperao entre desenvolvedores e
futuros usurios. A viso de um algo j realizado melhora a moral do projeto como um todo,

72

Imagem ilustrativa usada pelos princpios de fair use. Imagem ilustrativa usada pelos princpios de fair
use. No se aplicam a essa imagem os mesmos direitos desse texto.

73

McConnell, Steve. Rapid Development: Taming Wild Software Schedules. Microsoft Press, Redmond, Washington,
1996

202

porm pode trazer como risco a confiana demasiada e um otimismo exagerado em relao a
prazos, como uma decepo proporcional a seguir.
Com certeza, prottipos facilitam em muito a validao de sistemas, principalmente
de novos sistemas, onde h certo grau de explorao da soluo mais adequada. Alm disso,
podem facilitar a encontrar funes desnecessrias ou funes esquecidas, principalmente
com usurios j acostumados com sistemas semelhantes.
Prottipos podem ser criados de forma parcial. Por exemplo, se um sistema exige a
manuteno (incluir, excluir e alterar) de vrias entidades, como aluno, professor e
funcionrio em um sistema acadmico, a prototipagem de uma dessas interaes pode servir
de forma de validao para todas as outras.

X.3.1 Prottipos de Baixa Fidelidade & StoryBoarding

A construo de prottipos de baixa fidelidade algo que muitos fazemos sem nem
mesmo nos darmos conta. Um prottipo de baixa fidelidade (PBF) um desenho,
provavelmente feito a mo, usado por uma pessoa para demonstrar o comportamento do
sistema para outra pessoa. Esse tipo de prottipo totalmente diferente do prottipo
tradicional proposto normalmente e que inclui a construo de um software.
PBF podem ser desenhados em quadros negros, quadros brancos, sobre papel, sobre
transparncia, em tablet PCs, ou qualquer outra forma, incluindo a unio das citadas.
Podem ser feitos a mo livre ou com auxlio de rguas, gabaritos ou outros materiais de
desenho. Pode ser preto e branco ou colorido. Podem usar materiais pr-desenhados, como
frames de janelas, ou serem feitos a partir de colagens.
Poucos so as habilidades necessrias para desenhar um PBF. Seu custo tambm
baixo e o ciclo de interao com o usurio muito rpido. PBFs podem ser desenhados junto
com o usurio, inclusive em uma reunio de JAD. Um dos efeitos psicolgicos interessantes
que o usurio, no vendo uma implementao, fica mais disposto a propor mudanas, pois
no v nenhum custo ou esforo associado s mesmas, o que, na prtica, verdade.
A principal caracterstica de PBF que eles so explicados e executados, ou
melhor, encenados, manualmente. Partes do prottipo podem ser desenhadas com detalhes,
enquanto outras podem ser s indicadas. Alguns objetos podem ser cortados em um tamanho
apropriado, como caixas mensagens e menus. A construo dessa encenao semelhante
tcnica de storyboarding usada no cinema.

203

Figura 109. Um storyboard para um desenho animado indica como deve

ser a seqncia de cenas. Original encontrado em
(http://www.surrart.ac.uk/arc/archive/digitation.html)

Como o comportamento de um PBF executado por uma pessoa, em uma estratgia

conhecida como Mgico de Oz74, sua documentao no to simples. A partir da
encenao do uso da interface feita uma avaliao, que pode levar a necessidade de aceitla, melhor-la ou at mesmo iniciar tudo do incio.

74

Na histria, uma pessoa manipula o Mgico de Oz atrs de uma cortina.

204

Figura 110. Exemplo de partes de um prottipo de baixa fidelidade.

Algumas janelas foram desenhadas a mo, outras em um computador. O
mouse um ponteiro que pode ser mexido com a mo (Landay).75

Figura 111. Um prottipo de baixa fidelidade de uma tela, indicando

operaes possveis (em vermelho) (Landay).76

75

Imagem ilustrativa usada pelos princpios de fair use. Imagem ilustrativa usada pelos princpios de fair
use. No se aplicam a essa imagem os mesmos direitos desse texto.

76

Imagem ilustrativa usada pelos princpios de fair use. No se aplicam a essa imagem os mesmos direitos
desse texto.

205

Figura 112. Vrios prottipos de baixa fidelidade em uma folha compondo

um storyboard (Landay). 77
Softwares para prototipagem de baixa fidelidade
Com computadores se tornando presente em todos os ambientes,
possvel pensar em construir prottipos de baixa fidelidade diretamente no
computador
e
no
apenas
com
papel.
O
software
DENIM
(http://guir.cs.berkeley.edu/projects/denim/) foi projetado para isso. Ele permite
que um grupo de pessoas desenhe a interface a mo e associe algum
comportamento que executado pelo automaticamente. Na verdade, o
software mais adequado a ambientes que usam canetas (como um tablet PC)
do que mouse.
Uma das vantagens de usar um software desse tipo que ele pode executar
a interface automaticamente. DENIM fornece essa possibilidade, por meio do
comando Run. No futuro, DENIM deve permitir a identificao automtica dos
widgets mais comuns em ambientes de desenvolvimento.

77

Imagem ilustrativa usada pelos princpios de fair use. No se aplicam a essa imagem os mesmos direitos
desse texto.

206

Figura 113. O software DENIM, para desenho de prottipos de baixa

fidelidade e construo de storyboards (Landay).78

Figura 114. Uma pgina sendo executada em DENIM (Landay).79

X.4 Modelos de Navegao

Modelos funcionais e de dados tambm no representam uma caracterstica
importante que o comportamento esperado do sistema pelos usurios. Novamente, alguns
autores defendem que essa modelagem deve ser feita na fase do projeto, e provavelmente ela
realmente deve ser detalhada nessa fase, porm a ausncia dessa modelagem na fase de
anlise pode levar a graves erros de estimativa de custos, pois comportamentos distintos para
alcanar a mesma funcionalidade podem ter custos de desenvolvimento muito diferenciados.
Por exemplo, imaginem um sistema cuja finalidade registrar as multas de trnsito
aplicadas por policiais e gerar alguns relatrios. A especificao funcional simples, o
principal evento policial envia auto de infrao. Porm isso pode ser recebido de vrias
formas: por meio de um digitador que l o auto de infrao, por meio da digitalizao e

78

Imagem ilustrativa usada pelos princpios de fair use. No se aplicam a essa imagem os mesmos direitos
desse texto.
79

Imagem ilustrativa usada pelos princpios de fair use. No se aplicam a essa imagem os mesmos direitos
desse texto.

207

reconhecimento de caracteres ou recebendo arquivos gerados por PDAs, como j acontece

em algumas cidades. O custo de implementao de cada uma dessas formas muito diferente,
alm do que um sistema pode exigir que todas essas formas sendo implementadas, o que
aumenta ainda mais o custo.
Por isso, importante criar um modelo do comportamento do sistema ainda na
anlise, respondendo, de certa forma, como as funes sero executadas, mesmo que em um
nvel muito alto de abstrao. Esse modelo pode ser muito simples, porm no existem
ferramentas padronizadas para cri-lo, o que complica um pouco o seu desenho. A seguir
veremos algumas propostas j utilizadas com diferentes graus de sucesso em sistemas
distintos.

X.4.1 O Diagrama de Navegao de Telas

Esse um diagrama muito simples, semelhante a um diagrama de transies estado,
que mostra quais so as possveis navegaes entre as telas de um sistema. Vrios autores
sugerem notaes similares.
O exemplo da figura a seguir utiliza algumas regras arbitrrias, que so comuns em
modelos de navegao. No se faz distino entre a funcionalidade, apenas na navegao.
Assim, por exemplo, de Apaga Usurio navegamos para Lista Usurio qualquer que seja
a opo (OK ou Cancel). Nesse diagrama no indicamos a necessidade de selecionar
elementos para apagar ou editar, o que pode ser feito em alguma outra notao. O importante
aqui ter uma idia de quantas telas abstratas sero necessrias e ter uma noo do
comportamento do sistema (isso porque o cadastro de um usurio, por exemplo, pode exigir
vrias telas, o que s seria visto no projeto). Outra coisa que podemos notar que s est
sendo considerado, nesse modelo, o comportamento normal. Outros modelos, ou um
refinamento deste modelo, podem permitir a incluso de telas de ajuda ou mensagens de erro,
por exemplo.
Entre as vantagens de construir um diagrama de navegao esto a sua simplicidade e
informalidade. Apesar de abstratos, podem ser usados em discusses com o usurio com certa
facilidade. Alm disso, servem tambm para dar aos desenvolvedores uma viso geral do
comportamento do sistema.

208

Figura 115. Um diagrama de navegao de telas, feito com o software

PowerPoint.

X.5 Organizando Informao

Uma das tarefas mais difceis na modelagem da interface como organizar a
informao a ser apresentada. De acordo com Shedroff [B1]existem 7 formas bsicas de
organizar a informao:
31. Alfabetos, que na prtica no tem nenhum significado especial, mas so ensinados desde
a infncia. Assim, a ordem alfabtica, apesar de totalmente artificial (quem disse que a letra
M vem antes da letra V?) se tornou natural para as pessoas.
32. Locais, principalmente quando podemos associar imediatamente a informao a uma
referncia geogrfica.
33. Tempo, organizando a informao pela seqncia em que os fatos ocorrem no tempo.
34. Contnuos, na forma de nmeros ou outra escala, como estrelas para um hotel, ou escalas
comparativas (o alfabeto uma escala comparativa especial), onde temos uma noo de
ordem. Organizando desta forma estamos indicando que a escala escolhida a mais
importante naquele contexto.
35. Nmeros que no representam um contnuo, por exemplo o Sistema Decimal de
Dewey. Nmeros apresentam a vantagem de ser uma representao mais universal que
alfabetos.
36. Categorias, ou seja, juntar objetos semelhantes.
37. Aleatrios, que no uma forma de organizao, mas sim uma forma de desafiar e de
apresentar dados para serem explorados ou melhorar a experincia do usurio.

X.6 Tipos de Erros

Conhecendo os possveis tipos de erros, podemos prev-los e evitar que aconteam
por meio de algum mecanismo de interface.
209

Segundo [B44], existem 6 tipos de erros:

Erros de Captura

Erros de Descrio

Erros Causados por Dados Externos

Erros por Ativao Associativa

Erros por Falta de Ativao

Erros por Modos

X.6.1 Erros de Captura

Acontece, por exemplo, se estamos acostumados a contar cartas e vamos contar
cartes de crdito. Poderamos falar algo como 1,2,3,...,10,valeta,dama,rei.
Esses erros acontecem quando executamos 2 seqncias de aes diferentes com um
estgio inicial comum, sendo uma muito mais praticada que a outra. Algumas vezes, ao
realizar a menos comum, automaticamente passamos a executar a mais comum.
Dizemos
que a mais comum captura a menos comum. Raramente, pode acontecer o inverso

X.6.2 Erros de Descrio

So erros como em vez de jogar a roupa no cesto de lavar, jogar no lixo.
Nesse caso, a descrio de duas ou mais aes so muito semelhantes e uma delas
escolhida ao acaso, causando o erro.
importante lembrar que antes de realizar uma atividade, as pessoas a descrevem
mentalmente de alguma forma. Essa descrio pode ser, por exemplo, jogar a roupa na caixa
aberta.
Ocorrem de forma mais comum quando os objetos confundidos esto prximos

X.6.3 Erros Causados por Dados (externos)

Ao discar para um nmero de telefone, em vez de escolher o nmero correto, disca
para um nmero que est na sua frente.
Aes automticas so dirigidas por dados - ativadas pela chegada do dado..
Algumas vezes a chegada de outro dado atrapalha uma ao j iniciada.

X.6.4 Erros por Ativao Associativa (confuso com dados internos)

Toca o telefone e dizemos "pode entrar".
Associaes (dados internos) podem ativar aes.

X.6.5 Erros por falta de ativao

Acontecem quando, por exemplo, ficamos na porta da geladeira nos perguntando o
que viemos fazer.
apenas o que conhecemos como esquecer.
Acontece quando se perde (esquece) o estmulo que nos levou a atividade.

X.6.6 Erros por Modos

Ocorrem quando um dispositivo tem 2 modos de operao e ativamos a funo que
desejamos no modo errado, com possveis resultados catastrficos.
210

211

Captulo XI. Qual o Tamanho do Software

Como medir software?
Preo
Esforo
Tamanho
Medidas diretas
Medidas indiretas
Pontos de Funo
COCOMO

XI.1 Qual o tamanho do sistema?

Uma das perguntas mais freqentes em desenvolvimento do software qual o
tamanho do sistema? Essa pergunta pode vir sob vrias formas:

Qual o preo do sistema?

Qual o custo do sistema?

Qual o esforo para desenvolver o sistema?

Quantas pessoas sero necessrias para fazer esse software?

Em quanto tempo o sistema ficar pronto?

Quantas linhas de cdigo tem o sistema?

Quantos pontos de funo tem o sistema?

Qual o tamanho do sistema?

Que recursos so necessrios para o sistema?

Nesse captulo veremos como responder essas questes.

XI.2 Preo e Custo

Quando queremos saber o preo ou o custo do sistema a preocupao econmica.
No nosso contexto vamos separar os conceitos de custo e preo: custo quanto se gasta para
desenvolver o sistema, preo quanto se cobra pelo sistema. Apesar de existir uma relao
entre preo e custo, cabe aos responsveis pelo desenvolvimento prever, acompanhar e
calcular o custo do sistema (incluindo muitas vezes no s o desenvolvimento, mas tambm o
custo de implantao, operao e manuteno). O preo, porm, determinado por uma
relao comercial entre cliente e fornecedor80.
Fica claro ento que a principal e primeira pergunta que o desenvolvedor deve fazer
quanto o sistema custa para ser desenvolvido. A partir desse valor, pode-se comear, se
necessrio, a pensar em um preo a ser cobrado.

80

Nessa relao o cliente tenta pagar o menor preo possvel para o sistema e o fornecedor tenta cobrar o maior preo
possvel. Tanto fornecedores quanto clientes devem evitar fazer um acordo com risco de futuro arrependimento.

212

Para sistemas de informao o principal fator de custo o gasto com pessoal81.

Assim, o custo do software diretamente ligado quantidade de pessoas envolvidas no seu
desenvolvimento e ao tempo que elas dedicam a essa atividade.

XI.3 Esforo e Tempo de Desenvolvimento

Tendo em vista que o principal fator de custo no desenvolvimento de software o
gasto com pessoal, uma das principais preocupaes da Engenharia de Software determinar
qual ser a quantidade de pessoas e o tempo por elas dedicado a um projeto. Para isso usamos
o conceito de Esforo que representa a quantidade de trabalho realizado, medido em pessoams82, ou seja, o trabalho feito por uma pessoa em um ms.
Assim, podemos dizer que um sistema precisa de 4 pessoas-ms para ser realizado, ou
seja, que uma pessoa trabalhando 4 meses ou 4 pessoas trabalhando um ms. Acontece que
sistemas de informao so um pouco como bebs: no podemos ter a gestao de um beb
com nove mes em um ms. Na verdade, Boehm achou uma relao entre o esforo
necessrio e o tempo necessrio para fazer um sistema, e conseqentemente o tamanho mdio
da equipe.
Obviamente, o que fazemos no incio do projeto tentar prever o esforo necessrio
para realiz-lo com sucesso, e conseqentemente o tempo necessrio para complet-lo. Essas
previses so mais ou menos acertadas de acordo com vrios fatores, incluindo a maturidade
da empresa, a disponibilidade de dados histricos, a experincia dos responsveis pela
predio e a capacidade intrnseca do modelo utilizado na predio.
Um dos principais modelos de predio do esforo necessrio o COCOMO II. Esse
modelo, baseado em equaes matemticas derivadas a partir da anlise estatstica de casos
reais bastante completo. No COCOMO II, que apresentaremos de forma reduzida a seguir,
o esforo calculado a partir de uma previso do tamanho do software.

XI.4 O Tamanho do Software

At agora descobrimos que para saber o preo de um software precisamos saber seu
custo, e que para saber seu custo precisamos saber o esforo necessrio para desenvolv-lo.
Finalmente chegamos questo mais difcil: como prever o tamanho do software, de forma a
determinar o esforo necessrio?
A primeira questo a responder como medir o tamanho do software. Vrios autores
j discutiram amplamente sobre essa questo. Atualmente duas formas so aceitas
internacionalmente para essa medida: milhares de linhas de cdigo fonte (KSLOCs, a partir
do acrnimo em ingls kilo source lines of code) e pontos de funo (PFs ou FPs, do
ingls). Ambos possuem defensores e detratores, vantagens e desvantagens mais bvias ou
mais sutis.
Uma linha de cdigo, no contexto do COCOMO II, deve ser uma linha executvel, ou
uma declarao ou uma diretiva para o compilador, que no tenha sido gerada com um
gerador automtico e que tenha sido feita pela empresa. Linhas de cdigo, obviamente, s
podem ser contadas aps a implementao do software.
81

Outros custos adicionais comuns so equipamento e software. Mesmo quando j possumos o equipamento e o
software temos que nos lembrar de amortizar o seu custo original de alguma forma entre os vrios projetos.
82

Em sistemas menores a medida pessoa-hora.

213

Um ponto de funo uma medida abstrata que representa a funcionalidade entregue

ao cliente, em funo das interfaces do sistema com o usurio, com outros sistemas e ainda
com a informao vista pelo cliente. Pontos de funo so tratados detalhadamente em um
captulo posterior. Pontos de funo podem ser contados a partir desde a especificao do
sistema at sua implementao final.
Essas duas medidas podem ser convertidas uma na outra, por meio de estatsticas
globais ou especficas da empresa.
A vantagem de KSLOC que podemos simplesmente cont-las, a principal crtica
que medir produtividade ou custo por KSLOCs pode provocar distores, pois bons
programadores deveriam utilizar menos linhas de cdigo para realizar uma funo.
Pontos de funo podem ser criticados por ser uma medida abstrata demais, porm
permitem a comparao de sistemas de forma direta.

XI.5 Uma viso reduzida do modelo COCOMO II

COCOMO (Constructive Cost Model) um mtodo de previso de custos de
software. Atualmente possvel conseguir gratuitamente um software COCOMO baseado em
pontos de funo, o que facilita o clculo de custos de projeto de sistemas de informao.
A relao entre o tempo de desenvolvimento e o esforo necessrio, que apresentamos
em sua forma completa a seguir, parte importante do modelo COCOMO83:

TDEV = [C ( PM NS ) ( D + 0.2( E B )) ]

SCED %
100

Equao 1. Tempo de Desenvolvimento calculado pelo modelo COCOMO

Nessa frmula PMNS a quantidade nominal de pessoas/ms84, SCED a compresso

necessria no tempo de desenvolvimento, B,C e D so constantes calibrveis e E um
coeficiente calculado a partir de coeficientes de escala.
N

E = B + 0.01 SF j
j =1

Equao 2. Clculo de E, a partir dos coeficientes de escala.

Na fase inicial do projeto, os coeficientes de escala so 5 (N=5), e representam a

precedncia do sistema, a flexibilidade do projeto, o risco do projeto e da arquitetura, a
coeso da equipe e a maturidade do processo. Em situao normal para todos os casos, o
valor de E igual a 0.2807.
Ficaremos ento com uma frmula simplificada, capaz de atender plenamente os
objetivos desse livro. Caso necessrio, o leitor pode recorrer ao livro Software Cost
Estimation With COCOMO II ou ao web site:
http://sunset.usc.edu/research/COCOMOII/index.html

83

Atualmente em sua segunda verso (COCOMO II)

84

PMNS um valor de pessoas-ms sem considerar esforos de traduo automtica e ainda sem considerar efeitos da
necessidade de acelerar o desenvolvimento

214

TDEV = [3.67 ( PM NS ) 0.32 ]

Equao 3. Equao simplificada que pode ser usada para ter uma
previso do tempo de desenvolvimento a partir do esforo necessrio em
pessoas-ms, baseada no modelo COCOMO II.

Fica ento a pergunta: como descobrir o esforo necessrio. O modelo COCOMO II

tambm nos fornece uma frmula, desta vez baseada na quantidade de linhas de cdigo
previstas para o software. Desta vez forneceremos logo a frmula simplificada:
PM = 2.94 MLDC 0, 28
Equao 4. Equao simplificada de clculo do esforo, onde MLDC
significa milhares de linhas de cdigo.

2.94

0.91

3.67

0.28

Tabela 30. Valores atuais de A, B, C e D.

XI.5.1 Distribuio do Esforo

Uma questo importante na previso do esforo a ser feito para o desenvolvimento de
um software como esse esforo ser distribudo nas fases do processo de desenvolvimento.
O COCOMO 81 tratava desse problema com certo detalhe que no foi continuado no
COCOMO II em 2000. Os dados do COCOMO 81, porm, foram reaproveitados com as
metodologias do COCOMO II.2000 para nos fornecer valores provisrios com que trabalhar.
Para um processo seguindo o modelo em Cascata, os seguintes resultados so
esperados:

Fase

Esforo %

Tempo %

Planos e Requisitos

7 (2-15)

16-24 (2-30)

Projeto do Produto

17

24-28

Programao

64-52

56-40

Programao: Projeto
Detalhado

27-23

Programao: codificao e
Teste de unidade

37-29

Integrao e Testes

19-31

20-32

Transio

12 (0-20)

12.5 (0-20)

Tabela 31 Diviso do esforo nas fases de desenvolvimento do

software segundo Boehm

215

XI.6 Anlise de Pontos de Funo

Uma das mais importantes informaes que podemos ter sobre um produto de
software o esforo necessrio para desenvolv-lo. Usualmente definimos este esforo pela
quantidade de homens/hora ou homens/ms necessrios para desenvolver o produto. A
principal utilizao desta informao tem como objetivo prever e acompanhar o esforo que
ser gasto no desenvolvimento de um produto de porte semelhante.
Porm, como saber qual o porte de um produto de software?
Para isso foram inventadas vrias medidas, algumas delas arbitrrias, outras fceis de
medir. comum que digamos o tamanho de um software pela quantidade de linhas de
cdigo, pelo nmero de horas gasto para desenvolv-lo ou pelo custo final do mesmo.
Porm, at 1979 no tnhamos uma boa medida do tamanho do software em funo da
sua funcionalidade como vista pelo usurio. Apenas nessa data, Albrecht [B45] apresentou
uma medida conhecida como Pontos de Funo, cujo objetivo era servir como avaliador e
preditor do tamanho de um sistema.
Um Ponto de Funo (PF) uma medida abstrata e relativa que conta o nmero de
funes de negcio entregues ao usurio. Um relatrio simples, por exemplo, pode medir 4
Pontos de Funo. Da mesma forma que um metro ou um litro, Pontos de Funo s
fazem sentido quando comparados com um padro. Assim, um sistema com 1.000 PF entrega
o dobro de funcionalidade de que um sistema com 500 PF. Com o tempo, aprendemos a ter
uma idia absoluta do tamanho de um sistema a partir da contagem de seus PFs.
A maneira padronizada de contar pontos de funo fornecida pelo International
Function Points User Group (IFPUG), que fornece aos seus associados um manual contendo
detalhes do que deve e do que no deve ser contado. Esse captulo apenas uma introduo
ao mtodo, descrevendo uma forma levemente simplificada da metodologia oficial, servindo
para fazer clculos aproximados do nmero de pontos de funo de um sistema.

XI.6.1 Procedimento de Contagem

O procedimento de contagem se inicia com a determinao do propsito da contagem,
isto , a explicitao do motivo da contagem estar sendo realizada. Normalmente esse
propsito estar relacionado a fornecer uma resposta a um problema de negcio existente,
como a contratao de um servio.
A partir do propsito podemos determinar o tipo de contagem. So considerados trs
tipos de contagem:

Projeto de Desenvolvimento: onde medimos as funcionalidades entregues ao

usurio em uma verso onde o software desenvolvido desde o incio. Inclui
as funcionalidades necessrias para a converso de dados, mesmo que usadas
uma nica vez.

Projeto de Melhoria: onde medimos as modificaes que alteram, adicionam

ou removem funcionalidades em uma aplicao existente. Inclui as
funcionalidades necessrias para a converso de dados, mesmo que usadas
uma nica vez.

Aplicao: onde medimos uma aplicao j instalada. Tambm chamada de

baseline e normalmente realizada no fim de um projeto de
desenvolvimento e mantida atualizada nos projetos de melhoria.

216

O escopo da contagem define um conjunto ou um subconjunto do sistema, e permite

dizer se uma funcionalidade deve ou no ser contada.
A fronteira da aplicao delimita o software medido, definindo sua interface com o
mundo exterior. Ela servir no s para considerarmos se uma funo deve ou no ser
contada, mas tambm para considerar se um arquivo lgico deve ser contado como interno ou
externo a aplicao.
Definido o tipo de contagem, a fronteira e o escopo da contagem, que influenciaro a
forma final de contagem, identificamos as funes de negcio como percebidas pelo usurio,
dividindo-as em 5 grupos, agrupados em 2 tipos:
XI.6.1.1 Funes

Transacionais
Um processo elementar a menor atividade significativa para o usurio de forma
indivisvel. Isso significa que o usurio o v como um processo nico, completo e
independente de outros, que se inicia com o sistema em um estado consistente e termina com
o sistema em um estado consistente.

Um processo elementar ser contado como uma de trs possveis formas de funo
transacional.

Sadas externas (SE ou EO),so informaes de negcio que o usurio final

pode receber, representando relatrios, telas e mensagens de erro como um
todo e no em suas partes individuais;

Consultas externas (CE ou EQ), que so sadas simples e imediatas, sem

alterao na base, usualmente caracterizveis por chaves simples de consulta.

Entradas externas (EE ou EI), que so processos elementares que processam

informaes de negcio recebidas pelo sistema de fora da fronteira da
aplicao e Cuja finalidade principal manter um Arquivo Lgico Interno .

XI.6.1.2 Funes

de Dados
Arquivos lgicos internos (ALI ou ILF), que contm os dados permanentes,
relevantes para o usurio e mantidos e utilizados pelo sistema. O sistema cria,
altera e apaga esses dados.
Arquivos de interface externos (AIE ou EIF), que contm dados
permanentes e relevantes para os usurios, guardados em algum lugar por
outra aplicao, mas referenciados pela aplicao em questo. Outro sistema
mantm esses dados.

O segundo passo determinar a complexidade de cada funo de negcio. A

complexidade fornece um peso para cada funo de negcio encontrada. O somatrio do
nmero de funes multiplicadas pelo seu peso fornece o nmero bsico de pontos de
funo. Esse nmero um indicador preliminar do tamanho do sistema.
Finalmente, no terceiro passo, o nmero bsico de pontos de funes corrigido em
funo de fatores que aumentam ou diminuem a complexidade do sistema.

217

Determinar
Tipo da
Contagem

Identificar Escopo e
Fronteira da Aplicao

Determinar valor
do Fator de Ajuste

Contar PF
Transacionais

Contar PF para
Dados

Determinar PF
no ajustado

Calcular PF
Ajustado

Figura 116. Procedimento de contagem dos pontos de funo, adaptado

de XXX.

XI.6.2 Identificando Funes de Negcio

Para identificar as funes de negcio devemos partir de algum documento que
aponte as funes aprovadas e pelo usurio e teis para o negcio. No devem ser contadas
funes necessrias por causa da tecnologia aplicada. Basicamente, s cobrado o que o
usurio pode ver e est disposto a pagar. Tambm importante que as funes de negcio
sejam cobradas como o usurio as percebem. Isto significa que no interessa se estamos
usando um ou vinte arquivos para guardar uma informao, mas sim de quantas formas o
usurio pode acessar essa informao.
Alm disso, devemos identificar as funes seguindo certa ordem. A ordem
importante porque encontrar um tipo de funo de negcio ajuda a encontrar as funes de
outro tipo. Assim, em um sistema novo devemos usar a ordem: sadas, consultas, entradas,
arquivos e interfaces. Por outro lado, em um sistema j existente devemos usar a ordem
arquivos, interfaces, sadas, consultas e entradas.
Para serem contados as funes devem:

Beneficiar claramente o usurio,

Ser especificamente aprovado pelo usurio e

Influenciar em algum grau mensurvel o projeto, desenvolvimento,

implementao e suporta aplicao.
218

No manual da IFPUG podemos encontrar vrios exemplos que nos permitem dirimir
as dvidas de como realizar a contagem. A tcnica simples, porm difcil de dominar.

Identificando Sadas
Para contar as sadas necessrio contar todas as informaes que o sistema gera para
o ambiente de forma procedimental. Tipicamente, sadas so relatrios impressos, telas,
janelas e arquivos gerados para outras aplicaes.
Deve ser contadas como sadas distintas cada formato utilizado. Basicamente, se for
necessrio fazer outro procedimento para produzir a informao, contamos como uma sada
distinta. Tambm contamos cada tipo de lgica utilizada para fazer gerar a informao.
Assim, se um relatrio de vendas contm as vendas por vendedor e por loja, contaremos
como duas sadas, pois so necessrios procedimentos lgicos distintos para calcular cada um
desses valores. Linhas de sumrio e total, porm, no so contadas como novas sadas.
Uma sada externa pode ter uma parte de entrada, para, por exemplo, selecionar os
registros necessrios em um relatrio, usando alguns campos como filtro. Essa parte
entrada no contada a parte, j est considerada nessa contagem.

Identificando Consultas
Consultas so, na prtica, sadas simplificadas. Normalmente utilizadas para achar
informaes para modific-las ou apag-las. So sempre no monitor, no existe uma consulta
em relatrio de papel.
Uma consulta no pode calcular nenhum valor. Em caso de clculo de qualquer valor,
temos uma sada.

Identificando Entradas
Entradas permitem adicionar, modificar e apagar informaes. Se uma tela permite
estas 3 funes, so contadas 3 entradas. Normalmente as funes de modificar e apagar
ainda exigem consultas correspondentes para achar a informao que ser alterada.
Um comando especfico para o sistema executar algo uma entrada.
Mensagens de erro que fazem parte de um processo no so contadas isoladamente,
mas sim como um DET. Por exemplo, se voc esquecer de colocar um campo obrigatrio e
receber uma mensagem de erro, no deve contar uma sada a mais, e sim essa mensagem
como um DET da entrada ou consulta.
Mensagens de notificao, por outro lado, so processos elementares e devem ser
contados como uma sada a parte. Por exemplo, ao tentar comprar um produto que no existe
e receber uma mensagem com essa notificao foi feito um processamento, que contado
como uma sada externa adicional.

XI.6.3 Entendendo as Lgicas de Processamento

A lgicas de processamento, ou formas de processamento lgico, so as
caractersticas que uma transao tem de acordo com os requisitos solicitados
especificamente pelo usurio.
A partir dessas lgicas de processamento podemos determinar, como indicado na
Tabela 32, qual o tipo de funo transacional que deve ser contado.

219

Forma de Processamento Lgico

Tipo de Funo
Transacional

Realiza validao dos dados

Realiza clculos ou frmulas matemticas

O*

Converte valores equivalentes

Filtra dados e seleciona usando critrios especficos para

comparar mltiplos conjuntos de dados

Analisa condies para determinar qual aplicvel

Altera ou inclui ao menos um ILF

O*

O*

Referencia ao menos um ILF ou EIF

Recupera dados ou informao de controle

Cria dados derivados

O*

Altera o comportamento do sistema

O*

O*

Prepara e apresenta informao fora das fronteiras do sistema

capaz de aceitar dados ou informao de controle que entra

pela fronteira da aplicao

Reordena ou reorganiza um conjunto de dados

Tabela 32. Tipo de Funo Transacional e lgica de processamento

correspondente (P=possvel, O=obrigatrio, N = No permitido, O* =
obrigatrio alternativo). Em especial, por obrigatrio alternativo queremos
dizer que uma das lgicas (linhas) deve estar presentes para caracterizar
uma entrada externa ou sada externa (na coluna). EE = Entrada Externa,
SE = Sada Externa, CE = Consulta Externa.

XI.6.4 Identificando Arquivos Internos

Arquivos representam um grupamento lgico requerido pelo usurio. Podem incluir
uma ou mais tabelas ou entidades.
Esse uma das partes mais difceis da contagem de pontos de funo, pois devemos
separar o que o usurio pensa do modelo que criamos. Nosso modelo muitas vezes usa vrios
grupos de dados, ou tabelas, ou entidades, para modelar algo que o usurio v como um
conceito nico. Mesmo na modelagem conceitual, a tendncia do analista incluir entidades
que o usurio no v naturalmente.
Um Tipo de Elemento de Registro (RET, Record Element Type) um subgrupo de
elementos de dados dentro de um arquivo ou interface. Na prtica, em um modelo de dados,
um arquivo do usurio (ILF) composto de um ou mais objetos do modelo.
Outra caracterstica difcil de contar que cada forma de acesso a um arquivo lgico
conta novamente. Assim, por exemplo, se o usurio exige acessar um automvel tanto por
sua placa quanto por seu nmero do chassi, temos 2 arquivos lgicos para contar.
Exemplos: Uma nota fiscal um arquivo lgico, com dois RETs: dados da nota, item
de nota.

220

XI.6.5 Identificando Arquivos Externos

Arquivos Externos representam um grupamento lgico requerido pelo usurio. Podem
incluir uma ou mais tabelas ou entidades.
Arquivos Externos so mantidos por outras aplicaes. Arquivos importados contam
tambm como Entrada Externa, arquivos exportados contam tambm como Consulta Externa
ou Sada Externa.
XI.6.5.1 Identificando

Itens de Dados (DETs)

Itens de dados ou elementos de dados (DETs) campos nicos, reconhecidos pelos
usurios, desconsiderando-se recurso e repetio. DETs tambm podem invocar aes.
Exemplos de DETs so:
Em Entradas externas

campos de entrada de dados

mensagens de erro

valores calculados que so guardados

botes

mensagens de confirmao

campos repetidos contam apenas como um DET

Em Sadas Externas

Campos em relatrio

Valores calculados

Mensagens de erro

Cabealhos de coluna que so gerados dinamicamente em um relatrio

Em Consultas Externas (alm dos anteriores que se enquadrem)

Campos usados em filtros de procura

O clique do mouse

Em GUIs, botes onde s se pode fazer uma seleo entre muitas (normalmente radio
buttons) devem ser contados como um DET apenas. J check boxes so normalmente
contadas uma a uma. Botes de comando devem ser contados como um elemento de dados
levando em conta o fato de executarem uma funo.

XI.6.6 Determinando a Complexidade

Para todos os tipos de funo de negcios, importante determinar o nmero de itens
de dados referenciados.
Para sadas, consultas e entradas, ns devemos contar o nmero de arquivos
acessados.
Para arquivos e interfaces, devemos contar o nmero de RETs e o nmero de campos
de dados do arquivo.

221

Sadas
Arquivos
Referenciados

Itens de dados referenciados

1-5

6-19

20+

0 1

Simples (4)

Simples (4)

Mdia (5)

2-3

Simples(4)

Mdia(5)

Complexa(7)

4+

Mdia (5)

Complexa (7)

Complexa (7)

Tabela 33. Clculo da complexidade de sadas externas

Entradas
Arquivos
Referenciados

Itens de dados referenciados

1-4

5-15

16+

0 1

Simples (3)

Simples (3)

Mdia (4)

Simples (3)

Mdia (4)

Complexa (6)

3+

Mdia (4)

Complexa (6)

Complexa (6)

Tabela 34. Clculo da complexidade de entradas externas

Consultas
Arquivos
Referenciados

Itens de dados referenciados

1-5

6-19

20+

0 1

Simples (3)

Simples (3)

Mdia (4)

2-3

Simples (3)

Mdia (4)

Complexa (6)

4+

Mdia (4)

Complexa (6)

Complexa (6)

Tabela 35. Clculo da complexidade de consultas externas (dica: analisar

como sada, dar o valor como entrada)
Arquivos Internos
RETs

Itens de dados referenciados

1-19

20-50

51+

Simples (7)

Simples (7)

Mdia (10)

2-5

Simples (7)

Mdia (10)

Complexa (15)

Mdia (10)

Complexa (15)

Complexa (15)

Tabela 36. Clculo da complexidade de arquivos lgicos internos

Arquivos Externos
RETs

Itens de dados referenciados

1-19

20-50

51+

Simples (5)

Simples (5)

Mdia (7)

2-5

Simples (5)

Mdia (7)

Complexa (10)

Mdia (7)

Complexa (10)

Complexa (10)

Tabela 37. Clculo da complexidade de interfaces lgicas externas

XI.6.7 As Perguntas
So 14 as perguntas que devem ser feitas e ajudaram a determinar a quantidade de PF
relativa a um sistema. Cada uma deve ser respondida com um nmero, de 0 a 5, indicando a
importncia da caracterstica que se pergunta sobre o sistema, da seguinte forma:
222

0 - No tem influncia
1 - Influncia incidental
2 - Influncia moderada
3 - Influncia mdia
4 - Influncia significativa
5 - Influncia essencial em todo o sistema

Para cada pergunta, o padro IFPUG determina tipos de respostas padronizadas que
nos permitem dar a resposta (entre 0 e 5) mais facilmente, como exemplificado no item 1
(Comunicao de Dados). Foge ao objetivo desse texto fornecer um detalhamento completo
do padro de contagem, que pode ser obtido junto ao IFPUG.
1. Quantas facilidades de comunicao existem para facilitar a transferncia ou troca de
informao com a aplicao ou sistema?
1.1.

Aplicao em batch ou computador isolado: 0

1.2.

Aplicao em batch com entrada ou (exclusivo) impresso remota: 1

1.3.

Aplicao em batch com entrada e impresso remota: 2

1.4.

A aplicao um front-end que necessita de executar coleta de dados ou

teleprocessamento para um sistema de fazer o processamento em batch ou de consultas:
3

1.5.

A aplicao mais que um front-end, porm s executa um tipo de protocolo de

teleprocessamento: 4

1.6.

A aplicao mais que um front-end e executa vrios protocolos de

teleprocessamento: 5

2. Como ser tratada a distribuio de dados e processamento?

3. O usurio exige tempos de resposta ou throughput, ou seja, o desempenho crtico?
4. Quo fortemente utilizada a plataforma (hardware) onde a aplicao vai ser executada?
5. Qual a freqncia das transaes (dirias, semanais, altas o suficiente para exigir um estudo
de desempenho)?
6. Que percentagem das informaes inserida on-line?
6.1.

Se mais de 30% das transaes forem entradas de dados interativas, a nota 5.

7. A aplicao projetada para eficincia para o usurio final?

8. Quantas ILFs so alteradas por transaes on-line?
9. A aplicao tem processamento lgico ou matemtico extensivo?
10. A aplicao desenvolvida para atender um ou muitos tipos de usurios diferentes?
11. Qual a dificuldade de converso e instalao?
12. Qual a eficincia e grau de automao de inicializao, backup e recuperao?
13. A aplicao foi especialmente projetada, desenvolvida e suportada para funcionar em locais
diferentes em diferentes organizaes?
14. A aplicao foi especialmente projetada, desenvolvida e suportada para facilitar mudanas?

223

XI.6.8 Clculo dos Pfs Finais

Os PF so calculados em etapas:

contam-se os nmeros de entradas, sadas, consultas, arquivos e interfaces do sistema;

Para cada entrada se determina um grau de complexidade, de acordo com as tabelas
complexidade da funo (Tabela 33 at Tabela 37), e somando os resultados (Tabela 38) se obtm a
contagem bsica de pontos de funo;
responde-se a uma srie de perguntas, as quais fornecem, cada uma, um valor de 0 a 5
(pi, 0 i 5),
calcula-se o nmero de pontos de funo com a equao:
PF = total-de-2 x (0,65 + 0,01 x (pi)).
Devemos notar que se o clculo de PF for usado para fazer previses
seguindo o mtodo COCOMO, apenas a contagem bsica
necessria (s devem ser feitos os passos 1 e 2).

224

(passo 1)

Mdia

Contagem
Total

Simples

Funo

Complexa

Complexidade (passo 2)

Total

Sadas Externas

Consultas Externas

Entradas Externas

Arquivos Lgicos Internos

10

15

Arquivos de Interface
Externos

10

Total
Tabela 38. Guia de clculo para os pontos de funo. Primeiro deve ser
feita a contagem total, por tipo de funo. Para cada item contado deve
ento ser determinada a complexidade, o que permitir encontrar o total
(que o total-de-2).

XI.6.9 Contando PFs na Anlise

So trs as principais informaes que temos para contar pontos de funo a partir da
anlise que fizemos:
1. Modelo Funcional, lista de eventos ou DFD
2. Modelo da interface
3. Modelo de Entidades e Relacionamento (MER), Modelo Conceitual ou Lgico.

A lista de eventos, o DFD ou o modelo da interface nos fornece a capacidade de

contar as funes transacionais. O MER nos permite contar os PFs para dados.
A questo da contagem deve levar em conta que tanto a entrada tem caractersticas de
sada (mensagens de erro, por exemplo), quanto sadas e consultas tem caractersticas de
entrada (valores de filtros nas consultas, por exemplo). A Tabela 32 a principal ferramenta do
analista nessa contagem.

XI.6.10
Inflao de PFs ao decorrer do projeto
normal que o nmero de PFs se modifique ao decorrer o desenvolvimento do
projeto. Isso acontece por dois motivos: alterao dos requisitos e necessidade de
implementar mais pontos de funo para atender ao comportamento desejado pelo usurio do
que estritamente exigido pelo modelo essencial.
normal que os pontos de funo previstos em um incio de anlise aumentem em at
25% at o final do projeto.

XI.6.11
Utilizando Pfs para previses
Para utilizar os Pfs para fazer previses necessrio primeiro conhecer a
produtividade em PF/(homem/ms) da equipe que realizar o software. importante levar em
conta o ambiente onde esta equipe trabalha, suas qualidades e defeitos, as ferramentas
disponveis e o tipo de trabalho que realizam afetam o clculo dessa produtividade. Por

225

exemplo, comum que equipes de manuteno obtenham produtividade (aparente) muito

maior que equipes de desenvolvimento quando utilizada a medida de pontos de funo.
Sabida a produtividade da equipe, basta calcular o nmero de PFs para o sistema
proposto, por exemplo, analisando o resultado da anlise essencial, e dividir esse nmero pela
produtividade, obtendo o esforo necessrio para implementar o produto.

XI.7 Ligando COCOMO II e Pontos de Funo

Boehm et al. [XXX] prope que o mtodo COCOMO II pode ser utilizado para prever
o tempo e o esforo necessrio para o desenvolvimento de um software a partir da previso
de pontos de funo necessrios. Para isso, usam uma tabela de converso entre pontos de
funo e linhas de cdigo lgicas, apresentada originalmente por Caper Jones [XXX Jones
96].
A previso se torna simples, basta calcular o nmero de pontos de funo no
corrigido (pois o COCOMO II j apresenta correes similares em seu clculo), converter
para linhas de cdigos com essa tabela e aplicar as frmulas.
Caper Jones, porm, alerta que os dados apresentados no so confiveis, sendo
mdias que no levam em conta diversas particularidades do desenvolvimento de software
por um grupo especfico, usando uma arquitetura e ferramentas especficas. Isso pode ser
confirmado usando a Tabela 39, fornecida pela empresa QSM, e que mostra no s a mdia,
mas como valores mais altos e mais baixos, o que demonstra variao de at 28 vezes (como
em Cobol) entre a menor e maior quantidade de linhas de cdigo por ponto de funo
encontradas em projetos distintos.
Linguagem
Access
ASP
Assembler
C
C++
C#
Clipper
COBOL
Excel
J2EE
Java
Lotus Notes
Oracle
Oracle Dev 2K/FORMS
Powerbuilder
SQL
Visual Basic

Mdia
35
69
172
148
60
59
38
73
47
61
60
21
38
41/42
30
39
50

SLOC/FP
Mediana Mais Baixo Mais Alto
38
15
47
62
32
127
157
86
320
104
9
704
53
29
178
59
51
66
39
27
70
77
8
400
46
31
63
50
40
60
59
14
97
22
15
25
29
4
122
30
21/23
100
24
7
105
35
15
143
42
14
276

Tabela 39. Tabela de converso de pontos de funo para linhas de

cdigo apresentada pela empresa QSM em
[http://www.qsm.com/FPGearing.html, em 26/1/2006.85

85

Dados apresentados dentro das regras de fair use.

226

XI.8 Estimando o Tamanho

Precisamos ento de metodologias que nos permitam prever o tamanho de um produto
de software. A partir de uma estimativa podemos ento utilizar as frmulas.
No caso de pontos de funo a metodologia principal fazer uma anlise inicial e
contar os pontos de funo presentes no resultado da anlise. Dependendo da qualidade do
processo da empresa e da profundidade dessa anlise inicial o erro nessa contagem ser bem
pequeno.
J no caso de linhas de cdigo precisamos de um mtodo de predio, como por
exemplo, solicitar a previso a um especialista com experincia em projeto semelhante. Um
dos mtodos sugeridos no passado foi a Tcnica de Delfos86. Atualmente a tcnica no
aparece muito nos livros didticos, provavelmente porque no atende as necessidades de
velocidade do mundo atual.

XI.8.1 A Tcnica de Delfos

A Tcnica de Delfos uma forma de fazer com que especialistas entrem em consenso
sobre uma predio ou estimativa sem que haja uma discusso frente a frente.
Segunda a tcnica a primeira ao a ser feita a definio do produto sobre o qual a
estimativa ser feita. No nosso caso a pergunta em que estamos interessados quantas linhas
de cdigo sero necessrias para implementar o software. Normalmente, a definio faz uma
diviso do software em mdulos, para facilitar a estimativa.
So ento escolhidos especialistas, para os quais so distribudos os questionrios com
a descrio dos mdulos. Para cada mdulo os especialistas devem fazer uma predio de
tamanho. Este o primeiro ciclo.
A partir do primeiro ciclo so feitos ciclos sucessivos onde so distribudos os
mesmos questionrios, porm com a informao, no identificada, de cada resposta dada.
Normalmente esta informao dada em um grfico indicando ainda a estimativa mnima, a
mxima, a mediana e a mdia. A partir do segundo ciclo os especialistas devem justificar
suas respostas, de maneira a facilitar a convergncia de opinies. Esse tipo de ciclo repetido
at que o consenso seja atingido.
Apesar da Tcnica de Delfos no ser muito rpida, compreender seu funcionamento
pode ajudar a determinar como deve ser feito o trabalho de predio de especialistas.

XI.8.2 Cenrios
Outra tcnica alternativa determinar cenrios de pior caso, caso mais provvel e de
melhor caso. O valor final da estimativa dado por:
Ve =

Vpc + 4 Vcmp + Vmc

6

Equao 5. Clculo do valor estimado (Ve) em funo do valor de pior

caso (Vpc), valor do caso mais provvel (Vcmp) e do valor do melhor caso
(Vmc).

86

Ou Delphi. Baseado no Orculo de Delfos, nica relao direta com a linguagem Delphi.

227

XI.8.3 Tcnicas baseadas em Pontos de Funo

Uma das formas de usar pontos de funo para a estimativa de tamanho do sistema
conhecida como contagem indicativa e foi proposta pela NESMA (Netherlands Software
Metrics Users Association). Ela consiste em contar apenas os Arquivos de Interface Externa e
os Arquivos Lgicos Internos. Consideram-se 35 pontos por cada AIE e 15 pontos para cada
AIL.
J o ISBSG (International Software Benchmarking Standards Group) prope acelerar
a contagem de pontos de funo com o uso de valores mdios para projetos de
desenvolvimento, segundo a tabela a seguir:
Tipo de Funo

PFs mdios
IBSBG

PFs mdios
NESMA

Arquivo Lgico Interno

7,4

Arquivo de Interface Externa

5,5

Entrada Externas

4,3

Sada Externa

5,4

Consulta Externa

3,8

Tabela 40. Valores mdios recomendados pelo IBSBG e pela NESMA para
contagem estimativa de Pontos de Funo

Outra forma possvel a analogia com sistemas semelhantes (com possvel aplicao
do mtodo Delphi ou do Valor Estimado).

XI.9 Verificando a Sanidade da Estimativa

importante que qualquer estimativa seja verificada quanto a sua qualidade. Uma das
melhores formas tentar formas alternativas de estimar e verificar se os resultados so
compatveis.
Por exemplo, interessante verificar a estimativa dada por um mtodo (por exemplo,
COCOMO II) com estimativas dadas por um segundo mtodo, de preferncia feitas por
pessoas diferentes.

XI.10

Produtividade em Pontos de Funo

Podemos apresentar dois dados recentes sobre a produtividade e Pontos de Funo. O

David Consulting Groups apresenta os seguintes valores87 mdios para diferentes plataformas
em janeiro de 2006:

87

http://www.davidconsultinggroup.com/indata.htm

228

Plataforma de
Desenvolvimento
Cliente-Servidor
Mainframe
Web
e-Business Web
Vendor Packages
Data Warehouse

PF por Pessoa
Ms
17
13
25
15
18
9

Tabela 41. Valores mdios de produtividade em pontos de funo para

pessoas-ms segundo David Consulting Group.

229

Captulo XII. Projeto 1: Livraria ABC

O exemplo a seguir, a Livraria ABC, uma adaptao de um problema que
apresentado em muitos cursos universitrios no Rio de Janeiro.

XII.1

Ateno:

A descrio a seguir tenta manter um nvel ainda inicial, mas mostrar alguns
problemas tpicos da elicitao de requisitos:
1. Nem todo entrevistado diz tudo o que faz na primeira entrevista.
2. Alguns casos de uso ficam escondidos em uma palavra ou sentena que
parece ter pouca importncia.
3. Termos diferentes so usados por entrevistados para significar a mesma coisa.
4. Alguns entrevistados falam de uma parte (ou de alguns objetos) de um caso de
uso que outro entrevistado no falou.
5. Usurio de mais alto nvel na empresa muitas vezes no citam partes
importantes do processo.
6. Algumas coisas que a empresa no quer que acontea, acontecem.

XII.2

Entrevista 1: Proprietrio da Empresa Sr. Jos Letrado

A Livraria ABC atua no mercado de venda de livros de arte e livros raros, de

colecionadores, sob encomenda.
Nossa atuao no prev a manuteno de livros em estoque. Todos os livros
solicitados por seus clientes so, semanalmente, encomendados s editoras, distribuidoras,
outras livrarias e outros vendedores em geral. Ns somos uma espcie de empresa de
corretagem, que facilita a vida de colecionadores.

O cliente pode pedir qualquer livro, mas ns no trabalhamos com livros comuns.
Nosso mercado restrito e de alto valor agregado. Trabalhamos com livros do mundo todo e
temos contatos em todos os lugares. At no Nepal. A partir do pedido do cliente, a gente
investiga se o livro pode ser encontrado e trazido para o Brasil.
Para usar os servios da livraria, os clientes devem se cadastrar previamente. O
pedido de cadastro aprovado por mim ou por meu filho.

230

Os clientes enviam seus pedidos pelo correio, telefone ou fax. O pedido aceito se o
cliente estiver previamente cadastrado. Caso contrrio, o pedido rejeitado com um aviso ao
solicitante para se cadastrar. Isso importante, pois ns normalmente pagamos os livros antes
de receber por eles e so livros caros.
Nas sextas-feiras, a livraria emite requisies de livros para os fornecedores, com base
nos pedidos recebidos.
Quando os livros so entregues pelo fornecedor, a livraria confere a nota de entrega
da editora com a requisio, devolvendo as que contiverem erros.
Os pedidos dos clientes so atendidos imediatamente quando completos, isto ,
quando todos os livros pedidos foram enviados pelos fornecedores (ou forem cancelados). O
atendimento consiste na emisso de uma nota fiscal, de um boleto de pagamento, que so
enviados junto com o livro. Cpias da nota fiscal e do boleto so enviadas a tesouraria.
Se depois de 30 dias da data de entrega o fornecedor no enviou um livro requisitado,
a livraria cancela o pedido junto ao fornecedor e elimina o livro do pedido do cliente.
enviado um aviso ao cliente desse fato, junto com o restante do pedido, se existir, ou
isoladamente pelo correio.

XII.3

Entrevista 2: Henrique Cupim Letrado, funcionrio e

filho do proprietrio (patrocinador)
A seguir descrevemos fragmentos de uma conversa com o Sr. Jos Letrado,
proprietrio da Livraria ABC, que deseja um SI para sua empresa.
A livraria funciona da mesma forma h muitos anos, com tudo feito de forma manual.
Porm, com a possibilidade cada vez maior de trabalhar com livros do mundo todo, nosso
trabalho aumentou muito. Meu pai das antigas, mas eu o convenci a comear a mudar as
coisas, para eu poder tocar melhor o negcio sozinho quando ele se aposentar.
Primeiro pensei em contratar mais pessoas, porm isso no ia diminuir a confuso de
papis com que estamos lidando e a falta de informaes, ento resolvi que seria necessrio
informatizar a empresa para, se necessrio, crescer.
Hoje nosso processo, como todo manual, tem muitos defeitos. Temos muita
informao repetida, pois temos que controlar os pedidos dos clientes e as requisies aos
fornecedores, que se cruzam. Muitas vezes recebemos um livro e por um problema de
anotao no sabemos para qual cliente se destina. Ento gastamos um bom tempo
procurando, cliente por cliente, quem pediu aquele livro.
Mantemos tambm vrios arquivos de clientes, o que facilita em certos casos, mas
dificulta em outros. Temos os clientes com pedido em andamento, aqueles com pedidos
atendidos, mas no pagos, os freqentes e os outros clientes, que no se enquadram em
nenhuma dessas categorias. E tem a lista dos clientes expulsos, pois nos deram calote e
ainda tem a cara de pau de pedir outro livro.
Como estamos sempre manipulando fichas, algumas vezes esquecemos de requisitar a
um fornecedor um ou mais livros pedidos pelo cliente. Isso atrasa o atendimento e resulta em
reclamaes que no so boas para a livraria.

231

Claramente, a primeira coisa que o sistema deve fazer suportar o nosso

funcionamento dirio. Estou falando da operao bsica de atendimento aos clientes, no da
cobrana ou outras coisas do gnero, pois para essas vou comprar sistemas prontos88.
A partir dessa operao, tambm so necessrios alguns dados para ajudar a gerenciar
melhor a empresa. Dois relatrios so muito importantes para mim: um relatrio de vendas
em um perodo e um relatrio de gastos por fornecedor. Outro relatrio que me ajudaria
muito o de pedidos no atendidos.
Os desenvolvedores devem se lembrar que essa empresa antiga e tradicional. Tanto
os funcionrios quanto a muitos dos clientes tem pouco hbito de usar computadores. O
sistema deve ser muito simples de ser usado. Alm disso, como pretendemos ter mais de um
computador, o sistema deve funcionar em rede.
Outra coisa importante que j compramos um sistema gerenciador de banco de
dados, por causa do sistema de ERP que instalamos. O sistema tem que usar esse SGDB.

XII.4

Entrevista 3: Sra. Lcia Pinho, Funcionria

A seguir, algumas informaes levantadas em uma reunio com Lcia Pinho,

funcionria de confiana da Livraria ABC.
Fazemos as coisas do mesmo jeito aqui h muitos anos, mas com a carga de trabalho
aumentando, concordo que um sistema de vendas pode ajudar.
O importante que se leve em conta que estamos comprando outros sistemas de
informao no especficos para a Livraria ABC no mercado. Por exemplo, teremos um
sistema de contas a pagar e a receber que dever receber as informaes do sistema que vocs
vo fazer.
O que eu mais preciso melhorar o nosso relacionamento com o cliente. Para isso, a
informao que vem do sistema de vendas essencial. Uma coisa importante, por exemplo,
saber que clientes freqentes no compram mais na freqncia que compravam. Outro
classificar os clientes de acordo com o tipo de livro que gostam, para podermos fazer ofertas
de livros novos.
Outra coisa importante que, com os problemas de entrega, acabamos com um
pequeno estoque de livros que compramos, mas os clientes no compraram da gente. Ento
eu quero fazer algo com isso. Uma mala direta de promoo, por exemplo.
Tenho pensado muito em como um sistema pode nos ajudar. At mesmo pensei se
no seria interessante vender livros pela Internet, o que vocs acham disso? Seria uma grande
novidade para ns e nossos clientes.

XII.5

Entrevista 4: Enron Lando Nopapo, vendedor

Sou eu que fao as vendas mesmo aqui. Normalmente eu recebo um pedido do cliente
com uma lista de livros. Ento eu vou nos vrios catlogos que possumos, alguns de editoras,
outros de distribuidoras, e procuro os livros desejados. Fao uma lista com cada livro, onde
podemos compr-los, o prazo de entrega, e o preo de custo e uma estimativa de preo de

88

O funcionamento dirio da empresa Livraria ABC descrito no Projeto 1.

232

frete. Tambm consulto a Internet para fazer essa lista. Algumas vezes tenho que esperar uma
cotao que vai chegar for fax ou telefone, ento eu para o servio para comear mais tarde.
Essa lista eu envio para a Lcia, que define o preo de venda de cada livro. Ela faz
isso baseada na experincia dela com os clientes e as necessidades da empresa. Ns
compramos os livros em muitas moedas, so livros caros, de arte, ou livros raros e antigos, de
colecionador, e a taxa de cmbio tambm importante.
Com os preos definidos eu fao uma estimativa do frete para o cliente e preparo uma
proposta. Essa proposta passada para o cliente de vrias formas: fax, carta, telefone ou,
ultimamente, tenho usado meu e-mail pessoal para facilitar.
Geralmente dentro de 24h o cliente confirma a proposta, ou parte dela. Eu ento
separo os pedidos que sero feitos na sexta-feira. Quem trata dessa parte dos pedidos para os
fornecedores o prprio Sr. Letrado. Muitas vezes ele consegue mais um desconto na compra
dos livros. Algumas das vezes esse desconto, ou parte dele, repassado para o cliente.
Quando chegam todos os livros de um cliente eu comeo a trabalhar de novo. Sou eu
que fecha a venda. Recalculo o preo de custo e de venda. Passo os casos de possvel
desconto para a Lcia, que decide na hora. Emito uma fatura, uma nota fiscal, empacoto e
preparo para os entregadores (a gente usa a DHD ou a XPS). Muitas vezes eu telefono, ou
mando um e-mail, para avisar o cliente que o pedido est sendo enviado.

XII.6

Nesse Exerccio:
1. Levante os stakeholders
2. Levante interesses e objetivos dos stakeholders
3. Levante os atores
4. Levante os casos de uso de nvel sumrio (nuvem) e nvel empresarial caixapreta
5. Levante os casos de uso de nvel sumrio (pipa) e nvel empresarial branca
6. Liste os casos de uso de nvel usurio e nvel sistema (caixa preta)
a. Descreva de forma breve e casual um desses os casos de uso
b. Descreva de forma detalhada um desses casos de uso
7. Desenhe os Diagramas de Atividade para todos os casos de uso
8. Define as condies de exceo

233

Projeto 2: Empresa de Clipping ClipTudo

A empresa de clipping ClipTudo trabalha coletando matrias de jornal que so de
interesse de seus clientes, preparando um portfolio peridico contendo cpias de todas as
matrias, uma pequena avaliao de cada matria segundo alguns critrios especficos e ainda
um relatrio mensal global.
A empresa funciona da seguinte maneira.
Com um entrevistador, o cliente define tpicos de interesse. Cada tpico uma
palavra ou uma sentena que pode ser identificada facilmente, como o nome da empresa do
cliente ou um termo como reforma da previdncia ou venda de bebidas. A partir desses
termos iniciais o entrevistador cria uma lista expandida, com sinnimos e conceitos
semelhantes. Essa lista verificada pelo cliente, gerando uma lista final de tpicos de
interesse.
Novamente com o entrevistador, o cliente define critrios de anlise. Os critrios so
quase sempre os mesmos, como vis da notcia em relao necessidade do cliente (boa,
ruim, neutra, propaganda paga), rea da notcia, nmero estimado de leitores, etc.
Tambm junto com o entrevistador, o cliente define que meios de comunicao
escrita sero monitorados, em uma lista mantida pela empresa de clippings.
A partir da quantidade de tpicos, da complexidade da anlise, do perodo de gerao
de portfolios e da quantidade e freqncia dos meios de comunicao, feito um preo bsico
do servio para o cliente. Alm do preo bsico o cliente ainda paga pela quantidade de
cpias que deseja do portfolio e do relatrio mensal.
No trabalho dirio da empresa so empregados dois tipos de funcionrios: leitores,
classificadores e analistas. Os leitores lem todas as publicaes e copiam os artigos
desejados, classificando segundo os tpicos de um ou mais clientes. Os classificadores pegam
todas as notcias, classificando-as por cliente e criando um portfolio bsico. Os analistas
fazem as anlises dirias e guardam os dados para as anlises mensais, completando os
portfolios.
Todo dia, at as 12h00min, so enviados os portfolios referentes a toda publicao
obtida at as 19h00min do dia anterior, de acordo com o perodo pedido pelo cliente (dirio,
semanal, etc.).
Mensalmente os analistas pegam os dados que guardaram diariamente e fazem os
relatrios mensais de resumo.
Cada vez que emitido um portfolio, uma cpia de portfolio ou um relatrio mensal
enviado um aviso ao sistema de cobranas.

234

O Diagrama de Fluxo de Dados

O objetivo de um Diagrama de Fluxo de Dados (DFD) descrever, graficamente, o
fluxo de informao e as transformaes que so aplicados nos dados [B41]. Ele pode ser
utilizado para representar, em diferentes nveis de abstrao, sistemas de informao, no
necessariamente automatizados. DFDs permitem a modelagem funcional de um sistema em
vrios nveis de abstrao.
Cada diagrama de um DFD composto de 4 tipos de objetos: processos, memrias,
agentes externos e fluxos de dados. Cada um desses objetos tem um smbolo, um nome e
possivelmente um rtulo associado.
No passado existiram duas correntes de smbolos para desenhar DFDs. Os que
desenhavam processos como caixas com as bordas arredondadas, baseados na proposta de Gane e
Sarson [B42], e os que desenhavam processos com crculos, baseados na proposta de Coad e
Yourdon [B43]. Atualmente a forma de Yourdon a mais difundida no mercado.

Cada processo em um DFD pode ser expandido em outro DFD, que o descreve. Dessa
forma, DFDs so utilizados para descrever um sistema em nveis cada vez mais detalhados de
informao. Usualmente tambm usamos o termo DFD para descrever um conjunto de
diagramas construdos com essa notao.
Figura

Processo

Descrio

Um processo identificado apenas pelo nome

1.2
Um processo com nmero e nome

Nome

Agente Externo

Memria

Um Agente Externo identificado

Uma memria identificada

Um fluxo de dados sem identificao

fluxo

Um fluxo de dados identificado

Tabela 117. Smbolos e seus significados para a construo de um

Diagrama de Fluxo de Dados

235

Agente Externo
estmulo
resposta
Processo

Memria

Figura 118. Um DFD simples

produtos comprados

produtos disponveis
Sistema
de Compra
e Venda

Compradores

Vendedores

Figura 119. Um DFD de Contexto muito simples

produtos novos
produtos existentes

produtos comprados
Compradores

1
Comprar
Produtos

produtos
2
Promover
Produtos
produtos disponveis

Vendedores

Figura 120. A exploso do DFD de Contexto da Figura 119

DFDs no descrevem uma seqncia de execuo ou qualquer outra relao de

controle89. Se uma seta indica que dados passam de um processo A para um processo B,
possvel que A chame B, B chame A, ou ainda que outro processo superior chame os dois e
faa a transferncia de dados. DFDs tambm no do nenhuma informao sobre a lgica de
execuo, como repeties ou condies. Qualquer fluxo de dados ou processo presente pode

89

De certa maneira, descries feitas com DFDs so semelhantes a descries feitas com diagramas IDEF0, pois estes
so descendentes de uma outra notao, SADT, que era usada de forma alternativa a DFDs.

236

ou no executar, uma ou mais vezes. Na verdade, existem tcnicas especiais para derivar
relaes de controle entre processos a partir da estrutura de um DFD. Essas tcnicas, porm,
no se aplicam ao caso em estudo nesse livro, pois no so muito eficazes para desenvolver
sistemas Cliente/Servidor. Finalmente, o DFD tambm no informa se algo acontece (ou seja,
se os fluxos de dados realmente comunicam os dados entre os processos), mas sim que algo
pode acontecer (ou seja, que possvel que um processo envie seus fluxos de dados).

XII.6.1

Algumas regras sintticas

Dados s podem passar de agentes externos para memrias por meio de um processo.
Agentes externos ou memrias tambm no podem se comunicar diretamente. Isso significa
que fluxos de dados devem comear ou acabar em um processo. 90

Processos devem ler alguma informao, de um agente externo, outro processo ou

memria, e gerar alguma informao, para um agente externo, outro processo ou memria.
No existem processos que criam informao do nada (fontes) nem processos que
consomem informao (buraco negro ou sink).

Um processo tem um nome e um nmero. O nome deve ser formado por um verbo
no infinitivo e um objeto (atender cliente, vender produto, etc.). O nmero deve identificar
unicamente o processo. Se estivermos usando um DFD para descrever um processo que
aparece em outro DFD, ento usamos uma numerao hierrquica. Por exemplo, os processos
que ficam em um DFD que explica o processo nmero 2 devem ser numerados 2.1,
2.2, 2.3 e assim sucessivamente. Se precisarmos de outro DFD para explicar o processo
2.2, os processos nesse terceiro DFD sero numerados 2.2.1, 2.1.2, sucessivamente.
Agentes externos e memrias (depsitos de dados) possuam um rtulo na notao
original de Gane e Sarson [B42], porm na notao de Yourdon, que utilizamos agora, no
possuem rtulos.
XII.6.2

Entendendo os Fluxos de Dados

Em um DFD, na verdade, temos trs tipos de fluxos de dados. O primeiro tipo de
fluxo, que ocorre entre um processo e um agente externo, representa dados que esto
cruzando a fronteira do sistema. Esse tipo de fluxo indica que cada dado descrito no fluxo
estar, possivelmente de forma opcional, sendo apresentado por ou a um agente externo. Ele
representa, realmente, um fluxo dos dados nele descritos.

J entre um processo e uma memria, o fluxo tem um significado levemente diferente.

Em primeiro lugar ele ocorre dentro do sistema, no cruza nenhuma fronteira. Mas,
principalmente, um fluxo saindo da memria em direo ao processo indica uma consulta a
uma memria, possivelmente usando operaes equivalentes a selees e projees da lgica
relacional, sem modific-la. Por outro lado, um fluxo saindo de um processo e entrando em
uma memria indica uma alterao dessa memria, que pode significar a criao, a alterao
ou a eliminao de um ou mais registros.
Finalmente temos fluxos de dados entre processos. Esses fluxos querem dizer apenas
que os dados utilizados em um processo so fornecidos por outro processo, porm no h
nenhum compromisso, no DFD, que isso seja feito dinamicamente. Um fluxo desse tipo , a
priori, equivalente ao primeiro processo salvar os dados em uma memria e o segundo
processo ler dessa memria. As implementaes podem ser vrias, incluindo o primeiro
processo ativar o segundo, o segundo ativar o primeiro ou os dois serem ativados de forma
90

Nos diagramas particionados isso um ou-exclusivo, ou seja, um fluxo de dados pode partir ou chegar em uma
atividade, mas no ambos. Nos outros diagramas um fluxo pode indicar a comunicao entre dois processos.

237

assncrona. Devemos notar que no aparecem fluxos de dados entre processos em DFDs
particionados por eventos.

XII.6.3

Entendendo as Memrias
Na anlise de sistemas fazemos a modelagem de dados simultaneamente a
modelagem funcional. Isso permite que as memrias do modelo essencial sejam modeladas
diretamente nas entidades do modelo de entidades e relacionamentos, uma das tcnicas
recomendadas originalmente e a mais adequada para o desenvolvimento de sistemas na
atualidade91.

Ao definir as memrias utilizamos uma regra simples: toda a entidade do modelo de

dados utilizada pelo processo deve ser tocada por uma seta. Se a seta estiver indo do processo
para a memria, dizemos que h uma alterao dessa memria, pela adio, excluso ou
alterao de um ou mais registros. Se a seta estiver vindo da memria para o processo ento
dizemos que est acontecendo uma leitura na memria, ou uma busca, porm fica claro que
seu contedo no modificado.
razovel tanto utilizar como memrias as entidades ainda no normalizadas na
terceira forma normal (modelo conceitual tradicional) quanto s normalizadas.

XII.6.4

Tipos de DFD
Em um DFD de Contexto todo o sistema representado por apenas um processo.
No aparecem memrias internas ao sistema em um DFD de Contexto, apenas agentes
externos e, segundo alguns autores, memrias que pertencem a outros sistemas e que so
utilizadas pelo sistema sendo descrito. Geralmente o DFD de Contexto o primeiro diagrama
de um DFD nivelado. O processo que aparece nesse diagrama geralmente tem o nome do
sistema sendo implementado.

O DFD de contexto pode ser criado imediatamente a partir do dicionrio de eventos,

ou da lista de eventos e respostas.
Um DFD Nivelado ou Hierrquico na verdade um conjunto de vrios DFD
interligados de forma hierrquica de modo que exista um DFD inicial e que cada DFD alm
desse possa ser alcanado a partir da expanso sucessiva dos processos em DFDs. DFDs
Nivelados so a forma mais tradicional de descrever um sistema de forma top-down em
Engenharia de Software.
Alguns autores chamam de DFD nvel zero o DFD de Contexto. Outros chamam de
DFD nvel zero o DFD gerado pela expanso do processo que aparece no DFD de Contexto.
Ns ficaremos com a segunda opo, isto : o primeiro DFD o de Contexto, contendo um
nico processo. Esse processo expandido para o DFD nvel zero, que contem um nmero
razovel de processos (entre 5 e 9, normalmente).
Um DFD particionado representa cada atividade essencial como um diagrama
isolado, cujo significado ser explicado mais tarde. DFDs particionados tm apenas um
processo por diagrama, a atividade essencial, que recebe dados de no mximo um agente
externo e de uma ou mais memrias. Nosso mtodo de desenvolvimento baseado no uso de
DFDs particionados e nas expanses de seus processos.
Um DFD global a unificao em um s diagrama de todos os DFDs particionados
de um sistema, eliminando as repeties de agentes externos e memrias. Um DFD global
91

Isso porque a modelagem conceitual de dados se encaixa perfeitamente com o conceito de modelo essencial e ainda
permite uma transio rpida para os SGBD relacionais (oops! Estamos falando de tecnologia?).

238

pode ser usado como passo intermedirio para transformar um DFD particionado em um
DFD nivelado. DFDs globais so normalmente ferramentas de rascunho e no de anlise.
Tambm possvel substituir um DFD global por uma Matriz CRUD.

XII.6.5

Criando o DFD Particionado

A principal forma de comunicar a modelagem essencial pela criao de um DFD
Particionado. Nesse DFD apresentamos um diagrama para cada evento. Cada um desses
diagramas contm apenas um evento e apenas uma atividade essencial.

Quando dizemos que cada diagrama contm apenas um evento, estamos tambm
dizendo existe no mximo um fluxo de dados entrando o sistema vindo de um agente externo.
Da atividade para os agentes externos podem existir vrios fluxos, que representam a sada de
dados do sistema. Entre atividades e memrias tambm podem existir quantos fluxos forem
necessrios para representar a busca, insero, alterao e eliminao de dados da memria.
Os DFD particionados podem ser resumidos em um DFD de Contexto. Nesse DFD
no aparecem as memrias internas ao sistema e o sistema representado como apenas um
processo. A principal funo do DFD de contexto representar, em um s diagrama, todas as
interaes do ambiente com o sistema (o contexto da aplicao!).
Vejamos a seguir uma descrio simples de um sistema e os DFDs particionados
equivalentes.

XII.6.6

Criando o DFD hierrquico

O Diagrama de Fluxo de Dados Hierrquico (ou nivelado) j foi uma das principais
ferramentas de anlise e documentao de sistemas. Atualmente, devido metfora de
programao gerada pelos ambientes GUI, que baseada em eventos, ele normalmente
dispensado. Tambm devemos notar que a anlise essencial, apesar de facilitar sua criao,
dificulta a manuteno de um DFD hierrquico, pois esse deve ser reconstrudo a cada
modificao dos eventos particionados.

Em todo caso, o DFD nivelado permite uma viso abstrata do sistema composta de
vises parciais cada vez mais detalhadas. Como essa caracterstica muito boa, algumas
vezes ainda podemos desenvolver DFD hierrquicos.
Para isso, iniciamos com o DFD Global do sistema. O DFD global no nada mais
que a unificao de todos os DFD particionados do sistema em um nico DFD, onde cada
memria, atividade essencial e agente externo s aparece uma vez. Ao fazer o DFD global
escolhemos uma folha de grande tamanho (A3 ou maior) e colocamos os DFDs particionados
nessa folha um a um, sempre reaproveitando todos os smbolos j existentes. Essa forma de
construir pode ser difcil para sistemas muito grandes, sendo outra estratgia colocar no
centro da folha todas as memrias, depois colocando os processos ao redor das memrias e os
agentes externos ao redor dos processos. Se o sistema ficar realmente muito complicado,
aceitvel duplicar agentes externos. A duplicao de memrias para facilitar a construo do
diagrama deve ser evitada ao mximo, mas aceitvel em alguns casos, como memrias que
so claramente acessadas por um nmero grande de processos. A duplicao de processos
proibida.
O diagrama global representa um nvel intermedirio do sistema, o nvel onde cada
processo representa um evento. A partir do diagrama global construiremos o DFD
particionado pela seleo de atividades essenciais em processos.
As seguintes heursticas podem ser utilizadas para isso:

239

 Agregar em um nico processo todas as atividades essenciais que usam uma memria
especfica. Como resultado, essa memria tambm ser representada dentro desse processo em
um nvel superior do DFD,
Agregar todas as atividades de custdia que acessem uma memria especfica,
Agregar funcionalidades que so utilizadas por um agente externo especfico e
Agregar por meio de funes de negcio.
Manter o nvel de complexidade de cada processo criado entre nmeros recomendveis (7 2
objetos em cada processo).
O resultado ser um conjunto de processos onde cada processo contm vrias
atividades essenciais e talvez uma ou duas memrias, interligados por sua conexo com
memrias do sistema.

Se o nmero resultante de processos for entre 5 e 9, alcanamos um nvel abstrato

razovel para o diagrama de nvel zero. Caso contrrio, repetimos esse processo at que isso
acontea.
Finalmente, alcanado o nvel zero, temos que construir o DFD nivelado por meio da
exploso de cada processo e criao de um DFD especfico para cada exploso, respeitandose todas as regras normais de criao de Diagrama de Fluxos de Dados.
captulos

240

ndice
Abstrao, 72, 106, 185, 187
Classificao, 45, 100, 106, 159, 165

Engenharia de Informao, 112, 130

Entrevista, 47, 48, 52, 230, 231, 232

Composio, 106, 107

Aberta, 47

Generalizao, 97, 106, 107, 181, 184

Estruturada, 48

Agente Externo, 235

por Questionrio, 47

Anlise, 18, 19, 39

EPC, 5, 70, 87, 88, 90, 91, 104

Anlise Essencial, 4, 39, 145, 146

estmulo, 150, 152, 153, 156, 164, 165,

210

princpio da neutralidade tecnolgica,

147

Evento, 40, 145, 154, 159, 164, 167, 170

anlise estruturada, 145

no-esperado, 154, 158

Anlise Estruturada, 145, 146

no-evento, 159, 165

Ator, 114, 162, 172, 174

temporal, 138, 145, 159

Boehm, Barry, 24, 25, 213, 226

Fatos, 45, 96, 97

Caso de Uso, 27, 150, 174, 179, 180, 182,

183, 184, 185, 186, 187, 190, 192, 193

Funes de Negcio, 70, 73, 218

Fluxo Alternativo, 174

Fluxo Principal, 174, 179, 188
Cenrio, 188
Cenrios, 174, 175, 176, 227
Chen, Peter, 112, 120, 130, 133
Comportamento, 51
Cor, 141
DENIM, 206, 207
Diagrama
de
Entidades
e
Relacionamentos, 100, 101, 106, 109,
111, 112, 113, 171

IDEF0, 5, 74, 75, 76, 77, 81, 82, 83, 85,

86, 104, 236
IDEF1X, 105, 112, 113, 128, 130, 132,
133, 134
Interface com o Usurio, 27, 197, 198
JAD, 5, 30, 45, 53, 54, 157, 203
Martin, James, 129
McMenamim, 146
Memria, 108, 145, 161
Microsoft, 28, 65, 202
Modelagem Conceitual de Dados, 109,
144

Diagrama de Fluxe de dados hierrquivo,

238

Modelo de Processo, 20, 22, 23, 24, 25,

41, 59, 60, 102, 103, 167, 193

Diagrama de Fluxo de Dados, 145, 150,

156, 161, 162, 164, 167, 171, 173, 225,
235, 236, 237, 238, 239, 240

Modelo Funcional, 19, 145, 225

de contexto, 236, 238, 239

nvel zero, 238
nivelado, 238
particionado, 239

Palmer, 146
Pontos de Funo, 212, 226, 228
arquivos, 217

interfaces, 217
sadas, 219

241

Pressman, 19

SIG, 12

Regras de Negcio, 70, 95, 98, 106

Sistemas de informao, 10, 11

Relatrios, 117, 159

Tecnologia Interna Perfeita, 147

Requerimentos

Tela, 166

verdadeiros, 39
Requisitos, 22, 30, 31, 36, 37, 38, 39, 41,
42, 45, 56, 57, 63, 68, 188, 189
Requisitos falsos, 38
SAD, 12

Termos, 96, 97, 171, 230

Testes, 22
Win-Win, 24
Yourdon, Edward, 146, 152, 169, 171,
235, 237

SADT, 74, 236

242