Etiquetando Ativos de Software
Continuação do artigo "Ativos de Software". Integrante da série "Gerenciando Ativos de Software".
No artigo anterior foi apresentada a "etiqueta" RAS (Reusable Asset Specification) [1], na sequência de uma definição sobre ativos de software e suas principais características. Neste post o padrão RAS será apresentado em maiores detalhes. O modelo abaixo apresenta uma visão geral dos elementos do Core RAS:
Existem 4 grandes grupos de informações sobre os ativos: Classificação, Solução, Uso e Ativos Relacionados. Abaixo serão apresentados os elementos de cada um dos grupos. Cabe lembrar que o Perfil e os Perfis Relacionados são extensões específicas de um ativo. Serão apresentados aqui apenas os elementos do Core RAS, ou seja, aqueles obrigatórios segundo o padrão.
Classificação
Trecho do padrão que trata da definição, identificação e contextualização de um ativo de software. Ele possui uma série de Descritores que apresentam suas características e qualidades. Enquanto o padrão RAS sugere o uso de uma descrição livre, alguns autores indicam o uso de uma classificação baseada em conjuntos de atributo+valor, como por exemplo: "tipo do ativo: Código", "linguagem: Java" [2]. Uma correta e ampla classificação facilita a busca por ativos em um repositório.
Assim como a apresentação de um ou mais Contextos. Na última versão publicada do padrão são apresentados alguns exemplos de categorias para contextos, como core, negócios, desenvolvimento, documentação etc. Interessante é que todos os exemplos referem-se a Artefatos e em sua maioria estão relacionados com produtos gerados em determinado momento do ciclo de vida de um ativo. São mais relevantes para a classificação de um ativo as informações acerca do ambiente (ambientes de desenvolvimento, testes e produção) e, em caso de ativos verticais, a descrição do(s) problema(s) de negócio que o ativo endereça.
Outra qualificação aparentemente ausente no padrão RAS* é uma indicação direta do Tipo do Ativo. Essa informação relaciona-se diretamente com o tipo de uso que pode ser feito daquele ativo. A lista abaixo apresenta exemplos de tipos de ativos, mostrando seu Tipo seguido do Tipo de Uso [2]:
Por fim há um grande elemento chamado Descrição que compila todas as informações sobre a classificação de um ativo, além de outras capturadas em outros grupos. Segundo o padrão, trata-se de um simples container para uma descrição apresentada em linguagem natural.
Solução
A solução oferecida por um ativo é representada por um ou mais Artefatos. Um artefato, segundo a especificação RAS, "é um produto que pode ser criado, armazenado e manipulado por produtores / consumidores de ativos e por ferramentas. Ele pode ser um arquivo armazenado no pacote do ativo ou uma entidade lógica que possui pelo menos um artefato que existe na forma de um arquivo" [1].
Na prática, a solução sempre será representada por um conjunto de artefatos com diferentes tipos de relacionamentos entre si. As relações de dependência são formalizadas em um elemento específico (Dependências / artifact-dependency)*. O tipo de dependência (em tempo de compilação ou em runtime, por exemplo) também pode ser especificado.
O padrão RAS fixa dois níveis de Tipos de Artefatos: Primários e Secundários. O primeiro vincula o artefato diretamente a um programa, usando a extensão do arquivo (.jar, .ppt, .htm, .js etc). Os tipos secundários são utilizados apenas para descrição. Como exemplos a especificação cita: Casos de Uso, Modelos etc.
Faz mais sentido que sejam colocadas aqui, no Contexto do Artefato (contexto-artefato / artifact-context), informações sobre o momento no ciclo de vida do ativo aquele artefato foi gerado. Outras informações, como ferramentas utilizadas, detalhes do ambiente (que se diferenciem daqueles fixados para o Ativo como um todo - na seção Classificação), também devem ser cadastradas neste elemento.
Finalmente, na seção Solução, há o Ponto de Variabilidade. Trata-se da indicação do(s) local(is) onde o artefato pode ser alterado. É indicado que se forneça um contexto, bem como uma referência que detalhe os tipos de alterações que podem ou devem ser feitas.
Uso
Nesta seção são fornecidas informações sobre a(s) forma(s) de uso e manipulação dos ativos. Condensa-se aqui, particularmente no elemento Atividade, todas as ações que podem ou devem ser executadas para o efetivo uso de um ativo e de seus artefatos. Uma atividade por ser vinculada a um artefato específico (atividade-artefato / artifact-activity) ou a todo o ativo (atividade-ativo / asset-activity). A atividade pode se referir a um contexto (ref-contexto / context-ref) específico, e pode ou deve indicar o ponto de variabilidade (variability-point-binding) ao qual se aplica.
É interessante como a descrição oficial da especificação RAS faz referências ao uso de ferramentas, particularmente nesta seção. Parece ser reflexo direto do perfil dos principais patrocinadores do padrão. No entanto, graças à extensibilidade da especificação, é relativamente simples 'corrigir' o padrão ou, colocando de outra forma, adequá-lo para as necessidades específicas de uma organização.
Nesta seção Uso, por exemplo, faz falta um Histórico de Uso do Ativo. Conhecer a história de um ativo é fundamental para uma eficaz avaliação do seu potencial e do retorno gerado por ele. O Histórico deveria indicar o "Contexto de Uso e os resultados obtidos (sucesso ou fracasso, facilidade de uso, melhorias necessárias, problemas encontrados no entendimento do ativo, testes, integração e adaptação do ativo, esforço requerido nessas tarefas, ...)" [2].
Ativos Relacionados
A última seção do Core RAS cuida de vincular o ativo com todos os outros ativos que se relacionam direta ou indiretamente com ele. Um ativo de software, como colocado na especificação, "raramente existirá em isolamento". Apesar do padrão indicar que o tipo de relacionamento entre ativos é totalmente aberto, ele indica que para quatro tipos de relacionamentos existem Valores Reservados. São eles [1]:
[continua]
Referências:
Observação importante: Para uma visão completa da especificação RAS, recomendo a sua leitura integral. A versão 2.2, publicada em novembro/2005, é um arquivo PDF com 121 páginas.
Não obtive NENHUM retorno na pequena pesquisa que fiz sobre a utilização do padrão RAS aqui no Brasil. Sei que as últimas versões das ferramentas IBM/Rational, por exemplo, usam RAS. Sei também que tais ferramentas possuem uma considerável base instalada por aqui. Mesmo assim, desconfio, RAS é uma feature ignorada. Aliás, como parece ser tudo que se relacione a "reuso de ativos de software".
Aliás, tentei um contato com o RiSE (Reuse in Software Engineering Group), que, apesar do nome, é uma iniciativa tupiniquim vinculada ao CESAR e à UFPE. Resposta rápida: "desculpe a demora. os papers do RiSE voce pode pegar nos sites de ieee, acm, etc.". Admiro o trabalho dos caras, mas queria entender porque é tudo tão fechado e difícil. Aliás, nem responderam meu último email, enviado em 21/dez. Parece ser mais fácil conversar com Scott Berkun, Martin Fowler e Grady Booch do que com algumas figuras daqui. Estranho, não? Mas deixa pra lá...
Seguinte: não queria "afundar" tanto assim, mas acho que na próxima parte desta série vou falar sobre os repositórios. Tentarei encaixar no mesmo artigo o job description do GBA, o nosso Gestor da Biblioteca de Ativos.
No artigo anterior foi apresentada a "etiqueta" RAS (Reusable Asset Specification) [1], na sequência de uma definição sobre ativos de software e suas principais características. Neste post o padrão RAS será apresentado em maiores detalhes. O modelo abaixo apresenta uma visão geral dos elementos do Core RAS:
Existem 4 grandes grupos de informações sobre os ativos: Classificação, Solução, Uso e Ativos Relacionados. Abaixo serão apresentados os elementos de cada um dos grupos. Cabe lembrar que o Perfil e os Perfis Relacionados são extensões específicas de um ativo. Serão apresentados aqui apenas os elementos do Core RAS, ou seja, aqueles obrigatórios segundo o padrão.
Classificação
Trecho do padrão que trata da definição, identificação e contextualização de um ativo de software. Ele possui uma série de Descritores que apresentam suas características e qualidades. Enquanto o padrão RAS sugere o uso de uma descrição livre, alguns autores indicam o uso de uma classificação baseada em conjuntos de atributo+valor, como por exemplo: "tipo do ativo: Código", "linguagem: Java" [2]. Uma correta e ampla classificação facilita a busca por ativos em um repositório.
Assim como a apresentação de um ou mais Contextos. Na última versão publicada do padrão são apresentados alguns exemplos de categorias para contextos, como core, negócios, desenvolvimento, documentação etc. Interessante é que todos os exemplos referem-se a Artefatos e em sua maioria estão relacionados com produtos gerados em determinado momento do ciclo de vida de um ativo. São mais relevantes para a classificação de um ativo as informações acerca do ambiente (ambientes de desenvolvimento, testes e produção) e, em caso de ativos verticais, a descrição do(s) problema(s) de negócio que o ativo endereça.
Outra qualificação aparentemente ausente no padrão RAS* é uma indicação direta do Tipo do Ativo. Essa informação relaciona-se diretamente com o tipo de uso que pode ser feito daquele ativo. A lista abaixo apresenta exemplos de tipos de ativos, mostrando seu Tipo seguido do Tipo de Uso [2]:
- Executável: Chamada direta.
- Biblioteca: Integração.
- Padrão (Pattern): Imitação.
- Frameworks: Customização.
- Pacotes de Software: Integração.
- Requisitos: Comparação.
Por fim há um grande elemento chamado Descrição que compila todas as informações sobre a classificação de um ativo, além de outras capturadas em outros grupos. Segundo o padrão, trata-se de um simples container para uma descrição apresentada em linguagem natural.
Solução
A solução oferecida por um ativo é representada por um ou mais Artefatos. Um artefato, segundo a especificação RAS, "é um produto que pode ser criado, armazenado e manipulado por produtores / consumidores de ativos e por ferramentas. Ele pode ser um arquivo armazenado no pacote do ativo ou uma entidade lógica que possui pelo menos um artefato que existe na forma de um arquivo" [1].
Na prática, a solução sempre será representada por um conjunto de artefatos com diferentes tipos de relacionamentos entre si. As relações de dependência são formalizadas em um elemento específico (Dependências / artifact-dependency)*. O tipo de dependência (em tempo de compilação ou em runtime, por exemplo) também pode ser especificado.
O padrão RAS fixa dois níveis de Tipos de Artefatos: Primários e Secundários. O primeiro vincula o artefato diretamente a um programa, usando a extensão do arquivo (.jar, .ppt, .htm, .js etc). Os tipos secundários são utilizados apenas para descrição. Como exemplos a especificação cita: Casos de Uso, Modelos etc.
Faz mais sentido que sejam colocadas aqui, no Contexto do Artefato (contexto-artefato / artifact-context), informações sobre o momento no ciclo de vida do ativo aquele artefato foi gerado. Outras informações, como ferramentas utilizadas, detalhes do ambiente (que se diferenciem daqueles fixados para o Ativo como um todo - na seção Classificação), também devem ser cadastradas neste elemento.
Finalmente, na seção Solução, há o Ponto de Variabilidade. Trata-se da indicação do(s) local(is) onde o artefato pode ser alterado. É indicado que se forneça um contexto, bem como uma referência que detalhe os tipos de alterações que podem ou devem ser feitas.
Uso
Nesta seção são fornecidas informações sobre a(s) forma(s) de uso e manipulação dos ativos. Condensa-se aqui, particularmente no elemento Atividade, todas as ações que podem ou devem ser executadas para o efetivo uso de um ativo e de seus artefatos. Uma atividade por ser vinculada a um artefato específico (atividade-artefato / artifact-activity) ou a todo o ativo (atividade-ativo / asset-activity). A atividade pode se referir a um contexto (ref-contexto / context-ref) específico, e pode ou deve indicar o ponto de variabilidade (variability-point-binding) ao qual se aplica.
É interessante como a descrição oficial da especificação RAS faz referências ao uso de ferramentas, particularmente nesta seção. Parece ser reflexo direto do perfil dos principais patrocinadores do padrão. No entanto, graças à extensibilidade da especificação, é relativamente simples 'corrigir' o padrão ou, colocando de outra forma, adequá-lo para as necessidades específicas de uma organização.
Nesta seção Uso, por exemplo, faz falta um Histórico de Uso do Ativo. Conhecer a história de um ativo é fundamental para uma eficaz avaliação do seu potencial e do retorno gerado por ele. O Histórico deveria indicar o "Contexto de Uso e os resultados obtidos (sucesso ou fracasso, facilidade de uso, melhorias necessárias, problemas encontrados no entendimento do ativo, testes, integração e adaptação do ativo, esforço requerido nessas tarefas, ...)" [2].
Ativos Relacionados
A última seção do Core RAS cuida de vincular o ativo com todos os outros ativos que se relacionam direta ou indiretamente com ele. Um ativo de software, como colocado na especificação, "raramente existirá em isolamento". Apesar do padrão indicar que o tipo de relacionamento entre ativos é totalmente aberto, ele indica que para quatro tipos de relacionamentos existem Valores Reservados. São eles [1]:
- Aggregation: indica que o ativo 'contém' o ativo relacionado;
- Similar: o ativo possui características similares às daquele relacionado;
- Dependency: indica que o ativo referencia ou depende dos serviços ou artefatos do ativo relacionado;
- Parent: o ativo 'é contido' ou pertence ao ativo relacionado.
[continua]
.:.
Referências:
- RAS - Reusable Asset Specification - Versão 2.2
Object Management Group (OMG) (05/Nov/2005). - Practical Software Reuse
Michel Ezran, Maurizio Moricio e Colin Tully
Springer (2002).
.:.
Observação importante: Para uma visão completa da especificação RAS, recomendo a sua leitura integral. A versão 2.2, publicada em novembro/2005, é um arquivo PDF com 121 páginas.
Não obtive NENHUM retorno na pequena pesquisa que fiz sobre a utilização do padrão RAS aqui no Brasil. Sei que as últimas versões das ferramentas IBM/Rational, por exemplo, usam RAS. Sei também que tais ferramentas possuem uma considerável base instalada por aqui. Mesmo assim, desconfio, RAS é uma feature ignorada. Aliás, como parece ser tudo que se relacione a "reuso de ativos de software".
Aliás, tentei um contato com o RiSE (Reuse in Software Engineering Group), que, apesar do nome, é uma iniciativa tupiniquim vinculada ao CESAR e à UFPE. Resposta rápida: "desculpe a demora. os papers do RiSE voce pode pegar nos sites de ieee, acm, etc.". Admiro o trabalho dos caras, mas queria entender porque é tudo tão fechado e difícil. Aliás, nem responderam meu último email, enviado em 21/dez. Parece ser mais fácil conversar com Scott Berkun, Martin Fowler e Grady Booch do que com algumas figuras daqui. Estranho, não? Mas deixa pra lá...
Seguinte: não queria "afundar" tanto assim, mas acho que na próxima parte desta série vou falar sobre os repositórios. Tentarei encaixar no mesmo artigo o job description do GBA, o nosso Gestor da Biblioteca de Ativos.
Marcadores: gerenciamento_de_ativos, mps, qualidade, reuso, soa, spi
quinta-feira, 4 de janeiro de 2007 |
Assine o finito
Lista completa no del.icio.us
neste post
Qual é a sua opinião?