Matriz de Interações (ou Matriz CRUD)

A Matriz de Interações (ou Matriz CRUD) é utilizada, no processo de desenvolvimento de sistemas, para retratar e analisar as relações entre Funcionalidades (ou atividades) e Entidades (ou tipos de objetos de dados) dentro de um escopo de negócio ou sistema de informação.

Ela é construída de forma que as funcionalidades são listadas num dos seus eixos e as entidades no outro. As células de interseção denotam o tipo de interação existente, ou seja: mostram que entidade será afetada pela execução de uma determinada funcionalidade e explicita as propriedades CRUD para tal interseção. Portanto, cada uma das suas células descreve as ações que uma atividade exerce sobre o tipo de objeto de dados associado, que podem ser: Create (inclusão), Read (leitura), Update (atualização) e Delete (exclusão).

Exemplo matriz original

Exemplo matriz clusterizada

Trata-se de um instrumento muito útil na identificação de clusters (ou blocos de construção) que podem ser usados para elaborar componentes, patterns, módulos ou mesmo aplicações voltadas ao suporte de processos de negócio específicos.

Durante o desenho de sistemas de informações de diferentes naturezas, modeladores podem usar o artefato para verificar a consistência entre as definições funcionais e de dados inerentes à solução que estão desenvolvendo.

Profissionais que lidam com a gestão do acervo de ativos digitais da organização, atuando, portanto, em um nível de abstração mais alto, podem se valer da mesma técnica para obter e disseminar uma melhor compreensão da arquitetura de informações corporativa. Nesse caso, as entidades podem ser obtidas a partir de um modelo corporativo de dados e as unidades funcionais, por meio do exame e da decomposição das funções organizacionais ou pela análise dos processos empresariais.

A Matriz de Interações é utilizada para se definir relacionamentos de uma forma concisa, mas os benefícios do seu uso não estão limitados a esta concisão. É possível analisá-la sob diferentes aspectos, conforme a seguir.

Análise de Rastreabilidade

A rastreabilidade é utilizada para mostrar como um item é relacionado a um outro item. Por exemplo, se as linhas da matriz representam atividades de negócio e as colunas representam necessidades de informação, um valor na célula de relacionamento indicaria que uma necessidade de informação foi identificada considerando a atividade com a qual se relaciona.

Uma análise de rastreabilidade pode evidenciar quaisquer entradas desnecessárias ou faltantes nos relacionamentos em questão. Por exemplo:

• Existe pelo menos um Create? Se não, deve-se perguntar como os dados estão sendo "carregados".
• Existe pelo menos um Delete? Se não, deve-se perguntar se o negócio realmente necessita disso.
• Cada Atividade interage com pelo menos uma Entidade? Se não, isso pode indicar que a decomposição funcional está num nível de granularidade desbalanceado; ou que a análise não está terminada; ou , ainda, que o sistema é apenas uma "grande calculadora".
• Cada Entidade interage com pelo menos uma Atividade? Se não, isso pode indicar que o rol de funcionalidades não está completo; ou que os dados são manualmente armazenados (arquivo em papel, fichas, etc.)

Análise de Cobertura

A análise de cobertura pode ser utilizada para conferir se os dois itens que estão sendo comparados estão consistentes entre si. Uma linha vazia pode indicar tanto a redundância de um item quanto a falta de um outro item no relacionamento.

Quando a análise de cobertura está consistente, ela pode servir como um sumário de todos os relacionamentos entre os dois itens em questão e isto pode ser especialmente útil se o texto em cada célula descrever a natureza do relacionamento entre os dois itens.

• Creates, Updates ou Deletes múltiplos - Se a matriz completa mostra que mais de uma atividade pode criar o mesmo dado, isso indica prováveis problemas de qualidade nos dados (duplicidade e ambiguidade). Deve-se analisar as regras de negócio e de priorização, além de aspectos particulares de consistência e tempo, visando investigar a existência de justificativa para tal duplicidade.

• Creates relacionados com Reads - A maioria das entidades deve ter pelo menos um create e mais do que um read. Deve-se verificar se os "reads" ocorrem sobre a mesma entidade, se não, averiguar os motivos da replicação. Se for na mesma entidade, deve-se buscar conhecer qual a utilidade de negócio para cada um deles.

Análise de Cluster

"Agrupamentos" de células da matriz podem ser identificados a partir da reorganização das suas linhas e colunas. Um agrupamento indica que esse conjunto de "interseções" têm alguma coisa em comum. Por exemplo, se as linhas representarem atividades de negócio e as colunas representarem tipos de objeto, um agrupamento de interseções pode ser usado para identificar aplicações de software ou "famílias" de aplicações.

Isto ocorre porque o agrupamento identifica o fato de que as atividades e os objetos de dados têm uma afinidade entre si. Obviamente, tais agrupamentos devem ser balanceados com as necessidades de dados e informações levantadas pela organização, quando da definição de escopos de sistemas.

Tais agrupamentos representam "afinidades" em razão de que as atividades têm o mesmo tipo de ação (ou semelhante) sobre o mesmo grupo de entidades (e vice versa). Isto baseia-se primariamente nas operações de criação e remoção de instâncias de entidades.

Entretanto, a análise de operações de leitura e alteração podem ajudar nas decisões relacionadas à busca de melhoria de performance do aplicativo (quando se considera a possibilidade de implementação de tabela de uma forma desnormalizada ou replicada, por exemplo).

Deve-se considerar, ainda, que eventos que possuem ação de leitura ou alteração sobre entidades que são criadas por outro aplicativo indicam a necessidade de uma "interface" (fluxo de dados) entre eles.

Referências

• Modelagem de Sistemas de Informação: Da Análise de Requisitos ao Modelo de Interface, Geraldo Xexéo, 2007.
• Engenharia de Software, Roger S. Pressman, McGraw Hill, 2002.
• Engenharia da Informação – Metodologia, Técnicas e Ferramentas, A. F. Neto, Wilson Higa, J. D. Furlan – McGraw-Hill, 1988.

Ver também

• Arquitetura de dados
• Sistemas de informação
• Engenharia de Software
• Modelagem de dados
• Banco de Dados
• Ferramenta CASE