Qualidade das Especificações Obtidas

O MIC proposto é basicamente igual ao artefato produzido na MUC, exceto pela inserção de um conjunto de expressões de dados para especificar a interface informacional de cada UC, construídas utilizando a linguagem semiformal apresentada na seção 5.3. Na presente seção, vamos examinar os efeitos dessa diferença, sobre a qualidade da especificação de requisitos resultante.

+Mesa(in nrMesa : Byte) -nr_mesa : Byte

Mesa

+Pedido(in dtPedido : Date, in mesa : Mesa, in itensPed : Object) +troco(in vlEntregue : Currency) : Currency

+vl_nota() : Currency +cancelar()

+pedirNota(in cliente : Cliente) +pendurarNota(in cliente : Cliente) +pagarNota(in dtPagto : Date) -dt_pedido : Date

-dt_pagto : Date -cancelado? : bool -pendurado? : bool

Pedido

+Cliente(in nomeCli : String, in telCli : String)

+vl_pendCli(in dtInicio : Date, in dtFim : Date) : Currency -nome_cliente : String

-tel_cliente : String

Cliente

+Item(in nomeItem : String, in pcUnit : Currency, in catItem : String) +quant_item(in dtConsumo : Date) : unsigned short

-nome_item : String -pc_unit : Currency -cat_item : String Item 1..1 0..* 0..* 0..1

PedidoItem(in nomeItem : String, in pcItem : Currency, in quantItem : Byte) nome_item : String pc_item : Currency quant_item : Byte Pedido-Item 0..* 1..* +Restaurante()

+vl_consumo(in dtInicio : Date, in dtFim : Date) : Currency +consumo_dia(in dtEmissao : Date, in dtConsumo : Date) +receita_realiz(in dtInicio : Date, in dtFim : Date) : Currency +receita_pend(in dtInicio : Date, in dtFim : Date) : Currency +receita_txServ(in dtInicio : Date, in dtFim : Date) : Currency +receita_total(in dtInicio : Date, in dtFim : Date) : Currency +receita(in dtEmissao : Date, in dtInicio : Date, in dtFim : Date) +vl_pend(in dtInicio : Date, in dtFim : Date) : Currency

+penduras(in dtEmissao : Date, in dtInicio : Date, in dtFim : Date) -pedidos : Object

-mesas : Object -clientes : Object -cardapio : Object

Restaurante

Figura 5.3 – Visão do MD do sistema Restaurante

Devido à semelhança entre os produtos das duas modelagens, é de se esperar que o modelo proposto herde muito das qualidades do modelo de UCs. Portanto, a análise a seguir se concentrará nos aspectos de qualidade que, a nosso ver, são impactados pela solução proposta.

Como o MIC basicamente acrescenta algo (a especificação da interface informacional dos UCs) ao MUC, é clara a necessidade de avaliarmos o impacto disso

sobre a usabilidade e a legibilidade do MIC. Algum impacto certamente há, pois agora os usuários e stakeholders devem ler e compreender uma especificação escrita em uma linguagem semiformal. Entretanto, acreditamos que esse impacto é pequeno se comparado aos benefícios da utilização do MIC. A experimentação com o MIC, relatada no capítulo 6, demonstrou que mesmo pessoas sem maior conhecimento em computação, são capazes de assimilar e usar, mediante um breve treinamento, essa linguagem e as especificações dela resultantes. LAUESEN (2002) a considera uma linguagem aceitável para muitos usuários, e afirma que mesmo aqueles sem formação específica em tecnologia da informação acham as especificações produzidas mais fáceis de compreender do que modelos E/R. Por último, existe a possibilidade de parafrasear, automaticamente, as descrições formais em linguagem natural, tornando-as acessíveis a leitores menos afeitos a formalismos.

Outro aspecto a considerar é a completude dos modelos produzidos com a técnica de ICs – o modelo de ICs (MIC) e o MD dele derivado. Sendo um modelo de requisitos, o MIC pode ser considerado a primeira representação dos requisitos dos stakeholders para o sistema e, portanto, inexiste uma especificação anterior em relação a qual se possa apurar a completude (externa) do MIC. No caso do MD, podemos avaliar a sua completude em relação ao MIC. Para isso, podemos utilizar a seguinte definição adaptada de GLINZ (2000) (seção 4.4): um modelo está (parcialmente) completo em relação ao outro quando ele contém todas as informações que são requeridas pelas informações presentes no outro modelo. Na técnica de ICs, boa parte dessa completude é alcançada por construção, ou seja, decorre da derivação do MD a partir das regras descritas na seção 5.4.2, conforme análise realizada mais adiante (seção 5.5.5). Outra avaliação desse aspecto de qualidade foi feita no capítulo 6, dessa vez experimentalmente, através do Estudo 3 (EC-3, seção 6.4), resultando em evidências de que o MD gerado com as regras é adequado (consistente e completo) em relação ao MIC. Das 25 alterações sofridas pelo MD originalmente obtido pela aplicação das regras de derivação, ao longo do projeto e implementação do sistema, apenas 3 visaram corrigir situações de incompletude (omissão) no MD em relação ao MIC (Tabela 6.18). Duas dessas situações resultaram de uma imprevisão da regra R4a (responsável pela inclusão de operações construtoras nas classes), e a outra situação decorreu de uma omissão da técnica, que deveria orientar o modelador a considerar a existência implícita,

no MIC, de consultas do tipo retrieve36, na hora de aplicar a regra R3a (responsável pela persistência de itens informados, na entrada). Conseqüentemente, as devidas ações corretivas foram tomadas para que tais situações não voltem a acontecer.

A consistência é outro aspecto de qualidade reforçado na técnica de ICs. Aqui, podemos considerar a consistência intermodelos (entre o MIC e MD) e a consistência interna (dentro de cada modelo). A consistência entre o MIC e MD está resolvida, em parte, pela característica de modelo integrado da solução alcançada neste trabalho. O mesmo pode ser dito com relação à consistência interna do MD, já que ele resulta, em grande parte, da aplicação das regras de derivação, que não produzem elementos inconsistentes entre si. Resta, então, considerar a consistência interna do MIC. Ela também é reforçada, pois a especificação semiformal da interface informacional dos ICs permite uma verificação de completude funcional em um nível de detalhe e precisão maiores do que no MUC, possibilitando na descoberta de lacunas e omissões que, normalmente na MUC, passariam despercebidas. Por exemplo, toda informação que entra em um IC deve ser utilizada no processamento desse IC, ou de outro qualquer; caso contrário, a informação não precisa entrar no sistema, ou então está faltando especificar sua utilização. O estudo experimental EC-3 (seção 6.4) também produziu evidências da consistência do MD gerado a partir do MIC. Das 25 alterações sofridas pelo MD originalmente obtido pela aplicação das regras, ao longo das etapas de projeto e implementação do sistema objeto do estudo, nenhuma visou corrigir uma situação de inconsistência do MD em relação ao MIC (Tabela 6.18).

Outro aspecto de qualidade a considerar é a rastreabilidade. Prover rastreabilidade entre o MIC e o MD é mais fácil do que entre o MUC e o MD. Isso porque o MD está intimamente integrado ao MIC, a ponto de poder ser, em grande parte, derivado deste através das regras de derivação apresentadas na seção 5.4.2. Essas regras exploram rastros formais entre elementos dos dois modelos. Portanto, a necessidade de se inserir, manualmente, rastros entre o MIC e seu MD, é menor do que entre o MUC e seu MD.

Por fim, e em decorrência do favorecimento da rastreabilidade que a técnica de ICs proporciona, podemos considerar também favorecida a manutenibilidade do conjunto de modelos dela resultantes (MIC e MD). Além disso, as regras orientam a propagação de modificações feitas em um modelo, em modificações correspondentes no

outro modelo. Do MIC para o MD, parte dessa propagação pode ser feita automaticamente (seção 5.5.5).