ANLISE DE SISTEMAS

ANLISE DE SISTEMAS

CAPTULO 1 1 Introduo O desenvolvimento de software uma atividade de crescente importncia na sociedade contempornea. A utilizao de computadores nas mais diversas reas do conhecimento humano tem gerado uma crescente demanda por solues computadorizadas. importante observar que, associada ao acrscimo da demanda, a evoluo do hardware tem sido mais acentuadas, disponibilizando aos usurios mquinas cada vez mais velozes e com maior capacidade de processamento. Neste contexto, identificou-se, j na dcada de 70, uma situao crtica no desenvolvimento de software, a chamada Crise do Software [Pressman], caracterizada pelos seguintes fatos: Demanda muito superior capacidade de desenvolvimento; Qualidade insuficiente dos produtos; Estimativas de custo e tempo raramente cumpridas nos projetos. Visando melhorar a qualidade dos produtos de software e aumentar a produtividade no processo de desenvolvimento, surgiu a rea de pesquisa denominada Engenharia de Software. A Engenharia de Software busca organizar esforos no desenvolvimento de ferramentas, metodologias e ambientes de suporte ao desenvolvimento de software. Dentre as principais atividades de um processo de desenvolvimento de software, destaca-se a atividade de anlise e especificao de requisitos, na qual os requisitos de um sistema so levantados e modelados, para s ento ser projetada e implementada uma soluo (FALBO, 2002).

ANLISE DE SISTEMAS

Problemas no Desenvolvimento de Sistemas

O processo de informatizao das atividades administrativas de uma empresa traz inmeras implicaes, que vo desde mudanas nas rotinas de trabalho at restruturaes organizacionais, com toda a problemtica que da, invariavelmente, decorre.

Em certos casos, devido grande presso exercida pelos usurios, tenta-se resolver o problema da informatizao atravs de uma viso mecanicista de realidade. Esta soluo leva a tentativas de soluo, quase sempre, de natureza instrumental, como acontece quando a direo da empresa convencida por um fornecedor de hardware ou de software que lhe garante ser o produto, por ele vendido, o remdio para todos os males que afligem a empresa. Isto, sem dvida, no costuma dar certo, pois sabemos que a simples aquisio de tecnologia de hardware ou de software no , por si s, suficiente para resolver certos problemas que dependem fundamentalmente de um planejamento estratgico e ttico, obviamente necessrio a uma boa administrao. Antes de escolher qualquer produto, seja hardware ou software, temos de determinar quais so os sistemas de que realmente a empresa necessita e quais so as suas caractersticas. Alis, lembrando o filsofo Plato: Para a nave que no tem nenhum ponto de destino qualquer vento bom (Embora possa haver alguma gratificao no movimento). Em vista disso, a informatizao de uma organizao empresarial deve ter como preocupao o conhecimento de todas as necessidades nos nveis estratgicos, ttico e operacional, no apenas contempladas pelos sistemas atuais mas tambm nos sistemas futuros sejam eles automatizados ou no. Portanto, precisa-se de uma boa quantidade na especificao das necessidades, com descries voltadas para a misso e os objetivos da organizao. A tarefa de especificar os sistemas de informaes que compem uma empresa uma das mais complexas e, em ltima anlise, um processo de soluo de problemas. Para ser bem feita requer no apenas conhecimentos de computao mas boa dose de vrios conhecimentos conexos, por seu carter interdisciplinar. A literatura de informtica cita uma srie de problemas de desenvolvimento de sistemas que so a natureza tcnico-econmica, tais como: produtividade da equipe,

ANLISE DE SISTEMAS

correo da especificao, confiabilidade do sistema, manutenbilidade do cdigofonte, segurana dos dados, desempenho e portabilidade do sistema.

Evidentemente. estes so problemas reais e importantes, que requerem um ateno especial. A soluo para estes problemas est na adoo de um tratamento sistemtico que viabilize, seno a sua eliminao, pelo menos a sua minimizao. As metodologias de desenvolvimento de sistema com as que fazem uso das tcnicas aqui apresentadas so um grande passo para resolver estes problemas, como poder ser como alguns desejvel para os analistas de sistemas e a questo do aprendizado e da comunicao. Desde os primrdios da informtica, a instalao dos usurios com o atendimento de suas necessidades de sistemas de informao causa de transtornos para os profissionais da rea. Vrios autores internacionais

documentaram este fenmeno, valendo citar, por exemplo, o relatrio produzido por McKinsey, em 1968, e mencionado por B.Langefors e B.Sudgren [ref.19], onde j se afirma que os dois teros das empresas ali estudadas estavam desapontadas com o atendimento recebido em sistemas de informao que faziam uso de computadores. Ainda hoje, o quadro no muito diferente. H evidncias e agrupamento tericos de que inadequao dos sistemas comum, que os profissionais de informtica tendem, durante a fase de desenvolvimento dos sistemas, a dar maior ateno aos aspectos relativos eficcia ou adequao dos sistemas s necessidades dos usurios. Este tema costumava ser relegado a um plano inferior e, infelizmente, essa ainda tem sido a regra em algumas situaes, hoje em dia, Muitas vezes, encontramos solues brilhantes do ponto de vista do desempenho da mquina, mas que no resolvem o problema do usurio. A conduta a ser adotada durante o desenvolvimento de sistemas deve ser tal que conduza construo de sistemas efetivos, isto , sistemas que no sejam apenas eficientes, mas tambm eficazes; que faam exatamente o que til e necessrio para os usurios particularmente e para a empresa de modo global. Ou seja, que no se d nfase apenas s preocupaes com o custo, mas que, sobretudo, atente-se para aderncia do sistema s necessidades do usurio, parmetro que serve para exprimir seu valor ou utilidade. Podemos dizer que entre as razes pelas quais baixo o grau de satisfao dos usurios com os seus

ANLISE DE SISTEMAS

sistemas automatizados sobressai inadequao da abordagem utilizada para a fase de desenvolvimento para os usurios. Entre as principais deficincias encontradas na maioria das abordagens utilizadas no desenvolvimento de sistemas est o fato de elas enforcarem apenas aspectos tcnico-econmicos em problemas que, normalmente, tm forte

componente psicossocial. Este , com frequncia e indevidamente, negligenciado. Um claro exemplo das dificuldades enfrentadas pela tentativa de utilizao de enfoque apenas tcnico-econmico est na proposta do uso de banco de dados como fator de integrao de empresa. Tal proposta, embora muito atraente do ponto de vista dos tcnicos-econmico de difcil implementao pelo menos quando se quer o preconizado na teoria. Note que estamos nos referindo a banco de dados como ponto-chave da integrao dos sistemas, desde o seu nvel de especificao conceptual, e no apenas como soluo de problemas de armazenamento de dados. Isto acontece justamente porque um dos famosos donos do dado-, o que, sem dvida, no pode ser resolvido sem uma anlise do aspecto social da organizao. Dados gerncias ou operacionais, quando representando informaes importantes, so fontes de disputa de poder. Em razo desta constatao, apenas um especialista em computadores. A partir do advento dos microcomputadores, a tecnologia de hardware e de software evoluiu rapidamente, e hoje so oferecidas ao prprio usurio enormes facilidades para o uso desses recursos. Em auxlio aos analistas, o avano tecnolgico trouxe, entre outras facilidades, o surgimento dos software do tipo CASE (Computer Aided Software Engineering) para apoio ao desenvolvimento de sistemas. Estes Softwares podem proporcionar um significativo aumento de produtividade. Por tudo isto, fica cada vez mais evidente a necessidade de o analista ter um perfil mais voltado para especificao dos requisitos do sistema e dos negcios de empresa do que apenas para o conhecimento da programao e operao de mquinas.

ANLISE DE SISTEMAS

1.3 Sistemas de Informao nas Organizaes.

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

Figura 1: Nveis dos sistemas de informao dentro de uma organizao (LAUDON, 2001, p.9).

ANLISE DE SISTEMAS

Cada uma dessas perspectivas suportada por uma maneira de expressar a realidade registrada por meio de um modelo que a descreve, segundo uma forma de representao (POMPILHO, 2002). Assim, considerando que uma organizao empresarial pode ser entendida como sendo um sistema, ele pode ser bem compreendida se apresentarmos trs modelos que, conceitualmente, a representam, a partir de trs perspectivas que se complementam: Um modelo funcional, que apresenta uma viso estruturada das funes ou dos processos que compem a organizao. Um modelo de dados, que apresenta uma viso dos dados que sero armazenados para serem usados pela organizao. Um modelo de controle, representando as transformaes de controle e uma viso do comportamento da organizao em relao aos seus diferentes estados vlidos, cada um dos quais sendo caracterizado por uma determinada resposta fornecida quando a organizao estiver sujeita a um certo conjunto de estmulos.

1.1 Etapas desenvolvimento software

Um completo entendimento dos requisitos do software essencial para o sucesso de um esforo de desenvolvimento de software. A atividade de anlise e especificao de requisitos um processo de descoberta, refinamento, modelagem e especificao. O escopo do software definido no planejamento do projeto refinado em detalhe, as funes e o desempenho do software so especificados, as interfaces com outros sistemas so indicadas e restries que o software deve atender so estabelecidas. Modelos dos dados requeridos, do controle e do comportamento operacional so construdos. Finalmente, critrios para a avaliao da qualidade em atividades subsequentes so estabelecidos (FALBO, 2002).

Desenvolver software a atividade, de longo prazo, de criar um ou mais programas de computador, um sistema, de forma a atender necessidades especficas de um cliente ou grupo de clientes.

ANLISE DE SISTEMAS

No desenvolvimento de software realizamos as atividades de descoberta das necessidades e de criao do produto de software propriamente dito. Podemos dividir as atividades do processo de desenvolvimento em alguns grandes grupos: Atividades de Anlise, cuja finalidade descobrir o que deve ser feito; Atividades de Projeto, cuja finalidade descobrir como o software deve ser feito; Atividades de Implementao, cuja finalidade produzir o produto de software de acordo com as especificaes produzidas nas fases anteriores; Atividades de Controle de Qualidade, onde se incluem todas as atividades com objetivo de garantir a qualidade do produto, como testes e verificaes (Xexo,2007).

1.1 O Perfil do Analista de Sistemas

Ponderando o que dissemos at aqui, podemos concluir que, para ter boa probabilidade de sucesso o analista de sistemas deve possuir uma formao que vai alm das disciplinas voltadas para o conhecimento de computadores. Em nossa opinio, o seguinte conjunto de habilidade seria mais adequado para o bom desempenho na atividade de anlise de sistemas de informao administrativos: Comunicao: entendida como capacidade para ouvir, redigir e expor ideias com clareza e preciso, aprender e expressar o contedo do aprendizado com facilidade.

Capacidade de anlise: entendida como aptido para realizar operaes mentais com abstraes sobre o recorte da realidade em estudo. Possuir uma viso sistemtica e critica do contexto em anlise, alm de habilidade para distinguir e conceituar categorias de significados de noes concretas e abstratas associadas aos negcios da empresa.

ANLISE DE SISTEMAS

Conhecimento da rea usuria: entendido, principalmente, como aquele tipo de conhecimento que no pode ser obtido atravs de treinamento. mas adquirido por meio de experincia pessoal ao longo da vivncia com operaes da empresa.

Capacidade de negociao: entendida como habilidade em obter resultado desejado, ainda que em condies adversas, e capacidade de administrar conflitos de interesses interpessoais que surjam durante o trabalho em grupo, tornando exeqvel o concurso de vontade em cooperao.

Administrao de projetos: entendido como noes sobre alocao de tempo e recursos humanos, financeiros e materiais necessrios a projetos, nos quais participam pessoas de formaes diferentes, num empreendimento de caracterstica interdisciplinar, procurando sempre a efetividade, garantindo no s a eficcia como tambm a eficcia do processo de obteno dos resultados a serem alcanados.

Conhecimento Tcnico: entendido como capacidade de especificar sistemas de informao, principalmente nas suas fases de nvel de abstrao mais alto, utilizando ferramentas de modelagem, especialmente as adotadas pela tcnica de anlise essencial. Pode ser til, ainda, o conhecimento das estruturas lgicas do Sistema Gerenciador de Banco de Dados utilizados pela empresa. Os requisitos acima colocados constituem o perfil considerado por ns como ideal. Reconhecemos, todavia, a dificuldade de se terem disposio profissionais com essa capacitao. Para iniciar-se na atividade de anlise de sistemas, no condio indispensvel a proficincia em todas as habilidades mencionadas. s funes de analista, projetista e programador so, s vezes, confundidas. Para esclarecer este ponto, podemos dizer que, a rigor, o papel do analista de sistemas especificar quais so os requisitos do sistema do ponto de vista eficcia, ou seja, garantir que o sistema alcance os objetivos globais da empresa. Trata-se de certificar-se de que o sistema far o que precisa ser feito, far o que certo ser

ANLISE DE SISTEMAS

feito, independentemente da instrumentao que ser usada para chegar a esse objetivo. Por sua vez, o projetista tem um papel voltado para eficincia, isto , voltando para a obteno do melhor desempenho individual dos componentes do sistema. Por fim, o papel do programador construir (implementar) o sistema de acordo com as especificaes feitas pelo projetista.

1.2 O Aprendizado e a Comunicao

Para bem realizar a especificao de um sistema de informao, o primeiro passo reconhecer que atividade de desenvolvimento de sistemas , em essncia, um processo de soluo de problemas. E, como tal, esse processo compem-se em de uma fase de aprendizado (entendimento dos requisitos do sistemas) e outra de comunicao ((apresentao, da soluo encontrada para aprovao dos usurios). Ambas as fases devem ser executadas, de modo interativo, por refinamentos sucessivos, para se obter, por fim, o melhor resultado.

Normalmente, quando um analista inicia o desenvolvimento de um sistema, ele sabe pouco ou quase nada sobre o sistema a ser desenvolvido. Portanto, o desenvolvimento comea com uma fase de aprendizado. A obteno dos requisitos necessrios ao sistema torna-se bastante dificultada, pois o usurio expem o seu problema em linguagem natural , podendo ainda no ser capaz de expressar adequadamente as suas necessidades. Isto pode resultar em problemas de consistncia ou m interpretao, o que, sem duvida, ir acarretar erros cuja a conseqncia poder ser muito cara. Por tudo isto, trata-se de uma tarefa bastante delicada. Reconhecidamente, a fase do aprendizado de grande complexidade, e vrios so as teorias sobre os mecanismos pelos quais ela se processa. Entre essas teorias, podemos exemplificar com contribuio de C. Manguerez e que citada em trabalho de J. Bordenave[ref.42]. Manguerez dividiu a fase de aprendizado em trs grandes etapas , denominada sncrise, anlise e sntese.

Na primeira etapa (sncrise), partimos da observao da realidade, tentando obter uma viso global do assunto em estudo. Isto, na verdade, buscado atravs de um processo no-estruturado e tem as caractersticas de uma coleta de

ANLISE DE SISTEMAS

conhecimentos, que sero reunidos no tema abordado. , a rigor , um processo informal , atravs do qual tentamos juntar todos os fatos relevante a respeito do problema em questo e descobrir os relacionamentos entre estes fatos. Geralmente, o analista, nesta fase, de posse de todo o conhecimento coletado, tem dificuldade de separar o que realmente relevante para o sistema . Na segunda etapa(anlise), j partimos da viso global , obtida na fase anterior. Nesta hora, o processo de aprendizagem passa pela construo de uma espcie de maquete, o que consiste em identificar as variveis ou pontos-chave do problema para construo de modelo simplificado com sua estrutura, com seus elementos e relaes, possibilitando, destaque, que ai se faa , tendo como suporte um modelo do problema. Ao final desta fase , o analista j tem uma idia do tudo e de suas partes . A ltima etapa ser, ento, aquela em que se iro propor hiptese de soluo a serem adotadas. a etapa chamada sntese; ao final, tem - se idia de todo o sistema, quais as suas partes e qual a soluo proposta para o problema. Cabe assinalar que, diferentemente de algumas reas de cincia exatas, no estamos tratando de um problema que tenha uma nica soluo correta, mas buscando uma que seja aceitvel entre as solues possveis. Como se pode observar, bastante complexo o processo de aprendizado. Fica fcil entender porque se costuma errar tanto na hora de se prever um prazo para o desenvolvimento de um sistema, especialmente o prazo para as primeiras fases de especificao. muito difcil prever o tempo que algum vai levar para compreender, com exatido, todos os requisitos de um sistema. alm disso, o tempo pare se aprender algum assunto varia muito de pessoa para pessoa. A capacidade de aprender com eficincia tambm, em nossa opinio, uma habilidade considerar da importante para os profissionais de desenvolvimento de sistemas. A compreenso do domnio do problema a ser resolvido realmente um ponto crucial da anlise de sistemas se compreendermos bem um problema, j temos um grande avano para a soluo . Uma vez terminada a fase de aprendizado, entramos na fase de comunicao com o usurio. Esta fase tambm tem fatores que dificultam. Os principais gargalos num processo de comunicao, segundo J. Bordenave[ref.42], ocorreram por conta de problemas das seguintes naturezas:

ANLISE DE SISTEMAS

Problemas psicolgicos: relacionados com percepo, ateno, motivao, atitudes, memria, hbitos de pensamento.

Problemas semiolgicos: relacionados com o emprego de signos e cdigos para comunicar : palavras, gestos , tom de voz, coisas escritas etc.

Problemas semnticos: relacionados com os significados das palavras, dos objetos e das pessoas, assim como com sua interpretao.

Problemas sintticos: relacionados com a estrutura ou organizao dos contedos e dos signos. Problemas cibernticos: relacionados com retroinformao e dialogo, com a quantidade de idias transmitidas por diversos canais e com capacidade destes para levarem sinais. Esta relao de problemas foi aqui colocada apenas para dar idia da complexidade do problema da comunicao bem como enumerar as cincias que contm estudos que tangenciam este assunto. A literatura especfica de desenvolvimento de sistemas at que tem reconhecido o problema da comunicao. Nesta literatura, tm sido apresentadas vrias tcnicas, todas visando minimizar as dificuldades da comunicao entre os desenvolvedores de sistemas e os usurios. Sabemos que o sucesso de um sistema depender fundamentalmente de sua aceitao por parte do usurio. Para tanto, devemos apresentar a soluo proposta a todos os que, de alguma forma, puderem contribuir para a descoberta da soluo mais adequada ao ambiente no qual o sistema ser implantado. Isto implica necessariamente de uma linguagem (forma de expresso) comum a ser usada por profissionais de formaes diferentes, num empreendimento de caracterstica interdisciplinar.

ANLISE DE SISTEMAS

CAPITULO 2

A MODELAGEM DE SISTEMAS

Desde que foi percebido pelos profissionais de informtica que grande parte das deficincias nas especificaes de sistemas era devida problemtica de comunicao, um esforo considervel tem sido realizado no sentido de se superar este problema. Para tanto, construram-se vrias propostas metodolgicas, que enfatizam a necessidade de uma linguagem a ser empregada pelos analistas de sistemas, linguagem essa que pudesse ser compreendida tambm pelos usurios. Dentro desta linha, desenvolveram - se linguagens que passaram a incluir os recursos necessrios para definir as necessidades do usurio, independentemente de qualquer restrio relativa implementao. Ou seja, linguagens de especificao que, por um lado, contornem os hermetismos tecnicistas, de modo a se tornarem mais inteligveis ao usurio no-tcnico e por outro lado, permaneam suficientemente precisas, para permitir que se produza uma especificao que seja base para um subsequente projeto operacional dos sistemas de informao necessrios. Este tipo de linguagem deve possuir recursos que permitam produzir uma especificao que possa ser apresentada ao usurio e com ele discutia . Um erro muito comum no passado, entre os profissionais de informtica, era a crena de que todas as necessidades de informaes seriam conhecidas apriori pelos usurios. A prtica mostrou que isto no era verdade, o que faz com que est restrio deva ser considerado com devido cuidado na soluo do problema da linguagem. O fato do usurio no saber a priori to dos os requisitos do sistema ser construdo no uma caracterstica exclusiva de problemas da rea de desenvolvimento de sistemas. Na verdade, isto comum em qualquer ramo de atividades onde haja complexidade que exija especificao, na qual seja necessrio mostrar claramente o que se quer construir, para que todos aqueles afetados pelo produto final do trabalho possam certificar-se de que se est no caminho certo.

Duas abordagens complementares so bastante utilizadas sempre que nos deparamos com problemas muito complexos. A primeira tentar decompor o

ANLISE DE SISTEMAS

problema em subproblemas que possuam menor complexidade que o problema original, no se esquecendo de utilizar um mtodo de decomposio que nos garanta a possibilidade de, a partir dos subprogramas, reconstituir o todo. evidente que se devem fazer parte integrante do mtodo o reconhecimento e a descrio dos elementos de ligao entre os subprogramas constituintes do todo. Assim, no caso do projeto de uma casa, poderamos dizer que ela se compem de uma sala, trs quartos , dois banheiros , etc. A outra abordagem consiste em decompor o problema no por partes, como um mosaico, mais por pontos de vista diferentes. Nesta abordagem diramos que a casa compor-se-ia de planta de instalao eltrica, uma planta de instalao hidrulica etc..., onde todas as plantas referem-se casa e no apenas uma das partes . Novamente, a integrao entre os componentes do problema original se faz necessria, visto que as plantas componentes da casa no podem ser tratadas isoladamente. Por exemplo, o que aconteceria se, por falta de integrao, a planta de instalao eltrica determinasse a passagem de um cabo eltrica justamente pelo mesmo local onde a planta de instalao hidrulica especificasse a passagem de um cano dgua? O exemplo apresentando apenas tem por objetivo ilustrar algumas das dificuldades enfrentadas na soluo de problemas complexos, e chamamos a ateno do leitor para a utilidade de uma planta para descrever o projeto mencionado, a qual possibilita a resoluo de algumas questes de natureza tcnica, antes do incio da construo, o que se traduz em economia no custo total. Os requisitos do futuro usurio da casa, quanto s suas necessidades, podero ser discutidos fazendo-se uso da planta, o que ajuda a garantir a adequao do projeto s necessidades do usurio. Desta forma, a planta funciona como um modelo reduzido e mais barato da casa e serve ainda como mecanismo (leia-se, linguagem) de comunicao entre tcnicos e entre usurios e tcnicos, pois, em problemas complexos, a soluo ideal s ser alcanada se os tcnicos tiverem forte interao com os usurios e, para tanto, um modelo do empreendimento dever ser produzido. Do que foi expresso fica absolutamente claro que, analogamente ao exemplo da casa, antes de se construir um sistema de informaes, deve-se elaborar um modelo que seja capaz de expressar com a mxima fidelidade possvel o conhecimento que se tem do ambiente onde o sistema ser implantado, de modo a satisfazer a todos os requisitos necessrios. Se, por um lado, o custo de um sistema

ANLISE DE SISTEMAS

funo do desempenho de seus componentes, por outro, o valor deste mesmo sistema funo da utilidade que ele tenha para seus usurios. A boa tcnica de anlise dos sistemas de uma empresa preconiza uma boa interao, vale dizer, comunicao - entre os usurios e os tcnicos de informtica.

O principal produto da anlise so modelos que daro origem aos sistemas. Entre as utilidades de um modelo, T.De Marco [ref.10] destaca as seguintes:

Estabelecer uma viso comun. (entre usurios e analista) do ambiente antes da automao. Servir como suporte para negociao e especificao de requisitos e possibilidades futuras para o sistema. Representar, avaliar e refinar conceitos do projeto. Escalonar a informatizao em frases, com produtos bem - definidos e dependncia mnima entre as fases. Tratar a complexidade do problema por nveis de abstrao, comeando pela viso mais abstrata e descendo a vises progressivamente mais detalhadas. Promover indicaes quantitativas do escopo e da complexidade do problema Prover facilidades para gerao de testes de aceitao.

Alm disso, sabe-se que, na especificao dos sistemas de informao, devem ser consideradas diversas perspectivas do problema como nas diversas plantas do exemplo da construo da casa. As modernas abordagens enfatizam a perspectiva dos dados, no ignorando, entretanto, a importncia da perspectiva das funes bem como a dos controles do sistema.

Cada uma dessas perspectivas suportada por uma maneira de expressar a realidade registrada por meio de um modelo que a descreve, segundo uma forma de representao.

ANLISE DE SISTEMAS

2.1 Tcnicas de Levantamento requisitos de software

O incio para toda a atividade de desenvolvimento de software o levantamento de requisitos, sendo esta atividade repetida em todas as demais etapas da engenharia de requisitos. Anlise e levantamento de requisitos so de extrema importncia serve para um bom Documento de Requisitos de Software possvel visualizar e interferir em um sistema sem causar problemas aplicao existente. Alm disso, o esforo gasto na localizao de qualquer tipo de modificao ou implementao se torna aceitvel (SOMMERVILLE, 2003).

Figura 2: disponvel em http://scott.yang.id.au/2003/08/software-development-life-cycle/

Sommerville (2003) prope um processo genrico de levantamento e anlise que contm as seguintes atividades: Compreenso do domnio: Os analistas devem desenvolver sua

compreenso do domnio da aplicao; Coleta de requisitos: o processo de interagir com os usurios do sistema para descobrir seus requisitos;

ANLISE DE SISTEMAS

Classificao: Essa atividade considera o conjunto no estruturado dos requisitos e os organiza em grupos coerentes; Resoluo de conflitos: Quando mltiplos usurios esto envolvidos, os requisitos apresentaro conflitos. Essa atividade tem por objetivo solucionar esses conflitos;

Definio das prioridades: Em qualquer conjunto de requisitos, alguns sero mais importantes do que outros. Esse estgio envolve interao com os usurios para a definio dos requisitos mais importantes;

Verificao de requisitos: Os requisitos so verificados para descobrir se esto completos e consistentes e se esto em concordncia com o que os clientes desejam do sistema. O levantamento e anlise de requisitos um processo iterativo, com uma

contnua validao de uma atividade para outra, conforme exemplificado pela Figura 2:

Figura 2: Processo de levantamento e anlise de requisitos (SOMMERVILLE, 2003)

2.1 O Ciclo de Vida do Sistema

Um sistema pode ser entendido como um mecanismo composto por um conjunto de partes inter-relacionadas, onde cada parte est sempre relacionada a, pelo menos, uma das outras.

ANLISE DE SISTEMAS

Como toda linha de produo, o desenvolvimento de sistemas pode envolver diversas frases. Ao encadeamento das frases para a construo do sistema denominamos ciclo de vida de desenvolvimento de sistemas - H na literatura da rea diversos enfoques propostos para o ciclo de vida de um sistema. Entre estes, o enfoque em cascata e o da prototipao. Adotaremos para nossa explicao o primeiro destes. Simplificadamente, tomaremos como base um ciclo de vida de desenvolvimento que ter as seguintes frases, na ordem apresentada a seguir:

ANLISE PROJETO IMPLEMENTAO

Por anlise de sistemas entenderemos a fase do desenvolvimento em que se determinaro quais os requisitos dos sistemas, o que o sistema deve fazer, em termos essenciais. A fase de anlise tem por objetivo interpretar e definir uma estrutura para um problema ainda no estruturado. Diz respeito eficcia do sistema, ainda sem preocupaes de performance. Por Projeto de Sistemas entenderemos a fase do desenvolvimento em que se determinar como o sistema funcionar para atender aos requisitos especificados na fase de anlise. Diz respeito eficincia do sistema, j com preocupaes de performance. O objetivo desta fase modelar o sistema de modo a implementar a soluo idealizada na fase de anlise, mas de acordo com os recursos tecnolgicos existentes na empresa. Por implementao de Sistemas entenderemos a fase do desenvolvimento em que ser efetuada a construo do sistema de acordo com o modelo de funcionamento especificado na fase de projeto. Faz uso dos recursos tecnolgicos existentes na empresa para atividades como a programao de computadores. O ciclo de vida ilustrado acima um ciclo compulsrio. Todo O ciclo de desenvolvimento de sistemas ter pelo menos estas fases. H quem inclua no ciclo de desenvolvimento uma fase de estudo, anterior fase de anlise, e duas outras fases aps a implementao: so elas a simulao e a implantao do sistema. Neste caso, o ciclo de desenvolvimento ficaria assim:

ANLISE DE SISTEMAS

ESTUDO ANLISE PROJETO IMPLEMENTAO SIMULAO IMPLANTAO

Uma vez implantando o sistema, duas outras fases surgem: operao e manuteno. Ao ciclo de atividades que inclui, alm das fases de desenvolvimento, a operao e a manuteno de um sistema que podemos denominar ciclo de vida do sistema, e faremos a seguinte figura:

ESTUDO ANLISE PROJETO IMPLEMENTAO SIMULAO IMPLANTAO OPERAO MANUTENO

Podemos ento dizer que um sistema, uma vez implantado, entra em operaes e, at que seja desativado, poder sofrer manutenes, sejam elas corretivas por acrscimos de novos elementos. Vale ressaltar que o desenvolvimento de sistemas, na prtica, no ocorre de maneira to linear no tempo, como possa parecer pela figura do ciclo da vida. Na prtica, possvel acontecer uma certa superposio de fases, principalmente entre as consecutivas, ainda que tal superposio deva ser reduzida. Por exemplo: pode ser que j se esteja na fase

ANLISE DE SISTEMAS

de projeto e seja necessrio, por alguma contingncia, rever uma parte da fase de anlise.

2.2 Metodologias de Desenvolvimento de Sistemas Para haver sucesso no desenvolvimento de sistemas, torna-se necessria a utilizao de uma metologia de trabalho. Uma metodologia pode ser entendida como uma dissertao sobre a maneira de se utilizar um conjunto coerente e coordenado de mtodos para atingir um objetivo, de modo que se evite, tanto quanto possvel, a subjetividade na execuo do trabalho. Um mtodo pode ser entendido como um procedimento a ser adotado para se atingir um objetivo. Para tanto, o mtodo se vale de um conjunto de tcnicas. Uma tcnica pode ser entendida como sendo um modo apropriado de se investigar sistematicamente um determinado universo de interesse ou domnio de um problema. Para se expressar, uma tcnica faz uso de uma notao. Uma notao um conjunto de caracteres, smbolos e sinais formando um sistema a melhor maneira de se resolverem os problemas da atividade de desenvolvimento. Deve ser definido o ciclo de vida do sistema adotado, ou seja, quais as fases de trabalho a serem executadas. Uma boa metodologia deve tambm apresentar definio clara de quem faz o qu, quando, como, e at mesmo onde, para todos os que estejam envolvidos diretamente ou no com o desenvolvimento de sistemas. Deve definir tambm qual o papel dos tcnicos de informtica, o dos usurios e o da administrao da empresa no processo de desenvolvimento. Alm disso, deve instituir um conjunto de padres preestabelecidos, de modo a se evitar a subjetividade na abordagem, a fim de garantir a facilidade de integrao de sistemas de desenvolvidas por grupos de pessoas diferentes em pocas distintas. As tcnicas adotadas que devem ser estveis, e no os tcnicos. Deve, assim, evitar um problema muito comun. em algumas instalaes: o de tcnicos que se comportam como verdadeiros donos de determinados sistemas, pois s eles os conhecem bem e s eles so capazes de altera-los sem riscos, o que sem dvida indesejvel para a administrao da empresa. Tudo isto permite uma maior mobilidade na alocao dos recursoshumanos, materiais, financeiros e tempo- envolvidos na atividade e d condies direo do projeto de melhor controlar o trabalho em curso. Em face do que j foi dito, uma metodologia deve definir quais as fases de trabalho previstas no desenvolvimento de sistemas. Para cada fase, quais as tcnicas adotadas. So exemplos de tcnicas: Anlise Estruturada Anlise Essencial e Projeto Estruturado. A metodologia deve ainda, para cada tcnica adotada, definir quais as ferramentas utilizadas. So exemplos de ferramentas:

ANLISE DE SISTEMAS

Diagrama de Fluxo de Dados Diagrama de Entidade-Relacionamento Diagrama de Transio de Estados.

Cada ferramenta ir produzir um tipo de modelo. So exemplos de modelos: Modelo Funcional Modelo Conceitual de Dados Modelo de Controle. A metodologia deve estabelecer ainda quais os pontos de controle e padres de qualidade, alm da responsabilidade do pessoal envolvido nos controles e mtricas. Tais tcnicas fazem uso de ferramentas que do origem a modelos que representam as principais perspectivas de um sistema. Entre estas, principalmente nos ambientes de sistemas de informao administrativos, as ferramentas de modelagem como as que so usadas em tcnicas do tipo de Anlise Estruturada e Projeto Estruturado tornaram-se bastante conhecidas. O quadro a seguir, apresentado em IBPI [ref.43], mostra as principais ferramentas de modelagem utilizadas na fase de anlise de sistemas por trs tcnicas:

Anlise de Sistemas TCNICAS

ANLISE TRADICIONAL

ABORDAGENS
*FUNCIONAL

FERRAMENTAS
*TEXTOS *FLUXOGRAMAS *DIAGRAMA DE FLUXO DE DADOS *DIAGRAMA DE ESTRUTURA DE DADOS *MINIESPECIFICAES *NORMALIZAO *DICIONRIO DE DADOS

ANLISE ESTRUTURADA

*FUNCIONAL *DADOS

ANLISE ESSENCIAL

*FUNCIONAL *DADOS *CONTROLE

*TABELA DE EVENTOS *DIAGRAMA DE FLUXO DE DADOS *DIAGRAMA DE ENTIDADE-RELACIONAMENTO *DIAGRAMA DE TRANSIO DE ESTADOS *DIAGRAMA DE ESTRUTURA DE DADOS *NORMALIZAO *MINIESPECIFICAES *DICIONRIO DE DADOS

ANLISE DE SISTEMAS

O quadro anterior mostra tambm uma espcie de evoluo histrica das tcnicas de anlise. O que estamos denominando por Anlise Tradicional a tcnica que costumava ser usada para a fase de anlise, antes do surgimento da Anlise Estruturada. Basicamente, produzia um documento que, alm de texto, usava, de vez em quando, uma ferramenta bastante popular denominada fluxograma. A abordagem usada era quase que exclusivamente voltada para a perspectiva das funes do sistema. Com o advento da Anlise Estruturada, como se pode notar, passou-se a fazer um uso maior das ferramentas de modelagem, e a abordagem passou a contemplar tambm a perspectiva dos dados, alm da perspectiva das funes. Finalmente, a Anlise Essencial faz amplo uso das ferramentas de modelagem e opta por uma abordagem que contempla tambm a perspectiva dos controles, alm da perspectiva das funes e dos dados. Assim, medida que foram evoluindo as tcnicas de anlise, maior quantidade de ferramentas de modelagem passou a ser utilizada. Embora as ferramentas de modelagem sejam extremamente importantes, por razes diversas, na prtica, algumas empresas ainda relutam na sua adoo. A titulo de exemplo, vale mencionar que uma das queixas muito comuns entre os que relutam em usar ferramentas de modelagem refere-se ao fator tempo. que, em suas avaliaes, acreditam que, com a adoo destas tcnicas, o desenvolvimento dos sistemas estende-se muito longamente. Segundo esses queixosos, fazendo-se uso de mtodos mais tradicionais, chegar-se-ia ao mesmo objetivo em tempo menor. Nossa opinio a de que esto equivocados. A experincia nos tem mostrado, at agora, que, sempre que h suspeio de que o desenvolvimento de um sistema foi lento por ter havido o uso de ferramentas de modelagem, estamos diante de trs hipteses em que pelo menos uma verdadeira. So elas:

1) O prazo para o desenvolvimento foi realmente mal estimado, sendo que, neste caso, mesmo com mtodos tradicionais, no se teria acertado na previso do tempo; 2) Os profissionais que atuam no desenvolvimento do sistema ainda no dominavam a utilizao das ferramentas adotadas pela tcnica. Neste caso, a suposta lentido se deve falta de proficincia dos tcnicos no uso das ferramentas; 3) O diagnstico que aponta perda de tempo distoro de parmetro. Isto porque, com a utilizao de ferramentas que permitem um mecanismo rigoroso de verificao, muitas situaes especficas de nveis abstracionais mais altos-como sejam, as fases conceitual e lgica do sistema - foram corretamente analisadas. Ora, no se pode comparar o tempo que tal anlise demanda com aquele que se consumiria nas anlises realizadas pelos mtodos tradicionais, porquanto ai no teramos contemplado uma srie de situaes que as ferramentas de modelagem apontam. Anlises mais pobres podem at economizar tempo, mas no cobrem a riqueza de situaes que se devem identificar em anlises extremamente mais abrangentes e aderentes ao mundo real.

ANLISE DE SISTEMAS

A chave do problemas est, principalmente, no item (3). Via de regra, a utilizao de mtodos tradicionais deixa escapar de sua anlise situaes que, pouco tempo aps a implantao, fazem com que o sistema comece a sofrer manuteno. Esta escolha pode ser enquadrada na categoria de solues de curto prazo que acarretam problemas de longo prazo. Uma concluso importante, de tudo quanto temos observado, diz que um sistema menos sujeito a necessidade de manuteno quando mais altos, se fez uso de mtodos mais formais (menos empricos), permitindo identificar, antecipadamente, problemas que s seriam percebidos nas fases finais do desenvolvimento ou aps a implantao do sistema. Outros problemas, tambm citados na utilizao de ferramentas de modelagem, so o volume de documentao produzida e a dificuldade de mant-la atualizada. Quanto ao primeiro problema, podemos afirmar que, para o mesmo volume de documentao, a utilizao de uma ferramenta de modelagem registra uma quantidade de conhecimento (informao) maior do que a registrada por mtodos tradicionais. Isto se deve, entre outros fatores, ao fato de as tcnicas de modelagem fazerem uso de linguagens grficas (bidimensionais), enquanto que as tcnicas tradicionais usam a linguagem textual (que linear). Alm disso, caracterstica da prpria ferramenta de modelagem buscar a no-redundncia de informaes, o que, normalmente, no ocorre nos mtodos tradicionais. Quanto dificuldade de se manter a documentao atualizada, cabe dizer que, com qualquer tcnica que se use, isto sempre foi difcil. Todavia, com o surgimento dos software para apoio ao desenvolvimento de sistemas (do tipo CASE), esse problema foi bastante minorado. No que diz respeito ao desenvolvimento de sistemas, vimos que a proposta de se estabelecerem modelos para cada um dos aspectos ou perspectivas do sistema pode ser de extrema utilidade. A dificuldade neste campo reside em se decidir quais os aspectos do sistema a serem apresentados em uma especificao. Dissemos que a maioria dos sistemas pode ter sua especificao bem compreendida se apresentarmos trs modelos que conceitualmente representam o sistema a partir de trs perspectivas que se completam: modelo funcional, modelo de dados, e modelo controle. Os sistemas podem, ainda ser classificados de acordo com a importncia relativa de cada um dos trs modelos para sua especificao. Desta forma, poderamos classificar os sistemas em centrados nas funes, centrados nos dados e centrados nos controles. verdade que haveria uma srie de sistemas hbridos, os quais no seriam to claramente definidos assim. Para exemplificar, chamaremos de sistema centrado nos dados aqueles cuja precaues(na especificao e implementao) deve ser maior em relao aos dados e seus inter-relacionamento do que em relao s operaes. As aplicaes de robtica so um exemplo de sistemas mis centrado nos controles e processos, enquanto que as aplicaes de consulta generalizada so o extremo de sistemas centrados nos dados. O principal objeto de nosso estudo sero os sistemas de informao administrativos cujas principais perspectivas so a das funes e dos dados, especialmente esta ltima.

ANLISE DE SISTEMAS

Curiosamente, apesar de ser facilmente compreensvel esta classificao, a literatura da rea de desenvolvimento de sistemas, durante muito tempo, no apresentou, a nosso juzo, tcnicas que fizessem uso de ferramentas para tratamento de processos e dados de forma balanceada. Haja vista que o livro de Anlise Estruturada de T. DE MARCO [ref.9], em sua edio de lngua inglesa, contm 27 captulos, dos quais apenas um capitulo se refere estruturao lgica dos dados, assim mesmo sem maior preocupao em estabelecer uma representao conceitual dos dados. Neste particular, um trabalho um pouco mais abrangente apresentado por C. Gane e T. Sarson [[ref. 11], embora a nfase de seu livro seja ainda, claramente sobre os processos. Nos livros de Anlise Essencial, conforme apresentada por S.McMenamim e J. Palmer [ref.11], embora a nfase de seu livro seja, ainda claramente sobre os processos. Nos livros de Anlise Essencial, conforme apresentada por S. McMenamim e J. Palmer [ref. 4] e por E. Yourdon [ref.1], j h um reconhecimento maior da necessidade de uma abordagem que contemple de maneira balanceada estes dois modelos, embora, em nossa opinio, esses excelentes livros ainda apresentam a integrao de dados e funes de uma maneira um tanto tmida e , ousaramos dizer, at um pouco nebulosa. Como elaborar os dois modelos - de dados e de funo - de maneira perfeitamente integrada, de modo a permitir a derivao de qualquer dos modelos, a partir do outro , um dos principais objetivos deste nosso trabalho. A tcnica da Analise Essencial tem como uma de suas fundamentais usar-se os eventos como base para o particionamento dos sistemas. Assim sendo, em nosso trabalho, mostraremos como efetuar a decomposio tanto das funes como dos dados do sistema a partir dos eventos, garantindo, dessa forma, que o modelo de dados e o de funes possam ser construdos simultaneamente, estando assim integrados, por construo. Podemos afirmar, sem receio de errar, que ao adotado a tcnica da Anlise Essencial, como apresentada neste livro, o leitor poder produzir sistemas muito mais efetivos, e em tempo hbil do que se usar qualquer outra tcnica tradicional. Quando se tem o mtodo adequado para resolver um problema, facilmente se encontra a soluo. A tcnica da Anlise Essencial pode ser encarada como uma bem-sucedida evoluo da Anlise Estruturada. denominada por E.Yourdon [ref.1] de Anlise Estruturada Moderna. Para compreender os conceitos da Anlise Essencial, necessrio antes conhecer como se elabora a Modelagem Funcional e a Modelagem de Dados Em funo do que acaba de ser exposto, nosso livro seque discorrendo inicialmente sobre os fundamentos da Modelagem Funcional. Em continuidade mostramos os fundamentos da Modelagem de Dados. Finalmente, na quarta parte, com o leitor j tendo o embasamento que se faz necessrio, estudaremos a tcnica da Anlise Essencial. Nesta parte, sero apresentadas as ferramentas para a modelagem de controle.

ANLISE DE SISTEMAS

PARTE-II

A Modelagem Funcional

Captulo 3 Ferramentas de modelagem

Como parte dos requisitos do sistema e da atividade de projetos, o sistema precisa ser modelado como um conjunto de componentes e de relaes entre esses componentes. Frequentemente a modelagem de software usa algum tipo de notao grfica e so apoiados pelo uso de ferramentas case. Modelagem de softwares normalmente implica a construo de modelos grficos que simbolizam os artefatos de software utilizados e seus interrelacionamentos. Uma forma comum de modelagem de programas procedurais (no orientados a objeto) atravs de fluxogramas, enquanto que a modelagem de programas orientados a objeto normalmente usam a linguagem grfica UML (Linguagem de Modelagem Unificada) a qual os fabricantes lderes de modelagem esto dando suporte. Na criao de sistemas com qualidade necessrio a utilizao de uma boa metodologia para a modelagem tanto do software, como de seu banco de dados. Algumas ferramentas j auxiliam na automao da escrita de cdigo e na implementao da estrutura dos bancos de dados. Os banco de dados so modelados atravs do modelo de Entidade Relacionamento. O principal objetivo facilitar o projeto de banco de dados, possibilitando especificar a estrutura geral do banco de dados. Funciona para modelos conceituais relacionais, objeto-relacionais ou orientado a objetos. As ferramentas de modelagem, surgiram para facilitar a criao dos modelos, as mais avanadas permitem a gerao de uma parte do cdigo-fonte do software a partir do modelo e at a gerao do banco de dados a partir do modelo de entidade relacionamento.

O diagrama de Fluxo de Dados(DFD)

Uma importante perspectiva a ser descrita a respeito de um sistema de informaes a de suas funes. Afinal de contas, todo sistema de informaes armazena e transforma dados de entrada em dados de sada. Estas transformaes so realizadas pelas suas funes.

ANLISE DE SISTEMAS

Todo modelo funcional de um sistema pode ser visto como sendo formado por uma representao grfica-uma rede de funes ou processos interligados-, acompanhada de uma descrio de cada funo e das suas interfaces. A representao grfica do modelo funcional costuma ser expressa atravs de um diagrama denominado diagrama de fluxo de dados, abreviadamente, DFD. Um diagrama de fluxo de dados uma forma grfica de mostrar a interdependncia das funes que compem um sistema, apresentando fluxos de dados entre elas. Mostra ainda os arquivos lgicos de dados, que so denominados depsitos de dados, como veremos mais adiante, bem como as entidades externas, denominao dada tanto origem dos fluxos de dados que chegam ao sistema, como ao destino dos fluxos que delem partem. Portanto, precisamos definir cada componente do DFD. Comearemos, na seo seguinte, definindo o que vem a ser uma funo.

3.1 O Conceito de Funo

Idealmente, podemos definir uma funo de um sistema analogamente de caixa-preta encontrando na literatura de algumas modalidades de engenharia. Uma caixa-preta pode ser entendida como uma caixa onde, conforme M.Page -Jones [ref.8]:

.h ligaes de entrada e de sada da caixa; .conhecem-se os elementos de entrada da caixa .conhecem-se os elementos de sada da caixa; .sabe-se o que a caixa realiza (o que a caixa faz para que, a partir dos elementos de entrada, sejam produzidos os elementos de sada); .no se precisa conhecer como a caixa realiza suas operaes e nem em que ordem.

Desta forma, uma funo pode entendida como um componente de um sistema onde somente os dados de entrada e os dados de entrada e os dados de sada so conhecidos. No se conhece explicitamente nada a respeito do processo interno de transformao dos dados de sada. As funes representam as aes que o sistema executa. Ressalte-se que, em qualquer sistema de informaes, nem todas as funes so automatizadas; sempre teremos funes que sero executadas manualmente. Isto significa que devemos representar todas as funes, independentemente de maneira como sero executadas. Convm enfatizar que

ANLISE DE SISTEMAS

estamos falando de funes de transformao de dados. No texto deste livro, usaremos s vezes, a palavra processo como sinnimo de funo.

3.2- O Fluxo de Dados Imagine uma tarefa bem simples, como, por exemplo, o preenchimento manual de um formulrio denominado NOTA DE DBITO. Neste caso, podemos dizer que a funo a ser executada PREENCHER NOTA DE DBITO. Conforme dissemos, para que a funo seja executada, necessria que haja dados de entrada; no caso, um formulrio de nota de dbito em branco. A sada desta funo ser uma nota de dbito preenchida. O diagrama a seguir representa esta situao:

Nota de dbito em branco

Preencher nota de dbito

Nota de dbito preenchida

Na figura anterior, a funo est sendo representada por uma forma oval, com uma seta de entrada e uma de sada. As setas esto representando o que chamaremos de fluxo de dados de entrada e de sada. Esta denominao tem por objetivo dar a idia de dados em movimento. Fluxos de dados so condutos que levam informao de um ponto de sistema para outro; mostram como os dados fluem atravs do sistema, o caminho percorrido pelos dados no sistema para outro; mostram como os dados fluem atravs do sistema, o caminho percorrido pelos dados no sistema. e no o suporte material onde um fluxo de dados representa um conjunto de dados e no o suporte material onde identificamos o conjunto de dados. Trata-se de fluxo de dados e no de fluxo de material. Portanto, no devemos confundir a nota de dbito com o formulrio onde os dados so preenchidos. Quando estamos escrevendo no fluxo de dados Nota de dbito estamos nos referindo ao contedo do formulrio (os dados formulrio) e no ao formulrio em si. Se acrescentarmos ao nosso pequeno sistema a funo DIGITAR NOTA DE DBITO, teremos o seguinte diagrama:

Nota de dbito branco

Preencher ` nota de dbito preenchida

Nota de dbito

Digitar
dbito

Nota de digitada

em

nota de

dbito

ANLISE DE SISTEMAS

3.3-Os Depsitos de Dados

No DFD anterior, temos duas funes em sequncia, onde a sada da primeira funo a entrada da segunda. Desta forma a entrada da funo DIGITAR NOTA DE DBITO a sada da funo PREENCHER NOTA DE DBITO. Assim sendo, para que a funo DIGITAR NOTA DE DBITO seja executada antes dela.

Podemos ento perguntar: para que a 2 funo seja executada, necessrio que a 1 funo seja executada imediatamente antes? fcil responder que no, pois, na verdade, o que precisamos para executar DIGITAR NOTA DE DBITO do formulrio NOTA DE DBITO preenchido.

Evidentemente, podemos preencher um formulrio em um determinado momento, quard-lo e, num tempo posterior, digit-lo. Queremos representar dados que vo ficar armazenados como num arquivo.

Ao conjunto de dados armazenados denominaremos depsito de dados. Constituem a memria do sistema. Note que, em vez de representar um determinado conjunto de dados que estejam em movimento, o caso dos fluxos de dados, devemos criar uma maneira de representar dados em estado de repouso. Para tanto, usaremos a representao adiante.

n
nota de dbito

Preencher nota de dbito nota de dbito

preenchida

o t p nota de dbito a r preenchida e d e e n c d h i b d i a t o

em branco

digitar nota de dbito

Nota de dbito digitada

Uma das maneiras usadas para identificar num DFD os pontos de reteno de dados, locais onde os dados esto armazenados, ou seja, os depsitos de dados, atravs de duas barras paralelas, em posio vertical ou horizontal. Portanto, uma determinada funo (PREENCHER NOTA DE DBITO) produz como sada um determinado conjunto de dados. A seguir, uma outra funo (DIGITAR NOTA DE DBITO) obtm (l) como dados de entrada o contedo do depsito de dados nota de dbito preenchida e produz como sada um outro conjunto de dados (nota de dbito digitada), que conduzido pelo fluxo de dados nota de dbito digitada. Vale

ANLISE DE SISTEMAS

sublinhar que estamos nos referindo a depsitos de dados a no a arquivos fsicos. Estamos nos referindo s estruturas de dados lgicas e no aos meios fsicos (fichrios, arquivos magnticos etc.) que possam vir a ser usados na fase de implementao para suportlas. 3.4 As Entidades Externas At aqui, j vimos como representar uma funo, suas entradas e suas sadas, bem como dados que devam ser armazenados para posterior utilizao. Entretanto, todo sistema est inserindo em algum ambiente com o qual ele interage, de onde partem os fluxos de dados de entrada e para onde vo os fluxos de dados de sada do sistema. Mas o que se entende por ambiente? Um ambiente de um sistema pode ser entendido como o meio externo ou em torno do sistema. delimitado pelos elementos externos que exercem influncia sobre o comportamento do sistema. Se observarmos o pequeno sistema que descrevemos, podemos perguntar: *De onde vem o fluxo de dados notas de dbito? *Para onde vai o fluxo de dados nota de dbito digitada? De modo a responder s perguntas acima, precisamos representar os elementos externos, que enviam e recebem informaes do sistema. A esses elementos denominaremos terminais ou entidades externas. So as fontes ou destinos dos fluxos de dados que chegam e saem do sistema com o ambiente em que ele est inserido. Uma entidade externa pode ser, por exemplo: um rgo ou uma atividade de uma empresa ou entidade governamental, um outro sistema etc.

A ilustrao de tais elementos apresentada a seguir:

DEPARTAMENTO DEPARTAMENTO DE DE COBRANA COBRANA Nota de dbito em branco N o t p Digitar Nota de dbito a r nota de dbito nota de preenchida e preenchida dbito d e n e c h d i d b a i t o

Preencher nota de dbito

nota de dbito digitada SISTEMA DE COBRANA

ANLISE DE SISTEMAS

Na figura anterior, usamos uma das maneiras de representar as entidades externas. No caso, quadrilteros, normalmente, retngulos ou quadrados.

A seguir, apresentamos um DFD um pouco maior onde se podem ver todos os seus elementos componentes:

CLIENTE DIRETORIA LISTA DE COMPRAS Lista de demanda EMITIR LISTA DE DEMANDA Razo social RAZO
SOCIAL

Lista de compras

CADASTRAR LISTA DE COMPRAS Lista de compras

item de compra

Produto

PRODUTOS

Produto

CADASTRAR PRODUTOS

Lista de produtos Fornecedores CADASTRAR FORNECEDORES Pedido de Cadastramento Fornecedores

LISTA DE PRODUTOS

FORNECEDORES

FORNECEDOR

Atividade
Quais os elementos componentes de um DFD ? -funes ou processos; -fluxos de dados; -depsitos de dados; -entidades externas.

b) Um DFD apresenta componentes externos (terminais ou entidades externas) e componentes internos (funes, fluxos de dados e depsitos de dados).

c) Um DFD apresenta componentes ativos (as funes) e componentes estticos (depsitos de dados). d) Um DFD pode ser visto como um modelo que apresenta as funes de um sistema

e) As informaes de um sistema podem ser apresentar em termos estticos (depsitos de dados) ou em movimento (fluxo de dados). f) Um fluxo de dados liga: -uma entidade externa a uma funo

ANLISE DE SISTEMAS

-uma funo a uma entidade externa; -uma funo a um depsito de dados; -um depsitos de dados a uma funo. -uma funo a outra funo.

ANLISE DE SISTEMAS

Captulo 4 O Diagrama de Contexto

Se considerarmos que todo sistema est circunscrito a um universo de interesse e que cada entidade extrema estabelece uma fronteira entre o sistema e o ambiente em que ele est inserido, poderemos afirmar que uma nica possvel representao de um sistema aquela em que ele apresenta como uma nica grande funo, cercada pelas entidades externas que com ele interagem. Por intermdio de fluxos de dados.

Para ilustrar esta idia, voltemos ao sistema que se suponha a produzir o fluxo de dados nota de dbito digitada. Se observarmos a figura a sequir, podemos com, por exemplo, uma linha dupla estabelecer a fronteira do sistema:

DEPARTAMENTO DE COBRANA Nota de Dbito em branco

Preencher Nota de dbito

N o t P Digitar Nota de Dbito a r Nota de Dbito Nota de Nota de Dbito preencher e preenchida Dbito digitada d e e n SISTEMA c DE D h COBRANA i b d i a t o

Como consequncia, pode-se expressar tal sistema como o diagrama:

DEPARTAMENTO DE COBRANA

Nota de dbito em branco

Obter nota de dbito digitada

Nota de dbito digitada

SISTEMA DE COBRANA

ANLISE DE SISTEMAS

O diagrama anterior, que representa apenas um sistema e suas interfaces, denominado Diagrama de Contexto. Se adotamos o mesmo procedimento para o outro exemplo apresentado, teremos:
CLIENTE Lista de compras CADASTRAR LISTA DE COMPRAS

DIRETORIA Lista de demanda Emitir Lista de Demandas Razo Social

LISTA DE COMPRAS item de compra

Lista de Compras

produto

PRODUTOS

produto

CADASTRAR PRODUTOS

li sta de produtos

FORNECEDORES

Fornecedores CADASTRAR Pedido de FORNECEDORES cadastramento Fornecedores

FORNECEDOR

E chegaremos ao sequinte diagrama de contexto:

CLIENTE Lista de Compras

DIRETORIA Lista de demanda Sistema de Acompanhamento da Demanda de Produtos Lista de produtos Pedido de Cadastramento de Fornecedores

FORNECEDOR

Ao analisar as duas situaes mostradas, podemos concluir que:

ANLISE DE SISTEMAS

a) O sistema Obter Nota de Dbito Digita pode ser decomposto em duas funes: 1)Preencher Nota de Dbito; 2)Digitar Nota de Dbito. b) O Sistema de Acompanhamento de demanda de Produtos pode ser decomposto em quatro funes: 1)Cadastrar Produtos; 2)Cadastrar Fornecedores; 3)Cadastrar Lista de Compras; 4)Emitir Lista de Demanda. Como consequncia, podemos concluir que: -Um DFD uma representao de um sistema sob a forma de uma rede que mostra os componentes ativos do sistema e as interfaces de dados entre eles.

-Todo sistema pode, apartir do Diagrama de Contexto, ser decomposto em diversas funes que se interligam. Note que as entidades externas no diagrama expandido (DFD que apresenta as funes do sistema) so as mesmas do Diagrama de Contexto, no qual, entretanto, so mostrados apenas os fluxos de dados que representam a interface do sistema com as entidades externas.

-para cada funo do sistema, podemos aplicar esse mesmo prncipio e decomp-la em funes mais simples, ou seja, subfunes. Todo sistema pode ser representado como um grande processo, interagindo como o ambiente em que est inserindo.Isto significa que a primeira visode um sistema o diagrama de contexto. Como desenhar um diagrama de contexto? Passo n1)Desenhar um nico processo ou funo para representar o sistema inteiro.

CIA. END- VIDADA

ANLISE DE SISTEMAS

Passo n2)Desenhar todas as entidades externas que se comunicam com o sistema.

DEPTO. PLANEJAMENTO CLIENTE

CIA. END- VIDADA

FORNECEDOR DEPTOFINANCEIRO

Passo n3)Para cada entidade externa, desenhar o fluxo de dados que mostra sua comunicao com o sistema
PAGAMENTO CLIENTE DEPTO. PLANEJAMENTO

CLIENTE

PEDIDO CLIENTE FATURA-CLIENTE ENCOMENDA

CIA.. END- VIDADA

RELATRIO FINANCEIRO COMISSO DOS VENDEDORES

FATURA DO FORNECEDOR FORNE CEDOR PAGAMENTO FORNECEDOR

DEPTO. FINANCEIRO

H quem discuta se, em um Diagrama de Contexto, J poderiam aparecer depsitos de dados ou no. Particularmente, preferimos no apresentlos neste nvel. Acreditamos que em um Diagrama de Contexto deve-se representar apenas um sistema e suas interfaces com as entidadesexternas.

ANLISE DE SISTEMAS

Captulo 5 Nivelamento e Balanceamento

Do que nos foi apresentado at agora, somos levados a considerar que estamos diante de um processo de decomposio sucessiva e hierrquica, que toma a forma de uma rede onde cada n (funo ou processo) pai pode ser decomposto em outra rede de funes filhas com os respectivos fluxos de dados e depsitos de dados do nvel imediatamente inferior, e assim sucessivamente, at que no possa mais ser decomposta. A funo que no possa mais ser decomposta denominada funo primitiva, ou primitiva funcional. Trata-se de uma funo bsica ou atmica - que no mais possa ser subdividida. Em resumo, todo DFD pode ser decomposto em DFDs de nvel inferior, recursivamente, at alcanarem-se as primitivas funcionais. Trata-se de uma fatorao hierrquica. A ilustrao a seguir nos mostra esta situao.

E1 FD1 SISTEMA FD2 E2 FD8 FD7

E3

Nvel Contexto
E4

SISTEMA E1 FD1 P2 FD6 E2 FD2 FD3 P1 FD4 FD5 P4 P3 FD8 E4 FD7 E3

Nvel 0

P3
P2 FD6 P1 FD4 P3.1 P3.2 P3.4 FD8 E4 P3.3

Nvel 1

ANLISE DE SISTEMAS

Apresentamos, inicialmente, um Diagrama de Contexto do sistema, onde: -as entidades externas esto representadas por E1, E2, E3 e E4; -os fluxos de dados so representados como FD1, FD2, FD7, e FD8.

No passo seguinte, exibido o primeiro nvel de particionamento do sistema, onde: -os processos (funes) do sistema so representados por P1, P2, P3, e P4. -alm dos fluxos de dados j apresentados, aparecem ainda FD3, FD4, FD5 e FD6

Em seguida, ilustrada a decomposio do processo P3,onde:

-aparecem processos com as denominaes P3.1, P3.2, P3.4. - apresentado ainda um depsito de dados entre os processos P3.1 e P3.3. -aparecem entidades externas com as denominaes P1, P2 e E4.

Algumas observaes se fazem necessrias:

a) Um sistema de tamanho razovel, normalmente, no deve ser modelado em nico DFD, pois o modelo poderia ficar ininteligvel.

b)Para resolver este problema, so construdos vrios DFDs representando o sistema em sucessivos nveis de detalhe, chamados nveis de abstrao. A esta estratgia costuma-se chamar nivelamento. Na figura anterior foram apresentados trs nveis de abstrao. Cada DFD representa o detalhamento (exploso) do DFD de um nvel imediatamente superior. Uma maneira de identificar os nveis de abstrao numer-los em ordem sequencial, tal como nvel zero, nvel 1, nvel 2, nvel3 etc.

A abordagem em que efetuamos a decomposio do sistema, partindo do diagrama de contexto (nvel mais geral) e descendo passo a passo a nveis mais baixo (mais detalhados), denominada abordagem top -down. Foi a abordagem preconizada pela tcnica de anlise denominada Anlise

ANLISE DE SISTEMAS

Estruturada, muito popular desde o final da dcada de 1970 at meados da dcada de 1980. Uma outra abordagem possivel, oposta top down, denominada bottom-up parte do nvel mais detalhado para o nvel mais geral. Outras abordagens tambm conhecidas so as denominadas outside-in, insideout, ou ainda midle-out. Esta ltima ser opurtanamente, apresentada ao leitor. Numa decomposio do tipo top-down, possivel que, em um determinado nvel algumas funes j sejam primitivas funcionais, enquanto outras ainda no o so. Estas ainda daro origem a DFDs mais detalhados (de nvel mais baixo). Uma imagem que pode ser adotada a de se considerarem as primitivas funcionais como sendo tomos que ao se agregarem vo formar as molculas de uma substncia.

conveniente que, em cada nvel de abstrao, as funes estejam em grau de detalhamento prximo, ou seja, no convm que em um dos nveis do DFD uma das funes ainda precise ser decomposta em subfunes de muitos nveis de abstrao inferiores at chegar primitiva funcional, enquanto outras funes do mesmo DFD j so primitivas. Cada DFD deve apresentar um nvel de detalhe equilibrado. Os processos que tratam de rotinas de erros e de exceesdevem ser expressos nos nveis mais baixos.

Para alguns autores, cada nvel de DFD deve ter de 5 a 9 funes. Segundo os defensores desta idia, esta uma boa maneira de se tratar a complexidade do sistema, visto que um DFD com inmeros funes tornar-se-ia de difcil leitura.

c)Sempre que ocorre particionamento, deve ser garantidaa a consistncia entre as entradas e sidas de cada dois nveis de particionamento sucessivos. Em outras palavras, h uma espcie de conservao de energiaou conservao dos dados, no sistema. A esta necessidade costuma-se chamar balanceamento.

Ao particionar um processo, qualquer fluxo de dados, depsito de dados ou entidade externa que aparea a ele ligado no nvel de cima tem de aparecer no DFD do nvel imediatamente inferior.

ANLISE DE SISTEMAS

Do ponto de vista de quem observa o sistema a partir do exterior, no pode haver fluxos de dados de entrada ou de sada no nvel inferior que no existam no de cima. Por consequinte, tanto no Diagrama de Contexto como no nvel imediatamente inferior, temos os mesmos fluxos de dados servindo de interface entre o sistema e o seu exterior, temos os memsos fluxos de dados servindo de interface entre o sistema e o seu exterior, ou seja F1, F2, F7, e F8. Da mesma forma, no particionamento do processo P3, notam-se os mesmos fluxos de dados de entrada e sada, no caso, FD6, FD4 e FD8.

d) Ao particionarmos um processo, cono o caso de P3, uma boa conduta reconhecer que, do ponto de vista de P3, os processos P1 e P2 so considerados entidades externas. Esta conduta nos ajuda a garantir a consistncia entre os diversos nveis de particionamento. Note que estamos chamando P1e P2 de entidades externas, apenas em relao exploso do processo P3; mas no para o sistema como um todo.

e)A maneira usada para expressar a correspondncia entre os nveis pais e nveis filhos da especificao estruturada foi a designao numrica mostrando a que diagrama pai corresponde um diagrama filho. Em consequncia, P3.1, P3.2 e P3.3 so processo filhos do processo pai P3. Se, por exemplo, o processo P32 ainda no fosse uma primitiva funcional, seus processos filhos seriam numerados por P3.2.1, P3.2.2, P3.2.3, e assim por diante. Ao analisar a figura anterior, trs problemas afloram:

a)Qual o critrio de particionamento de uma funo que deve ser usado? Por ora, podemos responder que, luz dos conhecimentos atuais sobre este assunto, o melhor critrio o de particionar uma funo detal forma que nos DFD resultante as subfunes componentes tenham a mnima quantidade de interfaces possvel. Voltaremos a este ponto mais tarde, quando, esperamos, este assunto ficar mais claro. b)O modelo das funes compe-se apenas de uma representao diagramtica? No. A especificao do modelo das funes (especificao funcional) inicia-se com a decomposio do diagrama de contexto em sucessivos DFDs, cada vez mais detalhados, at que se chegue s funes primitivas. Apenas os desenhos no so suficientes para que se possa compreender o modelo das funes em sua intereiza. Dessa maneira, falta ainda

ANLISE DE SISTEMAS

descrever o contedo dos fluxos de dados e dos depsitos de dados. Isto se faz atravs de uma linquagem de descrio apropriada para esta necessidade, a qual veremos no momento oportuno. Por outro lado, ao de chegar s funes primitivas, passa-se a especificar de forma descritiva, fazendo uso das tcnicas estruturadas de especificao Em uma especificao funcional, apenas as descries das funes primitivas so apresentadas e so chamadas miniespecificaes (miniespecs). Mais adiante veremos como se faz isto.

c) At quando se deve continuar particionando as funes? Poderiamos dizer que cada n pai deva ser particionado em uma rede de ns filhos at que o nvel desejado de detalhe seja alcanado, e ai estaramos diante de funes primitivas. Entretanto, qual deve ser o nvel de detalhe desejado? Aqui reside um problema, pois no h uma medida precisa sobre se uma funo ainda deve ser decomposta ou no.

Como regra puramente prtica, pode-se dizer que uma funo primitiva aquela que:

-pode ser descrita em apenas uma pgina, quer esta pgina represente a descrio de um pequeno procedimento manual ou um mdulo de um programa de computador, ou -sua descrio, em pseudocdigo, no ultrapassa 50 a 100 linhas. Para armazenar as descries mencionadas, necessrio um procedimento especfico para este objetivo. Isto apresentado no captulo seguinte.

Captulo 6 O Dicionrio de Dados Conforme dissemos, o modelo funcional composto de uma representao grfica e uma descrio dos componentes do modelo-entidades externas, funes, fluxos de dados e depsitos de dados. Logo, uma vez identificados os componentes do modelo, devemos descrev-los. Para tanto, conforme proposto pela literatura, usado um sistema, que vai quardar

ANLISE DE SISTEMAS

informaes sobre os componentes dos sistemas. Para tanto, conforme proposto pela literatura, usado um sistema, que vai quardar informaes (metadados) sobre os sistemas de nosso interesse, denominado dicionrio de dados. Um dicionrio de dados um repositrio de informaes sobre os componentes do sistemas. Para descrever os componentes de sistema, devemos adotar uma linguagem apropriada. Vrias formas podem ser usadas para, por exemplo, apresentar os dados de um fluxo de dados. Adotaremos uma linguagem baseada numa combinao daquelas propostas no livro de T. DeMarco [ref.9] e no de C.Gane e T.Sarson [ref.11]. Utilizaremos os sequintes smbolos:

SMBOLO = {} *(min-max) [] @ %% 6.1 Descrio dos Fluxos de Dados

SIGNIFICADO equivalente a ou repeties opcional chave comentrio

Seja mostrar a composio do fluxo de dados denominados FATURACLIENTE do DFD a seguir:

PAGAMENTO DO CLIENTE CLIENTE PEDIDO-CLIENTE DEPTO. PLAN EJA MENTO RELATRIO FINANCEIRO FATURA-CLIENTE ENCOMENDA FATURAFORNECEDOR FORNECEDOR PAGAMENTO AO FORNECEDOR

CIA. END-VIDADA
COMISSO DOS VENDEDORES DEPTO FINANCEIRO

fatura-cliente = NUM-FATURA cod-cliente

ANLISE DE SISTEMAS

ender-cliente produto *(1-10) VALOR-TOTAL-FATURA produto = COD-PRODUTO PREO-UNITRIO QTDE-PEDIDA VALOR-TOTAL-PRODUTO

ender-cliente = RUA NMERO COMPLEMENTO NOME-BAIRRO [CEP] SIGLA-UF% sigla da unidade da Federao% TELEFONE% telefone para contato, inclui DDD% cod-cliente = {CPF-CLIENTE%CPF, se pessoa fsica ou % CGC-CLIENTE}%CGC, se pessoa jurdica % Como se pode notar, foram usadas letras maisculas para identificar dados elementares (que no podem ser decompostos), ao passo que foram usadas letras minsculas para identificar os casos em que temos uma estrutura de dados (caso em que temos, na verdade, um agregado de outros dados, como, por exemplo, ender-cliente). Vale ressaltar que este tipo de procedimento recursivo, ou seja, uma estrutura de dados pode ser decomposta,ou ainda, uma combinao dos dois.

A leitura da descrio nos d conta de que: fatura-cliente e ender-cliente so estruturas de dados, enquanto que VALOR-TOTAL-FATURA e RUA so dados elementares; produto uma estrutura que pode ocorrer no mnimo uma vez at o mximo de dez vezes em cada fatura-cliente; no caso de CEP, vemos que foi definido como sendo um dado elementar opcional na estrutura de ender-cliente; ao lado de SIGLA-UF foi colocada uma explicao para ilustrar o uso do smbolo que expressa um comentrio; para exemplificar a utilizao do smbolo que serve para expressar o caso em que apenas uma das alternativas vlida, foi apresentada a definio de cod-cliente que dependendo do tipo de cliente, pode ser idenrtificado pelo CPFou pelo CGC.

ANLISE DE SISTEMAS

Pode-se imaginar um dicionrio de dados como um sistema de apoio especificao do sistema em desenvolvimento, uma vez que todas as definies dos componentes do sistema ali estaro armazenadas.

De maneira rudimentar, pode-se imaginar o dicionrio de dados como sendo um fichrio que contm uma ficha para cada componente do sistema, como na figura a seguir.

DICIONRIO DE DADOS

Fluxo de dados : Nome-cliente Dposito de dados : Clientes Dado elementar: Cidade Estrutura de dados: Endereo

Por ora, estamos colocando no dicionrio de dados apenas os componentes do modelo de funes. Todavia, para ser completo, ele deveria, ainda, conter os componentes de dados e do modelo de controle, que veremos em prxinmos captulos, alm de informaes adicionais que se fizessem necessrias. Como dissemos, o dicionrio de dados deve ser um sistema que descreve o sistema de nossos interesse. Hoje em dia, existem no mercado diversos sistemas automatizados de dicionrio de dados deveser um sistema que descreve o sistema de nosso interesse. Hoje em dia, existem no mercado diversos sistemas automatizados de dicionrio de dados, com inmeros recursos disponveis. O leitor leitor no precisa se preoucupar em desenvolver um. Basta apenas conhecer o conceito e usar o que esteja disponvel em sua instalao. Alm disso, com a evoluo dos softwaredo tipo CASE (Computer Aided

ANLISE DE SISTEMAS

Software Engeneering), que servem de apoio ao desenvolvimento de sistemas, j se pode ter um auxlio bastante grande na tarefa de documentao. Nos CASEs j costuma vir embutido um dicionrio de dados

6.2 Descrio dos Depsitos de Dados Seja o trecho de DFD mostrado na figura a seguir:

Gerncia Operacional

Cadastrar loja

Cadastrar livro

Loja Incrementar Estoque Sistema de Compras Etoque Loja

Livro

Para descrever os depsitos de dados, usando-se a linguagem de descrio de dados, por ns definida, teremos:

loja =

NUM-LOJA ender-loja @COD-LIVRO TTULO-LIVRO NOME-AUTOR-PRINCIPAL NUM-EDIO

livro =

ANLISE DE SISTEMAS

PREO-UNITRIO estoque-loja = @NUM-LOJA @COD-LIVRO QTDE-EM-ESTOQUE NVEL-DE-REPOSIO

ender-loja =

RUA NMERO COMPLEMENTO NOME-BAIRRO [CEP] SIGLA-UF% da unidade de Federao % TELEFONE % telefonr para contato, inclui DDD%

No se esquecer de que, como um depsito de dados representaum conjunto de dados como se fora um arquivo(note que no estamos nos referindo a arquivos fsicos do sistema, pois ainda no os protejamos nesta fase do desenvolvimento), podemos imaginar os depsitos de dados como sendo compostos de registros com as estruturas anteriormente definidas. Cabe ressaltar que para se ter acesso a cada refgistro individuializado de cada depsito de dados foi usado o conceito de chave de acesso, sendo usado o smbolo @para assinalar os elementos ou estrutura de dados que tenham esse papel. Resulta da que a chave para acesso ao depsito de dados livro CODLIVRO; a chave do depsito loja NUM-LOJA, enquanto que a chave para o depsito estoque-loja composta pela concatenao de NUM-LOJA e CODLIVRO, pois somente assim poderemos saber qual a quantidade de um determinado livro em uma determinada loja.

Uma forma diferente e mais sinttica de apresentar a composio de um depsito de dados ou de um fluxo de dados atravs de um conjunto de campos (dados elemenatres ou estruturas de dados) separados por vrgulas, onde os campos (dados elementares ou estruturas de dados) separados por vrgulas, onde os campos que formam a chave dos depsitos esto sublinhados.

loja = {NUM-LOJA, RUA, NMERO, COMPLEMENTO, NOME-BAIRRO, CEP, SIGLA-UF, TELEFONE} livro = {COD-LIVRO, TTULO-LIVRO, NOME-AUTOR-PRINCIPAL, NUMEDIO, PREO-UNITRIO}

ANLISE DE SISTEMAS

estoque-loja = {NUM-LOJA, COD-LIVRO, QTDE-EM-ESTOQUE, NIVELDE-REPOSIO}

Captulo 7 A Especificao dos Processos Ao chegar ao nvel das funes primitivas, encontramo-nos diante do problema de como descrever tais funes, com clareza e preciso. Alm disso, temos de considerar que a miniespec (descrio da funo primitiva) dever ser lida pelos analistas de sistemas e pelos futuros usurios do sistema em desenvolvimento, os quais, no necessariamente, tm formao que permita entender, por exemplo, o jargo tcnico da informtica. Portanto, no podemos usar a linquagem comun, pois notorio qua tal opo d margem a toda subjetividade de quem descreve, com todas as possibilidades de ser produzido um texto redundante, ambguo, confuso, inconscistente e incomleto.

Para solucionar este problema, e lembrando que a descrio de uma primitiva funcional (miniespec) no pode ser bem compreendida sem se ter idia do contexto em que se acha inserida, devemos estabelecer algum balizamento sobre os sequintes aspectos:

o que deve e o que no deve ser descrito; que tipo de tcnica deve-se usar na descrio.

Em relao ao primeiro aspecto, temos a considerar:

na miniespec no necessrio repetirf o que jfoi definido nos DFDs e no dicionrio de dados, como o caso das descries dos fluxos de dados e dos depsitos de dados, redundncia de deve ser evitada, sempre que possivel; toda miniespec deve definir a forma pela qual os fluxos de dados de entrada so transformados em fluxos de dados de sada,

ANLISE DE SISTEMAS

independentemente do fato de a funo ser executada manualmente ou por qualquer outra forma de implementao; Em relao ao segundo aspecto, as principais tcnicas de especificao so:

portuqus estruturado pseudocdigo tabela de deciso rvore de deciso

7.1 Portuqus Estruturado

Seja o trecho de DFD com a primitiva funcional a sequir, que representa uma funo de um sistema escolar que executada ao final do perodo de aulas:
DISCIPLINAS ALUNOS EMITIR AVISO DE SITUAO DO ALUNO APROVADO

EM RECUPERAO

REPROVADO AVALIAES-DE-ALUNOS

Sejam os sequintes os depsitos de dados:

ALUNOS = @MATR-ALUNO NOME-ALUNO ender-aluno ender-aluno = RUA NMERO COMPLEMENTO NOME-BAIRRO [CEP]

ANLISE DE SISTEMAS

SIGLA-UF% sigla da unidade da Federao% TELEFONE% telefone para contato, inclui DDD% AVALIAES-DE-ALUNOS = @MATR-ALUNO @COD-DISCIPLINA MDIA-FINAL DISCIPLINAS = @COD-DISCIPLINA NOME-DISCIPLINA CONTEDO-PROGRAMTICO Precisamos descrever qual o procedimento a ser adotado para emitir o aviso sobre a situao do aluno. A tcnica que usaremos denomina-se portuqus estruturado e constitui-se em uma verso adaptada de nosso prprio idioma, com nfase em algumas classes gramaticais (no caso, verbos, de preferncia no modo imperativo) em detrimento de outras (normalmente adjetivos e advrbios, pois estas classes do margem a confuses que devem ser evitadas em nome da clareza e preciso), acrescida de construes tpicas das estruturas de controle existentes nnas linquagens de programao (sequncias, decises e repeties). Busca estabelecer comunicao de alto nvel com o usurio, atravs de termos que lhe so familiares, e Assim, teremos:

EMITIR AVISO DE SITUAO DO ALUNO

PARA CADA aluno no arquivo de alunos: 1.Coloque a matrcula, o nome e o endereo do aluno no formulrio de aviso. 2.PARA CADA cod-disciplina, cursada pelo aluno, existente no arquivo de avaliaes: 2.1 Obtenha, a partir do arquivo de disciplinas, o nome da discplina. 2.2 Obtenha, a partir do arquivo de avaliaes, a mdia final do aluno na disciplina. 2.3 Coloque no formulrio de aviso o cdigo, o nome e a mdia final da disciplina cursada pelo aluno. 3. Calcule o total de disciplinas em que o aluno obteve mdia final menor do que 5. 3.1 (CASO 1) nenhuma disciplina com mdia final menor do que 5. 3.1.1Coloque no formulrio com a expresso APROVADO.

ANLISE DE SISTEMAS

3.2 (CASO2) mais de trs disciplinas com mdias finais menores do que 5 3.2.1Coloque no formulrio a expresso REPROVADO. 3.3 (CASO3) menos de quatro disciplinas com mdias finais menores do que 5 3.3.1 Coloque no formulrio a expresso EM RECUPERAO. Como se pode observar, usamos aqui construes anlogas a estruturas tpicas das linquagens de programao, como repetio (PARA CADA....), sequncia (coloque, calcule etc...), e seleo (CASO1; CASO2;...). Esta ltima parte da especificao tambm poderia ser expressa por estruturas ainda mais comuns nas linguagens de programao, quando se quer exprimir a noo de seleo. E, ento, poderamos ter algo parecido com o if-then-else, como o sequinte trecho: 3.Calcule o total de disciplinas em que o aluno obteve mdia final menor do que 5. SE em nenhuma disciplina a mdia fianl foi menor do que 5, Coloque no formulrio de aviso a expresso APROVADO. SE NO, SE em mais de trs disciplinas houve mdia final menor do que 5, Coloque no formulrio a expresso REPROVADO. SE NO, Coloque no formulrio a expressoEM RECUPERAO Como se pode ver, usamos uma tcnica de redao bastante estruturada, e fizemos uso das construes que citamos e cuja sintaxe pode ser vista na tabela a sequir: SINTAXE sequncia de instrues repetio de instrues seleo entre instrues PORTUQUS ESTRUTURADO Obtenha....;Calcule....;Coloque...;Co pie...;etc... PARA CADA...faa o que se seque: SE.... SE NO faa o que se seque: CASO 1:...faa o que se seque: CASO 2:...faa o que se seque: .................................................: .................................................: CASO N:....faa o que se seque:

No se pode esquecer que, ao se especificar uma funo, fundamental definir com clareza o objetivo dela. Por exemplo:

ANLISE DE SISTEMAS

EMITIR AVISO DE SITUAO DO ALUNO Objetivo: Emitir aviso a ser enviado para o aluno, indicando o desempenho em cada disciplina,alm da avaliao global, que indica a sua situao em relao ao periodo cursado. Em resumo, o portuqus estruturado consiste em:

verbos no modo imperativo; termos definidos no dicionrio de dados; determinadas palavras reservadas para descrever a lgica da funo

7.2 Pseudocdigo

Uma forma textual alternativa, e mais popular, da se descrever miniespecies, quase idntica ao portuqus estruturado, porm mais prxima das linquagens de programao, o chamado pseudocdigo. Contm:

verbos (LER; OBTER; IMPRIMIR; GRVAR; etc.) substantivos (elementos do dicionrio de dados) estruturas de controle (SE; ENQUANTO; REPETIR; CASO) operadores de relao (IGUAL; MAIOR QUE; MENOR QUEetc.)

Uma possvel comparao entre os dois modos de descrio apresentado L.Peters [ref.13]:

PORTUQUS ESTRUTURADO PSEUDOCDIGO orientado para os procedimentos orientado para implementao usa termos familiares ao usurio lembra linguagem de programaco (linguagem do negcio da empresa) o objetivo um alto nvel de o objetivo facilitar a programao comunicao Exemplo de uso de pseudocdigo:

ANLISE DE SISTEMAS

EMITIR FATURAS-MENSAIS DE CARTES-DE-CRDITO Inicializar programa (abrir arquivos, acertar contadores) Ler registro-de-carto-derdito REPETIR-ENQUANTOexistam registros-de-carto-de-crdito REPETIR-ENQUANTO existam itens-de-compra-no-carto-de-crdito Calcular total-de-item Somar total-de item ao total-da-fatura-mensal FIM REPETIR Calcular desconto Calcular fatura-lquida; total-a-pagar Imprimir fatura-mensal Gravar faturano arquivo faturas Ler registro-de-carto de crdito FIM REPETIR Terminar programa 7.3 Tabela de Deciso Tabela de deciso uma maneira de expressar, em forma de tabela, qual o conjunto de condies que necessrio ocorrer para que um determinado conjunto de aes deva ser executado. O cerne de uma tabel de deciso a denominada regra de deciso, a qual define o conjunto de aes a ser tomado, apartir de um conjunto de condies. Formato de uma tabela de deciso: Regra de deciso1 Regra de deciso2 ............... ............... Regra de deciso

CONDIES Condio1: Condio2: ................ ................ CondioN: AES Ao1: Ao2: .............. ..............

ANLISE DE SISTEMAS

.............. AoN: Uma tabela de deciso composta de: uma rea de condies, onde so relacionadas as condies que devem ser verificadas para que seja executado um conjunto de aes. uma rea de aes, que exibe o conjunto de aes que deve ser executado caso um determinado conjunto de condies ocorra. regras de deciso, representadas pelas colunas, apresentam a combinao das condies com as aces a serem executadas.

CONDIES Condio1: Condio2:

Regra de deciso1 S S

Regra de deciso2 S N

Regra de deciso3 N S

Regra de deciso4 N N

AES Ao1: X Ao2: X X Ao3: X X onde S = sim; N = no; X = ao a ser executada. Por exemplo, a tabela anterior lida da seguinte maneira:

Regra de deciso 1: caso as condies 1e 2 ocorram, devero ser executados as aes1 e 3. Regra de deciso 2: caso a condio 1 ocorra e a condio 2 no ocorra, somenete dever ser executada a ao 2. Regra de deciso 3: caso a condio 1 no ocorra e a condio 2 ocorre devero ser executadas as aes 2 e 3. Regra de deciso 4: caso as condies 1 e 2 no ocorram, dever ser executada somente a ao 3.

Uma das caracteristicas importantes de uma tabela deciso a de se poder determinar com exatido a quantidade de regras de deciso que far parte da tabela. Isto se obtm a partir do produto do conjunto de possibilidades para cada condio. Por exemplo: caso haja um conjunto de trs condies, onde cada uma delas tenha duas possibilidades, teremos:

ANLISE DE SISTEMAS

Condio 1: tem duas possibilidades Condio 2: tem duas possibilidades Condio 3: tem duas possibilidades O que d um total de 2 x 2 x 2 = 8 regras de deciso. A tabela a seguir ilustra este fato. Regra Regra Regra Regra Regra Regra Regra Regra 1 2 3 4 5 6 7 8 CONDIES Condio1: S S S S N N N N Condio2: S S N N S S N N Condio3: S N S N S N S N AES Ao1: Ao2: .......... AoN:

X X X X X X X

onde: S = sim; N = no; X = ao a ser executada.

Seja a descrio de um processo que determina qual o tipo de exame mdico peridico a que um empregado de uma determinada empresa deve ser submetido: Regra Regra Regra Regra Regra Regra Regra Regra 1 2 3 4 5 6 7 8 CONDIES Ocupa cargo de chefia? S S S S N N N N Idade maior que 40 anos? S S N N S S N N Mais de 2anos no cargo? S N S N S N S N AES Exame especial Exame normal

X X

X X X

onde: S = sim; N = no; X = ao a ser executada.

ANLISE DE SISTEMAS

Seja um processo que visa decidir quais as aces a serem tomadas a respeito de condicionamento fsico de, por exemplo, empregados de uma firma. Trs condies so consideradas:

Condio 1:sexo: a ser preenchida com as letras: M= sexo masculino F = sexo feminino Condio 2: altura a ser preenchida com as letras: A= altura maior que 1,60m B= altura at 1,60m Condio 3: atividade fsica: a ser preenchida com as letras: S= sedentrio R= prtica atividade fsica mais de 3 vezes por semana I= prtica atividade fsica mais de 3 vezes por semana Portanto, teremos: Condio1: tem duas possibilidades Condio2: tem duas possibilidades Condio3: tem trs possibilidades o que d um total de 2 x 2 x 3 =12 regras de deciso. A tabela a seguir ilustra este fato. Uma vantagem do uso da tabela de deciso que, como podemos conhecer, a priori, regras de deciso necessrias, temos como verificar se foram estabelecidas as aes correspondentes a todas as regras de deciso

CONDIES R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 Condico1: M M M M M M F F F F F F Condio2: A A A B B B A A A B B B Condio3: S R I S R I S R I S R I AES Ao1: Ao2: Ao3: Ao4:

X X X X X X X X X X X X

ANLISE DE SISTEMAS

7.4 rvore de Deciso Uma rvore de deciso uma resentao de uma tabela de deciso sob a forma de uma rvore. Tem a mesma utilidade da tabela de deciso. Tratase de uma maneira alternativa de expressar as mesmas regras que so obitidas quando se constri a tabela. Seja a tabela de deciso da figura anterior. Neste caso, teramos a seguinte rvore de deciso:

SEXO

ALTURA

ATIVIDADE FSICA

AO

A M B

S R I S R I S R I 3

4 2e4 3 3 2 2 3e4 1

F B S R I 2 1e4 4

ANLISE DE SISTEMAS

Seja a especificao do processo de clculo do valor da conta de energia eltrica. Uma rvore de deciso para expressar tal problema seria

consumo
de zero a 15KWH acima de 15kwth at 50kwh acima de 50KWH

valor a pagar
valor = R$11,00 x consumo valor = (R$11,00 x 15) + R$19,00 x (consumo-15) valor = (R$11,00 x 15) + (R$19,00 x 35) + R 32,00 x (consumo)

Seja a especificao do processo de obteno do tipo de tarifa a ser aplicada em uma ligao de conta telafnica. Uma rvore de deciso para expressar tal problema seria:

DIA da SEMANA

HORA

TARIFA

2 a 6 FEIRA ___ acima de 00 hs. at 24 hs ______ NORMAL acima de 00 hs.at 14 hs ______ NORMAL SBADOS acima de 14 hs.at 24 hs ______ REDUZIDA DOMINGOS e____acima de 00 hs.at 24 hs ______ REDUZIDA FERIADOS

7.5 Comparao entre Mtodos de Especificao de Processos Seja o problema j mencionado, que se prope a descrever um processo que determina qual o tipo de exame mdico peirdico a que um empregado de uma determinada empresa deve ser submetido. Colocado sob a forma de uma rvore de deciso, equivalente tabela de deciso j apresentada, teriamos:

ANLISE DE SISTEMAS

Ocupa Cargo mais de 40 anos Mais de 2 anos Tipo de de chefia? de idade ? de empresa? Exame

S S S N N S S N N N N S N S

ESPECIAL ESPECIAL ESPECIAL NORMAL ESPECIAL ESPECIAL NORMAL NORMAL

Observando a rvore construda, pode-se notar que o tipo de exame a ser aplicado em um empregado que satisfaa as duas primeiras condies, ou seja, ocupa cargo de chefia e possui mais de 40 anos de idade, independente de o empregado possuir mais de dois anos de empresa, pois tanto faz que ele possua mais de dois anos ou no, dever ser submetido a exame especial. Desta forma, podemos simplificar a rvore subistituindo dois ramos por apenas um. Uma situao da mesma natureza ocorre nos dois ramos inferiores da rvore, como se pode notar na figura seguinte:

ANLISE DE SISTEMAS

Ocupa Cargo mais de 40 anos Mais de 2 anos Tipo de de chefia? de idade ? de empresa? Exame

S S S N N S S N N N N S NORMAL ESPECIAL NORMAL N S ESPECIAL ESPECIAL

Podemos ento simplificar a rvore, desenhando-a como a seguir:

Ocupa Cargo mais de 40 anos Mais de 2 anos Tipo de de chefia? de idade ? de empresa? Exame

S S N N S N N S

ESPECIAL ESPECIAL NORMAL ESPECIAL NORMAL

ANLISE DE SISTEMAS

De maneira anloga, poderiamos fazer a mesma simplificao na tabela de deciso correspondente e teriamos:

CONDIES Regra1/2 Ocupa cargo de chefia ? S Idade maior que 40 anos? S Mais de 2 anos no cargo? AES Exame especial Exame normal

Regra 3 S N S

Regra 4 S N N

Regra5/6 Regra 7/8 N S N N

X X

X X

onde: S = sim; N = no; -= sim ou no (tanto faz) X = aoa ser executada.

O mesmo processo, descrito usando portuqus estruturado, ficaria: CASO 1: (empregado ocupa cargo de chefia) SE empregado possui mais de 40 anos de idade, aplicar exame especial SE NO (at 40 anos de idade), SE empregado possui mais de 2 anos de empresa, aplicar exame especial SE NO (at 2 anos de empresa), aplicar exame normal CASO 2: (empregado no ocupa cargo de chefia) SE empregado possui mais de 40 anos de idade, aplicar exame especial SE NO (at 40 anos de idade), aplicar exame normal Tabela de deciso X rvore de deciso: (regras prticas, de acordo com C.Gane e T Sarson [ref.11]): regra 1) Sempre que o nmero de aes for grande e ocorrem muitas combinaes de condies, usar uma tabela de deciso. regra 2) Quando o nmero de decises for pequeno e nem toda combinao de condies for possvel, usar uma rvore de decises.

ANLISE DE SISTEMAS

regra 3) Se houver dvidas de que rvore de deciso mostra toda a complexidade do problema, usar uma tabela de deciso. regra 4) Se a lgica do processo for muito complexa, uma tabela deciso dever ser montada para descobri-la. Entretanto, desde que no seja o caso da regra 1, devemos apresent-la sob a forma de uma rvore.

Captulo 8 Regras para a Construo de DFDs

A literatura referente construo de DFDs no apresenta um padro de notao, havendo mesmo razovel variao quanto forma grfica a ser usada para reprtesentar cada componente do diagrama. No Brasil, Tornaramse mais populres as formas grficas existentes nos livros como o de T.De Marco [ref.9] e o de C.Gane e T.Sarson [ref.11]. Entretanto, outras formas existem, na literatura, como a de D.Ross [ref.16] e a de B.Langefors [ref.18]. Emboraumm pouco diferentes, os grficos propostos por estes dois ltimos autores tambm representam os processos e fluxos de dados de sistemas. Aqui mostraremosas notaes mais populares e descreveremos regras para a construo de DFDs, de acordo com os autores destas notaes. Em termos de notao, entre outras formas, para representar uma funo ou um processo, comun usar: a) um crculo; b)uma figura ovalada; c)um retngulo de cantos arredondados

ANLISE DE SISTEMAS

Em termos de notao, entre outras formas, para representar um fluxo de dados, comun usar: a)uma seta em linha reta b)uma seta em linha curva c)segmento de retas ortogonais terminados por setas

Em termos de notao, entre outras formas, para representar um depsito de dados, comun usar: a)duas retas paralelas b)um retngulo aberto do lado direito

Em termos de notao, entre outras formas, para representar uma entidade externa, comun usar: a)um quadrado b)um retngulo

Como exemplo, podemos ter:

LIVROS CLIENTE CADASTRAR PEDIDOS CLIENTES

PEDIDOS

ANLISE DE SISTEMAS

Em termos de notao, para representar um fluxo de acesso memria (depsito de dados), comun usar : a)Consultar (Ler) b)incluir (Gravar)

c)Modificar

d)Excluir

OBS: Em nome da facilidade de leitura do DFD, convenienteusar sempre a mesma notao para cada um de seus componentes. Muitas vazes, ao desenhar um DFD complexo, nos deparamos com a possibilidade de cruzamento de linhas que representamos fluxos de dados, o que dificulta integilibidade do diagrama. Para resolver esse problema, a sada costuma ser repetio, em outro ponto do DFD, de algumas das figuras que representam os seua componentes, da seguinte forma: a)Para a duplicao de entidades externas, costuma-se acrescentar a o smbolo tantas diagonais quantas forem as repeties utilizadas, como a seguir:

CLIENTE

CLIENTE

CLIENTE

ANLISE DE SISTEMAS

b)Para duplicao de depsitos de dados, costuma-se acrescentar ao smbolo tantas linhas paralelas quantas forem as repeties utilizadas, como a seguir:

PEDIDOS

PEDIDOS

PEDIDOS

c)Nos casos em que for inevitvel o cruzamento de linhas, um expediente que pode ser usado o desenhar um arco, como a seguir:

d)No faz sentido duplicar processos. Isto geraria confuso quanto ao entendimento do diagrama.

Para ilustrar as situaes acima descritas, observar o DFD a seguir:

E1

D1

D2

E3

P3 D2 P1 P2 D4 D5 D3 P5 P4

E2

E1

Como se pode notar. Para evitar o cruzamento de linhas de fluxo de dados repetiu-se a entidade esterna E1 e o depsito de dados D2. Para evitar o cruzamento das linhas que representam os fluxos de dados D4 a P4 e de D5 a P3, poderiamos, ainda, repetir o depsito de dados D4. Desta forma,

ANLISE DE SISTEMAS

consequiramos evitar todos os cruzamentos de linhas. A figura a seguir mostra como ficaria o trecho de DFD depois de modificado.

P3 P1 P4 D4 P5 D3 D5 D4

E2

E1

Orietao geral do leiaute de um DFD a) O fluxo geral dos dados deve seguir uma orientao de cima para baixo e da esquerda para a direita.

ANLISE DE SISTEMAS

b) As entidades externas devem ficar, de preferncia, nas bordas do desenho:

E2 E1

E3

E4

c) Os depsitos de dados devem estar posicionados: -se forem de entrada: esquerda ou acima da funo que recebe seu dados; -se forem de sada: direita ou abaixo da funo que lhe fornece dados.

D1 D2

ANLISE DE SISTEMAS

d) Os processos podem estar ligados:

-diretamente, atravs de fluxos de dados; -indiretamente, com um depsito de dados entre eles. O processo de origem deve ficar esquerda ou acima do processo de destino.

P1

P2

P3

Nomeao dos componentes do DFD (de acordo com C.Gane e T. Sarson [ref.11]): a) Nome de funo ou processo: -deve ser formado por um verbo transitivo (significa a ao a ser executada) no modo infinitivo seguido de um complemento; -os nomes das funes no se confundem com os de seus executores; -deve descrever o objetivo da funo; -toda funo deve ser nomeada a partir da sada que ela produz; -os verbos usados para denominar uma funo de transformao de dados no podem ser ambguos ou muito genricos; portanto, no servem verbos tais como controlar, gerenciar,processar, atualizarou revisar

ANLISE DE SISTEMAS

etc. Isto significaria que no temos ainda uma idia precisa da ao a ser executada; -verbos como produzir, emitir, cadastrar, extrair, criar, calcular, computar so melhores para nomear uma funo; -exemplos: Emitir lista de demanda ou Cadastrar fornecedores so bons nomes para funes de transformao de dados. Observe que, em ambos os casos, temos a idia exata do que vai ser produzido pelas funes. Por isso que costumamos dizer que uma funo deve ser nomeada a partir do que ela produz; desta forma, no corremos o risco de a nomearmos de maneira inadequada.

b) Nome de depsito de dados: -usam-se substantivos simples ou compostos; -como representa a memria do sistema, ou seja, arquivos, comun usarem-se nomes no plural, para significar um conjunto de registros; -representa uma estrutura de dados; -exemplo:Podutos, Fornecedores. Encomendas-do-cliente, Listas-de-compras,

c)Nome de fluxo de dados: -usam-se substantivos simples ou compostos; -representa uma estrutura de dados; -exemplo: Lista de demanda, Relatrio de vendas, Encomenda do cliente.

d) Nome de entidades externas: -usam-se substantivos simples ou compostos; -representa o conjunto de entidades (pessoas, coisas, rgos, sistemas etc.) do ambiente externo que tem o mesmo tipo de interface com o sistema;

ANLISE DE SISTEMAS

-exemplo: Cliente, Sistema de crdito, Fornecedor, Diretoria. Consideraes gerais sobre DFDs -Adotar os mesmos nomes utilizados pelos usurios. -Manter padres grficos (forma, tamanho e estilo). -Todos os fluxos de dados, depsitos de dados e processos devem ser nomeados com preciso. -Todos os nomes que aparecerem nos DFDs devem estar registrados no dicionrio de dados. -Equilibrar o cruzamento de linhas com repetices de componentes do DFD. -Balancear fluxos dos DFDs com seus processos pai. -Equilibrar nveis de decomposico de processos. -Especificar todos os processos primitivos do DFD. -Desenhar DFDs, de preferncia, entre cinco e nove processos. -Cada diagrama deve ocupar apenas uma pgina. -As pessoas que conhecem as funes do sistema devem aprovar o modelo apresentado. Consideraes especificas sobre DFDs a)Em relao a processos -Evitar associar nomes dos processos a seus executores. -Evitar nomes de processos com verbos genricos. -Todos os processos devem, de preferncia, ser numerados. -Processos devem, de preferncia, ser numerados.

ANLISE DE SISTEMAS

-Todos os dados devem, de preferncia, ser numerados. -Processos devem ter sempre fluxos de dados de entrada e de sada. -Todos os dados de sada de um processo devem ser derivados dos dados de entrada. b)Em relao a fluxo de dados -Os fluxo de dados devem ser nomeados consistentemente atravs de todos os nveis de DFD. -Todos os fluxos de dados dos nveis superiores devem aparecer usados nos nveis inferiores. c)Em relao a depsito de dados -Os depsitos de dados devem ser mostrados em todos os nveis em que forem necessrios. -Todo depsito de dados deve ter sempre fluxos de dados de entrada e de sada. -Um depsito de dados surge nos DFDs na primeira vez quen estiver entre dois processos. Aqui encerramos este breve resumo sobre alguns fundamentos da modelagem funcional. Para elaborar um modelo, necessrio o uso de um mtodo qu enos indique por onde comear e quais os passos a serem seguidos. Este aspecto do problema ser visto, mais adiante, na parte que trata da Anlise Essencial. O assunto Modelagem de Dados, tratado a seguir, baseado em vrios trabalhos de nossa autoria e publicados nos Anais do Congresso Nacional de Informtica [ref.37 a 40], no perodo de 1982 a 1988. Modificamos apenas a notao usada e fizemos algumas adaptaes para facilitar o entendimento. importante o uso da abordagen por ns utilizada na Modelagem de Dados, de modo a facilitar a integrao no raro, a dificuldades na integrao entre os dois modelos mencionados, conforme mostramos em trabalho nosso [ref.40]. Propositamente, neste livro, por consideramos indispensvel um bom conhecimento de Modelagem de Dado este assunto tratado com mais densidade que na maioria dos trabalhos existentes em Anlise Essencial.