Engenharia de Software Unidade IX Análise Essencial Abordagem Básica franciscogerson10@gmail.com Prof. rancisco Gerson A. de Meneses Conteúdo Programático Introdução Comparação (Estruturada / Essencial) atores de uso Iniciando Arquitetura do modelo essencial Composição do modelo ambiental Declaração dos objetivos do sistema Diagrama de contexto Lista de eventos Composição do modelo comportamental DD Particionado por evento Diagrama entidade relacionamento Diagrama hierárquico de macro atividades Dicionário de dados Introdução O método da Análise Essencial pode ser considerado um refinamento da Análise Estruturada. É também conhecido como Análise Estruturada Moderna. Utilizase dos mesmos artefatos/ferramentas: DD s DER/DED Dicionário de dados A utilização de uma Lista de Eventos, propicia um maior controle dos processos e dos dados, e altera a forma como esses artefatos/ferramentas são dispostos no modelo: Comparação MODELO ESTRUTURADO TopDown (Decomposição uncional) DD 0 (escopo) DD 1, e demais Proc. 1 Proc. 2 Proc. 3 Proc. N MODELO ESSENCIAL (Lista de Eventos) DD 0 (escopo) Lista de eventos Proc. 1 Proc. 2 Proc. 3 Proc. N DD Hierárquico Proc. 1 Proc. 2 DER/DED DER/DED atores de uso atores de uso Podese sublinhar alguns fatores de seu uso: É muito utilizado atualmente: sua maturidade facilita o uso dos recursos. Princípio da abstração: parte dos eventos existentes em uma visão sintética da realidade para se chegar aos dados ou informações manipuladas. Principio da divisão: para resolver um problema, o mesmo é dividido em um conjunto de problemas menores, que são mais fáceis de serem compreendidos e resolvidos. A premissa básica é descrever o sistema de maneira independente de restrições tecnológicas; assim, a resolução mantém o foco apenas no problema do usuário. Isto implica dizer que devemos considerar na confecção do modelo essencial a existência de uma tecnologia perfeita, assim, de uma forma abstrata teríamos: Os custos, consumo e desgaste dos equipamentos são zero A capacidade de armazenamento de dados do sistema é infinita A velocidade dos processadores é infinita O tempo de acesso a dados é instantâneo Há Zero Erro (não ocorrem falhas) PROBLEMA??? Caso a se pensar...
Iniciando Iniciando Antecedendo a aplicação do método da análise essencial fazse um exame do domínio do problema (levantamento de requisitos). Buscase funcionalidades e dados exigidos ao sistema que será desenvolvido, inicialmente focando os aspectos mais essenciais pertinentes ao problema. Na análise essencial um sistema de informação é visto como um sistema de respostas planejadas. Os eventos no ambiente geram fluxos de dados (estímulos) para o sistema, os quais acionam ações (ativam processos que são alimentados pelos dados), que podem, por sua vez, gerar respostas internas (persistência de dados) ou respostas que retornam ao ambiente (relatórios, emails, etc.). Também há a possibilidade de ocorrência de eventos internos ao sistema, os quais geram fluxos temporais, que também acionam ações no sistema. O problema (necessidade) existente é estudado, porém não é modelado (a princípio); Os esforços são concentrados na identificação das funcionalidades lógicas requeridas para o software que será criado (Lista de Eventos). A partir de então, criase um modelo essencial do software que será desenvolvido. A análise essencial é constituída basicamente por duas fases ou modelos: Modelo Ambiental Modelo Comportamental Ambas podem ser observadas no seguinte organograma: Arquitetura do modelo essencial Composição do modelo ambiental Análise Essencial Modelo Ambiental Declaração dos Objetivos Diagrama de Contexto Lista de Eventos DD Particionado por Eventos Temse a especificação macro do sistema que encontrase inserido em um meio ambiente, buscando representar uma relação entre ambos. Eventos que ocorrem no meio ambiente são geradores de estímulos, os quais acionam procedimentos no sistema que, por sua vez, geram respostas. As respostas poderão ser internas ao sistema ou ainda enviadas ao meio ambiente (respostas externas). Três grandes atividades são elaboradas neste modelo: A Declaração dos Objetivos do Sistema, Modelo Comportamental Diagr. Entidade Relacionamento A Elaboração do Diagrama de Contexto e a Especificação da Lista de Eventos. Modelo Essencial, adaptado de (Pompilho, 1995) Normalização Declaração dos objetivos do sistema Devese fazer um minucioso levantamento de requisitos e conhecer profundamente o domínio do problema. Tratase da especificação daquilo que o sistema deverá fazer frente aos requisitos que foram identificados previamente. É uma descrição textual, sem um formato estabelecido pelo método. Deve também, quanto possível refletir os desejos do usuário sobre alternativas de solução dos problemas. Diagrama de contexto Semelhante à Análise Estrutura tradicional. Elaborado após a especificação formal dos objetivos do sistema. Reflete graficamente a relação do sistema com o meio ambiente onde está inserido. Esta relação dáse através do recebimento de estímulos do meio ambiente, que ativam processos que por sua vez geram respostas (internas ou externas).
Lista de eventos Tratase da especificação dos (processos) essenciais que o sistema terá. Tais atividades (no sistema) são ativadas por estímulos (fluxo de dados, temporal ou de controle), executam processamento e geram respostas. Não há uma precedência estabelecida para a elaboração da lista de eventos e o diagrama de contexto; são atividades que podem estar acontecendo paralelamente mas que devem estar consistentes. Composição do modelo comportamental É a fase em que o analista passa a olhar para dentro do sistema. Irá detalhar, através do DD particionado por eventos, como cada atividade existente na lista de eventos se comportará (como ela deve funcionar). Também fará um modelo de dados (DER) sobre o qual o sistema atuará, observando critérios para conseguir bom desempenho da sua utilização (por meio da normalização dos dados). Acompanhando mais efetivamente este modelo criase o dicionário de dados (muito embora ele já possa existir). inalmente, podese criar o DD Hierárquico do sistema, que representa o agrupamento de atividades essenciais afins, que enfocam determinado aspecto do sistema. Vejamos cada uma dessas atividades: DD Particionado por evento Para cada item da lista de eventos o Analista de Sistemas fará um DD, representando de forma gráfica, individualmente, cada evento existente no sistema. Desta forma, haverá tantos DD s particionados por eventos quantos forem os itens existentes na lista de eventos. Diagrama entidade relacionamento Para a modelagem de dados, o Analista de Sistemas fará inicialmente o DER. Poderoso instrumento para mapear como os dados estão organizados e como eles se relacionam. A representação inicial do modelo de armazenamento independe dos dispositivos onde os dados ficarão armazenados. Quando o DER estiver concluído, devese criar a modelagem física dos dados, gerando o Diagrama de Estrutura de Dados. Diagrama hierárquico de macro atividades Tratase de um DD que propicia uma visão sintética única do sistema. Neste DD serão aglutinadas as funcionalidades existentes na lista de eventos de acordo com os assuntos de que tratam. Pegamse os DD s particionados por eventos e verificamse quais são aquelas atividades afins (que tratam de determinado assunto). Estes processos são aglutinados em somente um único DD, tendo uma visão sintética, cuja finalidade, além da documentação, é a possibilidade de examinarse e definir interfaces e locais de processamento. Podese gerar também o Diagrama Preliminar com uma visão geral de todos os processos do sistema. Dicionário de dados Todos os dados referenciados na construção do sistema devem ter sua definição no dicionário de dados. Para a construção do dicionário existem alguns padrões, nos quais é comum encontrarse a convenção simbólica, conforme a seguir: SÍMBOLO = + () {} É composto de E Opcional SIGNIICADO Iteração (repetição) SÍMBOLO [] ** @ / ou Escolha uma das opções Comentário Atributochave SIGNIICADO Separa alternativas na construção []
Na fase de exame do domínio do problema, estabeleceuse que o objetivo é apenas o controle da disponibilidade de quartos do hotel, portanto, não envolve qualquer outro aspecto, como controle financeiro, contábil, etc. Requisitos: Quando o cliente telefonar ou comparecer no hotel pedindo para r um quarto, o funcionário verificará se existe a do quarto, em caso negativo será informada ao cliente a nãodisponibilidade do quarto. Quando o cliente não mais desejar o quarto do, o funcionário providenciará o cancelamento da, disponibilizando novamente o quarto para outras s. Requisitos continuação: Quando o cliente não comparecer ao hotel para hospedarse até às 12h do dia da, sua será cancelada automaticamente. Quando o cliente ocupar um quarto, do previamente, o funcionário fará o registro da ocupação do quarto pelo cliente. Caso o quarto não esteja do previamente, mas esteja livre, a liberação de ocupação será fornecida ao cliente. Quando o cliente deixar o hotel, notificando sua saída, lhe será apresentada a conta e o quarto será disponibilizado para limpeza. O cliente poderá pagar a conta à vista ou a prazo, utilizando cartão de crédito ou cheque. Quando o quarto estiver limpo, após uma ocupação, o gerente irá tornálo disponível para nova locação. De posse destas informações provenientes do levantamento de requisitos, segue um descritivo da análise do problema e as especificações técnicas da solução escolhida pelo Analista de Sistemas, com aplicação do método da Análise Essencial: => Declaração do Objetivo do Sistema: Controlar o serviço de s, registros e cobranças de quartos em um hotel A declaração do objetivo do sistema deve estar resumida a um parágrafo e ser global, especificando o principal propósito da criação do software. => Diagrama de Contexto: => Diagrama de Contexto: Mostra apenas os limites do sistema e sua relação com o mundo fora dele. As entidades externas devem ser aquelas que representam a origem ou o destino de alguma informação e não aquelas que fazem a transcrição destas informações para o sistema, via entrada de dados. Não cabe no DD de contexto a especificação do Depósito de Dados (está dentro da bolha). Os fluxos de dados que partem das entidades externas com destino à bolha (processo) são chamados de estímulos (acionam ações) e alimentam o sistema. Diagrama modelado no CASE Studio 2.25
=> Diagrama de Contexto: No exemplo, a partir da entidade externa é gerado um estímulo chamado Cli_Reserva. O nome do estímulo é uma representação para o conjunto de dados necessários a uma (rg, nome, quarto, período, etc). Quando Cli_Reserva chega ao sistema, um processo é acionado (Efetuar Reserva), através do qual alguém alimenta os dados no sistema. O DD de contexto é uma síntese dos requisitos documentados anteriormente e que, na seqüência, através da lista de eventos, sofrerão um detalhamento. Nº Nome do Descrição do Evento Estímulo Tipo Ação ou Resposta Evento Estímulo Processo 01 02 quarto cancela Quando o cliente telefona ou vem até o hotel e pede para r um quarto, um funcionário executa um procedimento padrão Quando o cliente não mais desejar o quarto do e comunicar o fato, a será cancelada, disponibilizando o quarto novamente Cli_ Reserva Cli_ Cancel Efetuar Cancelar por solicitação Cli_ Reservado Nº Nome do Descrição do Evento Estímulo Tipo Ação ou Resposta Evento Estímulo Processo Nº Nome do Descrição do Evento Estímulo Tipo Ação ou Resposta Evento Estímulo Processo 03 É hora de cancelar Quando o cliente não comparecer ao hotel para hospedarse até as 12h do dia da T Cancelar automaticamente Ger_ Cancel 06 paga a conta, paga a quantia correspondente ao aluguel do quarto e as despesas efetuadas durante sua estada Cli_Paga Registrar pagamento Cli_Recibo 04 registrase no hotel faz o registro para a ocupação do quarto, do previamente Cli_Ent Registrar cliente 07 Gerência disponibiliza quarto Quando o quarto estiver limpo, o gerente irá tornálo disponível Ger_Lib Liberar quatro 05 solicita saída do hotel Quando o cliente deixar o hotel, este solicita que providencie o fechamento de sua conta, havendo a disponibilidade do quarto para limpeza Cli_Sai echar locação Cli_Conta 08 Gerência cadastra quarto Gerência inclui, exclui ou modifica dados do quarto Ger_Cad Manipular cadastro de quarto Relaciona todas as atividades essenciais (fundamentais) do sistema que se está modelado. É construída após, ou paralelamente, a construção do DD de Contexto, a diretriz básica é que essas duas ferramentas devem apresentar dados coerentes entre si (estímulos e respostas). Só haverá resposta por parte de um sistema se houver um estímulo (interno ou externo) que acione a ação geradora da referida resposta. A lista de eventos deverá ter, no mínimo, tantos eventos quantos forem os estímulos existentes no DD de contexto; porém nem toda ação executada a partir de um estímulo irá gerar uma resposta externa ao sistema. O início da construção da lista de eventos pode ser a partir da coluna estímulos, a seguir atribuise um nome ao evento. O nome do evento a ser criado deve seguir a estrutura nome da entidade externa + verbo + complemento. A coluna descrição é facultativa, ela detalha como o evento acontece, se for omitida da lista ela deverá ser colocada no DD Particionado por Eventos. O tipo do estímulo poderá ser (luxo) quando uma entidade externa envia dados ao sistema, poderá ser T (Temporal), quando o estímulo for oriundo de ações do próprio sistema (interno), nesta situação um processo se autoexecuta ou é acionado por outro processo.
Nesse caso a coluna estímulo deverá ficar em branco e a coluna nome do estímulo deverá começar com os termos É hora de... complementados com algo que indique o que o processo fará. O terceiro e último tipo de estímulo possível referese ao chamado fluxo de controle, representado pela letra C. Tratase de um fluxo de dados proveniente de uma entidade externa que represente uma máquina, a qual enviará diretamente para algum processo no sistema dados a respeito do seu estado. A coluna ação ou processo na lista de eventos deve apresentar a atividade que será executada pelo sistema se o respectivo estímulo ocorrer (verbo no infinitivo). A última coluna resposta representa as possíveis saídas oriundas dos processos executados. Referese a respostas que são enviadas para fora do sistema para alguma entidade externa. Normalmente as repostas são relatórios, emails ou alguma outra forma de visualização dos dados que são exteriorizados pelo sistema, essas repostas devem referirse à essência do negócio, não apenas simplesmente a características operacionais de interface que serão tratadas posteriormente na fase de design (implementação). => DD Particionado por Evento: Depois que a lista de ventos estiver concluída, desenvolvese o DD Particionado por Eventos, também conhecido como DD das Atividades Essenciais. O aspecto principal é desenhar um modelo de como as funcionalidades existentes no sistema deverão ocorrer (Modelagem uncional), tudo com base nas ações especificadas na lista de eventos. A partir deste ponto, a Análise de Sistemas passa a incorporar os dados no projeto do sistema, documenta quais são os dados requeridos por determinada ação. Paralelamente pode estar sendo construído o DER assim como o dicionário de dados. => DD Particionado por Evento: Os dados sempre são características de algo ou de alguém ; este algo ou alguém será um depósito de dados que o processo utilizará. Cada depósito de dados no DD dará origem a uma entidade na modelagem de dados (DER). Conforme a lista de eventos do estudo de caso do controle hoteleiro deverá haver oito DD s particionados por evento (um para cada item da lista). Uma miniespecificação do processo deve acompanhar o referido DD, para a qual podese empregar um pseudocódigo. A miniespecificação detalha os aspectos necessários para a atividade de implementação. Vejamos: => DD Particionado por Evento: Evento 1 quarto Pseudocódigo: PEGAR Cli_Reserva LOCALIZAR SE existir então AÇA LER LOCALIZAR Quarto SE Quarto livre então AÇA LER Quarto GRAVAR Reserva (Sit_Res=1) CONIRMAR Cli_Reservado SENÃO SELECIONAR outro Quarto IMSE SENÃO CADASTRAR IMSE => DD Particionado por Evento: Evento 1 quarto Obs: O dicionário de dados, paralelamente poderá ser implementado, como exemplo, o atributo Sit_Res pode ser especificado assim: Nome Criado Sit_Res = Significado e Características *Indicará a situação da *: Tipo: Inteiro Tamanho: 01 Conteúdo: 0 *Quarto libertado* 1 *Quarto do* 2 *Reserva confirmada* 3 *Reserva cancelada pelo cliente* 4 *Reserva cancelada automaticamente* 5 *Locação concluída* Pseudocódigo: PEGAR Cli_Reserva LOCALIZAR SE existir então AÇA LER LOCALIZAR Quarto SE Quarto livre então AÇA LER Quarto GRAVAR Reserva (Sit_Res=1) CONIRMAR Cli_Reservado SENÃO SELECIONAR outro Quarto IMSE SENÃO CADASTRAR IMSE
=> DD Particionado por Evento: Evento 2 cancela a => DD Particionado por Evento: Evento 3 É hora de cancelar Pseudocódigo: PEGAR Cli_Cancel LOCALIZAR Reserva LER Reserva ATUALIZAR Reserva (Sit_Res=3) Pseudocódigo: PARA cada vencida AÇA LER Reserva ATUALIZAR Reserva (Sit_Res=4) ESCREVER Ger_Cancel IMPARA => DER/DED/Normalização: Após a atividade de construção do DD Particinado por Evento ou em paralelo a ele, o Analista de Sistemas deve construir a modelagem de dados, empregando para tanto o DER/DED. Para isso é necessário um estudo para verificar os possíveis atributos que surgirão a partir das particularidades observadas em cada depósito de dados. Lembrando que a existência de um depósito é oriunda da necessidade de um processo acessar dados, quer seja para seu armazenamento ou recuperação. Cada depósito de dados no DD se transformará em uma Entidade no DER/DED e essas Entidades podem se relacionar. Vejamos: => DER/DED/Normalização: Diagrama modelado no CASE Studio 2.25 => Diagrama Preliminar e Diagrama Hierárquico de Macroatividades: Uma vez concluídos os DD s particionados por evento e a modelagem de dados, podese modelar o Diagrama Preliminar que é um DD com a apresentação de todos os DD s particionados por evento em uma visão só. A partir dele fazse o Diagrama Hierárquico de Macroatividades que consiste em um DD que agregará eventos relativos a um mesmo assunto, permitindo uma visão simplificada do sistema. O Diagrama Preliminar equivale ao Diagrama de nível 1 visto na Análise Estruturada. No caso iremos modelar o Diagrama Preliminar. Vejamos: => Diagrama Preliminar : Diagrama modelado no CASE Studio 2.25
=> Dicionário de Dados: Paralelamente a todo o trabalho de análise do sistema, devese ir mantendo um dicionário de dados, que registrará todos os nomes criados (inventados) pelo Analista; independentemente de serem autoexplicarivos, para tal registro empregase a notação simbólica vista no anteriormente. Vejamos um exemplo: => Dicionário de Dados: Nome Criado Significado e Características Sit_Res = *Indicará a situação da *: Tipo: Inteiro Tamanho: 01 Conteúdo: 0 *Quarto libertado* 1 *Quarto do* 2 *Reserva confirmada* 3 *Reserva cancelada pelo cliente* 4 *Reserva cancelada automaticamente* 5 *Locação concluída* orma_pag *Indicará a forma de pagamento* Tipo: Inteiro Tamanho: 01 Conteúdo: 1 *A vista espécie* 2 *A vista cartão débito* 3 *A vista cheque* 4 *Parcelado cheque* 5 *Parcelado cartão* Bibliografia TONSIG, S. L. Engenharia de Software Análise e Projeto de Sistemas. Editora Ciência Moderna, 2ª Edição, 2008. Pesquisas na WEB Notas de aula