• Nenhum resultado encontrado

Cenário 8 Envolver a estruturação de ASs com o PDS

No documento Autoria de artefatos de software (páginas 103-107)

3 Trabalhos Relacionados

Artefato 1 Artefato 2 Contêiner

4.3.8 Cenário 8 Envolver a estruturação de ASs com o PDS

No cenário atual de modelagem de PDS, papéis, artefatos e atividades estão interligados entre si. Desta forma, é possível identificar quais atividades são responsáveis por dado artefato e seus respectivos papéis. Conforme identificado em alguns PDSs, assim como RUP e OPEN, é bastante comum a utilização de sub-atividades, ou seja, dividir uma atividade em pedaços menores. Muitas vezes uma atividade chega a ser subdividida a ponto de ser tornar uma tarefa (task), empregada apenas um papel exclusivamente.

Além disso, também é bastante comum o desenvolvimento de grupos de papéis (Composite

Role), que juntos contém competências, ou qualificações suficientes para atuar em atividades

um pouco mais exigentes.

Assim como as tarefas são exclusivas e interligadas com papéis específicos, que muitas ve- zes são agrupados, um artefato também precisa se relacionar desta forma, para que as restrições de execução da atividade, em meio de tarefas e papéis, sejam correspondidas.

Portanto, diante do fato de nossa abordagem subdividir ASs, devemos também alinhar tais fragmentos e contêineres as atividades e papéis correspondentes.

Pontos Fracos

Atualmente, já que PDSs tratam ASs de forma monolítica, ou seja, inteiros e sem divisões, existem alguns problemas conforme a ligação entre os papéis atuantes e as atividades corres- pondentes, tais como: (i) artefatos são produzidos inteiramente, sem identificar quais pontos serão produzidos durante aquela atividade; (ii) necessária experiência e conhecimento prévio

sobre construção do artefato para seu preenchimento correto durante atividade; (iii) os papéis precisam conter maior quantidade de competência ou qualificações para executarem uma ativi- dade dado o fato de produzirem artefatos inteiros; (iv) em um artefato não existem informações suficientes para identificar as atividades que foram responsáveis, (v) nem quais partes foram construídas.

Exemplo

A construção do artefato Visão, é feita parte a parte, ou seja, ao longo da execução de di- versas atividades do PDS, neste caso o RUP. Para a execução dessas atividades são necessários diferentes papéis. A exemplo temos as atividades Capturar um Vocabulário Comum que re- quisita um Analista de Sistemas, Localizar Atores e Casos de Uso de Negócios que precisa de um Analista de Processo de Negócios e Localizar Entidades e Trabalhadores de Negócios que utiliza um Designer de Negócios, e assim por diante.

Como pode ser visto, um mesmo AS pode ser construído por diversos papéis diferentes, em diversas atividades diferentes. Embora a documentação do RUP apresente quais passos devem ser feitos para executar as atividades, não fica claro quais partes que constituem o artefato Visão devem ser feitas por Quem (Papel) e Quando (Atividade). Desta forma, após o preenchimento do artefato, tais informações são praticamente impossíveis de rastrear dentro de um PDS.

Entretanto, muitas vezes a experiência adquirida em um PDS específico permite que este conhecimento seja formado ao longo do tempo. Porém, muitas vezes não se usa o mesmo processo inteiramente, além disso, suas execuções são diferentes entre si.

Solução encontrada

Para este fim o SPEM v2 foi estudado cuidadosamente, sendo identificados seus pontos de extensão. Por ser um metamodelo flexível e uma extensão da UML para desenvolvimento de um domínio específico, sua construção foi feita determinando diferentes níveis de conformidade (compliance levels).

Por fim, devemos integrar a extensão do metamodelo com o metamodelo original, combi- nando assim a autoria de ASs com a autoria de PDSs já definida pelo SPEM v2.

Como o próprio SPEM v2 já possui a conexão entre artefatos, papéis e atividades, dadas pelas metaclasses WorkProductDefinition/WorkProductUse, RoleDefinition/RoleUse e Activity-

Definition/ActivityUse, para haver integração é necessário definir como será a interação entre os

mesmos em relação aos conceitos acrescentados no metamodelo. Devido a extensão, artefatos e suas informações contêm tipo e estrutura interna, para adicionar este conhecimento aos papéis e atividades, deve existir uma ligação que permita tal sincronia.

Na Figura 4.18 estão algumas das metaclasses da extensão feita sobre o SPEM v2, em tons mais claros. As metaclasses ArtifactDefinition, ContainerDefinition e FragmentDefinition, já definidas anteriormente em 4.3.3, foram remodeladas como sub-

classes de WorkProductDefinition, herdando o auto relacionamento previamente defi- nido pela metaclasse do SPEM v2 WorkProductDefinitionRelationship. A meta- classe abstrata SimpleInformationElement tambem é uma dessas subclasses, por tran- sitividade. Desta forma, passa a existir uma conexão entre o metamodelo definido pela OMG e a extensão realizada nesse trabalho. Vale notar também, que qualquer alteração na metaclasse WorkProductDefinitionserá espelhada para suas subclasses.

Figura 4.18: Base hierárquica de heranças que permite interação entre ASs e outros elementos do PDS. As metaclasses em tons mais claros fazem parte do SPEM v2 enquanto as de tons escuros são da extensão.

Além disso, na Figura 4.19 é apresentado um diagrama que contém a solução de modelagem para relacionar ASs com seus respectivos papéis proposta no metamodelo do SPEM v2. No metamodelo estão as metaclasses RoleDefinition e WorkProductDefinition que estão relacionadas através de Default_ResponsibilityAssignment. Embora apenas ArtifactDefinitionesteja exposta no diagrama, todas as subclasses de WorkProduct Definitionpossuem o relacionamento com RoleDefinition.

Figura 4.19: Relacionamento entre papel e artefato.

Para definir a interação entre artefato e atividade foi reutilizada a estrutura do SPEM v2. Na Figura 4.20 está definido um diagrama que representa esta ligação. Através da metaclasse

Default_TaskDefinitionParameter do SPEM v2 pode-se criar um elo de ligação entre as subclasses de WorkProductDefinition e TaskDefinition, que especializa WorkDefinition. A metaclasse WorkDefinition modela o conceito de trabalho a ser realizado podendo ser um sinônimo para atividade, embora mais geral.

Figura 4.20: Relacionamento entre artefato e atividade.

Por fim, a Figura 4.21 apresenta as ligações existentes entre os conceitos de papel e ativi- dade. Como pode ser observado, uma TaskDefinition especializa a metaclasse abstrata WorkDefinition, que é uma representação geral do conceito de atividade. Desta forma, existe a relação entre TaskDefinition e RoleDefinition através da metaclasse do SPEM v2 Default_ResponsibilityAssignment.

Figura 4.21: Relacionamento entre papel e atividade do SPEM v2.

Comparação com abordagens atuais

Desta forma, tanto a estrutura da informação, quanto a estrutura do artefato devem possuir relacionamentos com papéis e atividades. A partir deste ponto pode ser visto que é possível de- terminar, exatamente, o que cada papel será responsável em produzir, conforme ação específica a ser feita em uma atividade que deva manipular um artefato.

No documento Autoria de artefatos de software (páginas 103-107)