Apuração e Análise da Evolução dos Modelos

Os dados coletados pelo analista, sobre a evolução dos modelos (MIC e MD) desde sua derivação através das regras, até o término da implementação da primeira versão do sistema, foram analisados pelo experimentador para avaliar a adequação da visão MD do MIC, produzida pela regras de derivação. Primeiramente o experimentador

categorizou cada modificação registrada, analisou se uma das situações prejudiciais à adequação do MD ocorreu (Seção 6.4.1), e consolidou os resultados para extrair deles algumas conclusões, conforme apresentado a seguir.

Comparação entre o par de modelos gerados pelas regras e o par dos primeiros modelos de implementação:

A1) Inclusão de atributos no MD, na expectativa das próximas versões evolutivas do sistema. Análise: O MIC é construído na perspectiva do modelo mínimo de requisitos, ou seja, apenas aquelas informações necessárias às mudanças de estado (do sistema e seu ambiente) previstas nos ICs geram atributos ou operações no MD. A inclusão não é justificável com base no MIC, pois a funcionalidade correspondente não foi nele especificada. Portanto, não configura uma situação comprometedora da adequação da visão MD do MIC. Número de ocorrências: 7

A2) Inclusão de operação construtora em classe de associação. Análise: As regras não determinam isso; entretanto, parece que as classes de associação também deveriam ter a sua operação construtora. Portanto, temos uma incompletude (omissão) na visão MD do MIC. Solução: Alterar a regra R4a para também indicar a criação de uma operação construtora para cada classe de associação existente no MD. Número de ocorrências: 2

A3) Inclusão de atributo derivado com base na implementação. Análise: a inclusão teve motivação com base em requisitos de projeto e implementação e, portanto, não é justificável com base no MIC. Conseqüentemente, não configura uma situação de omissão na visão MD do MIC. Número de ocorrências: 1

A4) Alteração do tipo do elemento do MD: de atributo para operação. Análise: falha na aplicação das regras, decorrente principalmente de uma subespecificação do dicionário de itens elementares (DI), que deve dizer como se obtém a informação. Portanto, a modificação não pode ser justificada com base no MIC e, portanto, ela não configura uma situação de inconsistência da visão MD do MIC. Número de ocorrências: 1

Comparação entre o par dos primeiros modelos de implementação e o par dos modelos intermediários de implementação:

B1) Introdução de um identificador (id_cliente) no fluxo de entrada de um IC, e a correspondente associação no MD. Análise: omissão/equívoco do modelador, pois o identificador já tinha feito parte de uma versão anterior do mesmo IC, tendo sido

retirado sem justificativa válida. Portanto, trata-se de uma modificação não justificável com base no MIC, não configurando uma situação de omissão da visão MD do MIC. Número de ocorrências: 1.

B2) Inclusão de um atributo para um item de informação que entra em um IC, mas não tem utilização especificada nele e nem em nenhum outro IC. Análise: itens nessa situação podem significar duas coisas. Primeiro, que o item não é necessário ao desempenho de nenhuma função do sistema e, portanto, já que o MD produzido pelas regras é uma visão minimalista do domínio do sistema (ou seja, considera apenas a parte do domínio que interessa, ou é necessária, para o desempenho das funções do sistema), o item não precisa figurar em nenhum dos dois modelos (MIC e MD). Ou então, pode significar que o item é utilizado em um tipo de consulta que não é modelada, ou melhor, que fica implícita, no MIC. São consultas para a recuperação de informações (atributos) de um objeto do domínio (também conhecidas como operações “Retrieve”, segundo a nomenclatura CRUD – Create, Retrieve, Update, Delete). Esse tipo de consulta não tem o seu próprio IC no MIC porque pode ser facilmente derivada a partir do IC que cria o objeto (IC correspondente à operação Create). Portanto, nesse segundo caso, existe uma omissão da visão MD do MIC. Solução: o modelador deve considerar essa necessidade (de operações retrieve) na hora de interpretar a regra da persistência de itens informados, na entrada (regra R3a). Número de ocorrências: 1.

B3) Introdução de atributo correspondente ao item de informação do MIC que deveria ter sido considerado a persistir. Análise: falha na aplicação da regra de persistência (R3a), decorrente principalmente de uma subespecificação do dicionário de itens elementares (DI), que deve dizer como se obtém uma informação. Portanto, a inclusão não pode ser justificada com base no MIC e, portanto, não configura omissão da visão MD do MIC. Número de ocorrências: 1.

B4) Introdução de operação da interface com o usuário. Análise: trata-se de uma operação que visa organizar informações disponíveis no MD, para visualização pelo usuário. Portanto, essa operação está relacionada com o projeto da interface do usuário e, como tal, estaria melhor localizada na camada de objetos de apresentação do sistema, e não na camada de objetos de domínio. Por isso ela não deve aparecer em nenhum dos dois modelos (MIC e MD). Não sendo essa inclusão justificável com base no MIC, ela não configura uma omissão da visão MD do MIC. Número de ocorrências: 1.

Comparação entre o par de modelos intermediários de implementação e o par de modelos finais de implementação:

C1) Introdução de item de informação no MIC correspondente a atributo já presente no MD (persistido a partir de outro IC). Análise: Modificação corretiva no MIC, que não gera efeito na visão MD. Número de ocorrências: 1.

C2) Introdução de um item de informação derivado no MIC, que por não precisar ser persistido, levou à introdução da operação correspondente no MD. Análise: Modificação corretiva no MIC, que gerou o devido efeito na visão MD, com a aplicação das regras. Número de ocorrências: 1.

C3) Eliminação de itens de informação de um fluxo de saída muito complexo de um IC, para possibilitar o enquadramento de todas as informações na folha de emissão do relatório (no entanto, os respectivos atributos foram mantidos no MD para futura utilização em outro layout de relatório). Análise: Essa modificação foi motivada por detalhes de implementação que não deveriam ter efeito sobre o MIC. Portanto, deve ser desfeita. Número de ocorrências: 1.

C4) Introdução de uma operação para a realização de uma consulta de interesse dos stakeholders, não prevista na MIC. Análise: A inclusão da operação não é justificável com base no MIC e, portanto, não deve ser considerada como uma omissão da visão MD. Sendo a consulta realmente necessária, o MIC deveria ser alterado para especificá- la, o que resultaria na inclusão da operação no MD (pela regra R4c). Número de ocorrências: 6.

C5) Introdução de uma operação para computar o valor de um item derivado não- persistido. Análise: não seria necessário incluir manualmente essa operação se a regra R4b tivesse sido aplicada, uma vez que ela faz exatamente isso. Portanto, não se pode considerar como uma omissão da visão MD obtida pelas regras. Número de ocorrências: 1.

Conclusão

A Tabela 6.18 resume o número de modificações ocorridas no MD, segundo o efeito sobre a adequação desse modelo.

Tabela 6.18 – Nr. de modificações segundo o efeito sobre a adequação do MD Efeito da modificação / Situação Contagem

Não afetam 22

Afetam / Omissão (A2, B2) 3 Afetam / Inconsistência 0 Total 25

Pelos resultados apresentados na Tabela 6.18, vemos que apenas 3 modificações afetam a adequação da visão MD do MIC, obtida pelas regras de derivação. Essas modificações (A2 e B2) visaram corrigir situações de omissão no modelo, que as regras não foram capazes de evitar. Conseqüentemente, com base nas conclusões tiradas da análise levada a cabo para as modificações em questão, duas providências se fizeram necessárias: (1) alterar o enunciado da regra R4a, responsável pela criação de operações construtoras nas classes, para que a mesma passe a indicar a criação de uma operação construtora para cada classe de associação existente no MD, e (2) incluir a orientação de que o modelador deve considerar a existência implícita no MIC, de consultas do tipo retrieve, na hora de interpretar a regra R3a (persistência de itens informados, na entrada).

Além desses ajustes nas regras, outros também foram feitos a partir de observações e análises realizadas pelos participantes do estudo, sobre os MDs produzidos por cada um deles. Esses outros ajustes estão descritos na Seção 6.4.6. A próxima seção analisa os testes de aceitação do sistema, realizados pelos stakeholders.