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

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.
6.2.
6.3.
6.4.

7.

A PASSAGEM PARA A ANLISE ESTRUTURADA .............................................................................. 29

MODIFICAES NA ANLISE ESTRUTURADA ................................................................................. 30
SURGIMENTO DAS FERRAMENTAS AUTOMATIZADAS DE ANLISE ................................................. 31
USO DA PROTOTIPAGEM ................................................................................................................. 31

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.
8.2.
8.3.
8.4.
8.5.
8.6.
8.7.

9.

NOTAO ....................................................................................................................................... 39
DEFINIES .................................................................................................................................... 40
ELEMENTOS OPCIONAIS .................................................................................................................. 40
ITERAO ...................................................................................................................................... 40
SELECO ...................................................................................................................................... 41
SINNIMO ...................................................................................................................................... 41
DEFINIO DE DEPSITOS.............................................................................................................. 41

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

10.3.
11.

CONSTRUINDO UM DTE ................................................................................................................. 47

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

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.

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
(computadorizado ou no) e interage com outros sistemas.

de

um

sistema

maior

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.

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.

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.

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.

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.

Objectivos

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 homemmquina 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 do ciclo de vida:

Abordagem Radical versus Conservadora

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.

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

Politicamente perigosa (muito tempo gasto com algo que vai ser descontinuado)

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 =

8.4.

Endereo + (Endereo-Remessa)

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 =

8.5.

Nome-do-Cliente + Endereo-Remessa + {Item}10

Seleco

Indica que deve ser seleccionada uma das opes apresentadas

Exemplo: definindo o estado civil

Estado-Civil =

8.6.

[Solteiro | Casado | Divorciado | Separado | Outro]

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

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

"O elemento de dados X ocorre"

"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

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.

"Ser produzida uma factura"

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

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

Idade > 21

Sexo

Aces
Exame fsico simples
Exame fsico completo
Exame prtico
Exame psicolgico

X
X

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

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

59