Autoria de Artefatos de Software: Uma abordagem baseada
em Estruturas
Marcos Silva1
Orientadores: Ricardo Bastos1 e Toacy Oliveira2
1Faculdade de Inform´atica – Pontif´ıcia Universidade Cat´olica do Rio Grande do Sul (PUC-RS)
Av. Ipiranga, 6681 – Porto Alegre – RS – Brazil
2School 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´os-Graduac¸˜ao em Ciˆencia da Computac¸˜ao Ano de ingresso: 2007
Previs˜ao de conclus˜ao: Marc¸o de 2009 Aprovac¸˜ao da proposta: 20/12/2007
Resumo. Processos de Software definem um conjunto de atividades e pap´eis na intenc¸˜ao de se obter os artefatos necess´arios para a produc¸˜ao 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 representac¸˜ao de Processos de Software atrav´es do uso da Unified Modeling Language (UML). Entretanto, por ser baseado nos processos atuais, este metamodelo n˜ao possui clareza quanto a utilizac¸˜ao, autoria e pre-enchimento dos artefatos, tratando-os como se fossem elementos monol´ıticos. Isto requer um extenso trabalho de construc¸˜ao manual, fazendo com que a documentac¸˜ao de softwares seja complexa e com custo elevado. Neste traba-lho apresentamos uma abordagem que se contrap˜oe em relac¸˜ao a forma atual de construc¸˜ao de artefatos, definindo-os como elementos fortemente estrutura-dos. Esta troca de paradigma permite que as informac¸˜oes utilizadas durante o processo sejam concentradas e compartilhadas por diversos documentos si-multaneamente. Por fim, ser´a constru´ıda uma ferramenta com o objetivo de suportar e verificar a abordagem supracitada.
1. Caracterizac¸˜ao do Problema
Em Processos de Desenvolvimento de Software s˜ao definidos conjuntos de artefa-tos necess´arios para que seja poss´ıvel atingir a um Produto de Software final dese-jado [Fuggetta 2000]. Segundo [Quint and Vatton 2004], tais artefatos deveriam possuir uma estrutura l´ogica interna e representac¸˜oes particulares de informac¸˜ao.
Entretanto, no atual paradigma de processos, tais artefatos s˜ao tratados como elementos monol´ıticos e as informac¸˜oes neles contidas, nem sempre s˜ao bem defini-das [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 interpretac¸˜oes s˜ao poss´ıveis e a informac¸˜ao tende a estar espalhada e, muitas vezes, repetida atrav´es de diferentes artefatos. Ou seja, atual-mente, n˜ao existe a certeza de que ser´a poss´ıvel evitar ou perceber redundˆancia e am-big¨uidade 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˜ao definidos aproximadamente 100 artefatos que, em sua grande maioria, s˜ao editados atrav´es de processadores de texto como o Microsoft Office WordTMou Open Office Writer1.
Al´em disso, a grande maioria dos artefatos que s˜ao baseados em textos s˜ao di-vididos em sec¸˜oes. Tais sec¸˜oes possuem t´ıtulos, em uma tentativa de especificar qual o tipo de conte´udo esperado [Akpotsui et al. 1992, Laitinen 1992], sendo feita a partir da interpretac¸˜ao do respons´avel pelo documento [Falbo et al. 2002].
Este trabalho tem como objetivo desenvolver conceitos capazes de permitir a mo-delagem, autoria e utilizac¸˜ao de artefatos de software de forma estruturada. Como objeti-vos espec´ıficos, temos:
1. Estruturar, efetivamente, artefatos de software, permitindo uma reusabilidade es-trutural e uma flexibilidade na criac¸˜ao, autoria e produc¸˜ao dos mesmos.
2. Especificar versionamento, identificac¸˜ao de n´ıveis de maturidade e controle estru-tural, para o gerenciamento dos artefatos.
3. Criar um metamodelo que trate das diferentes necessidades da autoria de proces-sos e artefatos, implementando os conceitos especificados nos itens 1 e 2.
4. Especificar uma ferramenta de software e produzir um prot´otipo, tendo como base o metamodelo do item 3.
5. Elaborar casos de testes envolvendo a autoria de artefatos utilizando o prot´otipo da ferramenta a ser desenvolvido em 4.
2. Fundamentac¸˜ao Te´orica
Um Processo de software ´e um conjunto coerente de pol´ıticas, estruturas organizacionais, tecnologias, procedimentos e artefatos que s˜ao necess´arios para conceber, desenvolver, instalar e manter um Produto de Software [Fuggetta 2000]. Nele s˜ao defidas atividades, pap´eis e artefatos que ser˜ao utilizados durante o desenvolvimento de software. As ati-vidades especificam as tarefas que devem ser executadas durante o processo, os pap´eis
descrevem as pessoas que cumprir˜ao com as atividades do processo e os artefatos arma-zenam as informac¸˜oes criadas durante a realizac¸˜ao das atividades.
O Software and Systems Process Engineering Metamodel (SPEM v2) [Object Management Group 2007] ´e um arcabouc¸o conceitual que provˆe ele-mentos para a modelagem, documentac¸˜ao, apresentac¸˜ao, gerˆencia, troca e execuc¸˜ao de m´etodos e processos de software. O SPEM v2 estende a Unified Modeling Lan-guage[Object Management Group 2003] (UML) e ´e definido pelo Meta Object Facility (MOF) [Object Management Group 2006], que consiste em uma linguagem para definic¸˜ao de metamodelos. O SPEM v2 ´e constitu´ıdo de sete pacotes, nos quais as principais metaclasses respons´aveis pela autoria de processos est˜ao divididas entre os pacotes Method Content, que permite a criac¸˜ao do processo, e Process with Methods, que utiliza as definic¸˜oes fornecidas pela criac¸˜ao do processo.
3. Caracterizac¸˜ao da Contribuic¸˜ao
A base da contribuic¸˜ao deste trabalho ´e constitu´ıda a partir dos desafios e objetivos trac¸ados nas sec¸˜oes anteriores.
A criac¸˜ao de um metamodelo capaz de permitir a criac¸˜ao, autoria e produc¸˜ao de artefatos de software define uma linguagem bem definida de representac¸˜ao visual[Pottinger and Bernstein 2003]. Desta forma, busca-se disponibilizar uma extens˜ao da UML capaz de definir artefatos, servindo como base para os esforc¸os futuros na ´area de autoria de processos e no desenvolvimento de aplicac¸˜oes neste contexto.
A existˆencia de uma linguagem para a definic¸˜ao de artefatos possibilita que eles sejam constru´ıdos utilizando-se uma estrutura l´ogica de organizac¸˜ao. Portanto, com a construc¸˜ao de um metamodelo que utiliza o metamodelo da UML ´e poss´ıvel utilizar mo-delos e diagramas j´a especificados pela linguagem UML que consistem em artefatos j´a utilizados no desenvolvimento de software.
Com a obtenc¸˜ao de conhecimento sobre o formato estrutural dos artefatos e seu preenchimento, podemos entender melhor sobre o ciclo de produc¸˜ao do mesmo. As informac¸˜oes que permeiam a forma do artefato podem ser verificadas e avaliadas ite-rativamente, assim podemos utilizar versionamento tanto na definic¸˜ao quanto no uso dos artefatos. Al´em do mais, o aumento no compartilhamento de conte´udo e estrutura, base-ado no reuso, pode diminuir o tempo de elaborac¸˜ao e produc¸˜ao dos artefatos.
4. Estado Atual do Trabalho
Para a realizac¸˜ao da Autoria de Artefatos em Processos de Software foram definidas as seguintes etapas que est˜ao sendo realizadas na ordem em que se apresentam:
Etapa 1: realizac¸˜ao do levantamento bibliogr´afico sobre os processos de software, buscando, na captura e identificac¸˜ao dos artefatos, conhecer suas estruturas internas (Ex.: gr´aficos, textos, figuras, sec¸˜oes, listas), estudando UML, MOF, SPEM v2 e trabalhos relacionados. Esta etapa ´e cont´ınua e visa a verificac¸˜ao do impacto de outros trabalhos na ´area na abordagem proposta.
Etapa 2: nesta etapa foi feito: (i) um levantamento sobre tipologia de artefatos atrav´es de estudo te´orico e (ii) um aprofundamento dos estudos sobre os mecanismos de extens˜ao do metamodelo do SPEM v2. Esta etapa foi fundamental para a definic¸˜ao dos
conceitos necess´arios para a extens˜ao do metamodelo. O n´ıvel de conformidade para a extens˜ao do SPEM v2 selecionado foi o MethodContent. O ponto de extens˜ao ser´a a partir dos pacotes MethodContent e Core. Tal etapa encontra-se finalizada.
Etapa 3: realizar uma an´alise 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 informac¸˜ao diferente; (iii) propor a extens˜ao do metamodelo SPEM v2 que permita a quebra do artefato em uma estrutura mais granular. Esta etapa encontra-se em fase de finalizac¸˜ao e a maioria dos conceitos j´a foram identificados. O metamodelo foi estendido com a definic¸˜ao de trˆes tipos de pacotes:
• pacotes que estendem o n ´ucleo do SPEM v2: pacotes que possuem metaclas-ses para classificac¸˜ao, conforme [Laitinen 1992], definic¸˜ao de n´ıveis de maturi-dade, baseado em [Visconti and Cook 1993] e gerˆencia de artefatos em relac¸˜ao as modificac¸˜oes feitas durante a definic¸˜ao e uso dos mesmos;
• pacotes de modelagem de informac¸˜ao: constitu´ıdo pelo pacote InformationTy-pese seus subpacotes, onde est˜ao os tipos de informac¸˜ao que foram mapeados; • pacote para extens˜ao do MethodContent: neste pacote est´a o acr´escimo das
me-taclasses capazes de estruturar o artefato de forma l´ogica permitindo tamb´em a definic¸˜ao de organizac¸˜ao hier´arquica.
Etapa 4: a ser realizada em trˆes atividades: (i) propor a ferramenta de suporte; (ii) fazer a an´alise 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´atica do que foi desenvolvido nas etapas anteriores; (ii) realizar a revis˜ao, entrega e defesa da dissertac¸˜ao. Esta etapa ainda n˜ao foi inicializada.
5. Trabalhos Relacionados
Em [Akpotsui et al. 1992], documentos s˜ao considerados estruturas l´ogicas feitas a partir de elementos (como t´ıtulos, sec¸˜oes, par´agrafos) que, quando compostos, s˜ao capazes de representar a organizac¸˜ao dos documentos. Cada elemento possui um tipo definido pelos seus relacionamentos atrav´es da modelagem de uma estrutura gen´erica. Em tal modelo deve existir um conjunto de Tipos T constru´ıdos a partir de um Conjunto B´asico de Tipos β = {Texto, Imagem, ..., Gr´afico} e um Conjunto de Construtores C = {Grupo, Lista, ..., Identidades}, ambos extens´ıveis. Embora o escopo esteja resumido a apenas artefatos do tipo Documento, esta soluc¸˜ao permite determinar sua estrutura e organizac¸˜ao.
HotDoc [Buchner 2000] ´e um arcabouc¸o para Documentos Compostos (Com-pounding Documents) e permite a autoria de documentos flex´ıveis e dinˆamicos que con-sistem em diferentes tipos e partes. Estes documentos s˜ao capazes de possuir outros tipos de conte´udos, como tabelas, figuras, diagramas, gr´aficos, som e v´ıdeo e n˜ao apenas texto. Al´em disso, as partes podem compartilhar um mesmo modelo de dados atrav´es de ligac¸˜oes entre elas, desde que estas ligac¸˜oes sejam entre modelos compat´ıveis. Desta forma, s˜ao adicionadas funcionalidades para a autoria de documentos, permitindo que o autor combine diferentes partes de conte´udo at´e obter um documento composto. As-sim como em [Akpotsui et al. 1992], o HotDoc tamb´em possui foco em Documento. No entanto, esta abordagem acrescenta a utilizac¸˜ao de partes flex´ıveis.
O Compound Document access and Management (CDAM) ´e um Banco de Dados Orientado a Objetos que permite a gerˆencia de documentos compostos. Se-gundo [Herzner and Hocevar 1991], documentos s˜ao pedac¸os de informac¸˜oes estrutura-das com a propriedade de se auto-definir em sentenc¸as como: um artigo consiste em um t´ıtulo, um resumo, o conte´udo e bibliografia. Para os autores, documentos s˜ao colec¸˜oes de partes ou componentes, formando uma agregac¸˜ao. O Sistema CDAM cont´em node types para acesso aos documentos, fazendo com que, diferentemente do HotDoc, ele esteja mais preocupado com o gerenciamento das informac¸˜oes de um documento e n˜ao sua autoria.
Em [Visconti and Cook 1993] ´e identificado um meio de melhorar o processo e definir quatro n´ıveis de maturidade para a documentac¸˜ao do mesmo. Neste trabalho fica evidente que n˜ao basta apenas construir os artefatos, ´e necess´ario determinar seus esta-dos, para que estejam em n´ıvel apropriado de qualidade. J´a para [Laitinen 1992], muitas abordagens possuem o foco na qualidade da documentac¸˜ao e n˜ao definem como classi-fic´a-la, nem mesmo como organizar as informac¸˜oes obtidas. Desta forma, o autor sugere uma abordagem para a classificac¸˜ao de documentos, provendo identificac¸˜ao sobre o tipo de informac¸˜ao contida no documento baseado em uma nomenclatura. Diferente dos tra-balhos apresentados at´e ent˜ao, estas abordagens classificam artefatos de um Processo de Softwarequanto aos seus estados e tipos de conte´udos, respectivamente.
Assim como nestes trabalhos tamb´em consideramos a classificac¸˜ao e o n´ıvel de qualidade dos artefatos. Al´em disso, nossa proposta aplica esforc¸os explicitamente na autoria de artefatos, detalhando-a. N´os utilizamos a extens˜ao do metamodelo SPEM v2, que ´e uma linguagem Orientada a Objetos e que utiliza a UML. Outro grande diferencial ´e a adic¸˜ao de versionamento.
6. Avaliac¸˜ao dos Resultados
Haver´a a utilizac¸˜ao do metamodelo sugerido e um prot´otipo ser´a desenvolvido. Preten-demos avaliar este trabalho utilizando casos de testes em um conjunto de artefatos, de-monstrando a efetividade do modelo atrav´es do uso sobre o prot´otipo. Desta forma, os resultados ser˜ao verificados e a abordagem refinada, pois ser˜ao realizados eventuais ajus-tes e correc¸˜oes no metamodelo e no prot´otipo.
7. Considerac¸˜oes finais
Atrav´es da extens˜ao da UML, a OMG foi capaz de definir um metamodelo para a especificac¸˜ao do dom´ınio de processos de software. No tocante a construc¸˜ao de arte-fatos, os paradigmas atuais s˜ao restritos, pois n˜ao resolvem, por completo, a falta de estruturac¸˜ao e excesso de redundˆancia das informac¸˜oes. Embora alguns trabalhos te-nham sido identificados, eles n˜ao resolvem os problemas supracitados e n˜ao representam esforc¸os direcionados na autoria de artefatos, focando apenas na edic¸˜ao, classificac¸˜ao 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 Informac¸˜ao - PDTI 001/2008, financiado pela Dell Computadores do Brasil Ltda. com recursos da Lei 8.248/91.
References
Akpotsui, E., Quint, V., and Roisin, C. (1992). Type modelling for document transforma-tion 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: Proce-edings of the 14th international conference on Software engineering and knowledge engineering, pages 477–478, 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 specifi-cation. ACM Press/Addison-Wesley Publishing Co., New York, NY, USA.
Herzner, W. and Hocevar, E. (1991). Cdam–compound document access and manage-ment: 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):32–39.
Object Management Group (2003). Unified modeling language specification v1.5. http://www.omg.org/docs/formal/03-03-01.pdf.
Object Management Group (2006). Meta object facility v2.0. http://www.omg.org/docs/formal/06-01-01.pdf.
Object Management Group (2007). Software & systems process engineering metamodel specification 2.0. http://www.omg.org/cgi-bin/doc?ptc/ 2007-11-01.
Pottinger, R. A. and Bernstein, P. A. (2003). Merging models based on given correspon-dences. In vldb’2003: Proceedings of the 29th international conference on Very large data bases, pages 862–873. 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 115–123, 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 226–233, 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 352–357, New York, NY, USA. ACM Press.
