Autoria de Artefatos de Software: Uma abordagem baseada em Estruturas

Transcrição

1 Autoria de Artefatos de Software: Uma abordagem baseada em Estruturas Marcos Silva 1 Orientadores: Ricardo Bastos 1 e Toacy Oliveira 2 1 Faculdade de Informática Pontifícia Universidade Católica do Rio Grande do Sul (PUC-RS) Av. Ipiranga, 6681 Porto Alegre RS Brazil 2 School of Computer Science University of Waterloo N2L 3G1 Toronto Canada {mtsilva,bastos}@pucrs.br, toacy@csg.uwaterloo.ca Nível: Mestrado Programa: Programa de Pós-Graduação em Ciência da Computação Ano de ingresso: 2007 Previsão de conclusão: Março de 2009 Aprovação da proposta: 20/12/2007 Resumo. Processos de Software definem um conjunto de atividades e papéis na intenção de se obter os artefatos necessários para a produção de um Produto de Software. O Software and Systems Process Engineering Metamodel (SPEM v2), criado pela Object Management Group (OMG), fornece um metamodelo para padronizar a representação de Processos de Software através do uso da Unified Modeling Language (UML). Entretanto, por ser baseado nos processos atuais, este metamodelo não possui clareza quanto a utilização, autoria e preenchimento dos artefatos, tratando-os como se fossem elementos monolíticos. Isto requer um extenso trabalho de construção manual, fazendo com que a documentação de softwares seja complexa e com custo elevado. Neste trabalho apresentamos uma abordagem que se contrapõe em relação a forma atual de construção de artefatos, definindo-os como elementos fortemente estruturados. Esta troca de paradigma permite que as informações utilizadas durante o processo sejam concentradas e compartilhadas por diversos documentos simultaneamente. Por fim, será construída uma ferramenta com o objetivo de suportar e verificar a abordagem supracitada. Palavras-chave: Artefatos de Software, Processos de Software, SPEM, UML 13

2 1. Caracterização do Problema Em Processos de Desenvolvimento de Software são definidos conjuntos de artefatos necessários para que seja possível atingir a um Produto de Software final desejado [Fuggetta 2000]. Segundo [Quint and Vatton 2004], tais artefatos deveriam possuir uma estrutura lógica interna e representações particulares de informação. Entretanto, no atual paradigma de processos, tais artefatos são tratados como elementos monolíticos e as informações neles contidas, nem sempre são bem definidas [Tilley and Huang 2002, Quint and Vatton 2004]. Ainda mais, por falta de uma linguagem que consiga formalizar e detalhar os artefatos em níveis como apontados por [Akpotsui et al. 1992], diversas interpretações são possíveis e a informação tende a estar espalhada e, muitas vezes, repetida através de diferentes artefatos. Ou seja, atualmente, não existe a certeza de que será possível evitar ou perceber redundância e ambigüidade sem ao menos conhecer os artefatos inteiramente. Muitos desses processos, assim como o Rational Unified Process (RUP) [Kruchten 1999] e Object-oriented Process, Environment and Notation (OPEN) [Graham et al. 1997], compreendem este mesmo paradigma. No caso do RUP, estão definidos aproximadamente 100 artefatos que, em sua grande maioria, são editados através de processadores de texto como o Microsoft Office Word TM ou Open Office Writer 1. Além disso, a grande maioria dos artefatos que são baseados em textos são divididos em seções. Tais seções possuem títulos, em uma tentativa de especificar qual o tipo de conteúdo esperado [Akpotsui et al. 1992, Laitinen 1992], sendo feita a partir da interpretação do responsável pelo documento [Falbo et al. 2002]. Este trabalho tem como objetivo desenvolver conceitos capazes de permitir a modelagem, autoria e utilização de artefatos de software de forma estruturada. Como objetivos específicos, temos: 1. Estruturar, efetivamente, artefatos de software, permitindo uma reusabilidade estrutural e uma flexibilidade na criação, autoria e produção dos mesmos. 2. Especificar versionamento, identificação de níveis de maturidade e controle estrutural, para o gerenciamento dos artefatos. 3. Criar um metamodelo que trate das diferentes necessidades da autoria de processos e artefatos, implementando os conceitos especificados nos itens 1 e Especificar uma ferramenta de software e produzir um protótipo, tendo como base o metamodelo do item Elaborar casos de testes envolvendo a autoria de artefatos utilizando o protótipo da ferramenta a ser desenvolvido em Fundamentação Teórica Um Processo de software é um conjunto coerente de políticas, estruturas organizacionais, tecnologias, procedimentos e artefatos que são necessários para conceber, desenvolver, instalar e manter um Produto de Software [Fuggetta 2000]. Nele são defidas atividades, papéis e artefatos que serão utilizados durante o desenvolvimento de software. As atividades especificam as tarefas que devem ser executadas durante o processo, os papéis

3 descrevem as pessoas que cumprirão com as atividades do processo e os artefatos armazenam as informações criadas durante a realização das atividades. O Software and Systems Process Engineering Metamodel (SPEM v2) [Object Management Group 2007] é um arcabouço conceitual que provê elementos para a modelagem, documentação, apresentação, gerência, troca e execução de métodos e processos de software. O SPEM v2 estende a Unified Modeling Language [Object Management Group 2003] (UML) e é definido pelo Meta Object Facility (MOF) [Object Management Group 2006], que consiste em uma linguagem para definição de metamodelos. O SPEM v2 é constituído de sete pacotes, nos quais as principais metaclasses responsáveis pela autoria de processos estão divididas entre os pacotes Method Content, que permite a criação do processo, e Process with Methods, que utiliza as definições fornecidas pela criação do processo. 3. Caracterização da Contribuição A base da contribuição deste trabalho é constituída a partir dos desafios e objetivos traçados nas seções anteriores. A criação de um metamodelo capaz de permitir a criação, autoria e produção de artefatos de software define uma linguagem bem definida de representação visual[pottinger and Bernstein 2003]. Desta forma, busca-se disponibilizar uma extensão da UML capaz de definir artefatos, servindo como base para os esforços futuros na área de autoria de processos e no desenvolvimento de aplicações neste contexto. A existência de uma linguagem para a definição de artefatos possibilita que eles sejam construídos utilizando-se uma estrutura lógica de organização. Portanto, com a construção de um metamodelo que utiliza o metamodelo da UML é possível utilizar modelos e diagramas já especificados pela linguagem UML que consistem em artefatos já utilizados no desenvolvimento de software. Com a obtenção de conhecimento sobre o formato estrutural dos artefatos e seu preenchimento, podemos entender melhor sobre o ciclo de produção do mesmo. As informações que permeiam a forma do artefato podem ser verificadas e avaliadas iterativamente, assim podemos utilizar versionamento tanto na definição quanto no uso dos artefatos. Além do mais, o aumento no compartilhamento de conteúdo e estrutura, baseado no reuso, pode diminuir o tempo de elaboração e produção dos artefatos. 4. Estado Atual do Trabalho Para a realização da Autoria de Artefatos em Processos de Software foram definidas as seguintes etapas que estão sendo realizadas na ordem em que se apresentam: Etapa 1: realização do levantamento bibliográfico sobre os processos de software, buscando, na captura e identificação dos artefatos, conhecer suas estruturas internas (Ex.: gráficos, textos, figuras, seções, listas), estudando UML, MOF, SPEM v2 e trabalhos relacionados. Esta etapa é contínua e visa a verificação do impacto de outros trabalhos na área na abordagem proposta. Etapa 2: nesta etapa foi feito: (i) um levantamento sobre tipologia de artefatos através de estudo teórico e (ii) um aprofundamento dos estudos sobre os mecanismos de extensão do metamodelo do SPEM v2. Esta etapa foi fundamental para a definição dos 15

4 conceitos necessários para a extensão do metamodelo. O nível de conformidade para a extensão do SPEM v2 selecionado foi o MethodContent. O ponto de extensão será a partir dos pacotes MethodContent e Core. Tal etapa encontra-se finalizada. Etapa 3: realizar uma análise dos resultados obtidos das etapas 1 e 2 para: (i) identificar os artefatos mais utilizados nos processos de software a serem analisados; (ii) identificar a tipologia dos artefatos, selecionando um mapeamento para cada estrutura de informação diferente; (iii) propor a extensão do metamodelo SPEM v2 que permita a quebra do artefato em uma estrutura mais granular. Esta etapa encontra-se em fase de finalização e a maioria dos conceitos já foram identificados. O metamodelo foi estendido com a definição de três tipos de pacotes: pacotes que estendem o núcleo do SPEM v2: pacotes que possuem metaclasses para classificação, conforme [Laitinen 1992], definição de níveis de maturidade, baseado em [Visconti and Cook 1993] e gerência de artefatos em relação as modificações feitas durante a definição e uso dos mesmos; pacotes de modelagem de informação: constituído pelo pacote InformationTypes e seus subpacotes, onde estão os tipos de informação que foram mapeados; pacote para extensão do MethodContent: neste pacote está o acréscimo das metaclasses capazes de estruturar o artefato de forma lógica permitindo também a definição de organização hierárquica. Etapa 4: a ser realizada em três atividades: (i) propor a ferramenta de suporte; (ii) fazer a análise e projeto da ferramenta; e (iii) implementar a ferramenta proposta. Esta etapa encontra-se em andamento. Etapa 5: a ser feita em duas atividades: (i) realizar os casos de testes, objetivando a prática do que foi desenvolvido nas etapas anteriores; (ii) realizar a revisão, entrega e defesa da dissertação. Esta etapa ainda não foi inicializada. 5. Trabalhos Relacionados Em [Akpotsui et al. 1992], documentos são considerados estruturas lógicas feitas a partir de elementos (como títulos, seções, parágrafos) que, quando compostos, são capazes de representar a organização dos documentos. Cada elemento possui um tipo definido pelos seus relacionamentos através da modelagem de uma estrutura genérica. Em tal modelo deve existir um conjunto de Tipos T construídos a partir de um Conjunto Básico de Tipos β = {Texto, Imagem,..., Gráfico} e um Conjunto de Construtores C = {Grupo, Lista,..., Identidades}, ambos extensíveis. Embora o escopo esteja resumido a apenas artefatos do tipo Documento, esta solução permite determinar sua estrutura e organização. HotDoc [Buchner 2000] é um arcabouço para Documentos Compostos (Compounding Documents) e permite a autoria de documentos flexíveis e dinâmicos que consistem em diferentes tipos e partes. Estes documentos são capazes de possuir outros tipos de conteúdos, como tabelas, figuras, diagramas, gráficos, som e vídeo e não apenas texto. Além disso, as partes podem compartilhar um mesmo modelo de dados através de ligações entre elas, desde que estas ligações sejam entre modelos compatíveis. Desta forma, são adicionadas funcionalidades para a autoria de documentos, permitindo que o autor combine diferentes partes de conteúdo até obter um documento composto. Assim como em [Akpotsui et al. 1992], o HotDoc também possui foco em Documento. No entanto, esta abordagem acrescenta a utilização de partes flexíveis. 16

5 O Compound Document access and Management (CDAM) é um Banco de Dados Orientado a Objetos que permite a gerência de documentos compostos. Segundo [Herzner and Hocevar 1991], documentos são pedaços de informações estruturadas com a propriedade de se auto-definir em sentenças como: um artigo consiste em um título, um resumo, o conteúdo e bibliografia. Para os autores, documentos são coleções de partes ou componentes, formando uma agregação. O Sistema CDAM contém node types para acesso aos documentos, fazendo com que, diferentemente do HotDoc, ele esteja mais preocupado com o gerenciamento das informações de um documento e não sua autoria. Em [Visconti and Cook 1993] é identificado um meio de melhorar o processo e definir quatro níveis de maturidade para a documentação do mesmo. Neste trabalho fica evidente que não basta apenas construir os artefatos, é necessário determinar seus estados, para que estejam em nível apropriado de qualidade. Já para [Laitinen 1992], muitas abordagens possuem o foco na qualidade da documentação e não definem como classificá-la, nem mesmo como organizar as informações obtidas. Desta forma, o autor sugere uma abordagem para a classificação de documentos, provendo identificação sobre o tipo de informação contida no documento baseado em uma nomenclatura. Diferente dos trabalhos apresentados até então, estas abordagens classificam artefatos de um Processo de Software quanto aos seus estados e tipos de conteúdos, respectivamente. Assim como nestes trabalhos também consideramos a classificação e o nível de qualidade dos artefatos. Além disso, nossa proposta aplica esforços explicitamente na autoria de artefatos, detalhando-a. Nós utilizamos a extensão do metamodelo SPEM v2, que é uma linguagem Orientada a Objetos e que utiliza a UML. Outro grande diferencial é a adição de versionamento. 6. Avaliação dos Resultados Haverá a utilização do metamodelo sugerido e um protótipo será desenvolvido. Pretendemos avaliar este trabalho utilizando casos de testes em um conjunto de artefatos, demonstrando a efetividade do modelo através do uso sobre o protótipo. Desta forma, os resultados serão verificados e a abordagem refinada, pois serão realizados eventuais ajustes e correções no metamodelo e no protótipo. 7. Considerações finais Através da extensão da UML, a OMG foi capaz de definir um metamodelo para a especificação do domínio de processos de software. No tocante a construção de artefatos, os paradigmas atuais são restritos, pois não resolvem, por completo, a falta de estruturação e excesso de redundância das informações. Embora alguns trabalhos tenham sido identificados, eles não resolvem os problemas supracitados e não representam esforços direcionados na autoria de artefatos, focando apenas na edição, classificação ou em qualidade de Documentos. Estudo realizado pelo Centro de Desenvolvimento e Pesquisa PUCRS-DELL. Termo Aditivo: Programa de Pesquisa e Desenvolvimento em Tecnologia da Informação - PDTI 001/2008, financiado pela Dell Computadores do Brasil Ltda. com recursos da Lei 8.248/91. 17

6 References Akpotsui, E., Quint, V., and Roisin, C. (1992). Type modelling for document transformation in structured editing systems. Mathematical and Computer Programming, Special Issue devoted to the 1992 Workshop on Principles documents. Buchner, J. (2000). Hotdoc: a framework for compound documents. ACM Comput. Surv., 32:Article No. 33. Falbo, R. A., Guizzardi, G., Natali, A. C. C., Bertollo, G., Ruy, F. F., and Mian, P. G. (2002). Towards semantic software engineering environments. In SEKE 02: Proceedings of the 14th international conference on Software engineering and knowledge engineering, pages , New York, NY, USA. ACM. Fuggetta, A. (2000). Software process: a roadmap. In ICSE 00: Proceedings of the Conference on The Future of Software Engineering, pages 25 34, New York, NY, USA. ACM Press. Graham, I., Henderson-Sellers, B., and Younessi, H. (1997). The OPEN process specification. ACM Press/Addison-Wesley Publishing Co., New York, NY, USA. Herzner, W. and Hocevar, E. (1991). Cdam compound document access and management: an object-oriented approach. SIGOIS Bull., 12(1):1 18. Kruchten, P. (1999). The Rational Unified Process: an introduction. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. Laitinen, K. (1992). Document classification for software quality systems. SIGSOFT Softw. Eng. Notes, 17(4): Object Management Group (2003). Unified modeling language specification v Object Management Group (2006). Meta object facility v Object Management Group (2007). Software & systems process engineering metamodel specification Pottinger, R. A. and Bernstein, P. A. (2003). Merging models based on given correspondences. In vldb 2003: Proceedings of the 29th international conference on Very large data bases, pages VLDB Endowment. Quint, V. and Vatton, I. (2004). Techniques for authoring complex xml documents. In DocEng 04: Proceedings of the 2004 ACM symposium on Document engineering, pages , New York, NY, USA. ACM. Tilley, S. and Huang, S. (2002). Documenting software systems with views iii: towards a task-oriented classification of program visualization techniques. In SIGDOC 02: Proceedings of the 20th annual international conference on Computer documentation, pages , New York, NY, USA. ACM Press. Visconti, M. and Cook, C. (1993). Software system documentation process maturity model. In CSC 93: Proceedings of the 1993 ACM conference on Computer science, pages , New York, NY, USA. ACM Press. 18