Baixe o app para aproveitar ainda mais
Prévia do material em texto
1 CAP I - Conceitos Básicos do Desenvolvimento de Sistemas de Software Sistema de Software Sistema de Software é um conjunto de unidades de programa e de dados que funcionam interligadas para realizar uma ou mais tarefas de processamento. Exemplos: - Sistema Acadêmico - Sistema de conta corrente bancária - Sistema de um caixa automático bancário - Sistema de controle de satélites Complexidade dos sistemas de software: Conjuntos dos problemas, informações, pessoas, coisas, eventos, políticas das instituições, custos, benefícios etc. relacionados com sistemas de software. Abstração É a capacidade que o homem tem de considerar (descrever, representar, imaginar) somente o que interessa no momento. Ex: Uma cidade para sua Prefeitura : Tamanho e tipo do imóvel Se tem ou não água encanada Se tem ou não coleta de lixo Se tem ou não calçamento na rua Ex.: Uma cidade para a Clínica Veterinária : Qual é o tipo de animal doméstico Nome e endereço do dono Dados 1 Prog 1 Dados 2 Prog 2 Dados n Prog n 2 Modelo É a representação de algo de interesse com a utilização da abstração e de um conjunto de regras e critérios (técnicas). Ex. Aeromodelo (miniatura de avião) Maquete de um edifício Planta baixa de uma cada Desenho da fachada da casa Observe-se que o modelo será diferente se o “interesse” mudar ou se as “regras” mudarem. Modelos de sistema de software a) Modelo Descritivo É um texto que descreve o sistema (regras da linguagem usada) b) Modelo Conceitual Representa quais as informações são importantes ao sistema usando um conjunto de regras e critérios (de uma determinada técnica). Exemplos: - Diagrama de Fluxos de Dados (DFD) - Diagrama de Entidades e Relacionamentos (DER) c) Modelo Lógico (Operacional) Representa a estrutura e a forma de manipulação das informações. Exemplos: - Fluxograma; - Tabela. d) Modelo Físico Representa como se realiza o processamento propriamente dito. Exemplos: - Programas (seqüências de instruções, códigos, etc); - Arquivos de dados. Processo de Desenvolvimento / Modelos De forma simplificada, um processo de desenvolvimento consiste das etapas (ou atividades) que devem ser realizadas para o desenvolvimento de sistemas de software. 3 Modelo Descritivo Modelo Conceitual Modelo Lógico Modelo FísicoInformações do Mundo Real Menos Detalhes Mais Detalhes Modelo X Foco de Interesse Nível Conceitual Nível Lógico Nível Físico Nível de Detalhes FUNÇÕES Ex.: Calcular a média das Notas DADOS Ex.: Nome e Notas EVENTOS Ex.: Chegada de Dados dos Alunos 4 Ciclo de Vida do Sistema de Software (abordagem clássica – simplificada) Especificação e Análise Projeto e Implementação Uso e Manutenção “O que” “Como” Ciclo de vida de um sistema de software é o período que vai desde o início do desenvolvimento do sistema até o instante que ele deixa de ser usado e é substituído por um novo sistema. Um sistema chega ao seu fim de vida útil porque: a) poderá se tornar obsoleto porque as adaptações não conseguiram acompanhar as alterações e necessidades do mundo real; b) tantos “remendos” forma feitos no sistema que não compensa mais fazer “novos remendos”, porque a cada remendo fica mais difícil fazer novos remendos. 5 Custo das alterações e correções Fases Custo Análise Projeto Implementação Uso Portanto, é interessante gastar um esforço maior nas fases de análise e de projeto. O Princípio “Dividir para conquistar” Dividir um problema em partes, para que resolvendo cada uma delas, o todo possa ser resolvido. Parte 1 Parte 2 Parte 3 Parte 4 Observações: 1 - As interfaces entre as partes devem ser simples. 2 - As partes devem compor o todo, sem falta e sem excesso. 3 - Se dividir pouco, as partes resultantes podem ser tão complexas como o todo. 4 - Se dividir demais, o conjunto das interfaces entre as partes poderá se tornar muito complexo e a tarefa de gerenciar as partes também. Exemplo: Sistema para gerenciar uma empresa Partes: Subsistemas de produção 6 Subsistema de pessoal Subsistema de contabilidade e finanças Subsistema de compra e almoxarifado Subsistema de vendas e marketing Exemplo: Modelo de um sistema de software Partes: Modelo Descritivo Modelo Conceitual Modelo Operacional Modelo Físico Participantes (envolvidos) do Projeto Equipe de Desenvolvimento: Gerente de Projeto Analistas/Projetista Programador Cliente (É o patrocinador, é quem paga as contas, ou um representante seu) Usuários (São as categorias de pessoas que irão utilizar diretamente o sistema de software) 7 CAP 2 – Modelagem Funcional Para desenvolver um sistema de software é necessário definir o que o sistema deverá realizar considerando que poderá realizar tarefas de processamento tais como: Receber dados externos Armazenar dados e depois recuperar Manipular dados (comparar, calcular, selecionar, alterar, apagar, etc) Visualizar dados Enviar dados para outros sistemas Se as fronteiras do sistema e o que ele deverá fazer forem definidos com um primeiro nível de quebra (com partes bem definidas) todos os demais trabalhos seguintes de desenvolvimento ficarão facilitados porque os trabalhos poderão estar concentrados em cada uma das partes e não necessariamente no sistema todo. Inicialmente essas partes podem ser definidas no nível conceitual, ou seja, sem a preocupação de detalhes de como elas serão implementadas (codificadas e fisicamente armazenadas) abstraindo-se desses detalhes e ficando num nível mais alto de abstração. A modelagem funcional objetiva representar a quebra do sistema nas principais funções de processamento e nas principais entidades de dados que sistema deverá ter para realizar as suas tarefas. Além disso, representar os principais dados de entrada e de saída do sistema e de onde virão e para onde irão esses dados. Portanto representar as fronteiras do sistema e a suas partes mais importantes para o seu funcionamento. A técnica utilizada neste capítulo consiste na utilização de DFDs para representar o sistema. DFD significa Diagrama de Fluxos de Dados, uma técnica baseada em DFDs é bastante antiga e consolidada e ainda hoje é usada por muitas empresas de desenvolvimento de software. È uma técnica do tipo “estruturada” porque mantém uma organização hierárquica entre funções de processamento onde cada função é parte de outra função do DFD de nível mais alto. O DFD é um modelo conceitual que representa os aspectos do sistema (ou uma parte dele) relacionados com o software, mostrando-os sob a forma de: entidades externas, os fluxos de dados, as funções de processamento e os depósitos de dados. Características: a) Simplicidade; b) Pode ser usado para representar todo o sistema como também parte dele; 8 c) Pode ser usado para representar diferentes níveis de abstração (com menos ou com mais detalhes). - Notação / Elementos Fluxo de Dados: Seta no DFD representa o caminho de um (ou mais) conjunto de dados que flui da origem para o destino. Nome do conj. de dados O nome deve representar os dados que fluem no fluxo. (Obs. não pode ser verbo). É comum representar vários conjuntos de dados em um mesmo fluxo: Por exemplo: Nome 1 Nome 2 Nome 3 Onde cada nome representa um conjunto de dados queflui no fluxo de acordo com o sentido da seta. OBS: Quando é óbvio qual conjunto de dados que flui pelo fluxo costuma-se não escrever o nome desse conjunto para melhorar a clareza do modelo. O fluxo de dados terá sempre como origem ou destino dos dados uma função de processamento. Função de Processamento (ou processo DFD): Representa uma parte do processamento do sistema (tarefa de processamento de dados) que futuramente será transformado em códigos de programa. Normalmente uma função representa as transformações de dados que chegam a ela para produzir os dados que saem dela através dos fluxos de dados. No DFD a função de processamento será denotada pela figura: 9 Identificador (Número ou código) Nome da Função (verbo + complemento) O nome da função deve representar a tarefa de processamento mais importante (para a regra do negócio) que ela representa e estar sob a forma de verbo + complemento (porque representa ações). Por exemplo: “Receber pedido” ( porque representa as ações de visualizar dados de produtos, ajudar o cliente selecionar e montar a relação dos produtos que interessam além de armazenar o pedido ) Depósito de dados Representa os dados que o sistema terá que manter armazenado a respeito de um tipo de entidade ( e que futuramente serão implementados como uma tabela do BD ou eventualmente um arquivo de dados do disco). Nome do depósito de dados Identificador (número ou código) O nome do depósito de dados poderá ser o nome da entidade (ou tipo das entidades) cujos dados estão armazenados no depósito. Exemplos: Livros Entidades externas Representam entidades do domínio do problema (externa ao sistema) que interagem diretamente com o sistema, ou seja, recebem dados e/ou enviam dados para o sistema. Poderá ser uma pessoa (cliente, funcionária, gerente, vendedor), outro sistema, ou um equipamento. Nome (da entidade externa) 10 - Diagrama de Contexto do Sistema No diagrama de contexto é um modelo inicial onde sistema como um todo é representado por uma moldura semelhante à representação de uma função de processamento. Além disso, são representadas também as entidades externas e os fluxos de dados entre o sistema e essas entidades externas e os nomes dos dados que fluem por esses fluxos. Objetivos do Diagrama de Contexto: a) Representar uma visão externa global do sistema de software a ser desenvolvido b) Definir as fronteiras do sistema de software. c) Representar os diálogos entre o sistema e as entidades externas, ou seja, os dados que entram e saem do sistema. d) Ser o primeiro passo para a construção do DFD_Sistema. 2.2.1 - Exemplo: Diagrama Contexto – Sistema de Software de uma Livraria Missão do Sistema de Software : “ Auxiliar a venda de livros para clientes remotos, recebendo pedidos pela Internet e enviando os livros por reembolso postal ” DESCRIÇÃO DO SISTEMA Através da Internet o cliente poderá visualizar a relação dos livros disponíveis na Livraria e fazer o pedido de compra de um ou mais livros. Para fazer o pedido o cliente fornecerá os dados pessoais para ser cadastrado como um novo cliente ou para atualizar o cadastro se já for cliente. Posteriormente o pedido será analisado por uma funcionária que deverá verificar se os livros relacionados no pedido existem no estoque da livraria e verificar no cadastro se o cliente não tem problema de dívidas anteriores O pedido aceito será tratado pelo setor de expedição onde será impressa a nota fiscal. Os livros relacionados no pedido serão embalados e enviados para o correio juntamente com a nota fiscal. O pedido que apresentar problema será rejeitado e posteriormente examinado pelo gerente para tomar uma decisão sobre o caso. Se o problema for por motivo de falta de pagamento o gerente poderá consultar o SERASA através da Internet e obter informações adicionais à respeito do cliente ou, até mesmo, falar com cliente pelo telefone. Se o gerente decidir por aceitar o pedido, este seguirá seu processamento normal. Caso contrário, o pedido será descartado. Os casos de falta de livro no estoque da Livraria serão registrados pelo sistema e posteriormente examinados pelo gerente. Através da Internet o gerente enviará os pedidos de aquisição dos livros em falta junto às editoras fornecedoras. Os livros recebidos das 11 editoras darão entrada no estoque onde o fato será registrado no sistema por um funcionário e os dados dos livros atualizados. OBS: A figura abaixo mostra como exemplo o diagrama de contexto do software da livraria. Os critérios práticos para construir diagramas de contexto serão apresentados no item 2.2.2. Aplicação desses critérios na construção do diagrama de contexto da livraria será mostrada no item 2.2.3. 12 Diagrama de Contexto – Sistema de Software de uma Livraria Liv Ped Cli Resu_P Ped Cli Consu R_Consu Ped_Rej Ped_Ok Cli Data R_Consu Consu Resu_F Liv_F Edit Ped_Aq Ped_Aq Ped_Aq Liv_Rec LEGENDA DOS CONJUNTOS DE DADOS QUE ENTRAM E SAEM DO SISTEMA ATRAVÉS DOS FLUXOS: LIV : Relação de livros com nome, autor, editora, ano, preço e qtde PED : Pedido de livros desejados e quantidades CLI : Dados do Cliente RESU_ P : Resultado da análise do pedido (OK ou rejeitado) CONSU : Consulta ao Serasa sobre um cliente R_CONSU : Resposta da Serasa à consulta feita PED_REJ : Pedido rejeitado RESU_F : Resultado final de um pedido rejeitado LIV_F : Livros em falta CLIENTE SERASA GERENTE EDITORA FUNC VENDAS FUNC_ EXPEDIÇ ÃO FUNC_ES TOQUE 13 EDIT : Editoras PED_AQ : Pedido de aquisição de livros junto às editoras LIV_REC : Dados dos livros recebidos da editora DATA : Data da emissão da nota fiscal 2.2.2 - Critérios práticos para a confecção do Diagrama Contexto 1º) Desenhar a moldura que representa os limites do sistema de software de maneira que o diagrama resultante venha a ocupar bem toda a página. 2º) Identificar as entidades externas e os diálogos entre essas entidades e o Sistema. 3º) Conte a quantidade total de diálogos. Se for maior do que 10 verificar quais diálogos poderão ser agrupados de modo que essa quantidade total fique num valor desejado. 4º) Cada diálogo corresponderá, em princípio, a um fluxo de dados (exceto quando diálogos forem agrupados). 5º) Desenhar os fluxos de dados e as entidades externas maneira espalhada ao redor da moldura do sistema (evitando a parte superior) para que o resultado seja um diagrama fácil de ser entendido. OBS: Usando papel de tamanho A4, a quantidade total de fluxos entre entidades externas e o sistema não deve ultrapassar a quantidade de 10 fluxos porque quando o diagrama de contexto for transformado em um DFD-Sistema poderá resultar em um diagrama difícil de ser entendido. 2.2.3 - EXEMPLO: Diálogos e fluxos no Sistema de Software de uma Livraria a) Entre Cliente e o Sistema : 1º diálogo: O sistema mostrará a relação de livros e o cliente retornará com os dados de pedido de livros. Liv Ped 2º diálogo: O cliente enviará seus dados para o Sistema, ou se ele já for cadastrado, receberá os seus dados do Sistema e retornará com elesatualizados. Cli b) Entre Serasa e o Sistema 14 1º diálogo: O sistema envia a consulta ao Serasa e recebe uma resposta à consulta feita. Consu R_Consu c) Entre o Gerente e o Sistema 1º diálogo: O Gerente recupera no sistema o pedido rejeitado, os dados do cliente que fez esse pedido e envia para o sistema a sua decisão sobre o pedido rejeitado como um resultado final. Ped_Rej Cli Resu_F 2º diálogo: O gerente envia através do sistema uma consulta ao Serasa e recebe uma resposta. R_Consu Consu 3º diálogo: O Gerente recupera do Sistema os livros em falta e a relação das Editoras para retornar ao Sistema o pedido de aquisição de novos livros. Liv_F Edit Ped_Aq d) Entre Editora e o Sistema 1º diálogo: A Editora recebe do Sistema o pedido de aquisição dos livros em falta Elaborado pelo gerente Ped_Aq . e) Entre a funcionária de vendas e o Sistema 1º diálogo: A Funcionária de vendas visualiza pelo Sistema o pedido, os dados dos livros e os dados do cliente para produzir e enviar para o Sistema o resultado da análise do pedido. Ped Liv, Cli Resu_P f) Entre o funcionário de expedição e o Sistema 1º diálogo: O Funcionário de expedição visualiza pelo Sistema o pedido aprovado, os dados do cliente e fornece ao Sistema a data para a emissão da nota fiscal. Ped_ok 15 Cli data g) Entre o funcionário do estoque e o Sistema 1º diálogo: O Funcionário do estoque visualiza pelo Sistema o pedido de aquisição para conferir os livros recebidos da editora e fornece ao Sistema os dados dos livros recebidos para atualizar a relação dos livros. Ped_Aq Liv_Rec TOTAL DE FLUXOS Como foram 10 os diálogos identificados poderíamos manter a correspondência de de um fluxo para cada diálogo. Entretanto, para este exemplo alguns diálogos serão agrupados para a formação dos fluxos ( a título de exemplo e para obter no final um diagrama menos detalhado). Dessa forma: a) Os dois diálogos entre Cliente e Sistema serão agrupados para forma um único fluxo considerando-se esses dois diálogos são muito relacionados, ou seja, para o pedido ser feito será sempre necessário que os dados do cliente estejam atualizados. Liv Ped Cli Os dois primeiros diálogos entre o gerente e o Sistema também serão agrupados considerando que ambos se referem ao tratamento do pedido rejeitado na análise. Ped_Rej Cli Resu_F R_Consu Consu Resu_F Desenhando as entidades externas e os fluxos espaçados ao longo da moldura obtém-se o diagrama de contexto do Sistema de Software da Livraria, como mostrado em 2.2.1 OBS: Para sistemas grandes pode-se ter 15 fluxos, ou mais, usando um papel maior para facilitar o entendimento do diagrama. - DFD do Sistema (DFD-Sistema) 16 O DFD-Sistema é um DFD que representa o sistema como um todo. Deve representar somente os aspectos do Sistema que irão ser transformados em software, ou seja, em programas e em dados que o sistema deverá armazenar. O DFD-Sistema representa a primeira quebra do processamento que o sistema deverá realizar, onde cada parte desse processamento é representada por uma função de processamento (e que irá ser transformada em códigos de programa). Deve ser considerado como uma base para o planejamento (semelhante a uma planta baixa de uma casa). O DFD-Sistema deve representar o máximo de detalhes, mas deve ser fácil de ser entendido, portanto não incluir detalhes em excesso. Se ocorrer excesso de detalhes a serem representados, os aspectos de tratamento de erros, de exceções e transitórios poderão ser excluídos com prioridade do DFD- Sistema. 2.3.1 - Passos para desenvolver um DFD Sistema 1º) Construir o Diagrama de Contexto do Sistema seguindo os critérios práticos mostrado em 2.2.2, ou seja: 1º a) Desenhar a moldura que representa os limites do sistema de software de maneira que o diagrama resultante venha a ocupar bem toda a página. 1º b) Identificar as entidades externas e os diálogos entre essas entidades e o Sistema. 1º c) Conte a quantidade total de diálogos. Se for maior do que 10 verificar quais diálogos poderão ser agrupados de modo que essa quantidade total fique num valor desejado. 1º d) Cada diálogo corresponderá, em princípio, a um fluxo de dados (exceto quando diálogos forem agrupados). 1º e) Desenhar os fluxos de dados e as entidades externas maneira espalhada ao redor da moldura do sistema (evitando a parte superior) para que o resultado seja um diagrama fácil de ser entendido. 2º) Para cada fluxo entre uma entidade externa e o Sistema, desenhar uma função de processamento dentro da moldura, deixando-a inicialmente sem nome. 3º) Para cada fluxo, e para cada um dos conjuntos de dados do fluxo perguntar: a) De onde vem o conjunto de dados que a função envia para a entidade externa ? a. A função obtém esse conjunto de dados de um depósito? b. ou o obtém de uma outra função? b) Se a função recebe um conjunto de dados da entidade externa, para onde ela deverá encaminhá-lo ? a. A função deverá armazená-lo em um depósito de dados ? b. ou deverá envia-lo para uma outra função? 17 c) À medida que as questões acima vão sendo respondidas desenhar os depósitos de dados (e funções) que se fizerem necessários 4º) Após considerar todos os conjuntos de dados tratados por uma função pode-se ter a noção das tarefas que ela deverá realizar, e portanto, pode-se dar um nome a essa função sob a forma de VERBO + COMPLEMENTO (que represente a tarefa mais importante para os objetivos do Sistema). 5º) Desenhar o DFD a mão livre evitando os cruzamentos de fluxos. Mesmo que para isso tenha que duplicar depósitos de dados e cuidando sempre para que o DFD seja fácil de ser entendido. (Assinalar os depósitos duplicados, por exemplo através de dois traços paralelos) 6º) Após a revisão, pode-se redesenhar o DFD e enumerar as funções (e depósitos de dados) se houver necessidade. 7º) Confeccionar o Dicionário de Dados registrando os dados que compõem cada conjunto de dados dos fluxos, os tipos de dados que estarão nos depósitos de dados e descrever cada função do DFD (com informações disponíveis até o momento). OBS: Seguir rigorosamente a seqüência dos passos acima, pelo menos até o 4º passo, para obter de maneira eficiente um DFD de qualidade. (Qualquer outro caminho, se adotado, provavelmente será mais difícil e menos eficiente). 18 2.3.2 – Exemplo de DFD_Sistema – Software da Livraria FLUXOS QUE ENTRAM E SAEM DO SISTEMA: [ 1 ] LIV : Relação de livros com nome, autor, editora, ano, preço, quantidade em estoque [ 2 ] PED : Pedido de livros desejados e quantidades [ 3 ] CLI : Dados do cliente como nome, endereço, RG, CPF, telefone [ 4 ] CONSU : Consulta ao Serasa de um dado cliente [ 5 ] R_CONSU : Retorno do Serasa à consulta feita [ 6 ] PED_REJ : Dados de pedido rejeitado CLI : Informações sobre o cliente R_CONSU : Resposta da Serasa à consulta feita [ 7 ] CONSU : Consulta ao Serasa sobre um cliente RESU_F : Resultado final de um pedido rejeitado [ 8 ] LIV_F : Relação dos livros em falta EDIT : Relação das editoras [ 9 ] PED_AQ : Pedido de aquisição de livros junto às editoras [ 10 ] PED_AQ : Pedido de aquisição de livros, ou seja, relação dos livros desejados da editora e as quantidades [ 11 ] LIV_REC : Dados dos livros recebidos da editora [ 12 ] DATA : Data da emissão da nota fiscal[ 13 ] PED : Pedido de livros desejados e quantidades CLI : Dados do cliente como nome, endereço, RG, CPF, telefone FUNC VENDAS GERENTE CLIENTE LIVROS ANALISAR PEDIDO RECEBER PEDIDO LIVROS FALTA PEDIDOS CLIENTES TRATAR PEDIDO REJEITAD O EMITIR NOTA FISCAL ADQUIRIR LIVROS ATUALIZA R LIVROS CLIENTES LIVROS FALTA CAD EDITORAS PED AQUIS LIVROS EDITORA FUNC_ES TOQUE 1 2 3 4 5 6 15 8 13 2 1 0 10 11 7 9 FUNC EXPEDIÇ ÃO SERASA 12 14 CONSULT AR SERASA ENVIAR PEDIDO AQUIS 19 [ 14 ] RESU_P : Resultado da análise do pedido (OK ou rejeitado) [ 15 ] PED : Pedido de livros desejados e quantidades LIV : Relação de livros com nome, autor, editora, ano, preço, quantidade em estoque OBS: Não utilizar números substituindo os nomes de dados como no exemplo acima porque torna o DFD mais difícil de ser entendido. Sempre que possível escreva os nomes dos dados (como foi feito no diagrama de contexto do item 2.2.1). 20 Exercícios EXERCÍCIOS DA DISCIPLINA DE ANÁLISE DE SISTEMAS PARTE A : DIAGRAMAS DE CONTEXTO DESCRIÇÃO: SISTEMA DE SOFTWARE PARA UMA OFICINA MECÂNICA Em uma oficina mecânica o cliente, após estacionar o seu carro, dirige-se à recepção para relatar os problemas e serviços a serem realizados no carro. Através de um terminal a recepcionista preenche, ou atualiza, o cadastro do cliente e os dados do veículo. Em seguida, ela digita a relação dos problemas/serviços relatados pelo cliente. Seguindo a ordem de chegada, o veículo é inspecionado por um dos mecânicos que, visualizando em um terminal o relato do cliente, relaciona os consertos e os serviços que serão necessários, bem como, o custo de cada um dos itens, compondo assim o orçamento. Para facilitar essa tarefa, o sistema disponibiliza ao mecânico a relação de serviços comumente realizados, os materiais utilizados, e os custos unitários para cada um deles. Disponibiliza ainda a relação de peças, e preço unitário, referente ao tipo do veículo com a finalidade de facilitar a determinação do custo de cada conserto necessário. Se um serviço a ser realizado não constar da relação, o mecânico poderá acrescentá-lo livremente no orçamento em questão. Após elaboração dos itens do orçamento, o sistema fará o cálculo do custo de cada item e do custo total. Uma estimativa do tempo gasto para execução dos trabalhos fará parte do orçamento. Através do seu terminal a recepcionista tem acesso ao orçamento elaborado pelo mecânico e comunica ao cliente por telefone os seus resultados. No próprio terminal em que estará visualizando o orçamento ela poderá habilitar os itens do orçamento que forem sendo aprovados pelo cliente e que deverão ser executados pelo mecânico. Para fazer o seu trabalho, o mecânico deverá observar no seu terminal a relação dos itens aprovados pelo cliente, incluir comentários que se fizerem necessários e assinalar o término de execução de cada item. A qualquer instante, através do seu terminal, a recepcionista poderá ter acesso à informação do andamento dos trabalhos do mecânico através do orçamento em execução e, naturalmente, quando eles tiverem sido terminados. A conclusão dos trabalhos será comunicada ao cliente por telefone. A emissão da nota fiscal será feita pelo caixa com o auxílio do sistema que mostrará os itens realizados do orçamento e o pagamento efetuado pelo cliente será registrado no sistema. Tendo a informação do pagamento realizado, a recepcionista poderá providenciar a liberação e a entrega do veículo ao cliente. 21 DESCRIÇÃO : SISTEMA DE SOFTWARE PARA UMA TRANSPORTADORA Uma transportadora possui um conjunto de caminhões de diversos tipos e realiza viagens de transporte de carga para qualquer parte do País. As solicitações de viagens são recebidas por um funcionário do escritório via e-mail ou por telefone. O cliente deverá fornecer: o tipo de carga, volume, peso, data desejada para o carregamento, origem e destino, além de seus dados como nome, endereço e telefone. O sistema de software deverá auxiliar o funcionário do escritório a: a) fazer a alocação do caminhão para uma viagem observando a sua disponibilidade e de acordo com o volume e o peso da carga; b) estimar o tempo de duração fornecendo a distância entre diferentes cidades; c) estabelecer o custo da viagem e o valor a ser cobrado mantendo o consumo para os diferentes tipos de caminhão, o custo do combustível e de estimativas de despesas de viagem; d) designar o motorista de acordo com a disponibilidade e o rodízio de escala. Após a viagem, o funcionário do pátio deverá registrar no sistema eventos ocorridos durante a viagem, tais como, problemas com o caminhão, atrasos, etc. Deverá também registrar os valores das despesas da viagem, tais como, combustível, consertos, pedágios e refeições. Ao final de cada mês o gerente irá acionar o sistema para obter um relatório que resume as viagens realizadas, indicando as despesas e os valores recebidos pelo transporte, e outro relatório que, para cada caminhão, relaciona os quilômetros rodados e as despesas referentes aos consertos e manutenção. 22 DESCRIÇÃO : SISTEMA DE SOFTWARE PARA UMA CLÍNICA MÉDICA O paciente poderá agendar horário de consulta diretamente no sistema via internet ou pelo telefone por intermédio da secretária. Para isto, deve ser possível verificar no sistema os horários disponíveis do médico desejado, e após a escolha do horário mais conveniente, o sistema solicitará o nome e telefone do paciente. Quando o paciente chegar a clínica, a secretária verificará no sistema o horário da consulta e se o mesmo constar na agenda do sistema, ela cadastrará os dados do paciente (ou atualizará os seus dados se já for um paciente cadastrado), receberá o valor da consulta e solicitará ao sistema a emissão do respectivo recibo. No caso de ser apresentado o comprovante de convênio, o sistema possibilitará à secretária inserir as devidas informações para posterior processamento. O médico poderá visualizar no sistema a agenda de pacientes e verificar o próximo paciente que deverá atender. Quando estiver pronto, ele poderá enviar um aviso pelo sistema para que a secretária providencie a entrada do paciente para a sala de atendimento. Durante a consulta, o médico poderá acessar a ficha histórica de tratamento do paciente e também prescrever uma nova receita baseando-se em tratamentos e remédios pré-cadastrados, ou quando necessário, cadastrar novos. Quando solicitado pelo paciente, o médico poderá emitir um atestado através de facilidades do sistema. 23 CAP. 3 - EXPANSÃO DE DFD 3.1 - Como fazer uma expansão 3.2 - Critérios para fazer as expansões de DFDs 3.3 - Exemplo de expansão de DFD – Locadora de Fitas Quando se tem um grande sistema de software a ser desenvolvido o DFD-Sistema poderá não representar todas as informações necessária para o projeto lógico do Sistema. Nesse caso a solução é fazer a expansão do DFD, ou seja, representar um próximo nível de detalhes do Sistema, transformando cada função de processamento que não estiver suficientemente detalhada em um novo DFD. A expansão poderá ser aplicada a cada novo nível de DFDs, sempre que houver funções que não estejam no nível de detalhes desejado. 3.1 - Como fazer uma expansão Para cada função do DFD que deve ser expandida para dar origem a um DFD de nível mais baixo: 1º) Desenhar a moldurado novo DFD que corresponderá a função a ser expandida. 2º) Para cada fluxo que entra e/ou sai da função a ser expandida desenhar um fluxo correspondente cruzando a moldura do novo DFD. Para cada fluxo desenhado denotar os nomes dos conjuntos de dados que fluem através do fluxo. 3º) Se um fluxo de dados da função estiver representando mais de um diálogo, no novo DFD ele poderá ser desmembrado em mais de um fluxo (por exemplo, um fluxo por diálogo). 4º) Se houver necessidade, adicionar novos fluxos correspondentes às situações de erros e exceções (que poderão não aparecer no DFD de nível mais alto). 5º) Após considerar todos os fluxos representando dados que entram e saem do DFD, verificar se a quantidade e a distribuição dos fluxos ao longo da moldura estão dentro do razoável. 6º) Desenhar uma função de processamento para cada fluxo, deixando inicialmente sem nome e continuar de forma semelhante aos passos para desenvolver um DFD-Sistema (Vide no Cap 2 – Passos para desenvolver um DFD-Sistema ) 24 3.2 - Critérios para fazer as expansões de DFDs a) Balanceamento de fluxos 1º) Os dados que entram e saem de uma função a ser expandida devem corresponder aos fluxos que entram e saem do DFD resultante da expansão. 2º) Essa correspondência não é pela quantidade de fluxos, mas pelo significado dos dados envolvidos. 3º) Para verificar o balanceamento não se deve considerar os fluxos relacionados com erros e exceções (pois são aspectos que devem ser representados à medida que se detalha o Sistema). b) Extensão do particionamento 1º) Expandir (detalhar) o mais possível, ou seja, representar o máximo de informações a cada DFD. Porém, produzir sempre DFDs legíveis e estéticos. 2º) Os DFDs de nível mais baixo podem ter menos funções do que os níveis mais alto. (Porque um DFD carregado de informações detalhadas tenderá a ficar mais difícil de ser entendido). 3º) Uma referência: 5 + ou – 2 funções de processamento em cada DFD. c) Nível mais baixo da expansão 1º) Limite prático: até 4 níveis de DFDs (se a cada nível a expansão produzir DFDs contendo o máximo de informações) 2º) Quando a Mini-especificação da função couber em 1 página (narrativa da função usando fluxograma ou português estruturado) é um indício que a função já está num nível de detalhes suficiente. 3º) Quando uma função possuir mais de 1 fluxo com saídas de dados dessa função é um indício de que talvez seja necessário fazer a expansão dessa função. 25 3.4 - Exemplo de expansão de DFD Considere um sistema de software para uma locadora de vídeo, sua descrição e o DFD_Sistema compondo o seu nível o1. Missão do Sistema: Fornecer conforto aos clientes no acesso às informações sobre as fitas disponíveis e dar suporte às atividades das funcionárias e do gerente da Locadora. DESCRIÇÃO NÍVEL 01 No hall de recepção da Locadora o cliente poderá ter acesso às informações sobre as fitas através de um terminal e montar o seu pedido de locação. No balcão de atendimento ele será atendido por uma funcionária que, com o auxílio do sistema verificará o seu pedido e fará (ou atualizará) o cadastro do cliente e depois irá apanhar as fitas relacionadas nas prateleiras. Para devolver as fitas o cliente deverá dirigir-se ao balcão de atendimento e entrega-las para uma das funcionárias. O sistema auxiliará a funcionária a calcular o valor a ser pago pelo cliente e, se necessário, dará a indicação do local nas prateleiras onde cada fita deverá ser recolocada. Através da Internet os fornecedores enviarão periodicamente para a Locadora informações sobre os lançamentos de novas fitas. O sistema auxiliará o gerente a fazer os pedidos de aquisição de novas fitas e enviá-las aos fornecedores. Recebendo novas fitas, elas serão conferidas com o respectivo pedido de aquisição e as informações das fitas existentes na Locadora serão atualizadas no sistema. 26 DFD-SISTEMA DA LOCADORA DE VÍDEO (Nível 01) Fitas_Nov Fitas Fitas_Nov Ped Ped_Aq Ped_F Fitas_Dev Ped_F Cli Ped_Aq Lança Ped Sit_Cli Sit_Cli Lança Ped_F Fitas_Dev Ped_F Ped_Aq LEGENDA DOS CONJUNTOS DE DADOS QUE FLUEM ATRAVÉS DOS FLUXOS: Fitas : Relação das fitas da Locadora Ped : Pedido de fitas contendo a relação de fitas Ped_F : Pedido final contendo as informações completas além da relação de fitas que irá levar Sit_Cli : Situação do Cliente Fitas_Dev : Informações sobre fitas devolvidas pelo cliente Lança : Relação de novos lançamento de fitas Ped_Aq : Pedido de aquisição de novas fitas Fitas_Nov : Novas fitas recebidas pela Locadora DESCRIÇÃO DO SISTEMA DE SW DA LOCADORA DE FITAS - NÍVEL 02 CLIENTE ELABORAR PEDIDO FUNC_ES TOQUE FUNC_BA LCÃO GERENTE FORNEC EDORES TRATAR PEDIDO RECEBER DEVOLUÇÃ O RECEBER FITAS NOVAS ADQUIRIR R NOVAS FITAS ENVIAR PEDIDO DE AQUIS FITAS PED_FITAS CLIENTES LANÇAMENTOS PED_AQ FORNECEDORES FITAS RECEBER _LANÇAM ENTOS 27 DESCRIÇÃO NÍVEL 02 DA FUNÇÃO: ELABORAR_PEDIDO A locadora possui um hall de entrada com diversos terminais onde os clientes poderão obter informações sobre as fitas existentes para locação (sem a necessidade de percorrer as prateleiras). Através de um desses terminais o cliente poderá elaborar seu pedido selecionando uma, ou mais, fita da relação de fitas disponíveis. O sistema mostrará no terminal as informações sobre as fitas de diferentes maneiras de acordo com a opção do cliente: lista dos nomes dos filmes em ordem alfabética; lista de nomes de filmes por assunto; lista por artista e pelos mais recentes lançamentos. Caso o cliente deseje, ele poderá optar por ver informações detalhadas de uma dada fita, tais como: descrição resumida do filme, a relação dos principais artistas, a figura da capa da fita, o nome do diretor e da produtora. O sistema mostrará ainda a quantidade de exemplares existentes de cada fita, a quantidade de exemplares disponíveis para locação no momento, bem como, o preço por dia de locação. O sistema permitirá ao cliente fazer uma pré-seleção das fitas que eventualmente teria interesse de locar e posteriormente fazer a escolha final das fitas que irão compor o pedido final de locação. Além do seu nome, na elaboração do pedido de locação o cliente digitará para cada fita o período de locação que ele deseja e o sistema mostrará o valor a ser pago por fita e o total. Assim que as fitas forem sendo selecionadas pelo cliente o sistema irá marcando que elas estão reservadas e irá atualizando o número de exemplares disponíveis para locação. Após o cliente ter concluído a elaboração do pedido, ele se dirigirá à recepção da loja para pegar as fitas. 28 ELABORAR PEDIDO - NÍVEL 02 Fitas Fitas_Pre Fitas Op_visu Fitas Det_Fitas Ped Fitas Qtde_disp_at Fitas_Pre Val_Aloc Ped Nome_Cli Ped Ped Nome_Cli LEGENDA DOS CONJUNTOS DE DADOS QUE FLUEM PELOS FLUXOS: 1 FITAS = Relação de fitas contendo: Nome do filme, Tipo do filme, Preço da locação, Qtde_disponível 2 DET_FITAS= Detalhes de fitas : Descrição do filme, Artistas principais, Figura da capa, Diretor, Produtora 3 OP_VISU = Opção para visualização : (Relação em ordem alfabética dos filmes, Por assunto, Por artista, Lançamentos) 4 FITAS PRE = Fitas pré-selecionadas : Nomes das fitas que o cliente tem interesse e que poderão fazer parte do pedido de locação 5 PED = Pedido : Fitas que farão parte do pedido final de locação, período de locação, valor da alocação 6 VAL_ALOC : Valor a ser pago pela alocação das fitas do pedido 7 QTDE_DISP_AT = Quantidade disponível atual : Relação de fitas com qtdes disponíveis atualizadas OBS: a) O fluxo de dados entre o cliente e o sistema do nível 1 foram desmembrados no nível 2 para representar com mais detalhes os diálogos para a elaboração do pedido de locação (O qual passou a ser realizada em duas etapas: primeiro para uma seleção prévia e depois a seleção final para definir o pedido). b) De maneira semelhante o fluxo para acessar os dados do depósito de fitas também foram desmembrados para representar os diferentes diálogos para os acessos. c) A entidade externa Clientes e os depósitos de dados Fitas e Ped_Fitas, externos à função, foram desenhados na parte externa ao DFD para facilitar o entendimento, mas não seriam necessários desenha-los. CLIENTE S PRE_SE LECION AR_FITA S FAZER_ PEDIDO _ FINAL RECUPER AR_FITAS ATUALIZAR _QTDE_DIS PONIVEL GRAVAR_ PEDIDO DETALHES_ FITAS FITAS_PRE_SELEC FITAS PED_FITAS 29 DESCRIÇÃO DE NÍVEL 02 DA FUNÇÃO: TRATAR_PEDIDO Pelo seu terminal, a recepcionista verá no vídeo a relação de fitas do pedido elaborado pelo cliente e a indicação do local nas prateleiras onde as fitas poderão ser encontradas. A recepcionista verificará se os dados do cliente precisam ser atualizados e se existe alguma pendência na devolução de fitas alocações anteriores. O sistema dará a ela a opção de confirmar o pedido, deixá-lo suspenso ou então cancelá-lo. No caso de cancelamento, as informações correspondentes as disponibilidades das fitas deverão ser atualizadas na relação de fitas da locadora e o pedido apagado do sistema. Caso haja pagamento antecipado, a recepcionista registrará no sistema o valor pago e este mostrará o valor da diferença, se houver, a ser pago pelo cliente no ato da devolução das fitas. DESCRIÇÃO DE NÍVEL 02 DA FUNÇÃO: RECEBER_DEVOLUÇÃO DAS_FITAS Ao receber as fitas do cliente, a recepcionista recuperará no sistema as informações referentes à alocação através no nome do cliente e verificará se as fitas devolvidas são aquelas locadas. Se houver alguma fita não devolvida ela deverá registrar essa pendência no sistema. Verificará ainda se houve diferença entre o período de locação constante no pedido e o período que o cliente ficou com as fitas. Se for o caso, ela digitará essa informação para que o sistema possa refazer o cálculo do valor a ser pago pelo cliente. Por uma opção da funcionária o sistema emitirá o recibo a ser entregue ao cliente. O sistema registrará o resumo da transação no cadastro do cliente: Identificação das fitas locadas, o valor da locação e o valor pago, a data, e o número do pedido se houver pendência. Se não houve nenhuma pendência o pedido será então apagado do sistema após o seu pagamento e as informações das fitas do pedido serão atualizadas. OBS: Não usar números para nomear os conjuntos de dados dos fluxos. Será sempre melhor dar nomes que lembrem os dados (use abreviações dos nomes e faça a legenda). 30 Exercício - SISTEMA DE SOFTWARE PARA UM HOTEL FAZENDA Missão do sistema: O sistema de software deverá facilitar o controle de despesas e de empréstimo de materiais de cada hospede nas diversas unidades do hotel e agilizar o fechamento da conta ao término da estadia. Descrição: No atendimento a um pedido de reserva um funcionário verificará no sistema as vagas existentes, fará a alocação dos apartamentos e registrará o nome e o telefone da pessoa responsável pela reserva, além do número de pessoas e período da estadia. Na chegada dos hospedes no hotel, após verificar a reserva, o funcionário da recepção digitará os dados de cada hospede e passará o cartão magnético na leitora para que o sistema registre qual é o cartão que está sendo entregue a um dado hospede. O hotel possui diversas unidades de atendimento aos hospedes. Eles poderão consumir alimentos e bebidas no restaurante e no bar, na loja eles poderão adquirir materiais como vestimentas e souvenires, no salão de jogos, piscina, e praça de esportes eles poderão fazer empréstimos de materiais. Em cada unidade existirá um microcomputador com seus periféricos normais e uma leitora de cartões magnéticos através da qual será feita e identificação do hospede e a validação das operações. Por exemplo, no restaurante, o consumo de cada mesa será registrado nos sistema pelos funcionários. Após a refeição, o hospede poderá verificar na tela do micro a relação dos alimentos e bebidas consumidos e passar o seu cartão na leitora para confirmar as despesas. Ao emprestar uma toalha no vestiário da piscina o hospede deverá observar a descrição do material na tela do micro e passar o seu cartão na leitora para confirmar a operação. No ato de devolução do material emprestado ele passar novamente o cartão para registrar essa operação. Os micros computadores das unidades terão, em princípio, independência no processamento e armazenamento de dados, mas deverão transmitir através da rede para um computador central todas as operações de consumo e de empréstimos efetuadas pelos hospedes. Dessa forma no computador central, denominado servidor, ficarão registrados todos os dados para o acerto de contas na saída dos hospedes. Para o acerto de contas na saída, o cartão magnético de cada hospede deverá ser passado na leitora para o sistema recuperar todos os gastos do hospede, calcular o valor total a ser pago e emitir o relatório de despesas. O funcionário registrará no sistema o valor pago e a devolução do cartão. 31
Compartilhar