Engenharia de Software Unidade IX Análise Essencial Abordagem Básica

(1)

franciscogerson10@gmail.com

Engenharia de Software

Unidade IX – Análise

Essencial – Abordagem Básica

Prof. Francisco Gerson

A. de Meneses

Conteúdo Programático

Introdução

Comparação (Estruturada / Essencial)

Fatores 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

DFD Particionado por evento

Diagrama entidade relacionamento

Diagrama hierárquico de macro atividades

Dicionário de dados

Estudo de Caso - Sistema Hoteleiro

Prof. Francisco Gerson A. de Meneses

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.

Utiliza-se dos mesmos artefatos/ferramentas: DFD’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/ferramentassão dispostos no modelo:

Comparação

MODELO ESTRUTURADO Top-Down (Decomposição Funcional) MODELO ESSENCIAL (Lista de Eventos) DFD 1, e demais Proc. 1 Proc. 2 Proc. 3 Proc. N

DFD 0 (escopo) DER/DED DFD 0 (escopo) DER/DED Proc. 1 Proc. 2 Proc. 3 Proc. N

Lista de eventos

DFD Hierárquico

Proc. 1 Proc. 2

Fatores de uso

Pode-se 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.

Fatores de uso

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

(2)

Iniciando

Antecedendo a aplicação do método da análise essencial faz-se um exame do domínio do problema (levantamento de requisitos).

Busca-se 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.

Iniciando

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, cria-se 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

Análise Essencial Modelo Ambiental Modelo Comportamental Declaração dos Objetivos Diagrama de Contexto Lista de Eventos DFD Particionado por Eventos Diagr. Entidade Relacionamento Normalização Modelo Essencial, adaptado de (Pompilho, 1995)

Composição do modelo ambiental

Tem-se a especificação macro do sistema que encontra-se 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, A Elaboração do Diagrama de Contexto e a Especificação da Lista de Eventos.

Declaração dos objetivos do sistema

Deve-se fazer um minucioso levantamento de

requisitos e conhecer profundamente o domínio

do problema.

Trata-se 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).

(3)

Lista de eventos

Trata-se 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 DFD 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çãodos dados).

Acompanhando mais efetivamente este modelo cria-se o dicionário de dados

(muito embora ele já possa existir).

Finalmente, pode-se criar o DFD Hierárquico do sistema, que representa o agrupamento de atividades essenciais afins, que enfocam determinado aspecto do sistema.

Vejamos cada uma dessas atividades:

DFD Particionado por evento

Para cada item da lista de eventos o Analista de

Sistemas fará um DFD, representando de forma

gráfica, individualmente, cada evento existente no

sistema.

Desta forma, haverá tantos DFD’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, deve-se criar a

modelagem física dos dados, gerando o

Diagrama de Estrutura de Dados.

Diagrama hierárquico de macro atividades

Trata-se de um DFD que propicia uma visão sintética

única do sistema.

Neste DFD serão aglutinadas as funcionalidades existentes na lista de eventos de acordo com os assuntos de que tratam.

Pegam-se os DFD’s particionados por eventos e verificam-se quais são aquelas atividades afins (que tratam de determinado assunto).

Estes processos são aglutinados em somente um único DFD, tendo uma visão sintética, cuja finalidade, além da documentação, é a possibilidade de examinar-se e definir interfaces e locais de processamento.

Pode-se 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 encontrar-se a convenção simbólica, conforme a seguir:

Separa alternativas na construção []

/ ou |

Iteração (repetição) {} Atributo-chave

@

Opcional () Comentário

**

E +

Escolha uma das opções

[]

É composto de = SIGNIFICADO SÍMBOLO SIGNIFICADO SÍMBOLO

(4)

Estudo de Caso - Sistema Hoteleiro

C

Na fase de exame do domínio do problema, estabeleceu-se 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 reservar um quarto, o funcionário verificará se existe a reserva do quarto, em caso negativo será informada ao cliente a não-disponibilidade do quarto.

Quando o cliente não mais desejar o quarto reservado, o funcionário providenciará o cancelamento da reserva, disponibilizando novamente o quarto para outras reservas.

Estudo de Caso - Sistema Hoteleiro

Requisitos - continuação:

Quando o cliente não comparecer ao hotel para hospedar-se até às 12h do dia da reserva, sua reserva será cancelada automaticamente.

Quando o cliente ocupar um quarto, reservado previamente, o funcionário fará o registro da ocupação do quarto pelo cliente. Caso o quarto não esteja reservado previamente, mas esteja livre, a liberação de ocupação será fornecida ao cliente.

Estudo de Caso - Sistema Hoteleiro

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 torná-locação.

Estudo de Caso - Sistema Hoteleiro

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 reservas, registros e cobranças de quartos em um hotel”

C

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.

Estudo de Caso - Sistema Hoteleiro

=> Diagrama de Contexto:

Diagrama modelado no CASE Studio 2.25

Estudo de Caso - Sistema Hoteleiro

CMostra apenas os limites do sistema e sua relação com o mundo fora dele.

CAs 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.

CNão cabe no DFD de contexto a especificação do Depósito de Dados (está dentro da bolha).

COs 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.

(5)

Estudo de Caso - Sistema Hoteleiro

CNo exemplo, a partir da entidade externa “ Cliente” é gerado um estímulo chamado “Cli_Reserva”. O nome do estímulo é uma representação para o conjunto de dados necessários a uma reserva (rg, nome, quarto, período, etc).

CQuando “Cli_Reserva” chega ao sistema, um processo é acionado (Efetuar Reserva), através do qual alguém alimenta os dados no sistema. CO DFD de contexto é uma síntese dos requisitos documentados anteriormente e que, na seqüência, através da lista de eventos, sofrerão um detalhamento.

Estudo de Caso - Sistema Hoteleiro

=> Lista de Eventos: -Cancelar reserva por solicitação F Cli_ Cancel Quando o cliente não mais desejar o quarto reservado e

comunicar o fato, a reserva será cancelada, disponibilizando o quarto novamente Cliente cancela reserva 02 Cli_ Reservado Efetuar reserva F Cli_ Reserva Quando o cliente telefona ou vem até o hotel e pede para reservar um quarto, um funcionário executa um procedimento padrão Cliente reserva quarto 01 Nome do Evento Nº Ação ou Resposta Processo Tipo Estímulo Estímulo Descrição do Evento

Estudo de Caso - Sistema Hoteleiro

=> Lista de Eventos: Cli_Conta Fechar locação F Cli_Sai Quando o cliente deixar o

hotel, este solicita que providencie o fechamento de

sua conta, havendo a disponibilidade do quarto para limpeza Cliente solicita saída do hotel 05 -Registrar cliente F Cli_Ent Cliente faz o registro para a

ocupação do quarto, reservado previamente Cliente registra-se no hotel 04 Ger_ Cancel Cancelar reserva automatica-mente T -Quando o cliente não comparecer ao hotel para hospedar-se até as 12h do dia da reserva É hora de cancelar reserva 03 Nome do Evento Nº Ação ou Resposta Processo Tipo Estímulo Estímulo Descrição do Evento

Estudo de Caso - Sistema Hoteleiro

=> Lista de Eventos: -Manipular cadastro de quarto F Ger_Cad Gerência inclui, exclui ou modifica dados do quarto Gerência cadastra quarto 08 -Liberar quatro F Ger_Lib Quando o quarto estiver limpo, o gerente irá torná-lo

disponível Gerência disponibi-liza quarto 07 Cli_Recibo Registrar pagamento F Cli_Paga Cliente paga a quantia correspondente ao aluguel

do quarto e as despesas efetuadas durante sua

estada Cliente paga a conta, 06 Nome do Evento Nº Ação ou Resposta Processo Tipo Estímulo Estímulo Descrição do Evento

Estudo de Caso - Sistema Hoteleiro

=> Lista de Eventos:

CRelaciona todas as atividades essenciais (fundamentais) do sistema que se está modelado.

CÉ construída após, ou paralelamente, a construção do DFD de Contexto, a diretriz básica é que essas duas ferramentas devem apresentar dados coerentes entre si (estímulos e respostas). CSó haverá resposta por parte de um sistema se houver um estímulo (interno ou externo) que acione a ação geradora da referida resposta.

CA lista de eventos deverá ter, no mínimo, tantos eventos quantos forem os estímulos existentes no DFD de contexto; porém nem toda ação executada a partir de um estímulo irá gerar uma resposta externa ao sistema.

Estudo de Caso - Sistema Hoteleiro

CO início da construção da lista de eventos pode ser a partir da coluna estímulos, a seguir atribui-se um nome ao evento. CO nome do evento a ser criado deve seguir a estrutura nome da entidade externa + verbo + complemento.

CA coluna descrição é facultativa, ela detalha como o evento acontece, se for omitida da lista ela deverá ser colocada no DFD Particionado por Eventos.

CO tipo do estímulo poderá ser “F” (Fluxo) 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.

(6)

Estudo de Caso - Sistema Hoteleiro

CNesse 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á. CO terceiro e último tipo de estímulo possível refere-se ao chamado fluxo de controle, representado pela letra “C”. Trata-se 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.

CA 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).

Estudo de Caso - Sistema Hoteleiro

CA última coluna resposta representa as possíveis saídas oriundas dos processos executados. Refere-se a respostas que são enviadas para fora do sistema para alguma entidade externa.

CNormalmente as repostas são relatórios, e-mails ou alguma outra forma de visualização dos dados que são exteriorizados pelo sistema, essas repostas devem referir-se à 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).

Estudo de Caso - Sistema Hoteleiro

=> DFD Particionado por Evento:

CDepois que a lista de ventos estiver concluída, desenvolve-se o DFD Particionado por Eventos, também conhecido como DFD das Atividades Essenciais.

CO aspecto principal é desenhar um modelo de como as funcionalidades existentes no sistema deverão ocorrer (Modelagem Funcional), tudo com base nas ações especificadas na lista de eventos.

CA 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.

CParalelamente pode estar sendo construído o DER assim como o dicionário de dados.

Estudo de Caso - Sistema Hoteleiro

=> DFD Particionado por Evento:

COs 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á.

CCada depósito de dados no DFD dará origem a uma entidade na modelagem de dados (DER).

CConforme a lista de eventos do estudo de caso do controle hoteleiro deverá haver oito DFD’s particionados por evento (um para cada item da lista).

CUma miniespecificação do processo deve acompanhar o referido DFD, para a qual pode-se empregar um pseudocódigo. A miniespecificação detalha os aspectos necessários para a atividade de implementação. Vejamos:

Estudo de Caso - Sistema Hoteleiro

=> DFD Particionado por Evento: Evento 1 – Cliente reserva quarto

Pseudocódigo:

PEGAR Cli_Reserva LOCALIZAR Cliente SE Cliente existir então FAÇA

LER Cliente LOCALIZAR Quarto SE Quarto livre então FAÇA

LER Quarto

GRAVAR Reserva (Sit_Res=1)

CONFIRMAR Cli_Reservado SENÃO

SELECIONAR outro Quarto FIMSE

SENÃO CADASTRAR Cliente FIMSE

Estudo de Caso - Sistema Hoteleiro

=> DFD Particionado por Evento: Evento 1 – Cliente reserva quarto

Obs: O dicionário de dados, paralelamente poderá ser implementado, como exemplo, o atributo Sit_Respode ser especificado assim:

Pseudocódigo:

PEGAR Cli_Reserva LOCALIZAR Cliente SE Cliente existir então FAÇA

LER Cliente LOCALIZAR Quarto SE Quarto livre então FAÇA

LER Quarto

GRAVAR Reserva (Sit_Res=1)

CONFIRMAR Cli_Reservado SENÃO

SELECIONAR outro Quarto FIMSE

SENÃO CADASTRAR Cliente FIMSE

*Indicará a situação da reserva*: Tipo: Inteiro Tamanho: 01 Conteúdo: 0 *Quarto libertado* 1 *Quarto reservado* 2 *Reserva confirmada* 3 *Reserva cancelada pelo cliente* 4 *Reserva cancelada automaticamente* 5 *Locação concluída* Sit_Res =

Significado e Características Nome Criado

(7)

Estudo de Caso - Sistema Hoteleiro

=> DFD Particionado por Evento: Evento 2 – Cliente cancela a reserva

Pseudocódigo:

PEGAR Cli_Cancel LOCALIZAR Reserva LER Reserva

ATUALIZAR Reserva (Sit_Res=3)

Estudo de Caso - Sistema Hoteleiro

=> DFD Particionado por Evento: Evento 3 – É hora de cancelar reserva

Pseudocódigo:

PARA cada reserva vencida FAÇA LER Reserva

ATUALIZAR Reserva (Sit_Res=4)

ESCREVER Ger_Cancel FIMPARA

Estudo de Caso - Sistema Hoteleiro

=> DER/DED/Normalização:

CApós a atividade de construção do DFD Particinado por Evento ou em paralelo a ele, o Analista de Sistemas deve construir a modelagem de dados, empregando para tanto o DER/DED. CPara 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.

CLembrando que a existência de um depósito é oriunda da necessidade de um processo acessar dados, quer seja para seu armazenamento ou recuperação.

CCada depósito de dados no DFD se transformará em uma Entidade no DER/DED e essas Entidades podem se relacionar. Vejamos:

Estudo de Caso - Sistema Hoteleiro

=> DER/DED/Normalização:

Diagrama modelado no CASE Studio 2.25

Estudo de Caso - Sistema Hoteleiro

=> Diagrama Preliminar e Diagrama Hierárquico de Macroatividades: CUma vez concluídos os DFD’s particionados por evento e a modelagem de dados, pode-se modelar o Diagrama Preliminar que é um DFD com a apresentação de todos os DFD’s particionados por evento em uma visão só.

CA partir dele faz-se o Diagrama Hierárquico de Macroatividades que consiste em um DFD que agregará eventos relativos a um mesmo assunto, permitindo uma visão simplificada do sistema. CO Diagrama Preliminar equivale ao Diagrama de nível 1 visto na Análise Estruturada.

No caso iremos modelar o Diagrama Preliminar. Vejamos:

Estudo de Caso - Sistema Hoteleiro

=> Diagrama Preliminar :

(8)

Estudo de Caso - Sistema Hoteleiro

=> Dicionário de Dados:

CParalelamente a todo o trabalho de análise do sistema, deve-se ir mantendo um dicionário de dados, que registrará todos os nomes criados (inventados) pelo Analista; independentemente de serem auto-explicarivos, para tal registro emprega-se a notação simbólica vista no anteriormente.

Vejamos um exemplo:

Estudo de Caso - Sistema Hoteleiro

=> Dicionário de Dados:

*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* Forma_Pag

*Indicará a situação da reserva*: Tipo: Inteiro Tamanho: 01 Conteúdo: 0 *Quarto libertado* 1 *Quarto reservado* 2 *Reserva confirmada* 3 *Reserva cancelada pelo cliente* 4 *Reserva cancelada automaticamente* 5 *Locação concluída* Sit_Res =

Significado e Características Nome Criado

Bibliografia

TONSIG, S. L. Engenharia de Software – Análise e Projeto de Sistemas. Editora Ciência Moderna, 2ª Edição, 2008. Pesquisas na WEB