Durante a aula, observamos a importância de haver um consenso entre os modelos conceituais existentes na mente de cada pessoa, sobre um mesmo domínio, para que houvesse uma boa comunição. Da mesma forma, isso é observado para softwares. Esse assunto pode ser relacionado ao TCC da Glaice, no qual foi necessário mapear os conceitos dos modelos de ODE e de dotProject com o objetivo de integrar essas ferramentas num contexto de gerência de projetos, no que se referia à alocação de recursos humanos, controle de atividades e geração de cronogramas. Nesse TCC, o conceito de Projeto foi mapeado diretamente, porém alguns conceitos necessitaram de certas restrições para serem mapeados. Por exemplo, em dotProject, havia usuários e contatos. Foi necessário analisar o real papel de cada um no software, para que pudesse finalmente poder dizer que um Contato, em dotProject, se referia a um Recurso Humano, em ODE. Um outro exemplo é o caso de Atividade, em ODE, que só é uma Tarefa, em doProject, se ela tiver datas de início e fim previstas definidas no sistema.
A questão da interoperabilidade é complexa e por isso um campo fértil para estudos. No exemplo apresentado, modelos que pertencem a uma mesma organização (mas que no caso concreto da Petrobrás não ao mesmo departamento) apresentam significados diferentes. Não é difícil imaginar que problemas semelhantes ocorram em outras organizações. Talvez essas divergências estejam relacionadas ao número de departamentos, pois quanto maior esse número mais difícil deve ser obter um consenso sobre a definição de um conceito.
É possível observar ainda que problemas de interoperabilidade ocorrem também em modelos de referência (ISO e outros), pois ao comparar dois modelos fatalmente serão encontradas definições diferentes para um mesmo conceito. Durante a aula de Engenharia de Software, alguém disse que estudaria a interoperabilidade de modelos durante seu doutorado/mestrado.
O problema de interoperabilidade de conceitos não necessita de ser entre empresas e nem entre departamentos. Conhecemos um caso em que uma empresa tinha particularmente um departamento de portos, onde entre outros requisitos, desejava-se controlar os equipamentos utilizados no embarque e o embarque em si. Uma das funcionalidades que supria este requisito era o relacionamento entre parada de embarques e suas causas, por exemplo, mau tempo. Uma das causas era relativa as paradas de equipamentos, i.e. se nenhum equipamento operasse, o embarque parava. E assim, existia uma divergência de conceitos entre os operários do mesmo departamento. Alguns desses operários alegavam que a culpa da parada de embarque era do último equipamento que parasse de trabalhar, e outros diziam que dependia da causa da parada do equipamento. Por exemplo, um equipamento pode parar por falha elétrica, falha mecânica, falha operacional ou mudança de rota de equipamento.
Neste exemplo, vemos que ao explicitar a semântica de um relacionamento causamos conflitos até mesmo com conhecedores do domínio de uma mesma região/empresa.
