A KMDL define construtos para modelagem das convers˜oes de conhecimento e informac¸˜ao definidas por Nonaka e Takeuchi. H´a tamb´em o construto fluxo de informac¸˜ao, correspondente `a operac¸˜ao de transferˆencia de informac¸˜ao definida no modelo de GIC adotado nesta pesquisa. As subsec¸˜oes seguintes descrevem como esses construtos s˜ao incorporados `a metodologia de modelagem desenvolvida nesta pesquisa.
Convers˜oes
Nesta metodologia as convers˜oes s˜ao modeladas como processos. S˜ao definidos quatro no- vos estere´otipos, especializac¸˜oes do estere´otipo processo: combinac¸˜ao, socializac¸˜ao, internalizac¸˜ao e externalizac¸˜ao. O diagrama de processos da figura 3.8 mostra como modelar cada uma das convers˜oes de informac¸˜ao e conhecimento. A informac¸˜ao ou conhecimento a ser convertido ´e representado como entrada do processo. O resultado da convers˜ao ´e representado como sa´ıda. Um ou mais indiv´ıduos s˜ao respons´aveis pela execuc¸˜ao dos processos, podendo ser represen- tados como papel ou pessoa, ligados ao processo atrav´es de uma ligac¸˜ao estereotipada como fornece.
No processo de socializac¸˜ao algumas vezes n˜ao existe recurso de sa´ıda do processo. Considera- se que um ou mais indiv´ıduos participantes do processo tˆem seu estado alterado durante o pro- cesso: uma alterac¸˜ao na estrutura de conhecimento. Normalmente um indiv´ıduo j´a possui o conhecimento sendo convertido, e este o compartilha com um ou mais indiv´ıduos, que passam a ter esse conhecimento. No processo internalizac¸˜ao tamb´em h´a alterac¸˜ao de estrutura de co- nhecimento no indiv´ıduo que executa o processo. Essa soluc¸˜ao de modelagem ´e v´alida, uma vez que Eriksson e Penker (2000, p. 109) definem que “...um objeto que supre o processo tamb´em pode mudar de estado durante o processo”.
Caso novo conhecimento seja criado durante a socializac¸˜ao pode-se especificar objetos do tipo conhecimento como sa´ıda do processo.
Pode ser interessante tamb´em o uso do construto nota da UML, para especificar quem ´e a fonte e o receptor em uma socializac¸˜ao, ou o meio em que a operac¸˜ao ocorre, por exemplo: telefone, reuni˜ao, e-mail, etc.
Na KMDL as convers˜oes de conhecimento e informac¸˜ao s˜ao modeladas como ligac¸˜oes simples entre os objetos. Uma vantagem da modelagem das convers˜oes como processos ´e a explicitac¸˜ao dos indiv´ıduos participantes das convers˜oes, o que n˜ao ocorre na KMDL.
Transferˆencia
A transferˆencia de informac¸˜ao ´e modelada como uma ligac¸˜ao tern´aria entre objetos: fonte, destino e informac¸˜ao. A figura 3.9 mostra uma transferˆencia de informac¸˜ao gen´erica. As setas, indicadores de navegabilidade na UML, indicam o sentido da transferˆencia, isto ´e, quem ´e a fonte e quem ´e o receptor da informac¸˜ao. O s´ımbolo de ligac¸˜ao tern´aria da UML ´e estereotipado graficamente colocando-se um “T” no seu interior. Como n˜ao ocorre transformac¸˜ao de recurso – informac¸˜ao, neste caso – n˜ao seria adequado modelar essa operac¸˜ao como processo.
A transferˆencia de conhecimento pode ser modelada de duas formas, dependendo do as- pecto a ser enfatizado:
• Como processo. Neste caso se d´a ˆenfase ao fato de transferˆencia de conhecimento ser uma especializac¸˜ao da operac¸˜ao de socializac¸˜ao, onde h´a alterac¸˜ao do estado de conhecimento dos participantes do processo.
• Como ligac¸˜ao. Neste caso se d´a ˆenfase `a transferˆencia de conhecimento em si, sem enfatizar a alterac¸˜ao do estado de conhecimento dos participantes. Nessa representac¸˜ao fica mais expl´ıcito quem ´e a fonte e quem ´e o receptor do conhecimento.
78
Figura 3.9: Diagrama gen´erico mostrando as operac¸˜oes de transferˆencia de informac¸˜ao e co- nhecimento.
Exemplo
A figura 3.10 mostra um diagrama de processos contendo as convers˜oes de conhecimento ocorridas nos processos de definic¸˜ao e implementac¸˜ao de uma nova funcionalidade da Exem- plo Ltda.. A especificac¸˜ao de requisitos ´e internalizada pelo analista de sistemas, que passa a ter o conhecimento dos requisitos do cliente. A primeira vers˜ao do documento de acom- panhamento do projeto ´e gerada atrav´es de uma combinac¸˜ao tendo o cronograma inicial como entrada. O mesmo ocorre com a especificac¸˜ao de requisitos, que ´e usada pelo analista para gerar a especificac¸˜ao de implementac¸˜ao. O analista de sistemas precisa compartilhar o conhecimento sobre os requisitos do cliente com o programador que ir´a implementar a nova funcionalidade. Isso poderia ocorrer em uma reuni˜ao ou conversa informal, por exemplo. Esse processo ´e modelado como uma socializac¸˜ao. Uma nota ´e associada ao processo, explicando o fluxo de conhecimento ocorrido no processo e o modo como deve ocorrer.
Figura 3.10: Convers˜oes de conhecimento no processo de exemplo.
3.4
Perspectiva de modelagem: Perspectiva da informac¸˜ao e
do conhecimento
Define-se uma nova perspectiva de modelagem: a perspectiva da informac¸˜ao e do conhe- cimento. Eriksson e Penker (2000) recomendam que um neg´ocio deve ser modelado atrav´es de perspectivas de neg´ocio. Essas perspectivas n˜ao s˜ao diagramas nem modelos. S˜ao diferen- tes vis˜oes de um mesmo neg´ocio, expressas atrav´es de diferentes diagramas. Juntas criam um modelo completo do neg´ocio. A perspectiva da informac¸˜ao e do conhecimento, portanto, deve ser usada em conjunto com as perspectivas originais definidas por Eriksson e Penker: vis˜ao de neg´ocio, processos, estrutural e comportamental.
A perspectiva da informac¸˜ao e do conhecimento ´e composta por diagramas e submodelos. Os submodelos conceitual e de informac¸˜ao e o diagrama de linha de montagem j´a existem na abordagem de Eriksson e Penker. Estes foram inclu´ıdos nesta perspectiva de modelagem pois podem ser usados para modelar aspectos de neg´ocio relacionados a GIC.
Foram desenvolvidos tamb´em novos tipos de diagramas e submodelos, seguindo trˆes princ´ıpios:
• Possibilitar a modelagem de aspectos de GIC de acordo com o modelo ecologia da informac¸˜ao de Davenport (1998).
• Adaptar vis˜oes da KMDL de Gronau, M¨uller e Korf (2005).
• Aproveitar a capacidade de modelagem das extens˜oes da UML de Eriksson e Penker (2000) para modelar aspectos de GIC compat´ıveis com o modelo te´orico adotado.
80
Figura 3.11: Diagrama de classes representando uma parte do submodelo conceitual da Exem- plo Ltda..