Anlise Estruturada Moderna

(Apontamentos baseados na metodologia de Yourdon)

1. INTRODUO....................................................................................................................................... 4
2. A NATUREZA DOS SISTEMAS.......................................................................................................... 5
2.1. CONCEITOS BSICOS ........................................................................................................................ 5
2.2. TIPOS DE SISTEMAS.......................................................................................................................... 5
2.3. SISTEMAS FEITOS PELO HOMEM....................................................................................................... 6
2.4. SISTEMAS DE INFORMAO ............................................................................................................. 6
2.5. CLASSIFICAO QUANTO FORMA DE PROCESSAMENTO................................................................. 7
Sistemas Batch.......................................................................................................................................... 7
Sistemas On-Line ...................................................................................................................................... 7
Sistemas em Tempo Real........................................................................................................................... 7
Sistemas Baseados em Conhecimento....................................................................................................... 7
Sistemas Especialistas .............................................................................................................................. 7
2.6. CLASSIFICAO QUANTO AO NVEL ORGANIZACIONAL.................................................................... 8
Sistemas de Processamento de Transaces............................................................................................. 8
Sistemas de Planeamento e Controlo Operacional................................................................................... 9
Sistemas de Apoio Deciso .................................................................................................................... 9
Sistemas de Planeamento Estratgico .................................................................................................... 10
2.7. PRINCPIOS GERAIS DOS SISTEMAS ................................................................................................ 10
3. PARTICIPANTES NO DESENVOLVIMENTO DE SISTEMAS................................................... 11
3.1. UTILIZADORES ............................................................................................................................... 11
Classificao por Tipo de Funo.......................................................................................................... 11
Classificao por Nvel de Experincia.................................................................................................. 12
3.2. GESTOR DE PROJECTO.................................................................................................................... 12
3.3. AUDITORES, CONTROLO DE QUALIDADE E NORMALIZAO.......................................................... 12
3.4. ANALISTA DE SISTEMAS................................................................................................................. 13
3.5. PROJECTISTA DE SISTEMAS ............................................................................................................ 13
3.6. PROGRAMADOR.............................................................................................................................. 14
3.7. OPERADOR..................................................................................................................................... 14
4. PRINCIPAIS PROBLEMAS NO DESENVOLVIMENTO DE SISTEMAS .................................. 15
4.1. PRODUTIVIDADE ............................................................................................................................ 15
Demanda reprimida................................................................................................................................ 15
Tempo de desenvolvimento ..................................................................................................................... 15
4.2. CONFIABILIDADE ........................................................................................................................... 17
4.3. MANUTENIBILIDADE ...................................................................................................................... 18
4.4. QUALIDADE ................................................................................................................................... 18
4.5. PORTABILIDADE............................................................................................................................. 19
4.6. SEGURANA................................................................................................................................... 19
4.7. PRINCIPAIS CAUSAS........................................................................................................................ 19
5. CICLO DE VIDA DO PROJECTO DE DESENVOLVIMENTO................................................... 20
5.1. CONCEITO DE CICLO DE VIDA DE UM PROJECTO............................................................................ 20
5.2. OBJECTIVOS ................................................................................................................................... 20
5.3. CICLO DE VIDA CLSSICO.............................................................................................................. 21
5.4. CICLO DE VIDA SEMI-ESTRUTURADO ............................................................................................ 23
5.5. CICLO DE VIDA ESTRUTURADO...................................................................................................... 24
Levantamento.......................................................................................................................................... 24
Anlise .................................................................................................................................................... 25
Projecto................................................................................................................................................... 25
Implementao........................................................................................................................................ 25
Gerao de Testes de Aceitao............................................................................................................. 26
Controlo de Qualidade ........................................................................................................................... 26
1
Descrio dos Procedimentos................................................................................................................. 26
Converso das Bases de Dados .............................................................................................................. 26
Instalao ............................................................................................................................................... 26
5.6. ABORDAGEM RADICAL VERSUS CONSERVADORA.......................................................................... 26
5.7. CICLO DE VIDA DA PROTOTIPAGEM............................................................................................... 27
6. MODIFICAES NA ANLISE DE SISTEMAS............................................................................ 29
6.1. A PASSAGEM PARA A ANLISE ESTRUTURADA .............................................................................. 29
6.2. MODIFICAES NA ANLISE ESTRUTURADA ................................................................................. 30
6.3. SURGIMENTO DAS FERRAMENTAS AUTOMATIZADAS DE ANLISE................................................. 31
6.4. USO DA PROTOTIPAGEM................................................................................................................. 31
7. DIAGRAMA DE FLUXO DE DADOS............................................................................................... 32
7.1. COMPONENTES DE UM DFD........................................................................................................... 32
Processos ................................................................................................................................................ 32
Fluxos de Dados ..................................................................................................................................... 32
Depsitos de Dados ................................................................................................................................ 33
Entidades Externas ................................................................................................................................. 34
7.2. DIRECTRIZES PARA ELABORAO DE DFD.................................................................................... 35
Escolher Nomes Significativos................................................................................................................ 35
Devem-se numerar os Processos ............................................................................................................ 35
Evitar DFD Complexos........................................................................................................................... 35
Refazer tantas vezes quantas forem necessrias..................................................................................... 35
Criar diagramas esteticamente agradveis ............................................................................................ 36
Certificar-se de que o DFD seja logicamente consistente...................................................................... 36
Posio dos elementos ............................................................................................................................ 36
Duplicao de elementos ........................................................................................................................ 36
7.3. DFD COM NVEIS........................................................................................................................... 37
Diagrama de Contexto............................................................................................................................ 37
Diagrama Nvel 0.................................................................................................................................... 37
Diagrama de Nveis Intermdios ............................................................................................................ 38
8. DICIONRIO DE DADOS.................................................................................................................. 39
8.1. NOTAO....................................................................................................................................... 39
8.2. DEFINIES.................................................................................................................................... 40
8.3. ELEMENTOS OPCIONAIS.................................................................................................................. 40
8.4. ITERAO ...................................................................................................................................... 40
8.5. SELECO...................................................................................................................................... 41
8.6. SINNIMO ...................................................................................................................................... 41
8.7. DEFINIO DE DEPSITOS.............................................................................................................. 41
9. DIAGRAMA DE ENTIDADES-RELACIONAMENTOS................................................................ 42
9.1. ENTIDADES .................................................................................................................................... 42
9.2. RELACIONAMENTOS....................................................................................................................... 42
Tipos de Relacionamentos ...................................................................................................................... 42
Classificaes adicionais........................................................................................................................ 43
Cardinalidade ......................................................................................................................................... 43
Casos especiais de relacionamentos....................................................................................................... 43
10. DIAGRAMA DE TRANSIES DE ESTADO............................................................................ 44
10.1. NOTAO....................................................................................................................................... 44
Estado ..................................................................................................................................................... 44
Mudanas de Estado............................................................................................................................... 44
Condies e Aces ................................................................................................................................ 45
10.2. DIAGRAMAS SUBDIVIDIDOS............................................................................................................ 46
2
10.3. CONSTRUINDO UM DTE................................................................................................................. 47
11. ESPECIFICAES DE PROCESSOS.......................................................................................... 48
11.1. LINGUAGEM ESTRUTURADA .......................................................................................................... 48
11.2. PR/PS ......................................................................................................................................... 52
Pr-Condies ........................................................................................................................................ 52
Ps-Condies ........................................................................................................................................ 53
11.3. TABELA DE DECISO...................................................................................................................... 54
Estrutura de uma Tabela de Deciso...................................................................................................... 54
Criar uma Tabela de Deciso................................................................................................................. 54
11.4. RVORE DE DECISO..................................................................................................................... 55
Criar uma rvore de Deciso................................................................................................................. 55
12. O MODELO ESSENCIAL.............................................................................................................. 56
12.1. A ABORDAGEM CLSSICA .............................................................................................................. 56
Os quatro modelos .................................................................................................................................. 56
Porque a abordagem clssica no funcionava ....................................................................................... 56
12.2. O QUE O MODELO ESSENCIAL ..................................................................................................... 56
12.3. DIFICULDADES NA CONSTRUO DO MODELO ESSENCIAL............................................................. 57
12.4. COMPONENTES DO MODELO ESSENCIAL........................................................................................ 57
12.5. O MODELO AMBIENTAL................................................................................................................. 58
12.6. O MODELO COMPORTAMENTAL PRELIMINAR................................................................................ 58
A Abordagem Clssica (Top-Down) ....................................................................................................... 58
Particionamento por eventos .................................................................................................................. 58
12.7. O MODELO COMPORTAMENTAL FINAL.......................................................................................... 59
Nivelamento ............................................................................................................................................ 59
Complementar Dicionrio de Dados ...................................................................................................... 59
Complementar as Especificaes de Processos...................................................................................... 59
Complementar o Modelo de Dados ........................................................................................................ 59


3
1. Introduo

A anlise [de sistemas] frustrante, repleta de relacionamentos entre pessoas, indefinida
e difcil. Resumindo, fascinante. Depois que voc fisgado, os velhos e fceis prazeres da
construo de sistemas nunca mais sero suficientes para satisfaz-lo
Tom DeMarco, 1978, Structured Analysis and Systems Specification


Um analista de sistemas, alm de saber construir modelos, deve ser conhecedor ou
aprofundar-se no que est a modelar, seja um sistema de matrcula, vendas, controlo de
stock, bancrio, etc. Durante a modelao o analista muitas vezes torna-se um especialista
na rea.
4
2. A natureza dos Sistemas
Muitos dos sistemas baseados em computador so substituies ou implementaces de
sistemas no-computadorizados.
Um sistema computadorizado normalmente faz parte de um sistema maior
(computadorizado ou no) e interage com outros sistemas.
Existem princpios, filosofias e teorias que se aplicam a todos os tipos de sistemas. Um
bom exemplo, a lei da especializao de organismos (Biologia). Quanto mais bem
adaptados s condies de um ambiente, mais difcil ser a adaptao a outro ambiente.
Esta lei tambm vale para sistemas computadorizados.
2.1. Conceitos bsicos
Sistema:
Um grupo de itens que interagem entre si ou que sejam interdependentes, formando um
todo unificado, orientado para atender objectivos especficos.
Um conjunto organizado de doutrinas, ideias ou princpios, habitualmente previstos
para explicar a organizao ou o funcionamento de um conjunto sistemtico.
Exemplos:
Sistema gravitacional
Sistema digestivo
Sistema rodovirio
Sistema bancrio
2.2. Tipos de Sistemas
Sistemas Naturais
Sistemas Fsicos
Sistemas estelares: galxias, sistemas solares, etc.
Sistemas geolgicos: rios, cadeias de montanhas, etc.
Sistemas moleculares: organizaes complexas de tomos.
Sistemas Vivos
5
Animais
Vegetais
Espcie humana
Sistemas feitos pelo Homem
Sistemas sociais: organizaes de leis, doutrinas, costumes, etc.
Sistemas de transporte: redes rodovirias, canais, linhas areas, petroleiros, etc.
Sistemas de comunicaes: telefone, sinais de fumaa, etc.
Sistemas financeiros: contabilidade, inventrios, controlo de stocks, entre outros.
2.3. Sistemas feitos pelo Homem
O analista de sistemas deve modelar o comportamento bsico para depois seleccionar o que
deve ser executado pelo computador. Para isso, ele leva em conta variveis como:
Custo
Conforto
Segurana
Manutenibilidade
Poltica
2.4. Sistemas de Informao
Um sistema de informao um conjunto de elementos inter-relacionados, processos,
dados e tecnologia, cuja finalidade alimentar os centros de deciso com as informaes
necessrias escolha de directrizes de aco que permitam o atingimento dos objectivos da
organizao.
Dados:
So sequncias ordenadas de smbolos dos quais se pode extrair informao. Porm, no
contm nenhum significado quando analisados isoladamente.
Informao:
So dados tratados, analisados ou processados, capazes de transmitir algum conhecimento
ao receptor.
6
Componentes de um Sistema de informao:
Hardware
Software
Pessoas
Dados
Procedimentos
2.5. Classificao quanto forma de processamento
Sistemas Batch
O utilizador normalmente no interage com o computador por terminal e as informaes
so processadas em lotes, de forma sequencial.
Sistemas On-Line
O utilizador interage com o computador por terminal, os dados de entrada so fornecidos
directamente do local onde eles foram criados e os resultados do processamento so
dirigidos directamente para onde sejam necessrios.
Sistemas em Tempo Real
Controla um ambiente pelo recebimento de dados, seu processamento e apresentao dos
resultados com rapidez suficiente para afectar o ambiente naquele momento.
Sistemas Baseados em Conhecimento
Estes sistemas esto associados ao campo da inteligncia artificial. Contm grande
quantidade de conhecimentos variados para utilizao em determinadas tarefas.
Sistemas Especialistas
So uma espcie de sistemas baseados em conhecimento. Tm embutidos o conhecimento e
a capacidade que os tornam capazes de funcionar como um especialista.
7
2.6. Classificao quanto ao nvel organizacional


Sistemas de Processamento de Transaces
Nvel operacional
Apoia operaes rotineiras da empresa
Regista transaces
Origem dos dados: operaes internas
Grau de agregao dos dados: dados analticos, reais e precisos
Volumes manipulados: grandes
Sadas: relatrios analticos, alguns sintticos
Frequncia: peridica
Exemplos: facturao, stock, contabilidade, etc.
8
Sistemas de Planeamento e Controlo Operacional
Nvel tctico (superviso)
Apoia o planeamento e controlo operacional
Colecta informaes sobre o realizado e compara com o previsto
Origem dos dados: operaes internas
Grau de agregao dos dados: mdio
Volumes manipulados: mdios
Sadas: relatrios consolidados
Frequncia: peridica
Exemplos: custos, planeamento e controlo de produo, planeamento e controlo de
projectos
Sistemas de Apoio Deciso
Nvel tctico (mdia gesto)
Apoia processos decisrios
Trabalha com anlise matemtica e estatstica dos dados
Origem dos dados: operaes internas e fontes externas
Grau de agregao dos dados: alto
Volumes manipulados: pequenos
Sadas: grficos e tabelas
Frequncia: a pedido (ad hoc)
Exemplos: anlise de investimentos, anlise estatstica, simulao de cenrios.
9
Sistemas de Planeamento Estratgico
Nvel estratgico (alta gesto)
Apoia a anlise de factores crticos de sucesso da empresa: desempenho, mercado e
concorrncia
Trabalha com projeces a longo prazo e tendncias do mercado
Origem dos dados: operaes internas e, sobretudo, fontes externas
Grau de agregao dos dados: alto
Volumes manipulados: pequenos
Sadas: grficos e tabelas sofisticados
Frequncia: a pedido (ad hoc)
Exemplo: sistemas de informao executiva
2.7. Princpios Gerais dos Sistemas
Quanto mais especializado um sistema, menos capaz de se adaptar a circunstncias
diferentes.
Quanto maior for um sistema, maior o nmero dos seus recursos que sero destinados
manuteno diria.
Os sistemas fazem sempre parte de sistemas maiores e podem sempre ser divididos em
sistemas menores.
Os sistemas crescem.
10
3. Participantes no Desenvolvimento de Sistemas
Cada projecto possui um elenco diferente de pessoas envolvidas. Um analista de sistemas
precisa ter aptides interpessoais (alm do conhecimento da tecnologia e,
preferencialmente, tambm do negcio), ou seja, deve falar com outras pessoas usando uma
linguagem diferente.
3.1. Utilizadores
a pessoa ou grupo de pessoas para quem o sistema construdo. Para que o
desenvolvimento do sistema seja bem sucedido, necessrio que o analista estabelea um
contacto directo com o utilizador.
O analista de sistemas deve fazer reunies regulares com os utilizadores (tambm
chamados de clientes ou proprietrios). O ideal seria ter utilizadores dedicados
integralmente ao projecto. Alguns defendem que os prprios utilizadores deveriam fazer o
projecto.
Classificao por Tipo de Funo
Operativos
Tm viso local, isto , no conhecem o processo de forma global
Responsveis por executar as funes do sistema
Tm uma viso fsica do sistema, ou seja, imaginam o funcionamento do sistema
considerando a tecnologia de implementao
Supervisores
Podem ou no ter uma viso local
Geralmente conhecem as operaes pois muitos j foram Utilizadores Operativos.
Alm disso, tm que supervisionar os Utilizadores Operativos
Orientado por consideraes oramentais (reduzir o quadro de funcionrios ou
aproveit-los melhor)
Normalmente agem como intermedirios em relao aos nveis mais elevados
Executivos
No tm experincia operativa
Tm a iniciativa do projecto
11
Possuem uma viso global
Tm preocupaes estratgicas
Capazes de lidar com modelos abstractos
Classificao por Nvel de Experincia
Amador
Nunca trabalhou com um computador
Tem dificuldade para entender os modelos produzidos pelos analistas
Receia ser substitudo pelo sistema ou ter sua importncia minimizada
Novato arrogante
Participou de alguns projectos
Possui ou trabalha com computadores
Por conhecer algumas ferramentas, gosta de opinar sobre as tecnologias a serem
usadas para implementar o sistema
Experiente
Conhecem a anlise de sistemas
Tm experincia de outros projectos
Discutem sobre as tcnicas de modelao sendo utilizadas
3.2. Gestor de Projecto
As principais funes de um gestor de projecto so:
Gerir e alocar recursos de toda a equipa tcnica
Prestar contas junto da administrao superior
Encaminhar problemas identificados no decorrer do projecto
3.3. Auditores, Controlo de Qualidade e Normalizao
Responsveis por garantir que o sistema seja desenvolvido de acordo com os vrios padres
internos e externos da organizao, especialmente aqueles focados na segurana e no
controlo de qualidade do produto final.
12
Alguns problemas que devem ser considerados:
Normalmente no se envolvem no projecto at que ele tenha sido concludo. Neste
ponto, modificar o sistema muito mais difcil
s vezes no esto habituados notao utilizada
Geralmente, esto mais interessados na forma do que na substncia
3.4. Analista de Sistemas
O analista desempenha as seguintes funes:
Arquelogo e escriba: deve trazer luz os detalhes e documentar as actividades cujos
detalhes passam de gerao em gerao de utilizadores.
Inovador: no se limitar apenas a implementar as funes actuais do sistema mas
ajudar a encontrar produtos e mercados novos.
Mediador: como os utilizadores dificilmente chegam a um consenso, o analista deve
usar a arte da diplomacia e da negociao. O sistema deve ser feito da forma como os
utilizadores solicitaram.
Lder de projecto: Como o analista entrou antes no projecto, frequentemente tambm
o projectista e normalmente uma pessoa mais experiente, existe uma tendncia
natural de que ele assuma o papel de gestor de projecto.
Um analista deve ter:
Habilidade com pessoas
Conhecimento de aplicaes (ajuda a compreender a empresa do utilizador)
Habilidade em tecnologia
Mente lgica e organizada (visualizar o sistema sob diferentes perspectivas)
3.5. Projectista de Sistemas
Tem a funo de transformar os requisitos dos utilizadores, modelados pelos analistas de
sistemas, num projecto implementvel em computador.
Normalmente o analista e o projectista so a mesma pessoa, ou membros do mesmo grupo
de pessoas.
O analista de sistemas deve fornecer informaes suficientemente detalhadas para que o
projectista elabore um projecto tecnologicamente bom.
13
O projectista deve fornecer informaes suficientes para que o analista possa dizer se os
requisitos dos utilizadores podem ser completamente atendidos ou devem ser modificados.
3.6. Programador
Responsvel por codificar e testar (usando uma linguagem de programao) os mdulos do
sistemas modelados pelos projectistas.
Num cenrio ideal, o programador no deveria ter contacto com o analista j que se baseia
apenas no trabalho feito pelo projectista.
H programadores que so responsveis apenas por dar manuteno em um sistema.
Segundo Nicholas Zvegintzov:
At ao presente momento, o principal profissional da computaco era algum que
podia aprender o suficiente sobre as necessidades das empresas para express-las na
linguagem dos computadores. No futuro, quando a nossa sociedade se tornar
irreversivelmente computadorizada, o principal profissional ser algum que possa
aprender o suficiente sobre sistemas computadorizados para express-los em
linguagem humana. Sem essa pessoa, teremos perdido o controlo da nossa sociedade.
Esse algum o engenheiro s avessas. Os mantenedores de software so os
engenheiros s avessas da sociedade.
3.7. Operador
Pessoa encarregada de operar os computadores, da rede, da segurana do hardware e das
bases de dados, da execuo dos programas e da sada das impressoras.
14
4. Principais Problemas no Desenvolvimento de Sistemas
Para desenvolver sistemas teis, de alta qualidade e que realmente satisfaam as
necessidades dos utilizadores, necessrio considerar os seguintes aspectos:
Produtividade;
Confiabilidade;
Manutenibilidade.
4.1. Produtividade
Os dois aspectos mais importantes deste problema so:
A demanda reprimida (backlog) por novos sistemas
O tempo necessrio para construir um novo sistema
Demanda reprimida
O backlog dos sistemas pode ser dividido em trs categorias:
Visvel:
Solicitados oficialmente pelos utilizadores e que foram aceites e tiveram suas verbas
aproveitadas pela gesto.
Ainda no foram iniciados por falta de recursos humanos (analistas, programadores,
etc.)
Invisvel:
Sistemas que os utilizadores sabem que precisam, mas no se do ao trabalho de
solicitar oficialmente porque ainda esto a aguardar outros projectos
Desconhecido:
Sistemas que os utilizadores ainda no sabem que precisam mas que emergiro logo
que sejam concludos outros sistemas dos backlogs visvel e invisvel.
Num estudo realizado em 1982, descobriu-se que a demanda do backlog invisvel era 5,35
vezes maior que o visvel.
Tempo de desenvolvimento
H uma preocupao no apenas com o backlog global mas com a perda de oportunidades
de negcios devido incapacidade de desenvolver os sistemas de apoio necessrios.
15
Muitos projectos nem so terminados. Dentre os principais motivos, pode-se citar:
Problemas tcnicos
Problemas de gesto
Inexperincia da equipa
Falta de tempo para anlise e projecto
Escasso envolvimento por parte da gesto ou utilizadores
O tempo necessrio para criar um sistema pode ser reduzido atravs de algumas tcnicas:
Contratao de mais programadores e analistas de sistemas
Contratao de programadores e analistas de sistemas mais talentosos, oferecendo-lhes
melhores condies de trabalho
Deixar que os utilizadores desenvolvam seus prprios sistemas
Melhores linguagens de programao
Atacar o problema da manuteno
Controlos de Engenharia de Software
Ferramentas automatizadas de desenvolvimento (CASE)
Razes para os analistas terem conscincia dos problemas de produtividade:
A produtividade e a qualidade do trabalho dos programadores est directamente ligada
ao servio feito pelo analista
Algumas das tcnicas de aumento de produtividade tm importncia directa para os
analistas
A produtividade da anlise um problema politicamente sensvel
Utilizadores e gestor tm ansiedade pelo incio da programao
Utilizadores no entendem a importncia da especificao
16
4.2. Confiabilidade
Os erros em sistemas podem passar despercebidos (uma impresso de um nmero no
formatada correctamente) ou causar graves acidentes (problema em sistema de trfego
areo).
Os erros em software so difceis de serem extintos porque:
difcil descobrir como solucionar o erro
Deve-se encontrar todos os pontos de correco
Alta probabilidade de introduzir novos erros (efeitos colaterais)
Nem sempre so reportados pelos utilizadores
Dificuldade de reproduzir o erro
A figura abaixo mostra o nmero de erros encontrados em funo do tempo decorrido.

Figura 1 Erros descobertos em funo do tempo
Sobre a curva acima importante notar:
Inicialmente o n de erros encontrados pequeno (utilizadores sem segurana para
apontar erros), como indica T1.
medida que os utilizadores se familiarizam com sistema os erros so percebidos e
reportados (entre T1 e T2).
Aps um tempo (aps T2) o n de erros encontrados comea a diminuir (sistema
comea a tornar-se mais estvel).
17
O nmero de erros volta a crescer devido a correces ou modificaes que introduzem
novos erros (aps T3).
A curva nunca atinge zero.
4.3. Manutenibilidade
A correco de erros apenas um dos aspectos da manuteno de sistemas. A manuteno
tambm est vinculada a factores como:
Modificaes no hardware
Novos dispositivos
Necessidade de melhorar o desempenho
Garantir maior confiabilidade
Alteraes dos requisitos
A manuteno de um sistema deve ser sempre acompanhada de modificaes na
especificao do sistema. Entretanto, isso nem sempre ocorre devido a factores como:
Analista alocado a outro projecto
Urgncia na implantao das modificaes
Inexistncia de uma poltica que valorize a manuteno da especificao
4.4. Qualidade
A qualidade de um sistema pode ser mensurada considerando a eficcia e a eficincia
obtidas:
Eficcia = Resultados Obtidos / Resultados Pretendidos
Eficincia = Resultados Obtidos / Recurso Consumido
Problemas que denotam falta de qualidade em sistemas:
No contribuem para os objectivos da empresa;
No atendem s necessidades dos utilizadores;
No so confiveis;
So ineficientes;
18
Tm manuteno constante, difcil e onerosa.
4.5. Portabilidade
Consiste em escrever sistemas que podem ser transferidos para outras plataformas.
Apesar de no ser um problema da alada do analista, ele deve especificar que h essa
necessidade.
A portabilidade geralmente provoca ineficincia j que recursos disponveis de determinada
plataforma no so aproveitados.
4.6. Segurana
medida que os sistemas de informao crescem em nmero e importncia, o risco de
violaes aumenta.
A segurana de sistemas de informao consiste basicamente em:
Impedir o acesso de pessoas no autorizadas;
Conceder acesso a certas funcionalidades apenas a algumas pessoas.
4.7. Principais causas
Ausncia de Planeamento de Sistemas;
Ausncia de Administrao de Dados;
No utilizao de Mtodos e Tcnicas Formais de Desenvolvimento;
No utilizao de Tcnicas e Ferramentas;
Adopo de Metodologias no ambientadas realidade da empresa;
Falta de definio precisa dos objectivos e requisitos do sistema;
Dificuldade de comunicao e/ou falta de entrosamento entre as pessoas envolvidas no
processo;
Dificuldade de comunicao entre Utilizadores e Desenvolvedores (linguagem);
Rivalidade entre utilizadores;
Falta de preciso e clareza na especificao dos sistemas.
19
5. Ciclo de Vida do Projecto de Desenvolvimento
Um ciclo de vida de projecto bem definido oferece mecanismos para planejar e acompanhar
actividades de forma mais precisa, possibilitando a deteco de problemas de forma mais
rpida.
5.1. Conceito de Ciclo de Vida de um Projecto
Nas pequenas organizaes os projectos so caracterizados por:
Serem iniciados aps um entendimento verbal entre os utilizadores e a equipa de
projecto;
O trabalho de desenvolvimento feito sem muito estardalhao.
J nas grandes organizaes os projectos tm as seguintes caractersticas:
Tudo feito de maneira mais formal;
As comunicaes entre os utilizadores, a gesto e a equipa de projecto so
documentadas;
Todos esto cientes da existncia de vrias fases;
Normalmente o gestor responsvel por definir as fases e as actividades do projecto.
Algumas organizaes (pequenas ou grandes) definem para todos os projectos um nico
ciclo de vida, tambm conhecido como plano de projecto ou metodologia de
desenvolvimento de sistemas.
Outras organizaes adoptam um ciclo de vida existente (criado por outra organizao) e
adaptam s suas necessidades.
5.2. Objectivos
Definir as actividades a serem executadas num projecto de desenvolvimento de
sistemas.
Facilita a adaptao de pessoas novas;
Participantes tm uma viso do que esto a fazer no projecto e qual a importncia.
Manter consistncia entre projectos de uma mesma organizao.
Facilita a superviso do projecto pelos nveis mais altos de gesto
Introduz pontos de verificao para o controlo de gesto de decises
20
Permite identificar se o projecto est atrasado e como corrigir o problema
5.3. Ciclo de Vida Clssico
O ciclo de vida de um projecto clssico ou convencional mostrado na figura abaixo:

Pontos de divergncia que normalmente existem nas organizaes mas que no
descaracterizam o ciclo de vida clssico:
Levantamento e Anlise so fundidas (tudo que o utilizador solicita considerado
vivel);
Pode no haver o Estudo de Hardware se o sistema no deve causar srios impactos e
h disponibilidade;
21
Projecto preliminar e Projecto detalhado so reunidos numa nica fase (Projecto);
As fases de teste podem ser reunidas e at feitas junto com a codificao.
As duas caractersticas (e fraquezas) que definem um ciclo de vida clssico so:
Implementao Bottom-Up
Nada est terminado at que esteja totalmente pronto
Os erros triviais so encontrados no incio do perodo de teste e os erros mais srios
so encontrados no final.
A depurao tende a ser extremamente difcil durante os estdios finais dos testes
do sistema;
A necessidade de tempo para testes normalmente aumenta exponencialmente
durante os estdios finais do projecto.
Progresso Sequencial
As fases so seguidas de forma sequencial;
As especificaes produzidas em cada fase so "congeladas";
Apesar de ser uma tendncia humana (terminar uma fase para comear a seguinte),
no representa a realidade dos projectos por vrias razes:
Os requisitos mudam;
Erros so encontrados na especificao e devem ser corrigidos.
22
5.4. Ciclo de Vida Semi-Estruturado

O ciclo de vida semi-estruturado (mostrado na figura acima) tem as seguintes
caractersticas:
Implementao Top-Down usada no lugar da Botton-Up
O utilizador pode testar o sistema antes que esteja todo pronto
Utilizao do projecto estruturado no lugar do clssico (como mostra a figura abaixo).
Projectistas precisam transformar um documento narrativo (monoltico, ambguo e
redundante) em um modelo contendo:
Diagramas de Fluxo de Dados
Dicionrio de Dados
Diagramas de Entidades-Relacionamentos
Especificaes de Processos.
23

5.5. Ciclo de Vida Estruturado
A seguir encontram-se as descries das 9 (nove) actividades do Ciclo de Vida Estruturado:
Levantamento
Tambm conhecida como estudo de viabilidade ou estudo inicial das actividades.
Normalmente iniciado quando o utilizador solicita que algo seja automatizado.
uma importante pea na tomada de deciso e no planeamento do sistema.
Principais objectivos:
Identificar os utilizadores responsveis e desenvolver um "escopo" inicial do
sistema:
Diagrama de Contexto
Diagrama(s) de Fluxo de Dados
24
Identificar as actuais deficincias no ambiente do utilizador.
Estabelecer metas e objectivos para um novo sistema
Determinar se possvel automatizar o sistema e se assim for, sugerir alguns esquemas
aceitveis (custo, benefcio e cronograma).
Preparar uma previso do projecto que ser usada para conduzir o restante do projecto
Anlise
Gerar uma especificao estruturada do projecto do sistema a partir do critrio do
utilizador e da previso do projecto.
Isso envolve a modelao do ambiente do utilizador usando as seguintes tcnicas:
Diagramas de Fluxo de Dados (DFD).
Diagramas de Entidades-Relacionamentos(DER).
Diagramas de Transies de Estado.
Envolve o desenvolvimento de um modelo ambiental e um comportamental.
Projecto
Alocao de partes da especificao (modelo essencial) aos processadores apropriados
(pessoas ou mquinas).
Desenvolvimento de uma hierarquia de mdulos de programas e interfaces entre esses
mdulos.
Transformao do modelo de dados num projecto de bases de dados (dependente da
tecnologia adoptada).
Deve ser desenvolvido o modelo de implementao do utilizador (fronteira homem-
mquina e interface homem-mquina).
Implementao
Codificao e integrao dos mdulos.
Programao Estruturada e Implementao Top-Down.
O sistema vai ficando completo progressivamente.
25
Gerao de Testes de Aceitao
Criar os testes de aceitao a partir da especificao estruturada.
Pode ser feita paralelamente ao projecto e implementao.
Controlo de Qualidade
Tambm chamada de teste final ou teste de aceitao.
Exige como entrada os testes de aceitao e um sistema integrado.
Descrio dos Procedimentos
Descrio formal das partes manuais do novo sistema.
Descrio de como ser a interaco com o utilizador (parte automatizada).
Converso das Bases de Dados
Desenvolver programas para converter os dados existentes para a nova base de dados.
Instalao
Passagem imediata versus gradual.
Formao dos utilizadores.
5.6. Abordagem Radical versus Conservadora
Abordagem Radical do ciclo de vida:
As actividades do projecto so executadas em paralelo (a codificao comea no
primeiro dia).
Abordagem Conservadora do ciclo de vida:
Uma actvidade s iniciada quando a anterior foi concluda.
Ambas as abordagens so perigosas pois so os extremos.
Podem ser adoptadas abordagens intermedirias:
Iniciar uma fase quando 75% ou 50% da anterior estiver concluda.
Executar duas actividades em paralelo (levantamento e anlise).
26
Para cada projecto, uma abordagem diferente pode ser usada, baseada nos seguintes
factores:
Quo inconstantes so os utilizadores?
Utilizadores inconstantes ou inexperientes requerem uma abordagem mais
radical.
Utilizadores veteranos adequam-se mais a uma abordagem mais conservadora.
Presso para produzir resultados imediatos e palpveis.
Presso sobre o gestor do projecto para produzir um cronograma, um oramento e
uma avaliao de pessoas e outros recursos:
Mais radical (precoces) => maior erro.
Mais conservadora => menor erro.
Perigo em cometer um erro tcnico (implementao invivel).
5.7. Ciclo de Vida da Prototipagem
Na prototipagem cada necessidade levantada simulada no prottipo, que expandido
e refinado gradualmente.
Tambm conhecido como desenvolvimento heurstico.
uma alternativa atraente para lidar com a incerteza, a ambiguidade e a inconstncia
dos projectos.
No final da modelao o prottipo ser desprezado e substitudo por um programa real
pois ele apenas um modelo.
Os prototipadores normalmente utilizam os seguintes tipos de ferramentas:
Dicionrio de dados integrado.
Gerador de ecrs.
Gerador de relatrios no-procedural.
Linguagem de programao de quarta gerao.
Linguagem de consultas no-procedural.
Recursos poderosos de gesto de bases de dados.
27
Projectos que so bons candidatos para a abordagem de prototipagem tm as seguintes
caractersticas:
O utilizador incapaz ou no deseja examinar modelos abstractos de papel como
DFD's.
O utilizador incapaz de exprimir os seus requisitos, podendo identific-los atravs
de tentativas e erros ("Eu no sei o que quero, mas eu saberei, se o vir").
O sistema est previsto para ser on-line (a maioria das ferramentas de apoio so
orientadas para a abordagem on-line).
No exige a especificao de grandes quantidades de detalhamento algortmico.
O utilizador est mais interessado no formato e na diagramaco da entrada e da
sada.
A abordagem da prototipagem pode ser combinada com a anlise estruturada como uma
forma de auxiliar a descoberta/especificao dos requisitos.
A abordagem Top-Down pode funcionar como uma forma de prototipagem, na qual
cada verso contm mais funcionalidades e est mais prxima do desejo do utilizador.
O risco em adoptar o prottipo como um sistema de produo grande e pode ser
desastroso porque:
No foi preparado para manipular eficientemente grandes volumes de transaces.
Carece de detalhes operativos como:
Recuperao de erros.
Auditoria.
Backup/Recuperao.
Documentao do utilizador.
Procedimento de converso.
O projecto pode terminar (quando o prottipo for substitudo pelo sistema) sem que
tenha sido produzida qualquer documentao formal, que deveria ser mantida ao
longo da vida do sistema.
28
6. Modificaes na Anlise de Sistemas
necessrio estar ciente das tcnicas actuais e das modificaes ocorridas com o passar
do tempo.
H basicamente trs motivos para conhecer a evoluo da anlise de sistemas:
Ajuda a perceber a evoluo de uma empresa
Mudar de emprego
Sugerir a evoluo
Ocupar cargos de liderana para alavancar as mudanas
importante conhecer a abordagem anteriormente adoptada pela organizao e se
h algum tipo de transio em andamento
A noo de transio importante pois a anlise de sistemas dinmica:
Novas tcnicas
Modificaes em ciclos de vida
6.1. A passagem para a Anlise Estruturada
At o final da dcada de 70, os requisitos dos utilizadores eram documentados atravs
de uma narrativa no idioma adequado.
Os primeiros autores sobre Anlise Estruturada mostraram que esta forma de
especificao padecia de grandes problemas.
Monolticos: Era necessrio ler todo o documento para entender. Isso dificultava a
compreenso se fosse necessrio estudar apenas uma parte.
Redundantes: A dificuldade de actualizar e rever o documento conduz
inconsistncia.
Ambguos: utilizadores, analistas, projectistas e programadores tm interpretaes
diferentes do documento.
Manuteno impossvel: A especificao estava obsoleta antes mesmo do final do
projecto.
Como consequncia, no se tem ideia do que muitos sistemas desenvolvidos nas
dcadas de 60 e 70 fazem porque os analistas e programadores que os desenvolveram
no esto mais presentes.
29
Apesar das tcnicas de Programao Estruturada e Projecto Estruturado terem sido
adoptadas, era necessrio que houvesse uma evoluo na forma de especificar os
Requisitos do Utilizador.
"Poderia chegar-se a um desastre com mais rapidez do que nunca".
A especificao dos requisitos deveria ser:
Grfica
Particionada
Sem redundncia
6.2. Modificaes na Anlise Estruturada
Alguns anos de experincia prtica indicaram que eram necessrias algumas alteraes,
cujas principais so:
Evitar a construo de modelos "fsicos" e "lgicos" do sistema actual.
Politicamente perigosa (muito tempo gasto com algo que vai ser descontinuado)
A distino vaga entre os modelos lgico e fsico (dependente da tecnologia)
Modelo lgico => Modelo essencial (essncia do sistema)
Modelo fsico => Modelo de implementao (considera aspectos tecnolgicos)
Carncia de tcnicas de modelao para construir sistemas de tempo-real
Introduo dos Diagramas de Transio de Estado (DTE)
Necessidade de modelar as estruturas de dados do sistemas
Introduo dos Diagramas de Entidades-Relacionamentos
Melhor integrao entre as tcnicas (DFD, DER, DTE e DD)
Utilizao da subdiviso (particionamento) por eventos no lugar do Diagrama de
Contexto
30
6.3. Surgimento das Ferramentas Automatizadas de Anlise
Trabalho artstico de criar os diagramas
O grande problema fazer a manuteno dos diagramas
Muitas modificaes durante a anlise
Grande quantidade de diagramas
Dificultou a aceitao da Anlise Estruturada Trabalho artstico de criar os diagramas
Analista preferia deixar o diagrama desactualizado
Analista no subdividia o modelo do sistema em modelos de nvel mais baixo
Os Projectistas e Programadores no mantinham os diagramas actualizados durante
a implementao
No havia verificao automtica de consistncia nos diagramas (era necessrio fazer
inspeces visuais)
Custo elevado das ferramentas e dos terminais grficos
6.4. Uso da Prototipagem
Surgimento de ferramentas de Prototipagem
A Anlise Estruturada levava muito tempo:
Modelao do sistema novo s comea aps a do sistema actual
Como os Diagramas no geravam cdigo, suspeitava-se que o tempo gasto na
implementao seria igual
Os primeiros projectos levavam mais tempo pois os Analistas no estavam
acostumados com as tcnicas
muita da programao seria o mesmo se no fosse feita anlise
A prototipagem concentra-se na definio da interface homem-mquina
Evita os detalhes que so capturados atravs da Anlise e do Projecto
31
7. Diagrama de Fluxo de Dados
Principal tcnica de modelao funcional
Modela o sistema como uma rede de processos funcionais, interligados por dutos e
tanques de armazenamento
Pode ser usado para descrever processos computadorizados e no computadorizados
Tambm chamado de DFD (abreviatura), Diagrama de Bolhas, Modelo de Processo,
Diagrama de Fluxo de Trabalho e Modelo Funcional
Um DFD composto de Processos, Fluxos de Dados, Depsitos de Dados e Entidades
Externas
7.1. Componentes de um DFD
Processos
Tambm conhecido como bolha, funo ou transformao
Representam transformaes de fluxo(s) de dados de entrada em fluxo(s) de dados
de sada
O nome do processo deve descrever o que ele faz
Geralmente provoca mudanas de estrutura, contedo ou estado
Representaes grficas possveis:

Fluxos de Dados
Representam caminhos por onde passam os dados
So representados atravs de setas que indicam o destino do dado
Tm nomes que devem constar no dicionrio de dados
Um mesmo fragmento de dados pode ter significados diferentes em pontos distintos
de um DFD (CPF-Vlido e CPF-Invlido)
Um fluxo apenas no modifica os dados durante o transporte
32
Transportam dados entre os elementos do DFD
Processo Processo
Entidade Externa Processo
Depsito de Dados Processo
Tipos de fluxos
Fluxo externo: entre Entidade Externa e Processo
Fluxo interno: entre dois Processos
Fluxo de acesso memria: entre Processo e Depsito
Fluxo de erro ou rejeio: para fora de um Processo
Nomenclatura:
Cada fluxo deve ter um nico nome
O nome deve identificar os dados transportados pelo fluxo
Exemplos: Dados-Factura, Recibo-Pagamento, Dados-Cliente
Depsitos de Dados
Representa uma coleco de pacotes de dados em repouso
Nem sempre um depsito de dados um arquivo ou SGBD. Pode representar
microfilmes, pastas de arquivos em papel e diversas outras formas no
computadorizadas
Representaes grficas de um depsito de dados:

Quando um pacote de dados recuperado (ou inserido) por completo do depsito de
dados, pode-se omitir o rtulo do fluxo
Nomenclatura:
Deve estar no plural
Pode receber o nome do fluxo de dados (no plural)
33
Entidades Externas
Tambm chamados de Terminadores
So as fontes/destinatrios das informaes que entram/saem do sistema
Os procedimentos executados pelas entidades externas no so especificados no
modelo por no fazerem parte do sistema
Normalmente uma pessoa, um grupo de pessoas, uma organizao externa, um
sector dentro de uma empresa
Pode representar um outro sistema
Representao grfica de uma Entidade Externa:

Nomenclatura:
No plural quando se referir a um grupo de pessoas (Clientes)
Deve conter o nome do sector ou organizao externa (Directoria de Negcios)
Deve ser includa a palavra sistema quando se tratar de um sistema (Sistema de
Contabilidade)

34
7.2. Directrizes para elaborao de DFD
Existem algumas directrizes que auxiliam a criar DFD's com sucesso, ou seja, evitam a
criao de:
DFD's incorrectos (incompletos ou logicamente inconsistentes)
DFD's agradveis (facilmente examinados pelo utilizador)
Escolher Nomes Significativos
Evitar nomes para processos como: Fazer servio, Manipular entrada, Cuidar dos
clientes e Processar dados
Devem-se numerar os Processos
A numerao tem basicamente duas utilidades:
Permitir localizar os processos no diagrama facilmente
Facilita a identificao, a partir dos diagramas mais detalhados, do processo que foi
explodido
No importa a maneira desde que seja consistente
A numerao no indica sequncia pois o DFD uma rede de processos assncronos
que se intercomunicam
Evitar DFD Complexos
Evitar colocar elementos demais no digrama
Deve caber facilmente numa pgina
O DFD deve modelar correctamente as funes que um sistema deve executar e as
interaces entre elas.
Deve ser lido e entendido facilmente pelos utilizadores
Refazer tantas vezes quantas forem necessrias
Um DFD deve ser refeito at que:
Esteja tecnicamente correcto
Aceitvel pelo utilizador
O Analista no tenha vergonha de apresent-lo directoria.
35
Criar diagramas esteticamente agradveis
Manter consistentes o tamanho e a forma das bolhas
Fluxo de dados cursos versus rectos (questo de gosto)
Diagramas desenhados mo versus gerados por mquina
Os desenhados mo passam a sensao de que ainda podem ser modificados
Os gerados por mquina so mais limpos
Certificar-se de que o DFD seja logicamente consistente
Evitar "poos sem fundo" (processos que s recebem entradas)
Evitar processos com gerao espontnea (processos que no recebem entrada mas
produzem sadas)
Cuidado com fluxos e processos sem rtulos
Cuidado com depsitos que tenham somente leitura ou escrita
Posio dos elementos
O processo origem deve ficar esquerda ou acima do processo destino
As entidades externas devem ser desenhadas nas bordas do desenho:
As de entrada, esquerda ou acima
As de sada, direita ou abaixo
Os depsitos de dados devem ser distribudos no meio do desenho, entre os processos
Duplicao de elementos
Pode-se duplicar Entidades e Depsitos para evitar cruzamento de fluxos e melhorar a
organizao do diagrama
Um mesmo fluxo de dados pode aparecer mais de uma vez no mesmo DFD
No faz sentido duplicar processos
36
7.3. DFD com Nveis
O DFD de sistemas no triviais muito complexo
Para evitar que tudo seja definido num nico diagrama (difcil de ser entendido e
mantido), criam-se DFD's que detalham um processo de um nvel mais alto
Diagrama de Contexto
o DFD de nvel mais alto
D a viso das principais funes do sistema
Contm um processo (representa o sistema), os fluxos externos e as entidades externas

Diagrama Nvel 0
o primeiro detalhamento do diagrama de contexto
Contm as macro-funes do sistema
37

Diagrama de Nveis Intermdios
So os diagramas que mostram a decomposio (detalhamento ou exploso) de cada
processo de nvel mais alto
A quantidade de nveis depende de factores como complexidade e porte do sistema
Em geral, a decomposio deve terminar quando for possvel especificar o processo
numa pgina


38
8. Dicionrio de Dados
necessrio descrever a composio dos dados de alguma forma.
A forma narrativa longa e sujeita a erros
necessrio usar uma notao compacta e concisa
Elementos de dados so dados que no necessitam de decomposio
Estrutura de dados so composies de elementos de dados e/ou de outras estruturas
de dados
A definio no DD feita de forma Top Down
O dicionrio de dados define os elementos de dados descrevendo:
O significado de fluxos e depsitos
A composio de pacotes agregados de dados que se movimentam pelos fluxos (Ex:
Endereo pode ser divido em itens elementares como cidade, estado, etc.)
A composio dos pacotes de dados nos depsitos
Os valores e unidades relevantes de partes elementares de informaes dos fluxos e
depsitos
Os detalhes dos relacionamentos entre os depsitos realados num DER
8.1. Notao
H vrios esquemas de notao. Porm, o mais comum o seguinte:
= composto de
+ E (concatenao)
( ) Opcional
{ } Iterao
[ ] Escolha de uma das opes alternativas
* Delimitador de comentrio
@ Identificador (campo chave) de um depsito
| Separa opes alternativas na construo [ ]
39
Exemplo: definio de um nome (estrutura de dados)
nome = * Nome completo do cliente *
ttulo-cortesia + primeiro-nome + (nome-intermdio) +
ltimo-nome
ttulo-cortesia = [Sr.|Srta.|Sra.|Sras.|Dr.|Professor]
primeiro-nome = {carcter-vlido}
nome-intermdio = {carcter-vlido}
ltimo-nome = {carcter-vlido}
carcter-vlido = [A-Z|a-z|0-9|'| ]
8.2. Definies
Uma definio de um item de dados apresentada com o smbolo "=", que deve ser lido
como " definido como", ou " composto de", ou simplesmente "significa"
A notao A = B + C, significa A composto de B e C
O significado do dado no contexto da aplicao deve ser colocado na forma de
comentrio
8.3. Elementos opcionais
Um elemento de dados opcional quando a sua presena no elemento de dados
composto no obrigatria
Exemplo: um cliente deve ter um endereo e pode informar um endereo de remessa
Cliente = Endereo + (Endereo-Remessa)
8.4. Iterao
Usado para indicar a ocorrncia repetida de um componente de um elemento de dados
Exemplo 1: um pedido que composto de um nome do cliente, um endereo de remessa e
zero ou mais itens
Pedido = Nome-do-Cliente + Endereo-Remessa + {Item}
Exemplo 2: um pedido que composto de um nome do cliente, um endereo de remessa e
de 1 a 10 itens
Pedido = Nome-do-Cliente + Endereo-Remessa + 1{Item}10
Exemplo 3: um pedido que composto de um nome do cliente, um endereo de remessa e
pelo menos um item
40
Pedido = Nome-do-Cliente + Endereo-Remessa + 1{Item}
Exemplo 4: um pedido que composto de um nome do cliente, um endereo de remessa e
no mximo 10 itens
Pedido = Nome-do-Cliente + Endereo-Remessa + {Item}10
8.5. Seleco
Indica que deve ser seleccionada uma das opes apresentadas
Exemplo: definindo o estado civil
Estado-Civil = [Solteiro | Casado | Divorciado | Separado | Outro]
8.6. Sinnimo
necessrio quando os utilizadores usam termos diferentes para um mesmo dado
Exemplo:
Nmero-do-Item = 1{Dgito}5
Nmero-da-Pea = * Sinnimo de Nmero do Item *
Dgito = [0 | 1 | 2 | 3]
8.7. Definio de Depsitos
A definio deve vir entre {} para indicar a existncia de 0 a n ocorrncias
Coloca-se o caractere @ antes do item de dado que identifica uma ocorrncia
(instncia) do depsito
Exemplo: definindo depsitos de Clientes e Funcionrios
Clientes = { @CPF-CNPJ + Nome + Data-cadastro + Endereo }
Funcionrios = { @Matrcula + Nome + Data-contratao + Endereo +
{@Telefone + Descrio} + {@RG-Dependente + Nome} }

41
9. Diagrama de Entidades-Relacionamentos
O DER serve para modelar os dados de um sistema
Um DER interessante quando se deseja:
Especificar os dados que so necessrios
Mostrar a quem pertencem os dados
Identificar os relacionamentos entre os dados
Diferena entre Administrador de Dados (AD) e Administrador de Bases de Dados
(ABD)
9.1. Entidades
Uma Entidade representa uma coleco de objectos ou eventos cujos membros
individuais (exemplares ou instncias) tm as seguintes caractersticas:
Cada um s pode ser identificado de uma nica forma
Cada um exerce um papel fundamental no sistema de informao.
Cada um pode ser descrito por um ou mais elementos de dados
O nome da entidade deve estar no singular
Devem ser descritas no Dicionrio de Dados
Exemplos: Cliente, Automvel, Disciplina e Contratao de Funcionrio
9.2. Relacionamentos
Representam as associaes entre entidades
Um relacionamento est sujeito existncia das entidades que associa
Devem ser descritas no Dicionrio de Dados
Tipos de Relacionamentos
Podem ser classificados em: Obrigatrios, Opcionais, Mltiplos e Unitrios
42

Classificaes adicionais
Entidades fracas ou dependentes: As entidades fracas dependem da existncia de uma
ocorrncia da entidade principal. Exemplo: Cliente e Dependente
Subtipos e Supertipos: Os Subtipos possuem, alm dos seus atributos especficos, os
atributos de seu Supertipo. Exemplo: Cliente, Cliente Pessoa Fsica e Cliente Pessoa
Jurdica.
Entidades Associativas: So fruto de relacionamentos M para N, ou 1 para N, com
informaes prprias. So identificados atravs das chaves das Entidades que relaciona.
Exemplo: Produto - Venda - Cliente
Cardinalidade
Representam o nmero de ocorrncias de cada entidade associadas num relacionamento
Podem ser 1:1 (um para um), 1:N (um para N) e M:N (M para N)
Casos especiais de relacionamentos
Relacionamentos entre vrias Entidades
Auto-Relacionamento
Racionamento em paralelo
43
10. Diagrama de Transies de Estado
Modela o comportamento dependente do tempo
Empregado em sistemas de tempo real
Interagem com fontes de dados externas de alta velocidade
Devem produzir respostas e dados de sada rapidamente para interagir com
ambiente externo
Exemplos: Sistemas de controlo de processos, Sistemas de controlo militares,
Sistemas de navegao em automveis, etc.
10.1. Notao
Os principais componentes de um DTE so os rectngulos que representam os estados
e as setas que representam as alteraes de estado
Estado
Um estado uma situao em que o sistema se encontra e que pode durar por um
determinado perodo de tempo
representado por um rectngulo
Exemplos: A aguardar o prximo comando; A executar transaco; A esperar a
digitao da senha; A acelerar o motor; etc.
Em geral os estados apresentam situaes em que o sistema est aguardando pela
ocorrncia de um evento ou est fazendo algo
Mudanas de Estado
So as transies de um estado para outro
Indicam, para cada estado, os seus possveis estados subsequentes
Geralmente apontam os estados iniciais e finais
O estado inicial normalmente desenhado na parte de cima do diagrama. identificado
atravs de uma seta que chega a ele sem partir de outro estado
Um estado final normalmente desenhado na parte de baixo do diagrama e no possui
setas que partem dele
Um DTE pode ter vrios estados finais
44
Condies e Aces
Num DTE tambm possvel incluir as condies que causam uma mudana de estado
e as aces que o sistema empreende quando muda de estado
So exibidas junto seta que indica a mudana de estado (a condio acima e a aco
abaixo, separadas por uma linha)
Exemplo de diagrama de transies de estados (browser web)

45
10.2. Diagramas subdivididos
Em sistemas complexos difcil (ou at impossvel) representar todos os estados num
nico DTE.
permitido criar um DTE de alto nvel e detalhar cada estado num outro DTE (mais
detalhado)
No DTE mais detalhado h um estado inicial e um ou mais estados finais
Exemplo:

46
10.3. Construindo um DTE
Para construir um DTE pode-se utilizar as seguintes abordagens:
Abordagem 1:
Identificar todos os possveis estados do sistema
Descobrir as transies significativas entre os estados
Abordagem 2:
Identificar o estado inicial
Descobrir quais so os estados seguintes e os caminhos possveis
Repetir o passo anterior para cada um dos estados seguintes
Aps elaborar o DTE, verifica-se a sua consistncia atravs dos seguintes testes:
Todos os estados so atingveis?
Todos os estados foram especificados?
Todos os estados no finais tm transio de sada?
Em cada estado, o sistema reage adequadamente a todas as condies possveis?
As condies de excepo esto representadas?
47
11. Especificaes de Processos
Tem como propsito definir o que deve ser feito para transformar as entradas de um
processo em sadas.
H vrias formas de se especificar um processo, dentre as quais pode-se destacar:
Linguagem Estruturada
Condies Pr/Ps
Tabela de Deciso
rvore de Deciso
Os principais problemas da linguagem natural so:
Ambiguidade (condies booleanas)
Riqueza de formas (mais de uma forma de definio)
Impreciso de limites (no especificao de casos especiais)
Qualquer forma de especificar processos vlida desde que:
Seja expressa de uma forma que possa ser verificada pelo utilizador e pelo analista.
Possa ser efectivamente entendida por todos os envolvidos no projecto (utilizadores,
gestores, auditores, etc.)
O analista deve conhecer as tcnicas para que possa seleccionar a mais apropriada para
cada situao
11.1. Linguagem Estruturada
Subconjunto da linguagem normal com algumas restries sobre as sentenas quanto:
Tipo de sentenas que podem ser utilizadas
Formas como podem ser utilizadas
Formas como podem ser reunidas
Equilbrio entre a preciso de uma linguagem de programao formal e a informalidade
e a legibilidade da lngua normalmente utilizada
48
O vocabulrio da Linguagem Estruturada consiste em:
Verbos no imperativo:
RECEBER (fluxo)
ENVIAR (fluxo)
MOVIMENTAR (dados)
ACEDER (depsito de dados)
Palavras reservadas (estruturas de controlo)
Termos definidos no Dicionrio de Dados
Termos locais
Numerais e valores booleanos
Estruturas de controlo
Sequncia: uma ou mais sentenas executadas em sequncia sem interrupo
Seleco: SE e FAA-CASO
Repetio: FAA-ENQUANTO e REPITA
Sintaxe e exemplo do comando de seleco SE
SE <condio>
Sentena A
SENO
Sentena B
FIM-SE
----------------------
SE idade-cliente < 18
categoria = 'Menor'
SENO
categoria = 'Maior'
FIM-SE
49
Sintaxe e exemplo do comando de seleco FAA-CASO
FAA-CASO
CASO <condio>
Sentena A
CASO <condio>
Sentena B
...
CASO-CONTRRIO
Sentena X
FIM-CASO
--------------------------
FAA-CASO
CASO situacao = 1
risco = 'Pequeno'
CASO situacao = 2
risco = 'Moderado'
CASO situacao = 3
risco = 'Alto'
CASO-CONTRRIO
Risco = 'Indefinido'
FIM-CASO
Sintaxe e exemplo do comando de repetio FAA-ENQUANTO
FAA-ENQUANTO <condio>
Aco A
FIM-ENQUANTO
-------------------------------------------
total = 0
FAA-ENQUANTO h mais pedidos
LER prximo pedido de PEDIDOS
total = preo-unitrio * quantidade-item
FIM-ENQUANTO
EXIBIR total
50
Sintaxe e exemplo do comando de repetio REPITA
REPITA
Aco A
AT-QUE <condio>
-------------------------------------------
total = 0
REPITA
LER prximo pedido de PEDIDOS
total = preo-unitrio * quantidade-item
AT-QUE no haja mais pedidos
EXIBIR total
Algumas sugestes
Uma especificao de processo em linguagem estruturada deve caber numa folha de
papel
No usar mais de trs nveis de aninhamento, principalmente em seleces
Evitar confuses sobre os nveis de aninhamento, utilizando indentao
Examinar os documentos com as especificaes, vrias vezes, para garantir que os
utilizadores os entendero
Verificar a consistncia da especificao do processo com o DFD e o DD
51
11.2. Pr/Ps
So um modo prtico de descrever um processo, sem que seja necessrio detalhar o
algoritmo que ser utilizado.
Tem duas partes: pr-condies e ps-condies e til quando:
O utilizador tende a especificar um algoritmo muito especfico e particularizado que
vem sendo utilizado h muito tempo
O analista est seguro de que existem muitos algoritmos que podem ser usados
O analista deseja deixar a definio do algoritmo para o programador, no se
preocupando em defini-lo com o utilizador
Pr-Condies
Definem o que deve ser verdade antes do incio da execuo do processo.
Podem ser consideradas como uma garantia do utilizador.
Normalmente, as pr-condies descrevem o seguinte:
Que entradas devem estar disponveis para que o processo seja activado
"O elemento de dados X ocorre"
Que relacionamentos devem existir entre as entradas ou no interior delas
"Detalhes de pedidos e detalhes de remessas com o mesmo nmero de conta"
"Ocorre um pedido com data de entrega superior a 60 dias"
Que relacionamentos devem existir entre entradas e depsitos de dados
"Existe um pedido-de-cliente com um nmero-de-conta-de-cliente que coincide
com um nmero-de-conta-de-cliente no depsito de clientes"
Que relacionamentos devem existir entre diferentes depsitos ou no interior de um
depsito
"Existe um pedido no depsito de pedidos cujo nmero-de-conta-de-cliente
coincide com o nmero-de-conta-de-cliente no depsito de clientes"
"Existe um pedido no depsito de pedidos com uma data-de-embarque igual
data actual"
52
Ps-Condies
Descrevem o que deve ser verdadeiro quando o processo terminar.
Podem ser consideradas como uma garantia do sistema para o utilizador.
Normalmente, as ps-condies descrevem o seguinte:
As sadas que sero geradas ou produzidas por um processo
"Ser produzida uma factura"
Os relacionamentos que existiro entre os valores de sada e os valores originais de
entrada
"O total-facturado foi calculado como soma dos preos-unitrios-de-item mais
taxa-de-embarque"
Os relacionamentos que existiro entre os valores de sada e os valores num ou mais
depsitos.
"O balano-pendente no depsito inventrio ser aumentado pelo valor-recebido
e o novo inventrio-pendente ser produzido como sada deste processo"
As alteraes que devero ser feitas nos depsitos
"O pedido ser acrescentado ao depsito pedidos"
"O registo cliente ser eliminado do depsito clientes"
Exemplo:
Pr-Condio 1
- O Cliente apresenta-se com um nmero-de-conta coincidente com um nmero
de conta em Contas, cujo cdigo-de-status est ajustado em "vlido"
Ps-Condio 1
- A factura emitida contendo nmero-de-conta e valor-da-venda
Pr-Condio 2
- A pr-condio falha por algum motivo (o nmero-de-conta no
encontrado em Contas ou cdigo-de-estados no igual a vlido
Ps-Condio 2
- emitida uma mensagem de erro
53
11.3. Tabela de Deciso
uma tcnica no-procedural que permite especificar processos que produzem uma
sada ou aco dependendo da avaliao de condies complexas
Utiliza um formato tabular que facilita a visualizao e compreenso do problema
O processo representado normalmente requer IF's aninhados e/ou CASE's
No implica uma implementao especfica (programador tem liberdade de escolha)
Estrutura de uma Tabela de Deciso
Uma tabela de deciso composta por:
Seco de Condies - (Superior esquerdo)
Seco de Aces - (Inferior esquerdo)
Entrada de Condies - (Superior direito)
Entrada de Aces - (Inferior direito)

Condies 1 2 3 4
Idade > 21 S S N N
Sexo M F M F
Aces
Exame fsico simples X
Exame fsico completo X X
Exame prtico X
Exame psicolgico X

Criar uma Tabela de Deciso
Identificar todas as condies ou variveis na especificao
Identificar todos os valores possveis para cada condio ou varivel
54
Calcular o nmero de combinaes possveis
Identificar as aces
Criar uma tabela de decises vazia
Preencher as condies e as aces na parte esquerda da tabela
Especificar as aces adequadas de acordo com as condies especificadas na coluna
Identificar omisses e ambiguidades existentes na especificao do problema e discuti-
las com o utilizador
11.4. rvore de Deciso
til quando nem todas as combinaes de condies so possveis
Permite representar graficamente tomadas de decises complexas
Por ser uma tcnica grfica, torna mais fcil compreender e discutir
Criar uma rvore de Deciso
Identificar as condies
Identificar os valores de cada condio
Determinar o nmero de regras do problema (ramos da rvore)
Identificar as aces
Fazer as simplificaes necessrias (podar a rvore)

55
12. O Modelo Essencial
12.1. A abordagem clssica
Os quatro modelos
Modelo fsico actual
Modelo lgico actual
Novo modelo lgico (80 a 90% igual ao modelo lgico actual)
Novo modelo fsico
Porque a abordagem clssica no funcionava
Algumas suposies equivocadas:
O analista precisava entender o sistema actual. Para isso, utilizava o modelo fsico
actual
O utilizador talvez no queira ou no pode trabalhar como o novo modelo lgico no
incio do projecto
Desconfiana da capacidade do analista
Dificuldade em lidar com modelos abstractos
A transformao do modelo lgico actual num novo modelo lgico no exige muito
trabalho nem desperdcio de trabalho
12.2. O que o Modelo Essencial
Indica o que o sistema deve fazer, mencionando o mnimo possvel sobre como ser
implementado
Tecnologia perfeita
Tudo pode ser obtido a custo zero
No associar processos a pessoas ou sistemas existentes
56
12.3. Dificuldades na construo do Modelo Essencial
Dificuldade de eliminar completamente do modelo essencial todos os detalhes de
implementao
Sequncia arbitrria de actividades num modelo de fluxo de dados
Arquivos desnecessrios (devido tecnologia imperfeita)
Processamento em batch
Backup/Recuperao
Desnecessrias verificaes de erros e validao de erros e processos dentro do sistema
Dados redundantes ou derivados
Desempenho
12.4. Componentes do Modelo Essencial
Composto pelo Modelo Ambiental e pelo Modelo Comportamental
O Modelo Ambiental
Define a fronteira entre o sistema e o resto do mundo
Composto por:
Declarao de Objectivos
Diagrama de Contexto
Lista de Eventos
DD com as definies dos fluxos e depsitos externos (opcionalmente)
DER dos depsitos externos (opcionalmente)
O Modelo Comportamental
Descreve o comportamento do interior do sistema, necessrio para interagir com
sucesso com o ambiente
Composto por DFD, DER, DTE, DD e Especificao de Processos
57
12.5. O Modelo Ambiental
Declarao de Objectivos
Diagrama de Contexto
Lista de Eventos
Eventos Orientados por Fluxos
Eventos Temporais
Exemplos:
Cliente entrega pedido (F)
Cliente cancela pedido (F)
Direco solicita relatrio de vendas (T)
Contabilidade precisa (mensalmente) do relatrio de comisses de vendas (T)
12.6. O Modelo Comportamental Preliminar
Modelar o comportamento interno para que o sistema possa interagir com o ambiente
DFD
DER
Itens Iniciais do DD
A Abordagem Clssica (Top-Down)
Diagrama de Contexto DFD nvel 0 Detalhamento dos processos do nvel 0 at
chegar a processos atmicos
Desta forma, a diviso fica arbitrria
Particionamento por eventos
Envolve 4 etapas:
Desenhar um processo para cada evento da Lista de Eventos
Dar um nome ao processo de acordo com a resposta que o sistema deve dar ao
evento
58
59
Desenhar entradas, sadas e depsitos
Verificar o DFD inicial em relao ao Diagrama de Contexto e Lista de Eventos
12.7. O Modelo Comportamental Final
Nivelamento
Criar nveis superiores de DFD (ascendente)
Directrizes:
Agrupar processos que produzem respostas relacionadas
Agrupar processos que compartilham depsitos, permitindo ocult-los no nvel mais
alto
Manter o nmero de processos em 7 2
Criar nveis inferiores de DFD (descendente)
Quando o processo do DFD preliminar no puder ser especificado numa pgina
Directrizes:
Decomposio funcional
Decomposio pelos fluxos de entrada/sada
Complementar Dicionrio de Dados
Incluir os fluxos e os depsitos encontrados atravs do nivelamento
Complementar as Especificaes de Processos
Provavelmente ainda no haver nenhuma especificao
Deve comear depois da estabilizao do DFD (aps o nivelamento)
Complementar o Modelo de Dados
Pode ser feito em paralelo com o DFD
Pode ser feito por grupos diferentes
Deve incluir os depsitos identificados no nivelamento