Interface Informacional dos Info Cases

No documento Publicações do PESC Info Cases: Um Modelo Integrado de Requisitos com Casos de Uso (páginas 80-84)

5. A Solução: Info Cases

5.3 Interface Informacional dos Info Cases

No capítulo anterior (seção 4.3.3), antevimos a possibilidade de ter a especificação da interface informacional dos UCs refletindo formalmente as abstrações de domínio, que irão constituir a visão MD do modelo integrado de requisitos. Para isso, foram apontadas duas providências necessárias:

1. Determinar os UCs em um nível de abstração tal que suas interfaces informacionais exprimam informações a serem persistidas entre estados estáveis do sistema; e

2. Especificar as interfaces informacionais desses UCs, utilizando um formalismo capaz de permitir a captura de rastros formalmente detectáveis, para a derivação automática de elementos do MD.

A primeira das providências acima foi tomada com a instituição do NIO (Nível Informacional de Objetivos), resultante da determinação dos UCs segundo três critérios enunciados (seção 5.2). A continuação da presente seção mostra a linguagem semiformal adotada para cumprir a segunda providência, e ilustra sua utilização através de um sistema simples de gerência de restaurante, especialmente concebido para isso. Esse sistema possui dois atores − o gerente do restaurante e o cliente − e deve prover as seguintes funcionalidades:

a) Registrar o pedido de pratos e bebidas de cada cliente. Deverá também ser feita a emissão de um ticket de fechamento, quando o cliente solicitar a conta.

b) Cancelar um pedido por solicitação do cliente.

c) Registrar o pagamento ou a pendura da conta do cliente. A pendura é facultada apenas aos clientes considerados habituais do restaurante.

d) Emitir um relatório detalhado do consumo diário de pratos e bebidas, para fins de reposição de estoque.

e) Emitir um relatório detalhado da receita do restaurante, em um dado período, separando a receita realizada daquela a realizar (pelo pagamento de contas penduradas).

f) Registrar o cardápio em vigor, permitindo sua emissão, por iniciativa do gerente. A especificação da interface informacional de um UC é constituída das duas partes listadas a seguir, e ilustradas na Figura 5.2 e na Tabela 5.1, respectivamente, para o sistema Restaurante:

• Dicionário de itens elementares de informação.

A utilização de um glossário ou dicionário de dados já é uma prática comumente recomendada na modelagem com UCs (BITTNER, SPENCE, 2002). Portanto, basta acrescentar a especificação da composição dos fluxos da interface informacional, ao texto da especificação tradicional dos UCs (seção 2.2), para se obter o modelo integrado proposto nesta tese.

A linguagem adotada para descrever a composição dos fluxos da interface informacional é praticamente a mesma utilizada anteriormente pela Análise Estruturada de sistemas (YOURDON, 1990) (MAFFEO, 1992), para especificar fluxos e depósitos de dados. Uma referência mais recente para esse tipo de linguagem é (LAUESEN, 2002). Ela utiliza um pequeno conjunto de símbolos para a construção de expressões de dados. O Apêndice 1 desta tese descreve formalmente a sintaxe dessa linguagem em BNF (GORN, 1960), enquanto que a sua semântica é descrita informalmente a seguir.

Os sinais Î e Í indicam, respectivamente, fluxo de entrada e fluxo de saída de informações, do ponto de vista do sistema. Uma informação ou item em um fluxo pode ser elementar (indivisível) ou composto (agregado de outros itens elementares ou compostos). Os itens compostos também são chamados de pacotes, e indicados pelo símbolo . Os itens elementares podem ser itens informados ou derivados. Itens informados (ou de entrada) são aqueles cujo valor provém diretamente de uma entrada (itens presentes no fluxo de entrada de algum IC), enquanto que os itens derivados (ou calculados) não provêm diretamente de uma entrada, mas têm o seu valor derivado (calculado) pelo sistema a partir de outros itens informados ou derivados. Um tipo especial de item derivado são os itens identificadores. Eles se destacam pelo nome iniciado por id_ (por exemplo, id_cliente), e representam abstrações do domínio da aplicação identificadas durante a modelagem de requisitos. A notação utilizada para descrever a composição de um fluxo ou pacote é a seguinte: + significa composição,

n{x}m significa de n a m ocorrências (ou repetições) de x, ( ) é utilizado para agrupar

itens, | significa ou e [ ] delimita itens condicionais, ou seja, que nem sempre estarão presentes (podem não ser pertinentes, dependendo do contexto).

Figura 5.2 – Composição dos fluxos da aplicação Restaurante

Os estudos experimentais realizados com ICs (Capítulo 6) têm indicado que os usuários, após um breve treinamento, passam a trabalhar confortavelmente com as expressões produzidas nessa linguagem. Segundo LAUESEN (2002, página 60 e seguintes), essas expressões são excelentes para os modeladores e aceitáveis para muitos usuários, que mesmo sem um formação específica em tecnologia da informação, acham essas expressões mais fáceis de compreender do que modelos E/R. Ainda

ATOR: Cliente IC 1: Abrir pedido

Î pedido = dt_pedido + id_mesa + itens_ped  itens_ped = 1{id_item + quant_item}

Í id_pedido

ATOR: Cliente IC 2: Cancelar pedido

Î cancela_ped = id_pedido

ATOR: Cliente IC 3: Pedir a nota

Î solicitacao_nota = id_pedido + [id_cliente]

Í nota = id_pedido + nr_mesa + dt_pedido + itens_nota + vl_nota + [nome_cliente + tel_cliente]  itens_nota = 1{id_item + cat_item + nome_item + pç_unit + quant_item + vl_item}

ATOR: Cliente IC 4: Pagar a nota

Î pagamento = id_pedido + vl_entregue + dt_pagto Í troco

ATOR: Cliente IC 5: Pendurar a nota

Î pendura = id_pedido + id_cliente

ATOR: Gerente IC 6: Cadastrar cliente habitual

Î cliente = nome_cliente + tel_cliente Í id_cliente

ATOR: Gerente IC 7: Atualizar o cardápio

Î item_consumo = nome_item + pc_unit + cat_item + descr_item Í id_item

ATOR: Gerente IC 8: Solicitar consumo diário

Î solic_consumo = dt_emissao + dt_consumo

Í consumo_dia = dt_emissao + dt_consumo + consumo_itens

 consumo_itens = 0{cat_item + {id_item + nome_item + quant_item} }2

ATOR: Gerente IC 9: Solicitar receita

Î solic_receita = dt_emissao + periodo_apur  periodo_apur = dt_inicio + dt_fim

Í receita = dt_emissao + periodo_apur + vl_consumo + receita_realiz + receita_pend + receita_txServ + receita_total

ATOR: Gerente IC 10: Cadastrar mesa

Î mesa = nr_mesa Í id_mesa

ATOR: Gerente IC 11: Solicitar relação de notas penduradas

Î solic_penduras = dt_emissao + periodo_apur  periodo_apur = dt_inicio + dt_fim

Í penduras = dt_emissao + periodo_apur + {id_cliente + nome_cliente + tel_cliente + notas_pend + vl_pendCli} + vl_pend

 notas_pend = 1{id_pedido + dt_pedido + nr_mesa + itens_nota + vl_nota}

segundo ele, as expressões não têm a riqueza semântica de um bom dicionário de dados, mas as duas técnicas se complementam.

No Dicionário de Itens Elementares (DI), para cada item elementar presente na interface informacional de um UC, são informados seu Nome, Descrição, Tipo, e Domínio (Tabela 5.1). A informação de Domínio apresenta os valores que o item pode assumir. Uma forma estendida do dicionário incluiria ainda os campos Unidade e Precisão, aplicáveis aos itens com valores em uma determinada unidade de medida (exemplo, o item de informação pç_unit teria Unidade: Real, e Precisão: centavos). A experiência tem evidenciado que o DI desempenha um papel muito importante na especificação informacional dos UCs, pois é necessário definir, com precisão, a semântica de cada item de informação nela presente. Assim, o recomendável é que a Descrição de um item inclua não apenas a sua definição (denotação), mas também como é utilizado (conotação) (LEITE, OLIVEIRA, 1995).

Tabela 5.1 – Dicionário de itens elementares de informação, do UC 3 (parcial)

Ator: Cliente UC 3: Pedir a nota

Nome Descrição Tipo Domínio

id_pedido Identificador do pedido da nota a emitir. Nr. Natural

quant_item Quantidade consumida de um item. Nr. Natural

vl_item Valor do consumo de um item. Preço unitário ×

quantidade consumida do item. Moeda

cat_item Categoria do item de consumo Texto {prato, bebida}

A visibilidade dos nomes de fluxos, pacotes e itens elementares está limitada ao próprio IC onde o nome aparece, exceto para os nomes de itens identificadores (aqueles com nome iniciado por id_), que são visíveis em todos os ICs. A decisão de restringir a visibilidade do nome de um item não-identificador, ao IC onde ele aparece, se justifica pela necessidade de permitir ao modelador flexibilidade e agilidade na hora de especificar a interface informacional dos ICs20. Já como itens identificadores ocorrem em muito menor número do que os itens não-identificadores, o benefício de se ter apenas um nome designando a mesma abstração ao longo de toda a especificação, é mais relevante.

Daqui para frente, utilizaremos o termo info case (IC) para designar um UC pertencente ao NIO, com interface informacional especificada na linguagem descrita nesta seção.

20 Principalmente se o modelador não puder contar com uma ferramenta computacional de apoio, e se o

No documento Publicações do PESC Info Cases: Um Modelo Integrado de Requisitos com Casos de Uso (páginas 80-84)