Outros Ajustes das Regras de Derivação

A Seção 6.4.4 indicou a necessidade de dois ajustes nas regras de derivação, para garantir a adequação da visão MD do MIC, por elas produzida. A presente seção apresenta e discute os outros ajustes motivados por observações, e decididos após longas reflexões realizadas entre os participantes do estudo, principalmente durante a etapa de derivação da visão MD do MIC. A versão das regras, apresentada na Seção 5.4.2, já incorpora todos esses ajustes.

Associação entre classes

Versão anterior:

R2a (Determinação de associações - identificadores em fluxos distintos): Todo par <id1, id2>, que possa ser formado com id1 sendo um identificador gerado presente

no fluxo de saída do UC, e id2 um identificador presente no fluxo de entrada, determina

uma associação entre as classes identificadas por id1 e id2. No caso de mais de um

identificador gerado, as associações correspondentes a pares que compartilham o mesmo id2 tendem a ser redundantes. As multiplicidades dessas associações podem ser

parcialmente obtidas pela regra R2a-M abaixo.

R2b (Determinação de associações - identificadores no mesmo fluxo): Se o identificador id2 estiver no escopo de uma repetição70, os limites, inferior e superior, da multiplicidade no lado da classe identificada por id2 serão, respectivamente, o número mínimo e máximo de repetições especificados no modelo informacional (ou "0" e "*", na falta dessa especificação). Caso contrário, o limite superior da multiplicidade será 1, e o limite inferior "0" se id2 for condicional, ou "1" se id2 não for condicional. A multiplicidade no lado da classe identificada por id1 não fica determinada.

Nova versão:

R2 (Determinação de associações): As associações entre classes estão entre aquelas indicadas pelos pares (não-ordenados) de identificadores presentes na interface informacional de cada IC (para fluxos de saída, basta considerar identificadores gerados).

70 _{Isto é, se id}

Justificativa:

Em sua utilização no presente estudo, a regra R2a produziu associações equivocadas a partir de alguns ICs com mais de um identificador gerado no fluxo de saída. Além disso, ambas as regras (R2a e R2b) prevêem a possibilidade de geração de associações redundantes no caso de mais de dois identificadores gerados ou no fluxo de entrada, respectivamente. Em vista disso, decidimos elaborar uma versão “menos determinística” para a regra, capaz de evitar os erros da versão anterior, e de possibilitar, com base no particionamento do sistema em ICs (seção 5.2), uma argumentação segura sobre a sua validade (seção 5.4.2). Entretanto, o conhecimento embutido na regra R2a foi mantido na forma de heurística aplicável quando ocorrer, na interface informacional de um IC, o padrão sintático nela previsto (seção 5.4.2).

Multiplicidade das associações

As três regras de multiplicidade que vigoravam anteriormente estavam baseadas na versão anterior das regras de criação de associações (R2a e R2b – vide acima). Quando essas últimas foram transformadas em heurísticas, as regras de multiplicidade também passaram a ter esse status, mantendo o mesmo conteúdo.

Determinação da persistência de itens de informação

Anteriormente ao estudo, as duas regras a seguir determinavam a persistência dos itens elementares de informação, informados ou derivados, respectivamente:

R3a (Determinação de persistência - item de entrada71): Todo item elementar não-identificador e de entrada, que for necessário em um UC distinto daquele em que o item entrou no sistema, deve ser persistido; caso contrário, não deve ser persistido.

R3b (Determinação de persistência - item calculado72): Para todo item elementar não-identificador, de saída e calculado, cujo valor originalmente calculado for necessário em outro UC, se houver chance desse valor não poder ser reproduzido nesse outro UC, ele deve ser persistido; senão, ele não precisa ser persistido.

Durante o desenvolvimento do estudo percebemos a necessidade de considerar também a persistência de itens informados, presentes no fluxo de saída de um IC, que representem informação histórica não passível de ser restaurada no IC. Isso deu origem

71 _{O mesmo que informado.} 72 _{O mesmo que derivado.}

a uma nova regra (que por questões de organização recebeu a denominação de R3b, passando a regra R3b acima a se denominar R3c):

R3b: (Persistência – item informado, na saída, valor histórico). Todo item elementar não-identificador e informado, presente no fluxo de saída de um IC, representando informação histórica73 cujo valor não pode, em geral, ser restaurado nesse IC, precisa ser persistido; caso contrário, não deve ser persistido.

Regra para criação de classes de associação74

Na versão anterior do conjunto das regras, não havia uma regra explícita para a determinação das classes de associações, embora ela já fosse conhecida pelo autor desta tese. Essa situação foi corrigida com a modificação da regra anterior para alocação dos itens a persistir nas classes. Essa regra passou, também, a determinar a criação de classes de associação:

R3d (Alocação de atributo / Criação de classe de associação): Cada item a persistir, presente na interface informacional de um IC, deve ser alocado como atributo de uma das classes alcançadas pelos identificadores presentes nessa mesma interface. Caso nenhuma dessas classes comporte o item, ele deve ser alocado em uma nova classe de associação criada para esse fim, correspondente a uma associação existente entre as classes alcançadas.

Operações construtoras para classes de associação

A implementação do sistema modelado no estudo de caso fez com que se percebesse uma omissão da regra que trata da introdução de operações construtoras nas classes, no que diz respeito às classes de associação. A versão anterior dessa regra era:

R4a: Todo identificador gerado produz uma operação construtora na classe identificada por esse identificador.

Para que a regra passasse também a indicar a inclusão de uma operação construtora nas classes de associação, ela foi alterada para:

R4a (construtoras): Toda classe recebe uma operação construtora.

73 _{Informação relativa a um estado anterior do sistema, que possivelmente não mais vigora com o}

mesmo valor no estado atual.

Operações para mudança de estado do sistema e do ambiente

O estudo de caso propiciou a descoberta de que o conjunto vigente de regras para a determinação das operações do MD não tratava todas as situações possíveis. Especificamente, quando um IC tinha identificador gerado nele, e ao mesmo tempo produzia outras mudanças de estado no sistema, ou então saída, a aplicação das regras se restringia a gerar uma operação construtora que, como tal, não deve produzir outras mudanças de estado além daquelas correspondentes à inicialização de um objeto, nem produzir saídas previstas no MIC. Por isso, resolvemos alterar a versão vigente da regra R4d, para torná-la aplicável na situação descrita. A versão vigente desta regra era:

R4d: Todo UC que não tenha sido contemplado com operações originadas pelas regras (R4a) e (R4c), dá origem a uma operação para realizar mudança no estado do sistema, a ser incluída em uma das classes alcançadas pelos identificadores presentes na interface informacional do UC, ou na falta desses, a ser incluída na classe que representa o sistema.

Esta regra, em sua versão atual mais abrangente é:

R4d (mudança de estado): Todo IC que causa mudança no estado do sistema produz uma operação para realizar essa mudança e para produzir o fluxo de saída (se existir), a menos que uma operação construtora, resultante da aplicação da regra R4a, realize toda a mudança de estado requerida, e não exista saída a produzir.