Faculdade Paraíso Análise, Projeto e Implementação de Sistemas I M O D U L O

Transcrição

1 Alcione Santos Dolavale CURSO: SISTEMAS DE INFORMAÇÃO - 4º Período - dolavale@gmail.com M O D U L O I 1.0. EMENTA: Fundamentação da teoria envolvida no desenvolvimento de sistemas, processamento de dados e análise de sistemas, técnicas de análise de sistemas, levantamento de necessidades, planejamento de sistemas. Desenvolvimento de sistemas, avaliação de sistemas, banco de dados e modelagem de dados O QUE É UM SISTEMA? As pessoas empregam a palavra sistema em muitas situações cotidianas. Algumas destas situações estão exemplificadas a seguir: - O sistema telefônico ficou mudo! - O sistema de coleta de lixo está funcionando muito bem. - Desculpem, estou atrasado por culpa deste sistema de trânsito maluco - Nosso sistema eletrônico de votação... - No sistema de avaliação do professor... Em qualquer um dos casos pode-se observar que a palavra sistema está sempre acompanhada de outra(s) que a qualifica(m). Este fato também se verifica dentro das empresas, quando se faz referências a seus sistemas de informação: - Nosso sistema de vendas apontou uma desaceleração no mercado - O sistema financeiro está integrado com toda rede bancária. Observando atentamente os exemplos expostos, independentemente de seus fins, pode-se tentar fazer uma primeira generalização (extensão de um princípio ou de um conceito a todos os casos a que pode aplicar-se ou tornar geral) acerca de sistemas: todos os sistemas possuem um objetivo explicitamente declarado. O fato de um sistema expressar claramente seu objetivo (Sistema de Contabilidade, Sistema Financeiro, Sistema Respiratório) não significa que ele não possa ter outros objetivos inerentes a seu propósito, os quais podem encontrar-se ocultos ou correlatos ao explícito. Para exemplificar, considere um sistema educacional que, além de prover educação, poderia ser utilizado com objetivo oculto de domínio político. O objetivo declarado de um sistema é, a priori, a razão de sua existência. Um sistema está inserido em um meio ambiente, ou seja, tudo o que é externo ao sistema pode ser chamado de meio ambiente. O meio ambiente, portanto, pode ser um ou vários outros sistemas. Verifica-se que os sistemas utilizam o meio ambiente para um intercâmbio. Os sistemas normalmente buscam subsídios para seu funcionamento no meio ambiente e, além disso, enviam para o meio ambiente sua produção e ou resíduos. Há uma contínua troca entre o sistema e o meio ambiente. O meio ambiente, por sua vez, normalmente é outro sistema ou conjunto de sistemas. Chama-se subsistema aquele sistema interno a outros. A funcionalidade macro de um sistema pode ser representada conforme abaixo: Alimentação Processamento Saída Figura 1 Funcionamento de um sistema - 1 -

2 2.1. DEFINIÇÕES DE SISTEMA: Um sistema é um conjunto de objetos unidos por alguma forma de interação ou interdependência (Chiavenato, 1983) Conjunto de elementos, entre os quais haja alguma relação. Disposição das partes ou elementos de um todo, coordenados entre si, e que formam uma estrutura organizada. (Ferreira, 1988) 2.2. O QUE SÃO ENTIDADES DE UM SISTEMA? Entidades são elementos próprios (característicos, inerentes) de um determinado sistema. Estes elementos podem ser internos ao sistema ou estar em trânsito pelo mesmo. Qualquer que seja o caso, eles sempre entram no sistema com certas características e quando saem possuem novas características, ou ainda geram outros elementos na saída, como conseqüência de processos de transformação aos quais são submetidos. Há processos internos de transformação nos sistemas que atuam sobre as características iniciais das entidades em trânsito; em decorrência, tem-se que as mesmas entidades adquirem novas características ou transformam-se em outras entidades. A mudança de características pode ser originada pela ação direta de uma processo sobre a entidade ou o envolvimento desta como instrumento de um processo; neste caso, o desgaste da entidade implica na alteração de característica. Um exemplo seria quando ingerimos uma banana (entidade em trânsito pelo sistema digestivo), ela vai mudando suas características à medida que passa por diversos processamentos dentro do sistema. Em algum momento, quando ocorrer um processo de saída do sistema biológico (onde o sistema digestivo é um subsistema), os elementos de saída possuirão alguma característica oriunda da banana ingerida. Parte do que era a banana original foi consumida internamente e colaborou para manutenção do sistema biológico. Notas-se que outras entidades envolvidas no processamento descritivo tiveram suas características alteradas; o estômago, por exemplo, durante algum tempo, teve seu espaço interno preenchido. Outro exemplo de entidades pode ser encontrado no sistema educacional, tais como estudantes, professores, livros, administração (funcionários) e equipamentos. Observa-se que dentro de um sistema educacional é praxe a existência de um sistema de avaliação. Temos então um sistema dentro de outro: o sistema de fato de estar inserido no sistema educacional, é um subsistema. Subsistemas também são considerados entidades do sistema onde se encontram ABORDAGEM SISTÊMICA: Todos os sistemas conhecidos e verificados até este momento possuem alguma interação com o seu meio ambiente (trocam algo com o seu meio ambiente recebem ou enviam), sendo, portanto, conhecidos como caixas-pretas (Black Box), na verdade possuem alguma interação com o meio em que estão. Os sistemas fechados, no rigor de sua definição, não foram até o momento observados; portanto, existem apenas em teoria. Um sistema fechado funciona sem qualquer tipo de interação com seu meio ambiente, é totalmente auto-suficiente; jamais, em momento algum, precisa de algo que esteja for dele, é capaz de criar sua própria energia e elementos que venha a utilizar, bem como deve também ser capaz de cuidar dos elementos que gera (consumindo-os ou reciclado-os), como, por exemplo, o lixo, sem destinálo ao meio ambiente. As funções de um sistema dependem de sua estrutura. Elas podem ser: Deterministas Normalmente sistemas autômato, como o relógio. No seu estado perfeito de funcionamento, sabe-se exatamente o que acontecerá. Todo engenho está previamente planejado para que se cumpra a rigor um conjunto de tarefas

3 Probabilísticas Normalmente sistemas sociais (onde existam pessoas) ou sistemas biológicos. No seu estado perfeito de funcionamento, você tem uma probabilidade de saber o que poderá acontecer (como o sistema educacional você não sabe exatamente quantos alunos serão aprovados) INTERDEPPENDÊNCIA: As entidades buscam atingir o objetivo declarado do sistema ao qual pertencem; contudo, observase que, em alguns casos, os sistemas falham, não conseguem atingir seu objetivo ou ainda, o atingem apenas parcialmente. Por que ocorre tal fato? Observa-se que há dois tipos básicos de entidades em um sistema: aquela que são inerentes (próprias) ao sistema no caso do sistema educacional, como livros, carteiras, lousas, giz e aquelas que estão em trânsito pelo sistema, como alunos, professores e funcionários. E as externas, que influenciam o sistema indiretamente. Entidades com certas características (estudantes, professores, livros etc) Professores Livros Sist. de avaliação Estudantes Administração Equipamentos Entidades com novas características (estudantes, professores, funcionários etc) Figura 2 Sistema Educacional 4.0. A MODELAGEM DE SISTEMAS: Desde que foi percebido pelos profissionais de Informática que grande parte das deficiências nas especificações de sistemas era devida à problemática da comunicação, um esforço considerável tem sido realizado no sentido de se superar este problema. Para tanto, construíram-se várias propostas metodológicas, que enfatizam a necessidade de uma linguagem a ser empregada pelos analistas de sistemas, linguagem esta que pudesse ser compreendida também pelos usuários. Dentro desta linha, desenvolveram-se linguagens que passaram a incluir os recursos necessários para definir as necessidades do usuário, independentemente de qualquer restrição relativa à implementação. Este tipo de linguagem deve possuir recursos que permitam produzir uma especificação que possa ser apresentada ao usuário e com ele discutida. Um erro muito comum no passado, entre os profissionais de Informática, era a crença de que todas as necessidades de informação seriam conhecidas a priori pelos usuários. A prática mostrou que isto não era verdade, o que faz com que esta restrição deva ser considerada com o devido cuidado na solução do problema da linguagem. Na especificação dos sistemas de Informação, devem ser consideradas diversas perspectivas do problema, como nas diversas plantas do exemplo da construção da casa. As modernas abordagens enfatizam a perspectiva dos dados, não ignorando, entretanto, a importância de perspectiva das funções 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 representação

4 Assim, considerando que uma organização empresarial pode ser entendida como sendo um sistema, ela pode ser bem compreendida se apresentarmos três modelos que, conceitualmente, a representam, a partir de três perspectivas que se completam: Modelo Funcional, que apresenta uma visão estruturada das funções ou dos processos que compõem a organização; Modelo de dados, que apresenta uma visão dos dados que serão armazenados para serem usados pela organização; Modelo de controle, representando as transformações de controle e uma visão do comportamento da organização em relação aos seus diferentes estados válidos, cada um dos quais sendo caracterizado por uma determinada resposta fornecida quando a organização estiver sujeita a certo conjunto de estímulos O CICLO DE VIDA DO SISTEMA: Como toda linha de produção, o desenvolvimento de sistemas pode envolver diversas fases. Ao encadeamento das fases para construção 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 prototipação. Adotaremos para nossa explicação o primeiro destes. Simplificadamente, tomaremos como base um ciclo de vida de desenvolvimento que terá as seguintes fases, na ordem apresentada: Análise de Sistemas Implementação Projeto Implantação Implementação Modelo balbúrdia Figura 3 Ciclo de Vida Compulsório Por Análise de Sistemas entendemos a fase do desenvolvimento em que determinarão quais os requisitos do sistema, o que o sistema deve fazer, em termos essenciais. A fase de análise tem por objetivo interpretar e definir uma estrutura para um problema ainda não estruturado. Diz respeito à eficácia do sistema, ainda sem preocupações de performance. Por Projetos de Sistemas entendemos a fase do desenvolvimento em que se determinará como o sistema funcionará para atender os requisitos especificados na fase de análise. Diz respeito à eficácia do sistema, já com preocupações de performance. O objetivo desta fase é modelar o sistema, de modo a implementar a solução idealizada na fase de análise, mas de acordo com os recursos tecnológicos existentes na empresa. Por Implementação de Sistemas entendemos a fase do desenvolvimento em que será efetuada a construção do sistema de acordo com o modelo de funcionamento especificado na fase de projeto. Faz uso dos recursos tecnológicos existentes na empresa para atividades como a programação de computadores

5 O Ciclo de vida ilustrado anteriormente é um ciclo compulsório. Todo ciclo de desenvolvimento de sistemas terá pelo menos estas fases. Há quem inclua no ciclo de desenvolvimento uma fase de estudo, anterior à fase de análise, e duas outras fases após a implementação: são elas a simulação e a implantação do sistema. No modelo cascata, o desenvolvimento de um software se dá de forma seqüencial, a partir da atividade de verificação a viabilidade do desenvolvimento. Para cada etapa cumprida, segue-se a etapa imediatamente posterior, dando a idéia de uma cascata: Análise de viabilidades Análise de requisitos Projeto Implementação Testes Implantação Manutenção Figura 04 Modelo Cascata 6.0. METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS: Para haver sucesso no desenvolvimento de sistemas, torna-se necessária a utilização de uma metodologia de trabalho. Uma metodologia pode ser entendida como uma dissertação sobre a maneira de se utilizar um conjunto coerente e coordenado de métodos para atingir um objetivo, de modo que se evite, tanto quanto possível, a subjetividade na execução do trabalho. Um método pode ser entendido como um procedimento a ser adotado para se atingir um objetivo. Para tanto, o método se vale de um conjunto de técnicas. Uma técnica pode ser entendida como sendo um modo apropriado de se investigar sistematicamente um determinado universo de interesse ou domínio de um problema. Pra expressar, uma técnica faz uso de uma notação. Uma notação é um conjunto de caracteres, símbolos e sinais formando um sistema convencionado de representação ou designação. O uso de metodologias que proponham a modelagem dos sistemas é a melhor maneira de se resolverem os problemas de 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 também apresentar definição clara de quem faz o que, quando com o desenvolvimento de sistemas

6 Uma metodologia deve definir quais as fases de trabalho previstas no desenvolvimento de sistemas. Pra cada fase, quais as técnicas adotadas. São exemplos de técnicas: Análise Estruturada, Análise Essencial e Projeto Estruturado. A metodologia deve ainda, para cada técnica adotada, definir quais as ferramentas utilizadas. São exemplos de ferramentas: Diagrama de Fluxo de Dados, Diagrama Entidade-Relacionamento e Diagrama de Transição de Estados. Cada ferramenta irá produzir um tipo de modelo. São exemplos de modelos: Modelo Funcional, Modelo Conceitual de Dados e Modelo de Controle. A metodologia deve estabelecer ainda quais os pontos de controle e padrões de qualidade, alem das responsabilidades do pessoal envolvido nos controle e métricas. O quadro a seguir, mostra as principais ferramentas de modelagem na fase de análise de sistemas por três técnicas, bem como uma espécie de evolução histórica das técnicas de análise: TÉCNICAS ABORDAGENS FERRAMENTAS Análise Tradicional - Funcional - Textos - Fluxogramas Análise Estruturada - Funcional - Dados - Diagrama de Fluxo de Dados - Diagrama de Estrutura de Dados - Miniespecificação - Normalização Análise Essencial - Funcional - Dados - Controle Tabela 01 Ferramentas de Modelagem - Dicionário de Dados - Tabela de Eventos - Diagrama de Fluxo de Dados - Diagrama de Entidade Relacionamento - Diagrama de Transição de Estados - Diagrama de Estrutura de Dados - Normalização - Miniespecificações - Dicionário de Dados A Análise Tradicional é a técnica que costumava ser usada para a fase de análise, antes do surgimento da análise estruturada. Basicamente produzia um documento que, além de texto, usava, de vez em quando uma ferramenta bastante popular denominada fluxograma. A abordagem usada era quase que exclusivamente voltada para perspectiva das funções do sistema. Com o advento da Análise Estruturada, como se pode notar, passou-se a fazer um uso maior das ferramentas de modelagem, e a abordagem passou a contemplar também a perspectiva dos dados, além das perspectivas das funções. Finalmente, a Análise Essencial faz amplo uso das ferramentas de modelagem e opta por uma abordagem que contempla também a perspectiva dos controles, além das perspectivas das funções e dos dados. Assim, à medida que forma evoluindo as técnicas de analise, maior quantidade de ferramentas de modelagem passou a ser utilizada

7 7.0. PROBLEMAS NO DESENVOLVIMENTO DE SISTEMAS: Embora as ferramentas de modelagem sejam extremamente importantes, por razões diversas, na prática algumas empresas ainda relutam na sua adoção. A título de exemplo vale mencionar que uma das queixas muito comuns entre os que levam em usar as ferramentas de modelagem refere-se ao fator tempo. É que em suas avaliações acreditam que com a adoção destas técnicas, o desenvolvimento dos sistemas estende-se muito longamente. A experiência tem mostrado, até agora, que sempre que há suspeição de o desenvolvimento de um sistema foi lento por ter havido o uso de ferramentas de modelagem, estamos diante de três hipóteses em que pelo menos uma é verdadeira. São elas: 1) O prazo para o desenvolvimento foi realmente mal estimado, sendo que neste caso, o mesmo com métodos tradicionais, não se teria acertado na previsão do tempo; 2) Os profissionais que atuaram no desenvolvimento do sistema ainda não dominavam a utilização das ferramentas adotadas pela técnica. Neste caso, a suposta lentidão se deve à falta de proficiência dos técnicos no uso das ferramentas. 3) O diagnóstico que aponta perda de tempo é distorção de parâmetro, isto porque, com a utilização de ferramentas que permitem um mecanismo mais rigoroso de verificação, muitas situações específicas de níveis abstracionais mais altos como sejam as fases conceitual e lógica do sistema foram corretamente analisadas. Ora, não se pode comparar o tempo que tal análise demanda com aquele que se consumiria nas análises realizadas pelos métodos tradicionais, portanto aí não teríamos contemplado uma serie de situações que as ferramentas de modelagem apontam. Análises mais pobres podem até economizar tempo, mas não cobre a riqueza de situações que se deve identifica em análises extremamente mais abrangentes e aderentes ao mundo real O PERFIL DO ANALISTA DE SISTEMAS: O Analista de Sistemas deve possuir uma formação que vais além das disciplinas voltadas para o conhecimento de computadores. É importante, o seguinte conjunto de habilidades para uma melhor adequação para o bom desempenho na atividade de análise de sistemas de informação administrativo: - Comunicação: Entendida como a capacidade para ouvir, redigir e expor idéias com clareza e precisão, aprender e expressar o conteúdo do aprendizado com facilidade. - Capacidade de análise: Entendida como aptidão para realizar operações mentais com abstrações sobre o recorte da realidade em estudo. Possuir uma visão sistêmica e crítica do contexto em analise, além de habilidade em estudo. Possuir uma visão sistêmica e critica do contexto em análise, alem de habilidade para distinguir e conceituar categorias de significados de noções concretas e abstratas associadas ao negócio da empresa. - Conhecimento da área usuária: entendido principalmente, como aquele tipo de conhecimento que não pode ser obtido através de treinamento, mas adquirido por meio da experiência pessoal ao longo da vivencia com as operações da empresa. - Capacidade de negociação: entendida como habilidade em obter o resultado desejado, ainda que em condições adversas, e capacidade de administrar conflitos de interesse interpessoais que surjam durante o trabalho em grupo, tornando exeqüível o concurso de vontades em cooperação. - Administração de Projetos: entendida como noções sobre alocação de tempo e recursos humanos, financeiros e materiais necessários a projetos, nos quais participam pessoas de formações diferentes, num empreendimento de características interdisciplinar, procurando sempre a efetividade, - 7 -

8 garantido não só a eficácia como também a eficiência do processo de obtenção dos resultados a serem alcançados. - Conhecimento Técnico: entendido como a capacidade de especificar sistemas de informação, principalmente nas suas fases de nível de abstração mais alto, utilizando ferramentas de modelagem, especialmente as adotadas pela técnicas da análise essencial. Pode ser útil, ainda, o conhecimento das estruturas lógicas do sistema Gerenciador de Base de Dados utilizado pela empresa O APRENDIZADO E A COMUNICAÇÃO: Além de todas as qualidades pertinentes ao perfil do Analista de Sistemas, existe também uma fase de comunicação com o usuário que geram alguns gargalos num processo de comunicação. Ocorrem problemas das seguintes naturezas: - Problemas psicológicos: relacionados com percepção, atenção, motivação, atitudes, memória, hábitos de pensamento etc. - Problemas semiológicos: relacionados com o emprego de signos e códigos para comunicar: palavras, gestos, tom de voz, coisas escritas etc. - Problemas semânticos: relacionados com os significados das palavras, dos objetos e das pessoas, assim como sua interpretação. signos. - Problemas sintáticos: relacionados com a estrutura ou organização dos conteúdos e dos - Problemas cibernéticos: relacionados com retro informação e o diálogo com a quantidade de idéias transmitidas por diversos canais e com a capacidade destes para levarem sinais

9 Alcione Santos Dolavale CURSO: SISTEMAS DE INFORMAÇÃO - 4º Período - dolavale@gmail.com M Ó D U L O I I 1.0. O DIAGRAMA DE FLUXO DE DADOS: Uma importante perspectiva a ser descrita a respeito de um sistema de informação é a de suas funções. Afinal de contas, todo sistema de informações armazena e transforma dados de entrada em dados de saída. Estas transformações são realizadas pelas suas funções. Todo modelo funcional de um sistema pode ser visto como sendo formada por uma representação gráfica uma rede de funções ou processos interligados, acompanhada de uma descrição de cada função e das suas interfaces. A representação gráfica do modelo funcional costumava ser expressa através de um diagrama denominado diagrama de fluxo de dados, abreviadamente, DFD. Um diagrama de fluxo de dados é uma forma gráfica de mostrar a interdependência das funções que compõem um sistema, apresentando fluxos de dados entre elas. Mostra ainda os arquivos lógicos de dados, que são denominados depósitos de dados, bem como as entidades externas, denominação dada tanto à origem dos fluxos de dados que chegam ao sistema, como ao destino dos fluxos que dele partem O FLUXO DE DADOS: Imagine uma tarefa bem simples, como por exemplo, o preenchimento manual de um formulário denominado NOTA DE DÉBITO. Neste caso, podemos dizer que a função a ser executada é PREENCHER NOTA DE DÉBITO. Conforme dissemos, para que a função seja executada, é necessário que haja dados de entrada; no caso, um formulário de nota de débito em branco. A saída desta função será uma nota de débito preenchida. O diagrama a seguir representa esta situação: Nota de débito em branco Preencher nota de débito Nota de débito preenchida Quando estamos escrevendo no fluxo de dados Nota de débito estamos nos referindo ao conteúdo do formulário (os dados do formulários), e não ao formulário em si. Se acrescentarmos ao nosso pequeno sistema a função DIGITAR NOTA DE DÉBITO, teremos o seguinte diagrama: Nota de débito em branco Preencher nota de débito Nota de débito preenchida Digitar nota de débito Nota de débito digitada - 9 -

10 Os fluxos de dados são condutos que levam informação de um ponto do sistema para outro; mostram como os dados fluem através do sistema, o caminho percorrido pelos dados no sistema. É importante enfatizar que um fluxo de dados representa um conjunto de dados e não de fluxo de material. Portanto, não devemos confundir a nota de débito com o formulário onde os dados são preenchidos. Uma função pode ser entendida como um componente de um sistema onde somente os dados de entrada e os dados de saída são conhecidos. Não se conhece explicitamente nada a respeito do processo interno de transformação dos dados de entrada em dados de saída. As funções representam ações que o sistema executa OS DEPÓSITOS DE DADOS: No DFD anterior, temos duas funções em seqüência, onde a saída da primeira função é a entrada da segunda. Podemos então perguntar: para que a 2ª função seja executada, é necessário que a 1ª função seja executada imediatamente antes? É fácil responder que não, pois, na verdade, o que precisamos para executar DIGITAR NOTA DE DÉBITO é do formulário NOTA DÉBITO preenchido. Ao conjunto de dados armazenados denominaremos depósito de dados. Constituem a memória do sistema. Note que, em vez de representar um determinado conjunto de dados que estejam em movimento, como é o caso dos fluxos de dados, devemos criar uma maneira que estejam em movimento, como é o caso dos fluxos de dados, devemos criar uma maneira de representar dados em estado de repouso. Para tanto, usaremos a representação adiante: Nota de débito em branco Preencher nota de débito Nota de débito preenchida Nota de débito preenchida Digitar nota de débito Nota de débito digitada 1.3. AS ENTIDADES EXTERNAS: Um ambiente de um sistema pode ser entendido como o meio externo ou em torno do sistema. É delimitado pelos elementos externos que exercem influência sobre o comportamento do sistema. Se observarmos o pequeno sistema que descrevemos, podemos perguntar: - De onde vem o fluxo de dados nota de débitos? - Para onde vai o fluxo de dados nota de débito digitada? De modo a responder às perguntas acima, precisamos representar os elementos externos, que enviam e recebem informações do sistema. A esses elementos denominaremos terminais ou entidades externas. São as fontes ou destinos dos fluxos de dados que chegam e saem do sistema. Mostram as interfaces do sistema com o ambiente em que ele está inserido. Uma entidade externa pode ser, por exemplo, um órgão ou uma atividade de uma empresa ou entidade governamental, um outro sistema etc. A ilustração a seguir apresenta tais elementos: Departamento de cobrança Nota de débito em branco Preencher nota de débito Nota de débito preenchida Nota de débito preenchida Digitar nota de débito Nota de débito digitada Sistema de cobrança

11 Na figura anterior, usamos uma das maneiras de representar as entidades externas. No caso, quadriláteros, normalmente, retângulos ou quadrados. A seguir é apresentado um DFD um pouco maior onde se pode ver todos os seus elementos e componentes: 2.0. ALGUMAS CONSIDERAÇÕES SOBRE DFD: a) Os elementos componentes de um DFD são: - Funções ou processos - Fluxo de dados - Depósito de dados - Entidades externas b) Um DFD apresenta componentes externos (terminais ou entidades externas) e componentes internos (funções, fluxo de dados e depósito de dados). c) Um DFD apresenta componentes ativos (as funções) e componentes estáticos (depósito de dados). d) Um DFD pode ser visto como um modelo que apresenta as funções de um sistema e as informações necessárias a essas funções e) As informações de um sistema podem se apresentar em termos estáticos (depósito de dados) ou em movimento (fluxo de dados). f) Um fluxo de dados liga: - Uma entidade externa a uma função - Uma função a um depósito de dados - Um depósito de dados a uma função - Uma função a outra função 3.0. O DIAGRAMA DE CONTEXTO: Se considerarmos que todo sistema está circunscrito a um universo de interesse e que cada entidade externa estabelece uma fronteira entre o sistema e o ambiente em que ele está inserido, podemos afirmar que uma possível representação de um sistema é aquela em que ele se apresenta como uma única grande função, cercada pelas entidades externas que com ele interagem, por intermédio de fluxo de dados. Para ilustrar esta idéia, voltamos ao sistema que se propunha a produzir o fluxo de dados nota de débito digitada. Se observarmos a figura a seguir, podemos, por exemplo, estabelecer com uma linha dupla a fronteira do sistema:

12 Como conseqüência, pode se expressar tal sistema com o diagrama: Departamento de cobrança Nota de débito em branco Obter nota de débito digitada Nota de débito preenchida Sistema de cobrança O diagrama acima, que representa um sistema e suas interfaces, é denominado Diagrama de Contexto. Se adotarmos o mesmo procedimento para o outro exemplo apresentado, teremos:

13 E chegaremos ao seguinte diagrama: Ao analisar as duas situações mostradas, podemos concluir que: - O sistema Obter Nota de débito digitada pode ser decomposto em duas funções: 1) Preencher Nota de débito 2) Digitar Nota de débito - O Sistema de Acompanhamento da Demanda de Produtos pode ser decomposto em quatro funções: 1) Cadastrar Produtos 2) Cadastrar Fornecedores 3) Cadastrar Lista de Compras 4) Emitir Lista de Demanda Como conseqüência, podemos concluir que: - Um DFD é uma representação 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, a partir do Diagrama do Contexto, ser decomposto em diversas funções que se interligam. Note que as entidades externas no Diagrama expandido (DFD que apresenta as funções do sistema) são as mesmas de Diagrama de Contexto, no qual, entretanto, são mostrados apenas os fluxos de dados que representam a interface do sistema com as entidades externas - Para cada função do sistema podemos aplicar esse mesmo princípio e decompô-la em funções mais simples, ou seja, subfunções. Todo sistema pode ser representado como um grande processo, interagindo com o ambiente em que está inserido. Isto significa que a primeira visão de um sistema é o Diagrama de Contexto

14 4.0. COMO DESENHAR UM DIAGRAMA DE CONTEXTO? 1º PASSO) Desenhar um único processo ou função para representar o sistema inteiro: Companhia End-Vidada 2º PASSO) Desenhar todas as entidades que se comunicam com o sistema: Cliente Departamento de Planejamento Companhia End-Vidada Fornecedor Departamento Financeiro 3º PASSO) Para cada entidade externa, desenhar o fluxo de dados que mostra sua comunicação com o sistema: Há quem discuta se, em um Diagrama de Contexto, já poderiam aparecer depósitos de dados ou não. Particularmente é preferível não apresentá-los neste nível. Acredita-se que em um Diagrama de Contexto deve-se representar apenas um sistema e suas interfaces com as entidades externas

15 Alcione Santos Dolavale CURSO: SISTEMAS DE INFORMAÇÃO - 4º Período - dolavale@gmail.com M Ó D U L O I I I 1.0. NIVELAMENTO E BALANCEAMENTO DE DIAGRAMAS DE FLUXOS DE DADOS: Nivelar um DFD significa dividi-lo em processos cada vez mais detalhados. Isto significa que cada processo do DFD no nível atual pode ser expandido para tornar-se um novo DFD. Logo, o que acontece dentro de um dos processos do DFD pode ser mostrado com detalhes em outro DFD. Podemos considerar então, que estamos diante de um processo de decomposição sucessivo e hierárquico, que toma a forma de uma rede onde cada nó (função ou processo) pai pode ser decomposto em outra rede de funções filhas com os respectivos fluxos de dados e depósito de dados do nível imediatamente inferior, e assim sucessivamente, até que não possa mais ser decomposta. A função que não possa mais ser decomposta é denominada função primitiva ou primitiva funcional. Trata-se de uma função básica ou atômica que não possa mais ser subdividida. Em resumo, todo DFD pode ser decomposto em DFDs de nível inferior, recursivamente, até alcançarem-se as primitivas funcionais. Trata-se de uma fatoração hierárquica. A ilustração a seguir, nos mostra esta situação: Figura 1 Nivelamento do DFD

16 Apresentamos inicialmente, um Diagrama de Contexto do sistema, onde: As entidades externas estão representadas por E1, E2, E3 e E4. Os fluxos de dados são representados como FD1, FD2, FD7 e FD8. No passo seguinte, é exibido o primeiro nível de particionamento do sistema, onde: Os processos (funções) do sistema são representados por P1, P2, P3 e P4. Além dos fluxos de dados já apresentados, aparecem ainda FD3, FD4, FD5 e FD6. Em seguida, é ilustrada a decomposição do processo P3, onde: Aparecem processos com as denominações P3.1, P3.2 e P3.4. É apresentado ainda um depósito de dados entre os processos P3.1 e P3.3. Aparecem entidades externas com as denominações P1, P2 e E ALGUMAS OBSERVAÇÕES QUE SE FAZEM NECESSÁRIAS: a) Um sistema de tamanho razoável, normalmente não deve ser modelado em um único DFD, pois o modelo poderia ficar ilegível. b) Para resolver este problema, são construídos DFDs representando o sistema em sucessivos níveis de detalhe, chamados níveis de abstração. A esta estratégia costuma-se chamar nivelamento. Na figura anterior foram apresentados três níveis de abstração. Cada DFD representa o detalhamento (explosão) de DFD de um nível imediatamente superior. Uma maneira de identificar os níveis de abstração é numerá-los em ordem seqüencial, tal como nível zero, nível 1, nível 2, nível 3 etc. c) Sempre que ocorre particionamento, deve ser garantida a consistência entre as entradas e saídas de cada dois níveis de particionamento sucessivos. Em outras palavras, há uma espécie de conservação da energia ou conservação dos dados, no sistema. A esta necessidade costuma-se chamar balanceamento DICIONÁRIO DE DADOS: Um dicionário de dados é um repositório de informações sobre os componentes dos sistemas. Para descrever os componentes do sistema, devemos adotar uma linguagem apropriada. Várias formas podem ser usadas para, por exemplo, apresentar os dados de dum fluxo de dados. Para as especificações, usaremos os seguintes símbolos: SÍMBOLO SIGNIFICADO = é equivalente a { } ou * (min-max) repetições [ ] chave % % comentário

17 3.0. DESCRIÇÃO DOS FLUXOS DE DADOS: Seja mostra a composição do fluxo de dados denominado FATURA-CLIENTE do DFD a seguir: Figura 2 DFD da Cia.End-Vidada fatura-cliente = produto = ender-cliente = NUM-FATURA cod-cliente ender-cliente produto *(1-10) VALOR-TOTAL-FATURA COD-PRODUTO PREÇO-UNITÁRIO QTDE-PEDIDA VALOR-TOTAL-PRODUTO RUA NÚMERO COMPLEMENTO NOME-BAIRRO [CEP] SIGLA-UF % Sigla da Unidade da Federação % TELEFONE % Telefone para contato, inclui DDD % cod-cliente = {CPF-CLIENTE % CPF, se pessoa física % CGC-CLIENTE} % CGC, se pessoa jurídica %

18 Como se pode notar foi usado letras maiúsculas para identificar dados elementares (que não podem ser decompostos), ao passo que foram usadas letras minúsculas 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 em outras estruturas ou em dados elementares, ou, ainda, uma combinação dos dois. A leitura da descrição nos dá conta que: fatura-cliente são estruturas de dados, enquanto VALOR-TOTAL-FATURA e RUA são dados elementares. produto é uma estrutura que pode ocorrer no mínimo uma vez até o máximo 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 explicação para ilustrar o uso do símbolo que expressa um comentário. Para exemplificar a utilização do símbolo que serve para expressar o caso em que apenas uma das alternativas é válida, foi apresentada a definição de cod-cliente que, dependendo do tipo de cliente, pode ser identificado pelo CPF ou pelo CGC. De uma maneira rudimentar, pode-se imaginar o dicionário de dados como sendo um fichário que contém uma ficha para cada componente do sistema, como na figura a seguir: Figura 3 Supostas fichas de Dicionário de Dados Hoje em dia existem no mercado diversos sistemas automatizados de dicionários de dados, com inúmeros recursos disponíveis. Basta apenas conhecer o conceito e usar o que esteja disponível em sua instalação. Além disso, com a evolução dos softwares do tipo CASE ( Computer Aided Software

19 Engeneering ), que servem de apoio ao desenvolvimento de sistemas, já se pode ter um auxílio bastante grande na tarefa de documentação. Nos CASEs já costuma vir embutido um dicionário de dados DESCRIÇÃO DOS DEPÓSITOS DE DADOS: Seja o trecho do DFD mostrado na figura a seguir: Figura 4 DFD para incrementar estoque Para descrever os depósitos de dados usando-se a linguagem de descrição de dados por nós definida, teremos: loja = livro = estoque-loja = ender-loja TÍTULO-LIVRO NOME-AUTOR-PRINCIPAL QTDE-EM-ESTOQUE NÍVEL-DE-REPOSIÇÃO RUA NÚMERO COMPLEMENTO NOME-BAIRRO [CEP] SIGLA-UF % sigla da Unidade da Federação % TELEFONE % telefone para contato, inclui DDD %

20 Alcione Santos Dolavale CURSO: SISTEMAS DE INFORMAÇÃO - 4º Período - dolavale@gmail.com M Ó D U L O I V 1.0. NOMEAÇÃO DOS COMPONENTES DO DFD: a) Nome de função ou processo: - Deve ser formado por um verbo transitivo (significa a ação a ser executada) no modo infinitivo seguido de um complemento. - Os nomes das funções não se confundem com os de seus executores. - Deve descrever o objetivo da função. - Toda função deve ser nomeada a partir da saída que ela produz. - Verbos como produzir, emitir, cadastrar, extrair, criar, calcular e computar são melhores para nomear uma função. - Exemplos: Emitir-lista-de-demanda, Cadastrar-fornecedores. b) Nome de deposito de dados: - Usam-se substantivos simples ou compostos. - Como representa a memória do sistema, ou seja, os arquivos, é comum usar nomes no plural, para significar um conjunto de registros. - Representa uma estrutura de dados. - Exemplo: Produtos, Encomendas-do-cliente, Lista-de-compras, Fornecedor. c) Nome do fluxo de dados: - Usam-se substantivos simples ou compostos. - Representa uma estrutura de dados. - Exemplo: Lista-de-demanda, Relatório-de-vendas, Encomenda-do-cliente. d) Nome de entidades externas: - Usam-se substantivos simples ou compostos. - Representa o conjunto de entidades (pessoas, coisas, órgãos, sistemas etc) do ambiente externo que tem o mesmo tipo de interface com o sistema. - Exemplo: Cliente, Sistema-de-Credito, Fornecedor, Diretoria CONSIDERAÇÕES GERAIS SOBRE DFD s: - Adotar os mesmo nomes utilizados pelos usuários. - Manter padrões gráficos (forma, tamanho e estilo). -Todos os fluxos de dados, depósitos de dados e processos devem ser nomeados com precisão. - Equilibrar o cruzamento de linhas com repetições de componentes de DFD. - Balancear fluxos dos DFD com seus processos pai. - Equilibrar níveis de decomposição de processos. - Especificar todos os processos primitivos do DFD. - Desenhar DFD s, de preferência, entre cinco e nove processos

21 - Cada diagrama deve ocupar apenas uma página. - As pessoas que conhecem as funções do sistema devem aprovar o modelo apresentado PSEUDOCÓDIGO: Uma forma textual alternativa e mais popular de se descrever miniespecificações de forma quase idêntica ao português estruturado, é o pseudocódigo. O mesmo contém: - Verbos (LER, OBTER, IMPRIMIR, GRAVAR etc) - Substantivos (elementos do dicionário de dados) - Estruturas de controle (SE, ENQUANTO, REPETIR, CASO) - Operadores de relação (IGUAL, MAIOR QUE, MENOR QUE etc) Uma comparação entre os dois modos de descrição é apresentada por L. Peters: PORTUGUÊS ESTRUTURADO Orientado para os procedimentos Usa termos familiares ao usuário (linguagem da empresa) O objetivo é um alto nível de comunicação PSEUDOCÓDIGO Orientado para implementação Lembra linguagem de programação O objetivo é facilitar a programação Tabela 1 Comparação de formas textuais EXEMPLO DE PSEUDOCÓDIGO: EMITIR FATURAS-MENSAIS DE CARTÕES DE CRÉDITO: Inicializar programa (abrir arquivos, acertar contadores) Ler registro-de-cartão-de-crédito REPETIR-ENQUANTO existam registros-de-cartão-de-crédito REPETIR-ENQUANTO existam intes-de-compra-no-cartão-de-crédito Calcular total-de-item Somar total-de-item ao total-da-fatura-mensal FIM-REPETIR Calcular desconto Calcular fatura-liquida; total-a-pagar Imprimir fatura-mensal Gravar fatura no arquivo de faturas Ler registro-de-cartão-de-credito FIM-REPETIR Terminar programa

22 2.0. TABELA DE DECISÃO: Tabela de decisão é uma maneira de expressar, em forma de tabela, qual o conjunto de condições que é necessário ocorrer para que um determinado conjunto de ações deva ser executado. O cerne de uma tabela de decisão é determinada regra de decisão, a qual define o conjunto de ações a ser tomado, a partir de um conjunto de condições. Formato da tabela de decisão: CONDIÇÕES Condição 1 Condição Condição N Regra de decisão 1 Regra de decisão 2... Regra de decisão N AÇÕES Ação 1 Ação Ação N 2.1. COMPOSIÇÃO DA TABELA DE DECISÃO: Uma tabela de decisão é composta de: - Uma área de condições, onde são relacionadas as condições que devem ser verificadas para que seja executado um conjunto de ações. - Uma área de ações, que exibe o conjunto de ações que deve ser executado caso um determinado conjunto de condições ocorra. - Regras de decisão, representadas pelas colunas, que apresentam a combinação das condições com as ações a serem executadas. CONDIÇÕES Regra de decisão 1 Regra de decisão 2 Regra de decisão 3 Regra de decisão 4 Condição 1 S S N N Condição 2 S N S N AÇÕES Ação 1 X Ação 2 X X Ação 3 X X X Onde: S = Sim; e N = Não; X = Ação a ser executada

23 Por exemplo, a tabela anterior é lida da seguinte maneira: - Regra de decisão 1: caso as condições 1 e 2 ocorram, deverão ser executadas as ações 1 e 3 - Regra de decisão 2: caso a condição 1 ocorra e a condição 2 não ocorra, somente deverá ser executada a ação 2. - Regra de decisão 3: caso a condição 1 não ocorra e a condição 2 ocorra, deverão ser executadas as ações 2 e 3. - Regra de decisão 4: Caso as condições 1 e 2 não ocorram, deverá ser executadas só a ação 3. Uma das características importantes de uma tabela de decisão é a de se poder determinar com exatidão a quantidade de regras de decisão que fará parte da tabela. Isto se obtém a partir do produto do conjunto de possibilidades para cada condição. Por exemplo: Caso haja um conjunto de três condições, onde cada uma delas tenha duas possibilidades. Condição 1: tem 2 possibilidades, Condição 2: tem 2 possibilidades e Condição 3: tem 2 possibilidades. Logo, o que dá um total de 2 x 2 x 2 = 8 regras de decisão

24 Alcione Santos Dolavale CURSO: SISTEMAS DE INFORMAÇÃO - 4º Período - dolavale@gmail.com M Ó D U L O V 1.0. O MODELO CONCEITUAL DE DADOS: O valor de um modelo conceitual de dados é função de sua aderência à realidade do mundo que ele se propõe a representar. Antes de pensarmos em implementação, é necessário que tenhamos uma descrição da realidade tão fielmente retratada quanto possível. Uma técnica de modelagem de dados deve procurar capturar os conceitos semânticos do ambiente a ser modelado, bem como expressar-se em uma linguagem (notação) que facilite a percepção do usuário a respeito da organização da realidade que o cerca. Além disso, o método proposto deve permitir também que se possam estabelecer agrupamentos das classes de entidades do mundo real sob diversas formas de agregação, tais como por sistemas, por funções, por órgãos ou por qualquer outra forma de agregar entidades inter-relacionadas. Podemos então, estabelecer que o método de modelagem conceitual de dados satisfaça aos seguintes requisitos: a) Expandir a habilidade do analista no reconhecimento dos requisitos de informação. b) Capacidade de capturar ao máximo a semântica do mundo real durante o próprio processo de modelagem c) Facilidade de entendimento, através de uma representação pragmática, que possa inclusive, ser entendida por usuários não técnicos de informática d) Possibilidade de mapeamento (leia-se transformação) direto do modelo conceitual para o modelo lógico relacional. e) Possibilidade de uma abordagem que contemple a modelagem de dados de maneira integra com a modelagem das funções. f) Permitir a derivação do modelo de funções a partir do modelo de dados e vice-versa. Os quatro componentes primitivos do modelo, que representam o mundo real, são entidades, relacionamentos, atributos e domínios ENTIDADE: 1 Aquilo que constitui a essência de uma coisa, existência, individualidade. 2 Tudo quanto existe ou pode existir RELACIONAMENTO: Dentro do contexto de um sistema as classes de entidades relacionam-se entre si. Pode-se inclusive definir relacionamento como um mapeamento (regra de associação entre dois conjuntos), entre duas classes de entidades. Por exemplo: o relacionamento que expressa todas as encomendas feitas a um fornecedor, pode ser expresso: - Fornecedor fornece encomenda - Encomenda é fornecida por Fornecedor

25 Os atributos podem ser classificados segundo algumas características, conforme a tabela a seguir: CARACTERÍSITCA Único Obrigatório Simples Univalorado Derivado Identificador ALTERNATIVA Não Único Opcional Composto Multivalorado Não Derivado Não Identificador 4.0. DIAGRAMA DE ENTIDADE-RELACIONAMENTO: Seja o seguinte banco de dados pessoal, aqui representado pelas classes de entidades EMPREGADO e DEPARTAMENTO, onde João, Maria, Afonso, José, Pedro e Ana são as entidades da classe EMPREGADO; e Depto-A, Depto-B e Depto-C são as entidade da classe DEPARTAMENTO. Podemos visualizar tal situação da seguinte maneira na figura a seguir: Figura 1 Relacionamento da Classe EMPREGADO com DEPARTAMENTO Pela figura anterior, temos que: - Os empregados João e Maria pertencem ao Departamento Depto-A. - Os empregados Luiz e Ana pertencem ao Departamento Depto-B. - Os empregados Afonso, José e Pedro pertencem ao Departamento Depto-C. Outro aspecto que podemos observar é o relacionamento entre as classes de entidades EMPREGADO e DEPARTAMENTO. Tal relacionamento mostra um mapeamento entre as duas classes de entidades. A cada entidade da classe EMPREGADO pode estar associada apenas uma única entidade da classe DEPARTAMENTO. Por outro lado, a cada entidade da classe DEPARTAMENTO corresponde pelo menos uma entidade da classe EMPREGADO

26 Adotemos como premissas básicas que: I) Somente classe de entidades possuem atributos. II) Toda classe de entidades possui pelo menos 1 atributo ou conjunto de atributo que sirva como identificador. III) Em toda classe de entidades não haverá atributos que não sejam exclusivos daquela classe. Uma exceção é feita para os atributos que servirem como elementos de ligação (atributos relacionantes ou referenciais) com outras classes de entidades, os quais poderão ser comuns. IV) No contexto do sistema, nenhuma classe de entidades a ele pertence existe isoladamente. Deverá sempre estar ligada a pelo menos uma outra classe de entidade, através de um relacionamento, o qual é materializado através de atributos comuns, como descrito na premissa anterior. V) Entre cada duas classes de entidades deverá ser expresso um único relacionamento. Isto é sempre possível, usando-se a técnica de modelagem que vamos adotar. Figura 2 Exemplo de DER 1 Os retângulos representam classes de entidades. Assim, Empregado e Departamento são classes de entidades 2 As linhas que ligam uma classe de entidades a outra representam os relacionamento entre as classes de entidades. Os símbolos nas extremidades das linhas mostram o tipo de mapeamento válido entre as duas classes de entidades. Os símbolos que representam o tipo de mapeamento e seu respectivo significado são apresentados a seguir: Figura 3 Associação das Entidades

27 Na figura a seguir, exibiremos um exemplo para ilustrar o uso das regras apresentadas. Figura 4 Exemplo de uso das regras A leitura do exemplo da figura acima nos informa que: - A cada empregado deve, obrigatoriamente, estar associado um único departamento. - A cada departamento deve, obrigatoriamente, estar associado pelo menos um empregado. - A cada dependente deve, obrigatoriamente, estar associado um único empregado. - A cada empregado podem estar associados vários dependentes. - Um determinado empregado pode não estar associado a nenhum dependente. - A cada cônjuge deve, obrigatoriamente, estar associado um único empregado. - A cada empregado pode estar associado um único cônjuge. - Um determinado empregado pode não estar associado a nenhum cônjuge. Além das linhas e retângulos, podem-se ainda apresentar no DER os atributos de cada classe de entidades. Isto é feito através de linhas perpendiculares partindo dos lados do retângulo que representa a classe de entidade da forma a seguir: Figura 5 Representação dos atributos na classe de entidade As linhas que apontam para atributos que fazem parte do identificador da classe de entidade têm, na sua extremidade, um círculo cheio, enquanto as linhas que apontam para atributos que não fazem parte do identificador terão na extremidade um círculo vazio. Na figura anterior, o identificador da classe de entidades EMPREGADO é o atributo Num-Matrícula

28 Alcione Santos Dolavale CURSO: SISTEMAS DE INFORMAÇÃO - 4º Período - dolavale@gmail.com M Ó D U L O V I 1.0. ESTUDO DE CASO: SISTEMA DE BIBLIOTECA: Por meio deste estudo de caso, embora ainda considerando um ambiente imaginário, uma vez que os requisitos listados a seguir não foram oriundos de uma situação real, a partir da coleta das informações em campo, mas criados com o propósito de permitir a especificação de um pequeno projeto para efeito didático, procurando-se reforçar os conceitos já expostos anteriormente, de acordo com o método da Análise Essencial. O levantamento de requisitos para um sistema de consulta, reserva e locação de acervo de uma biblioteca verificou quais são os desejos do usuário e que o software a ser desenvolvido deverá disponibilizar. São elas as seguintes funcionalidades: - Possibilitar o cadastro de exemplares de diferentes tipos de obras tais como: - Livros - Periódicos - Dissertações - Teses - Relatórios técnicos (pesquisas) - CD-ROM - DVD-ROM - Blu-Ray - Vídeo (nos vários tipos e formatos) - Deixar previsto de forma flexível a possibilidade da inclusão de novos tipos de obras - Prever um cadastro com informações básicas e de contato para os usuários. - Permitir consultas ao acervo existente, bem como informar sobre sua disponibilidade ou não. - Obras que tenham mais de um exemplar podem aceitar reservas. - Possibilitar o empréstimo de obras que tenham mais de um exemplar na biblioteca, salvo nas situações descritas a seguir: - Quando a obra tratar-se de um periódico (só pode ser consultada nas dependências da biblioteca) - Quando o usuário da biblioteca já tiver em seu poder mais de 5 obras emprestadas. - Quando o usuário estiver em atraso há mais de 4 dias quanto a devolução de eventuais obras que estejam sob seu poder. Se a obra emprestada tiver sido antecipadamente reservada, no momento do empréstimo deve ocorrer a baixa do registro de reserva - Registrar a devolução das obras emprestadas - Identificar os usuários com devolução em atraso a mais de x dias, onde x deve ser variável; tais usuários devem ser variáveis; tais usuários devem ser notificados através de um ou carta