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 operador operador novela cadastrar diretor diretor dados de ator + tipo operador autor aviso de alocao captulo dep. pessoal ator ator horista novela ator horista horas ator diretor diretor receber captulo captulo captulo ator diretor captulo + resumo cadastrar novela dados de novela + diretor

Pedido Recebido

Pedido

Digitar Pedido

Vendas

cadastrar ator

Pedido Digitado

Dados de Produto Verificar Pedido Pedido Vendas

novela diretor

enviar formulrio

form. ator/horas diretor

registrar horas trabalh.

ator

XOR

ator

diretor ator hor + horas

ator horista

Pedido Correto

Pedido Incorreto

Cliente

(1,N)

Solicita

(0,N)

Livro

(1,1)

Estado Inicial Receber pedido

Entrega

(1,N)

Atividades

Processar pedido

Distribuidora
Enviar pedido Transaes

Estado Final

Incio

Evento a Sada 1 Evento c Sada 2 Estado2

Evento b Estado 1

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) 2) 3) 4) 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. Classifique os sistemas anteriores quanto ao seu nvel na organizao. Classifique os sistemas anteriores quanto ao seu tipo. 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. Que sistemas de informao fazem parte de seu dia a dia? Que papel voc assume ao utilizar esses sistemas? Que sistemas de informao voc pode se lembrar que contm informaes importantes sobre sua vida pessoal ou profissional?

5) 6)

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? 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. 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? Que tipos de sistemas podem interessar a Livraria ABC? Que tipos de sistemas podem interessar a Empresa de Clipping ClipTudo? 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?

8) 9)

10) 11) 12)

Caracterstica Preo da impressora (sem tinta) Preo do cartucho de tinta Nmero cartucho de cpias por

Impressora A R$ 300,00

Impressora B R$ 5.000,00

R$ 80,00 1.000

R$ 250,00 5.000

Vida til da impressora

120.000

800.000

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.
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.1.4

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
Aquisio Fornecimento

Processos de Apoio
Documentao Gerncia de Configurao Garantia de Qualidade

Operao

Verificao Validao

Desenvolvimento Reviso Conjunta Manuteno Auditoria Soluo de Problemas

Processos Organizacionais
Infraestrutura Gerncia Treinamento 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.

Adaptao

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. 6. Testes, onde verificamos e validamos o software. 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 Codificao Testes Anlise Projeto Codificao Testes Anlise Projeto Codificao Testes Tempo
Figura 6. O Ciclo de Vida Incremental

Anlise Projeto Codificao Testes

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 Chefe Administrador Senior Secretria

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. O sistema dever imprimir a nota fiscal de venda ao consumidor referente venda sendo registrada.
30

Exemplos de requisitos so:

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 Cliente Cliente Objetivo Fazer pedido Obter status do pedido Obter lista de pedidos diria Interesse Receber o produto pedido Prever o prazo de chegada do pedido Saber a produo diria Prioridade 1 2

Gerente

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 da Organizao

Requisitos Externos

Requisitos de Usabilidade

Requisitos de Confiabilidade

Requisitos de Portabilidade

Requisitos de Interoperabilidade

Requisitos De tica

Requisitos de Eficincia

Requisitos De Prazo

Requisitos de Implementao

Requisitos De Padronizao

Requisitos Legais

Requisitos de Desempenho

Requisitos de Espao

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 Busca de Fatos Tarefas orientadas ao usurio 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. Levantar a lista de desejos de cada grupo. Tarefas orientadas ao desenvolvedor 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. 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. Realizar uma anlise de riscos, investigando tcnicas, custos, prazos e incluindo anlise de custos e benefcios e viabilidade baseado na disponibilidade da tecnologia. Priorizar requisitos baseados em custo e dependncia. Estudar como o sistema pode ser implementado de forma incremental, investigando modelos arquiteturais apropriados. Resolver conflitos consistncia. e verificar

Coleta e Classificao dos Requisitos

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?. Determinar funcionalidades crticas para a misso.

Priorizao

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).

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. 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

IV.8.2.4 O

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. 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

IV.8.4.4 O

Figura 20. Uma sala de JAD bem planejada

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.

IV.8.4.5 O

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.

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 Causador Como no podemos analisar planos de negcio alternativos Como no sabemos o custo real de produo futura No possvel analisar cenrios de mercado No possvel fazer contratos de longo prazo Acima de 1 milho Planejamento Dados Causadores Sugesto de Soluo Modelagem de cenrios

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.
Metas subjetivas possvel que sejam definidas metas no mensurveis de forma objetiva. Isso pode ser resolvido por meio de avaliaes subjetivas.

V.6.1

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 Fora

Receber pedido do cliente Enviar nota fiscal Atender parcialmente Analisar crdito
Tabela 4. Exemplo de uma tabela de definio de escopo.

pedido

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.
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.

V.9.2

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.
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.

V.11.1

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 12

E ainda implantao, manuteno e operao. 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 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) Mtricas para avaliao das Metas

V.14
V.14.1 V.14.2

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

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.
Sutilmente, o preo do sistema proposto como investimento, o que de fato verdade na viso da empresa contratante.
14

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

Diretor de Produo

Diretor Administrativo

Gerente de Grandes Clientes

Gerente de Vendas

Gerente de Fbrica

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/). 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..
No h necessariamente um mapeamento direto entre funes e o organograma

17

18

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).
A metodologia IDEF0 derivada de uma metodologia anterior conhecida como SADT. O processo inicial sempre o A-0, no existindo um processo B-0 em nenhum caso. A letra A vem de atividade.

20 21

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

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):

23

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

1 2 A12

parent box

3 A1

child diagram

This arrow (position C2) is not shown on child diagram.

C1 I1
1

C3

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 means A

INTERPRETATION A A A

A means

A A

means
Where B is a portion of A

A B

means A

A&B

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).
Tax Requirements
This fork means that Files contains Customer Records (needed by Function 2) and Price & Tax Tables (needed by Function 3). This join means Account Entries are created by Deliver Products and "Do Billings".

Files KEEP RECORDS

1

Customer Records DELIVER PRODUCTS

Price & Tax Tables Account Entries DO BILLING

Ordered Product

Transactions
3

Account Clerk

Invoices

Figura 32. Conexes entre caixas

80

parent diagram

1 2 A12 3

parent box

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 2I1 O2 2O2 para 3C1 ou 2o2 para 3c1 I2 para 2I3 para 2O2 para (3C1 e 4C2) Caixa 2 Entrada 1 A seta cujo cdigo ICOM O2 (Sada 2) A seta de 2O2 para 3C1 (I, C, O ou M podem ser maisculas ou minsculas). 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. No diagrama A21 nesse modelo, veja o controle 2 da caixa 3. O ponto significa olhe especificamente para. No diagrama A32, veja a nota de modelo 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. No diagrama A42 desse modelo, veja a caixa 3. NO diagrama A42 do modelo MFG veja a caixa 1 Significado

A21.3C2 A42.3 A42.|3|

A42.3 MFG/A42.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 Exemplos: Quais as tarefas do atendente?, Quais as tarefas do arrumador?, Como os produtos circulam na loja?

6. Desenvolva as questes que o modelo deve responder

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 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. 13. Defina as entradas

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.
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.

VI.5.1

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: 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.

25

swimlane diagrams

87

Tipo
Evento Funo

Smbolo

Definio
Um Evento descreve uma ocorrncia que causa um efeito (funo) Uma funo descreve uma transformao (uma mudana no estado do sistema)

Conectores

XOR XOR AND OR

Um conector estabelece conexes lgicas entre eventos e funes Um fluxo descreve uma relao lgica ou temporal entre funes e eventos Um caminho estabelece uma relao entre processos.

Fluxo

Caminho

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
Unidade Organizacional Informao

Smbolo

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

Pedido

Digitar Pedido

Vendas

Pedido Digitado

Dados de Produto Verificar Pedido Pedido

XOR

Vendas

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 cliente produto produto entregas estoque

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.

VI.5.2.2

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. 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

VI.5.3

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.

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

Separar produtos

Preparar Nota Fiscal

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. 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.

VI.6.1

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 Atributo Generalizao Papel Agregao Associao simples Exemplo DRE um atributo de aluno Aluno de graduao um tipo de Aluno Um aluno pode ser representante de classe Uma turma precisa ter alunos 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
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.

VI.6.2

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).
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.

VI.6.3

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 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

Verso em linguagem natural Relevante Atmica Declarativa No totalmente precisa Pode ser incompleta Confivel Autntica Pode ser redundante Pode ser inconsistente

Verso em uma linguagem de especificao de regras Relevante Atmica Declarativa Precisa Completa Confivel Autntica nica Consistente

Verso em uma linguagem de implementao de regras 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 Termo

Descrio Detalhada Nome ou sentena com uma definio acordada que pode ser: Conceito, classe, entidade, Propriedade, atributo, Valor, Conjunto de valores detalhe,

Template <termo> definido como <texto>

Fato

Sentena que relaciona termos em observaes relevantes ao negcio Relacionamentos entidades Relacionamentos entidades e atributos entre entre

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

Relacionamentos de herana <termo> calculado como <formula>

Computao

Sentena fornecendo um algoritmo para calcular o valor de um termo Sentena que indica restries que devem ser verdade em informaes fornecidas ao sistema (input)

Restrio obrigatria

<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

Cliente

(1,N)

Solicita

(0,N)

Livro

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

(1,N)

(1,1)

102

Processos Vendas Administrao Agendamento Gerncia do Territrio Produo Fornecimento Planejamento

Pedidos de Servio

VP de Vendas Gerente de pedidos Organizao 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.
Dados Dado 1 Dado 2 Dado 3 Dado 4 Dado 5 Dado 6

Processos Processo A Processo B Processo C Processo D Processo E Processo F

CRUD R RUD

R R C R R C RU C C

CRUD R

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

Operao

Venda

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 Cadastro de Cliente Cadastro de Fornecedor Cadastro de Pedidos Criao de Pedidos Situao Corrente Corrente Planejado 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.

1.2

Modelos e Abstraes
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 Flamengo, Fluminense, So Paulo Brasil, Estados Unidos Pel, Zidane, Romrio Classe Times de Futebol Pas 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 Pneus, motor, etc. Capa, centenas de folhas, etc. Cabelo, pele, ossos, etc. Objeto Carro Livro 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 Funcionrio, Aluno, Professor Automvel, Avio, Navio Computador, Rdio, Televiso Classe mais geral Pessoa Meio de Transporte 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
Entity name

Significado Entidade

Relacionamento Ligao entre entidades, por meio de um relacionamento, com a descrio da cardinalidade.

1 Me

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.

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,

31

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 34 35

Como no excelente livro Princpios de Modelagem de Dados de David Hay[B35]. Devemos confessar que no temos a mesma preocupao com atributos, por exemplo. 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. Mas a ausncia de um ciclo no significa que no existe restrio.

37

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

(1,1)

(0,1)

(0,1)

(0,1)

(0,N)

(0,1)

(1,1)

(1,1)

(0,N)

(0,N)

(0,N)

(1,1)

(1,N)

(1,1)

(1,N)

(1,N)

(0,N)

(1,N)

(1,N)

(0,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.
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. 1.10.1

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 Placa Chassis (AK1.1) Modelo Ano

Automvel Chassis 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).

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 40

1.10.2

Ou seja, servem para modelar a abstrao de identificao 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 NomeFantasia NomeRegistro Telefone Contato Produto Nome 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 NomeFantasia NomeRegistro Telefone Contato Produto Nome Preco Descrio

Figura 63. O mesmo relacionamento, agora no identificador. Percebemos que a entidade Produto agora tem o seu smbolo normal. Software Erwin.
Empresa CNPJ NomeFantasia NomeRegistro Telefone Contato produz Produto Nome CNPJ (FK) Preco Descrio

Empresa CNPJ NomeFantasia NomeRegistro Telefone Contato produz

Produto Nome 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 possudo Apartamento

Figura 66. Uma pessoa possui zero ou mais apartamentos e um apartamento possudo por pelo menos uma pessoa ou mais

possui Pessoa possudo Apartamento

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 m Ator

Dirige m 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)

Filme

(1,n)

Atua (1,n) Ator

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.

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.

1.11.2

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.
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. 1.12.1

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

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

1.12.2

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

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. 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.4

1.12.3

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.

1.12.5

Algumas equivalncias so facilmente identificveis:

Relacionamentos n x m podem ser substitudos por uma entidade42. Relacionamentos 1x1 podem ser eliminados, unificando-se as entidades43.

1.13

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

Mas no precisam ser obrigatoriamente substitudos. Modelos conceituais admitem e at ficam mais claros com a presena de relacionamentos nxm. 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. 43

42

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 Jim Mary Renee Joe

Empregado Susan, Rob, Beth Alice, John, Asim Mike 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 Essa regra foi abandonada na prtica pela necessidade que temos de trabalhar com esses tipos de valores.

47

139

Gerente Jim Jim Jim Mary Mary Mary Renee Joe Joe

Empregado Susan Rob Beth Alice John Asim Mike Alan Tim

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

Turma Cdigo Nome Horrio Alunos smallint 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 Guerra nas Estrelas Guerra nas Estrelas Guerra nas Estrelas Might Ducks Waynes World Waynes World

Ano 1977 1977 1977 1991 1992 1992

Durao 124 124 124 104 95 95

Tipo Cor Cor Cor Cor Cor Cor

Estdio Fox Fox Fox Disney Paramount Paramount

Estrela Carrie Fisher Carrie Fisher Carrie Fisher Emilio Estevez Dana Carvey 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.
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. 1.14.5

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

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.14.6

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.

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. 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 50

49

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 54 55

Em alguns formatos de DFD, as entidades externas no possuem smbolo ou at mesmo no so indicadas. No confundir com as entidades do modelo de entidades e relacionamento.

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.

Atualmente fcil entender como o vendedor pode ser substitudo por uma interface Web e o sistema manter sua essncia.
57

56

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 Sadas Sistema Parado 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 59

No existem, logo, eventos essenciais internos ao sistema.

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
1

Evento 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...

Esperado

NoEsperado

Relativo

Absoluto

(p/ evento)

2 3 4

5 6 7 8

(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

Entidades Ator Horista Captulo CR C 162

Novela

Diretor

Eventos ou Atividades Cadastrar Diretor Cadastrar Novela Cadastrar Ator Receber Captulo

CRUD R CRUD R R R CRUD CRUD R R R R R

Registrar Horas Trabalhadas R Enviar Formulrio R

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

Horas

Ator

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.
Entidades Entidade 1 Entidade 3 Entidade 4 Entidade 5 Entidade 6 Entidade 2 Entidade 1 Entidade 2 Entidades Entidade 3 Entidade 4 Entidade 5 R C R RUD C R C R RU C Entidade 5 R C R R R C RU C Entidade 6 Entidade 6

Processos Processo A Processo B Processo D Processo F Processo C Processo E

Processos Processo A Processo B Processo D Processo F Processo C Processo E

CRUD R R C C R Posio inicial C R R RU C

R CRUD R RUD

CRUD R

CRUD R

Passo 1: Posio aps troca da posio da coluna Linha "Processo E" ser trocada de posio Entidades Entidade 5 Entidade 6 Entidade 1 Entidade 2 Entidade 3 R C Entidade 4

Coluna "Entidade 2" ser trocada de posio Entidades Entidade 1 Entidade 2 Entidade 3 Entidade 4

Processos Processo A Processo B Processo D Processo E Processo F Processo C

Processos Processo A Processo B Processo C Processo D

CRUD R

R R C R R C RU C C

CRUD R RUD

CRUD R

CRUD R

R RUD

Processo E Processo F

Passo 2: Posio aps troca da posio da linha Linha "Processo C" ser trocada de posio

Passo 3: Posio aps troca da posio da linha 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 Gerente solicita relatrio de Vendas Aluno solicita boletim Fornecedor entrega mercadoria

Atividade Emitir Relatrio de Vendas Emitir Boletim 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 Estado2

Evento b Estado 1

Evento d

Fim

Figura 86. Um diagrama de estados simples

Figura 86,

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.

Diagramas de estados podem ser representados por tabelas, como a seguir:

169

Estado Atual Incio Estado 1 Estado 2 Estado 2

Evento Evento a Evento b Evento c Evento d

Resposta Sada 1 Sada 2 -

Prximo Estado Estado 1 Estado 2 Estado 2 Fim

Tabela 25. Tabela representando o diagrama da Figura 86

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. Eventos ou fatos
Livro Existe na Base Cliente Cadastrado Cliente deve dinheiro

A
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

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

Resp ostas ou Aes

Dicionrio de Dados

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 66

O modelo ambiental foi definido por Yourdon[B43], sendo questo tpica de concurso. 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 operador operador

dados de novela + diretor

novela cadastrar diretor diretor dados de ator + tipo operador autor aviso de alocao captulo dep. pessoal ator ator horista novela ator horista horas novela diretor enviar formulrio form. ator/horas diretor registrar horas trabalh. ator diretor diretor receber captulo captulo captulo ator diretor captulo + resumo cadastrar novela

cadastrar ator

ator

ator

diretor ator hor + horas

ator horista

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.

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

68

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.

No Rio de Janeiro h um limite de retirada nos caixas automticos a partir de certa hora da noite, por medida de segurana.

70

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
Passa o carto Digita senha Requisita quantia a ser sacada

Sistema
Solicita senha Exibe menu de opes disponveis 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
Sumrio de Alto Nvel Sumrio Objetivo do Usurio Sub-Funo Nvel Muito Detalhado

cone

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
Organizao, caixa preta Organizao, caixa branca

cone

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 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

IX.11.6

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 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.11.10

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

Ator Principal: Colecionador Nvel: Cenrio Principal:
Colecionador solicita Cadastro Colecionador compra Livro

UC2: Comprar 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

1. Colecionador envia um pedido
1. Colecionador envia Fax 2. Colecionador envia Carta 3. Colecionador faz Ligao

UC4: Receber Pedido

Vendedor lista os Livros Vendedor investiga os Preos Vendedor envia proposta para Funcionria Funcionria aprova a Proposta Vendedor prepara a estimativa

includo

2. Vendedor recebe o Pedido 3. Vendedor envia estimativa ao Colecionador 4. Colecionador confirma proposta Aceita estimativa?
24

25

UC5: Preparar Estimativa

1. O Vendedor repete os seguintes passos
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

UC6: Preparar Estimativa

1. O Vendedor cria uma Estimativa 2. Os seguintes passos so repetidos
1. 2. 3. 4. 5. 6. 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

2. O Vendedor fecha a Estimativa 3. O Sistema imprime a Estimativa

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

Responder

Ler

Pensar

HOMEM

I n t e r f a c e

COMPU TADOR

Pensar

Ler

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 Respostas Psgraduado

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

1 grau

2 grau

3 grau

Liste suas tarefas no cargo

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 Mensal Mensal Mensal Mensal Mensal Mensal Mensal Mensal Rara Rara Rara Rara Rara Rara Rara Rara Outra _____ Outra _____ Outra _____ Outra _____ Outra _____ Outra _____ Outra _____ Outra _____

Diria Semanal Diria Semanal Diria Semanal Diria Semanal Diria Semanal Diria Semanal Diria Semanal Diria Semanal Qualidade do ambiente de trabalho Iluminao

Muito ruim

Ruim Razovel

Boa

tima

200

Pergunta Rudo
Postura ao trabalhar Risco ao trabalhar (venenos, exploses...

Muito alto Muito ruim Muito alto

Alto Aceitvel Ruim Aceitvel Alto Pouco

Pouco Boa Baixo

Respostas Quase nenhum tima

Nenhum

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.

McConnell, Steve. Rapid Development: Taming Wild Software Schedules. Microsoft Press, Redmond, Washington, 1996

73

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.

Imagem ilustrativa usada pelos princpios de fair use. No se aplicam a essa imagem os mesmos direitos desse texto.

76

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.

Imagem ilustrativa usada pelos princpios de fair use. No se aplicam a essa imagem os mesmos direitos desse texto.

77

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

Imagem ilustrativa usada pelos princpios de fair use. No se aplicam a essa imagem os mesmos direitos desse texto. Imagem ilustrativa usada pelos princpios de fair use. No se aplicam a essa imagem os mesmos direitos desse texto.
79

78

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.
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 81

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.

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 84

Atualmente em sua segunda verso (COCOMO II)

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.

A B C D

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
Planos e Requisitos Projeto do Produto Programao Programao: Projeto Detalhado Programao: codificao e Teste de unidade Integrao e Testes

Esforo %
7 (2-15) 17 64-52 27-23 37-29 19-31 12 (0-20)

Tempo % 16-24 (2-30) 24-28 56-40

20-32 12.5 (0-20)

Transio

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 . 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.

XI.6.1.2 Funes

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

E Realiza validao dos dados Realiza clculos ou frmulas matemticas 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 Referencia ao menos um ILF ou EIF Recupera dados ou informao de controle Cria dados derivados Altera o comportamento do sistema 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 P P P P P O* P P P O* P O P

E P O* P P P O* P P O* O* O P P

E P N P P P N O O N N O P P

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 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 Sadas Externas

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 0 1 2-3 4+ 1-5

Itens de dados referenciados 6-19 Simples (4) Mdia(5) Complexa (7) 20+ Mdia (5) Complexa(7) Complexa (7)

Simples (4) Simples(4) Mdia (5)

Tabela 33. Clculo da complexidade de sadas externas Entradas Arquivos Referenciados 0 1 2 3+ 1-4 Simples (3) Simples (3) Mdia (4) Itens de dados referenciados 5-15 Simples (3) Mdia (4) Complexa (6) 16+ Mdia (4) Complexa (6) Complexa (6)

Tabela 34. Clculo da complexidade de entradas externas Consultas Arquivos Referenciados 0 1 2-3 4+ 1-5 Simples (3) Simples (3) Mdia (4) Itens de dados referenciados 6-19 Simples (3) Mdia (4) Complexa (6) 20+ 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 1 2-5 6 1-19 Simples (7) Simples (7) Mdia (10) Itens de dados referenciados 20-50 Simples (7) Mdia (10) Complexa (15) 51+ Mdia (10) Complexa (15) Complexa (15)

Tabela 36. Clculo da complexidade de arquivos lgicos internos Arquivos Externos RETs 1 2-5 6 1-19 Simples (5) Simples (5) Mdia (7) Itens de dados referenciados 20-50 Simples (5) Mdia (7) Complexa (10) 51+ 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. 1.2. 1.3. 1.4. Aplicao em batch ou computador isolado: 0 Aplicao em batch com entrada ou (exclusivo) impresso remota: 1 Aplicao em batch com entrada e impresso remota: 2 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 A aplicao mais que um front-end, porm s executa um tipo de protocolo de teleprocessamento: 4 A aplicao mais que um front-end e executa vrios protocolos de teleprocessamento: 5

1.5. 1.6.

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

Complexidade (passo 2) Funo Complexa Simples Contagem Total (passo 1) Mdia Total

Sadas Externas Consultas Externas Entradas Externas Arquivos Lgicos Internos Arquivos de Interface Externos

4 3 3 7 5

5 4 4 10 7

7 6 6 15 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 Arquivo Lgico Interno Arquivo de Interface Externa Entrada Externas Sada Externa Consulta Externa PFs mdios IBSBG 7,4 5,5 4,3 5,4 3,8 PFs mdios NESMA 7 5 4 5 4

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.

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.

XII.3

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 Descrio

Processo

Um processo identificado apenas pelo nome

1.2
Um processo com nmero e nome

Nome

Agente Externo

Um Agente Externo identificado

Memria

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 Compradores Sistema de Compra e Venda

produtos disponveis Vendedores

Figura 119. Um DFD de Contexto muito simples

produtos novos produtos comprados Compradores 1 Comprar Produtos produtos 2 Promover Produtos produtos disponveis produtos existentes

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

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.

89

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
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.
90

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.
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.

XII.6.4

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
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?).
91

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 Composio, 106, 107 Generalizao, 97, 106, 107, 181, 184 Agente Externo, 235 Anlise, 18, 19, 39 Anlise Essencial, 4, 39, 145, 146 princpio da neutralidade tecnolgica, 147 anlise estruturada, 145 Anlise Estruturada, 145, 146 Ator, 114, 162, 172, 174 Boehm, Barry, 24, 25, 213, 226 Caso de Uso, 27, 150, 174, 179, 180, 182, 183, 184, 185, 186, 187, 190, 192, 193 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 Diagrama de Fluxe de dados hierrquivo, 238 Diagrama de Fluxo de Dados, 145, 150, 156, 161, 162, 164, 167, 171, 173, 225, 235, 236, 237, 238, 239, 240 de contexto, 236, 238, 239 nvel zero, 238 nivelado, 238 particionado, 239 Engenharia de Informao, 112, 130 Entrevista, 47, 48, 52, 230, 231, 232 Aberta, 47 Estruturada, 48 por Questionrio, 47 EPC, 5, 70, 87, 88, 90, 91, 104 estmulo, 150, 152, 153, 156, 164, 165, 210 Evento, 40, 145, 154, 159, 164, 167, 170 no-esperado, 154, 158 no-evento, 159, 165 temporal, 138, 145, 159 Fatos, 45, 96, 97 Funes de Negcio, 70, 73, 218 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 Modelo de Processo, 20, 22, 23, 24, 25, 41, 59, 60, 102, 103, 167, 193 Modelo Funcional, 19, 145, 225 Palmer, 146 Pontos de Funo, 212, 226, 228 arquivos, 217

interfaces, 217
sadas, 219

241

Pressman, 19 Regras de Negcio, 70, 95, 98, 106 Relatrios, 117, 159 Requerimentos verdadeiros, 39 Requisitos, 22, 30, 31, 36, 37, 38, 39, 41, 42, 45, 56, 57, 63, 68, 188, 189 Requisitos falsos, 38 SAD, 12 SADT, 74, 236

SIG, 12 Sistemas de informao, 10, 11 Tecnologia Interna Perfeita, 147 Tela, 166 Termos, 96, 97, 171, 230 Testes, 22 Win-Win, 24 Yourdon, Edward, 146, 152, 169, 171, 235, 237

242