Existe um Method Content com quatro artefatos, os quais estão em primeira

Exemplo 1: Dado o preenchimento do artefato Modelo de Casos de Uso, do RUP, ao qual

foram inicialmente definidos dois atores e três casos de uso, pode-se armazena-lo em um repo- sitório. Mais adiante caso haja a necessidade de reparos ou atualizações, como adição de mais um caso de uso, por exemplo, este artefato será recolocado no repositório, juntamente com as informações sobre o que ocorreu. Entretanto, caso os comentários feitos pelo responsável pelas alterações não sejam suficientes, a menos que comparemos os artefato em ambas as versões nós não saberemos o que foi modificado. Além disso, a utilização de mecanismos de diferenciação é desencorajada, por não se tratar de um artefato constituído apenas de texto.

Exemplo 2: Durante a modelagem de um PDS podem existir diversas alterações e refina-

mentos. Dada a autoria, poderiam ser criadas duas atividades, 1 papel e 3 artefatos, juntamente com suas ligações. A partir deste momento pode-se enviar o arquivo com o modelo do PDS para o repositório. Caso seja necessário alterar a estrutura previamente definida e outro arquivo deva ir ao repositório, possivelmente existirão problemas na identificação do que foi alterado. Infelizmente, se o Engenheiro de Processos responsável pela modelagem não for bastante cuida- doso, terá que rastrear os elementos da própria linguagem de modelagem do PDS para verificar onde ocorreram as alterações.

Exemplo 3: Dado uma família de PDSs previamente definida, a qual cada PDS é derivado

tornando-se uma versão do PDS Base, neste caso o RUP. Para uma melhor adaptação do PDS para um determinado domínio especifico atividades, papéis ou outros elementos do PDS Base foram excluídos, gerando a árvore de variabilidades de PDS. Sendo assim, da mesma forma que no Exemplo 2, caso não haja a informação explicita do que foi alterado, deve-se rastrear os arquivos de modelagem dos PDSs para verificar suas diferenças em relação ao PDS Base, percebendo então, as mudanças.

Exemplo 4: Existe um Method Content com quatro artefatos, os quais estão em primeira

versão, e será necessário alterá-lo para que um dos artefatos seja dividido em dois. As alterações foram feitas e enviadas ao repositório. Após a alteração foi necessário verificar o que foi mo- dificado, entretanto, não existe a informação de como um artefato se transformou em dois, nem ao menos qual artefato sofreu tais modificações e fora excluído. Além disso, deve ser avaliado o impacto da alteração, que ocorrerá nas camadas superiores, gerando mais problemas.

Solução encontrada

Conforme utilizaremos metamodelagem para definir o Method Content e Process Structure, escolhemos utilizar o próprio MOF Repository (OMG, 2007a) para gerenciar as versões nos

níveis de metamodelo e modelo.

O MOF Repository estende o MOF (OMG, 2006), adicionando metaclasses que represen- tam controle de versão. Na Figura 4.12 estão as principais metaclasses responsáveis pelo versi- onamento. Desta forma, todos os elementos das camadas de meta-metamodelo, metamodelo e modelo poderão ser versionados e não apenas artefatos.

Figura 4.12: Algumas das Metaclasses do MOF Repository

Como se trata de uma extensão do MOF, o MOF Repository adiciona estas metaclasses na própria camada M3. Desta forma, qualquer linguagem definida a partir desta extensão do MOF, poderá ser versionada. Como pode ser visto na Figura 4.12 a metaclasse VersionedExtent herda Extent. No contexto do MOF, um Extent é responsável por aplicar algumas das ca- pacidades a elementos do MOF, assim como gerar a identificação através de Uniform Resource

Identifier (URI) . Através de VersionedExtent é possível obter versões e históricos do

que foi alterado. O MOF Repository ainda contém metaclasses responsáveis por determinar

workspaces, Baselines e definir sessões.

Comparação com abordagens atuais

Com a utilização do MOF Repository é possível verificar o que exatamente foi alterado den- tro das camadas existentes em um PDS. Além disso, também é possível saber o papel respon- sável pelas alterações. Finalmente, é possível rastrear os elementos da modelagem nas diversas camadas modeladas para um PDS.

4.3.7 Cenário 7 - Relacionar os artefatos utilizando diferentes níveis de reuso e compar- tilhamento

Existe uma grande preocupação por parte da indústria no modo como é feito o armazena- mento de informações durante a execução de um processo. Como sabemos, estas informações são guardadas nos artefatos, porém, a preocupação está em armazená-las corretamente.

Assim como em um banco de dados, quando tratamos com informações existem problemas relacionados a forma estrutural e o conteúdo, que são tratados como duas coisas diferentes.

Desta forma, para relacionar os artefatos com suas respectivas informações, de forma a reduzir a redundância e a inconsistência pode-se tentar aumentar o reuso.

Pontos Fracos

Um grande problema visto na maioria dos projetos é a manutenção dos artefatos. Seja um pequeno trecho de código alterado, que pode vir a reduzir a consistência com o modelo, ou algum documento de negócios ou de gerência, que pode vir a estar desatualizado.

Durante a execução do processo, na medida do possível tanto a estrutura quanto o conteúdo são reutilizados. Entretanto, isto geralmente é feito através de procedimentos de cópia-e-cola das informações. O que pode causar problemas de manutenção dos artefatos supracitados.

Um outro problema é a inconsistência causada por falta de comunicação, o que pode le- var a redundâncias. Isto ocorre geralmente quando diferentes atores trabalham com diferentes artefatos que deveriam reutilizar estrutura ou conteúdo. Como os atores não se comunicaram, possivelmente os mesmos conceitos serão guardados de formas diferentes, e em diferentes ar- tefatos.