X-ARM: Um Modelo de Representação de Artefatos de Software

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

CENTRO DE CINCIAS EXATAS E DA TERRA

DEPARTAMENTO DE INFORMTICA E MATEMTICA APLICADA

PROGRAMA DE PS-GRADUAO EM SISTEMAS E COMPUTAO

Dissertao de Mestrado

X-ARM: Um Modelo de Representao de Artefatos de

Software

Michael Schuenck dos Santos

Natal RN Agosto de 2006

ii

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

CENTRO DE CINCIAS EXATAS E DA TERRA

DEPARTAMENTO DE INFORMTICA E MATEMTICA APLICADA

PROGRAMA DE PS-GRADUAO EM SISTEMAS E COMPUTAO

X-ARM: Um Modelo de Representao de Artefatos de

Software


Dissertao de Mestrado submetida ao Programa de Ps-Graduao em Sistemas e Computao do Departamento de Informtica e Matemtica Aplicada da Universidade Federal do Rio Grande do Norte como parte dos requisitos necessrios para a obteno do grau de Mestre em Sistemas e Computao (MSc.).

Orientador: Prof. Dr. Gldson Elias da Silveira

Natal RN Agosto de 2006

iii

Catalogao da Publicao na Fonte. UFRN / SISBI / Biblioteca Setorial Especializada Especializada do Centro de Cincias Exatas e da Terra CCET.

Dissertao (Mestrado) Universidade Federal do Rio Grande do Norte.

Centro de Cincias Exatas e da Terra. Departamento de Informtica e Matemtica

Aplicada. Programa de Ps-Graduao em Sistemas e Computao.

1. Software Dissertao. 2. Modelo X-ARM Dissertao. 3. Representao de

metadados Dissertao. I. Silveira, Gldson Elias da. II. Ttulo.

RN/UF/BSE-CCET CDU 004.4

Santos, Michael Schuenck dos. X-ARM : um modelo de representao de artefatos de software / Michael Schuenck dos Santos. Natal, 2006. 150 f. : il.

Orientador : Gldson Elias da Silveira.

iv

X-ARM: Um Modelo de Representao de Artefatos de Software


Esta Dissertao de Mestrado foi avaliada em 04 de agosto de 2006 e considerada aprovada

pelo Programa de Ps-Graduao em Sistemas e Computao do Departamento de

Informtica e Matemtica Aplicada da Universidade Federal do Rio Grande do Norte.

Banca Examinadora:

_________________________________________Prof. Dr. Gldson Elias da Silveira

Orientador

_________________________________________Prof. Dr. Bruno Motta de Carvalho

_________________________________________Prof. Dr. Itana Maria de Souza Gimenes

vA meus queridos pais, Gencio e Eliana.

vi

Agradecimentos

Agradeo a Deus, por me dar a vida, sade, motivao e fora no apenas para que este

trabalho pudesse ser realizado, mas tambm para que o mesmo fosse realizado com a maior

satisfao possvel, j que neste tempo, a vida e o mestrado funcionaram em paralelo, e no

sequencialmente.

Agradeo ao meu orientador, Prof. Gldson Elias da Silveira, por sua sbia

orientao, por sua exigncia pela perfeio e dedicao, que me fizeram crescer

enormemente. Tenho por ele uma grande admirao, seja por sua imensa capacidade

tcnica, quanto por sua integridade e honestidade como profissional e cidado. Agradeo

tambm Prof. Valria Gonalves Soares, por seu importante apoio desde o dia em que

me tornei um mestrando e por direcionar meus primeiros passos nesta jornada.

Agradeo aos membros do comit avaliador deste trabalho, a Prof Itana Maria de

Souza Gimenes e o Prof. Bruno Motta de Carvalho, pelo tempo e empenho, pois no s

avaliaram, mas tambm auxiliaram no enriquecimento deste trabalho com comentrios e

discusses de importante valor.

Agradeo aos companheiros do laboratrio Compose, em especial, a Joo Paulo

Freitas de Oliveira e Yuri Feitosa Negcio. Ao primeiro, por seu auxlio sempre que

precisei durante esta jornada, incluindo contribuies no tcnicas, como no dia em que

tive que ir para o hospital. Ao Yuri, pelas discusses e por suas relevantes contribuies a

este trabalho, desde os tempos em que o X-ARM ainda nem havia sido batizado.

Agradeo aos amigos de mestrado Adriana Takahashi, lvaro Nunes Prestes,

Camila de Arajo, Danilo de Abreu Noleto, Macilon Arajo Costa Neto e Raul Benites

vii

Paradeda, alm de Matheus Jancy Bezerra Datas. Agradeo-lhes pelos diversos tipos de

apoio oferecido, de contribuies tcnicas prpria convivncia diria, passando por

rodzios de pizza, para espairecer.

Expresso minha gratido aos professores Fabiano Fagundes e Parcilene Fernandes

de Brito, pelo fundamental incentivo para que eu me enveredasse por esta jornada, tanto por

seus conselhos, quanto por seus exemplos. Sem eles, eu no teria nem sequer cogitado a

possibilidade de querer me tornar um mestre. Tambm agradeo a Antonio da Luz Jnior,

Elaine Maria de Matos, Elaine da Silva Monteiro, Francisco de Assis dos Santos Jr.

(Chico), Heres Edison Valdivieso Tobar Neto, Marcus Barbosa Pinto, Nalva Neila Alves

da Silva, Pollyane de Almeida Lustosa e Renatto Pereira Mota pelo incentivo e torcida

antes e durante a realizao do meu mestrado.

No poderia deixar de agradecer a meus queridos pais, Gencio Gomes dos Santos e

Eliana Maria das Graas Schuenck dos Santos, por sempre quererem o melhor para mim e

por me apoiarem ao mudar pra to longe em busca de um ideal, mesmo que eles tenham

sofrido por isto. Agradeo aos meus irmos Tarcsio Schuenck dos Santos e Monize

Schuenck dos Santos, por me apoiarem nesta jornada, desde o momento em que tomei a

deciso de entrar no programa de mestrado, e por cuidarem de nossos pais.

Meus sinceros agradecimentos tambm ao meu primo Gladstone Miquillitto dos

Santos, cujo incentivo foi decisivo para que eu entrasse no caminho que me levaria ao ttulo

de mestre.

Por fim, mas no menos importante, agradeo querida Lisa Marie Medeiros de

Souza, por seu apoio nos meses finais de criao desta dissertao e por sua compreenso

pelo dias que deixei de ficar com ela para me dedicar a este trabalho.

viii

Resumo

O Desenvolvimento Baseado em Componentes tem como grande desafio a criao de

mecanismos que facilitem a identificao de assets reusveis que satisfaam os requisitos

de sistemas particulares sob desenvolvimento. Neste sentido, repositrios de componentes

tm sido propostos como meios para se atender esta necessidade. Porm, repositrios

precisam representar as caractersticas de assets que possam ser levadas em considerao

pelos consumidores quando da escolha dos assets mais adequados s suas necessidades.

Neste contexto, a literatura apresenta alguns modelos que foram propostos com a finalidade

de descrever as caractersticas de assets, tais como identificao, classificao, requisitos

no funcionais, informaes de implantao e uso, arquivos que compem os assets, e

interfaces de componentes. No entanto, o conjunto de caractersticas representadas por

estes modelos insuficiente para descrever diversas informaes usadas antes, durante e

depois da aquisio dos assets, dentre as quais pode-se destacar informaes de negociao

e certificao, histrico de mudanas, processo de desenvolvimento usado, eventos,

excees. De forma a solucionar tais deficincias, este trabalho apresenta um modelo

baseado em XML para a representao de diversas caractersticas, de diversos tipos de

assets, que possam ser empregadas no desenvolvimento baseado em componentes. O

modelo proposto, denominado X-ARM, fornece informaes usadas no apenas pelos

consumidores na identificao, aquisio e uso de assets, mas tambm para apoiar as

atividades dos desenvolvedores de assets. Dado que o modelo proposto representa uma

expressiva quantidade de informaes, este trabalho tambm apresenta uma ferramenta

chamada X-Packager, desenvolvida com o objetivo de auxiliar a descrio de assets com

X-ARM.

ix

Abstract

A great challenge of the Component Based Development is the creation of mechanisms to

facilitate the finding of reusable assets that fulfill the requirements of a particular system

under development. In this sense, some component repositories have been proposed in

order to answer such a need. However, repositories need to represent the asset

characteristics that can be taken into account by the consumers when choosing the more

adequate assets for their needs. In such a context, the literature presents some models

proposed to describe the asset characteristics, such as identification, classification, non-

functional requirements, usage and deployment information and component interfaces.

Nevertheless, the set of characteristics represented by those models is insufficient to

describe information used before, during and after the asset acquisition. This information

refers to negotiation, certification, change history, adopted development process, events,

exceptions and so on. In order to overcome this gap, this work proposes an XML-based

model to represent several characteristics, of different asset types, that may be employed in

the component-based development. Besides representing metadata used by consumers,

useful for asset discovering, acquisition and usage, this model, called X-ARM, also focus

on helping asset developers activities. Since the proposed model represents an expressive

amount of information, this work also presents a tool called X-Packager, developed with

the goal of helping asset description with X-ARM.

xGlossrio

CCM CORBA Component Model

CDML - Component Description Markup Language

CIDL - CORBA Interface Description Language

COM Component Object Model

DBC Desenvolvimento Baseado em Componentes

DOM - Document Object Model

EJB Enterprise JavaBeans

GPL GNU General Public License

MPL Mozilla Public License

OCL - Object Constraint Language

OMG Object Management Group

QML - Quality-of-Service Modeling Language

RAS Reusable Asset Specification

SWT - Standard Widget Toolkit

URL - Uniform Resource Locator

X-ARM XML-based Asset Representation Model

X-Packager X-ARM Packager

XML Extensible Markup Language

xi

Sumrio

Resumo ...............................................................................................................................viiiAbstract ................................................................................................................................ ixGlossrio................................................................................................................................ xSumrio ................................................................................................................................xiLista de Figuras .................................................................................................................xiiiLista de Tabelas .................................................................................................................xvi1 Introduo ..................................................................................................................... 1

1.1 MOTIVAO ............................................................................................................ 3 1.2 OBJETIVOS............................................................................................................... 4 1.3 ORGANIZAO DO TRABALHO................................................................................. 5

2 Trabalhos Relacionados............................................................................................... 62.1 RAS ........................................................................................................................ 6

2.1.1 Core RAS e Default Profile ............................................................................ 82.1.2 Default Component Profile............................................................................. 92.1.3 Default Web Service Profile ......................................................................... 10

2.2 OSD ...................................................................................................................... 11 2.3 CDML................................................................................................................... 11 2.4 MODELO PROPOSTO POR REDOLFI ET AL................................................................ 12 2.5 CONSIDERAES FINAIS ........................................................................................ 13

3 X-ARM ........................................................................................................................ 173.1 ASSETS EM X-ARM .............................................................................................. 17

3.1.1 Especificao e Implementao de Componentes........................................ 183.1.2 Interfaces, Eventos e Excees..................................................................... 193.1.3 Artefatos ....................................................................................................... 213.1.4 Modelos ........................................................................................................ 223.1.5 Empacotamento de assets............................................................................. 233.1.6 Identificao nica ....................................................................................... 23

3.2 HIERARQUIA DE PROFILES ..................................................................................... 24 3.3 X-ARM ARTIFACT PROFILE.................................................................................. 25

3.3.1 Artefatos do Processo de Desenvolvimento.................................................. 283.3.2 Rastreabilidade do Processo de Desenvolvimento....................................... 303.3.3 Classificao Baseada em reas de Aplicao............................................ 33

xii

3.3.4 Controle de Visibilidade............................................................................... 353.3.5 Histrico da Evoluo do Asset ................................................................... 373.3.6 Certificao .................................................................................................. 383.3.7 Informaes de Negociao ......................................................................... 42

3.4 X-ARM MODEL PROFILE ...................................................................................... 46 3.4.1 Processos de Desenvolvimento..................................................................... 483.4.2 Classificao Baseada em reas de Aplicao............................................ 523.4.3 Modelo de Certificao ................................................................................ 533.4.4 Modelos de Negcio ..................................................................................... 553.4.5 Modelos de Componentes............................................................................. 57

3.5 X-ARM INTERACTION PROFILE ............................................................................ 61 3.5.1 Interfaces ...................................................................................................... 643.5.2 Eventos ......................................................................................................... 683.5.3 Excees ....................................................................................................... 73

3.6 X-ARM COMPONENT PROFILE.............................................................................. 75 3.6.1 Especificaes de Componentes................................................................... 803.6.2 Implementaes de componentes.................................................................. 86

3.7 CONSIDERAES FINAIS ........................................................................................ 90 4 Ferramenta de Descrio e Empacotamento de Assets........................................... 93

4.1 A FERRAMENTA X-PACKAGER .............................................................................. 94 4.1.1 Utilizao do X-Packager ............................................................................ 95

4.2 UM EXEMPLO DE USO ........................................................................................... 97 4.2.1 Modelos ........................................................................................................ 994.2.2 Workflow Requirements.............................................................................. 1004.2.3 Workflow Specification............................................................................... 1004.2.4 Workflow Provisioning............................................................................... 105

4.3 DESCRIO DOS ASSETS USANDO X-PACKAGER ................................................. 107 4.3.1 X-ARM Model Profile................................................................................. 1084.3.2 X-ARM Artifact Profile............................................................................... 1194.3.3 X-ARM Interaction Profile ......................................................................... 1274.3.4 X-ARM Component Profile......................................................................... 134

4.4 CONSIDERAES FINAIS ...................................................................................... 139 5 Consideraes Finais ................................................................................................ 141

5.1 CONTRIBUIES .................................................................................................. 142 5.2 LIMITAES E PERPECTIVAS................................................................................ 144

6 Referncias ................................................................................................................ 146

xiii

Lista de Figuras

Figura 1: Hierarquia de profiles do RAS................................................................................ 7 Figura 2: Principais elementos definidos pelo Core RAS. ..................................................... 8 Figura 3: Principais elementos do Default Component Profile.............................................. 9 Figura 4: Categorias e tipos de assets do X-ARM. .............................................................. 18 Figura 5: Hierarquia de nomes no X-ARM.......................................................................... 23 Figura 6: Hierarquia de profiles do X-ARM. ....................................................................... 25 Figura 7: X-ARM Artifact Profile. ....................................................................................... 26 Figura 8: Representao de processo de desenvolvimento adotado..................................... 29 Figura 9: Exemplo de representao do processo de desenvolvimento adotado.................. 29 Figura 10: Representao de assets reusados. ...................................................................... 30 Figura 11: Abordagens de rastreabilidade de assets. ............................................................ 32 Figura 12: Classificao baseada em reas de aplicao...................................................... 34 Figura 13: Exemplo de classificao baseada em reas de aplicao. ................................. 35 Figura 14: Representao do controle de visibilidade.......................................................... 36 Figura 15: Exemplo de controle de visibilidade................................................................... 37 Figura 16: Representao do histrico de evoluo. ............................................................ 38 Figura 17: Exemplo de histrico de evoluo. ..................................................................... 38 Figura 18: Representao de certificao............................................................................. 39 Figura 19: Exemplo de certificao...................................................................................... 42 Figura 20: Representao de informaes de negociao. ................................................... 43 Figura 21: Exemplo de informaes de negociao............................................................. 45 Figura 22: Ilustrao da utilizao de modelos. ................................................................... 47 Figura 23: X-ARM Model Profile. ........................................................................................ 48 Figura 24: Especificao de processos de desenvolvimento. ............................................... 49 Figura 25: Exemplo de especificao do processo UML Components. ............................... 50 Figura 26: Exemplo de relacionamentos entre assets gerados em um processo. ................. 51 Figura 27: Especificao de reas de aplicao.................................................................... 52 Figura 28: Exemplo de especificao de reas de aplicao. ............................................... 53 Figura 29: Especificao de modelos de certificao........................................................... 53 Figura 30: Exemplo de especificao de modelo de certificao......................................... 55 Figura 31: Especificao de modelos de negcios. .............................................................. 56

xiv

Figura 32: Exemplo de especificao de modelo de negcio............................................... 57 Figura 33: Especificao de modelos de componentes. ....................................................... 58 Figura 34: Especificao do CCM com X-ARM Model Profile. .......................................... 60 Figura 35: X-ARM Interaction Profile.................................................................................. 62 Figura 36: Elementos para representao de evoluo......................................................... 62 Figura 37: Especificao de interfaces independentes de modelo. ...................................... 64 Figura 38: Exemplo de especificao de interface independente de modelo. ...................... 66 Figura 39: Especificao de interfaces dependentes de modelo........................................... 67 Figura 40: Notificao atravs de eventos............................................................................ 68 Figura 41: Especificao de eventos independentes de modelo........................................... 69 Figura 42: Exemplo de especificao de evento independente de modelo. ......................... 71 Figura 43: Elementos para especificao de eventos dependentes de modelo..................... 72 Figura 44: Especificao de excees independentes de modelo......................................... 73 Figura 45: Especificao de excees dependentes de modelo............................................ 75 Figura 46: X-ARM Component Profile. ................................................................................ 77 Figura 47: Controle de evoluo no X-ARM Component Profile. ........................................ 78 Figura 48: Especificao de componentes independentes de modelo.................................. 80 Figura 49: Exemplo de interfaces em uma especificao de componente independente..... 81 Figura 50: Exemplo de eventos em uma especificao de componente independente. ....... 82 Figura 51: Exemplo de propriedade de componente independente...................................... 82 Figura 52: Especificao de componentes dependentes de modelo. .................................... 84 Figura 53: Exemplo de especificao de componente dependente. ..................................... 86 Figura 54: Especificao de implementaes de componentes............................................ 87 Figura 55: Seqncia de status de uma implementao de componente.............................. 88 Figura 56: Exemplo de requisitos no funcionais. ............................................................... 90 Figura 57: Tela do Eclipse para escolha da forma de exportao. ....................................... 95 Figura 58: Tela para especificao dos arquivos que compem o asset. ............................. 97 Figura 59: Modelo conceitual de negcios para o sistema de reservas. ............................... 98 Figura 60: Arquitetura da especificao de componentes. ................................................. 102 Figura 61: Telas para especificao de processos de desenvolvimento. ............................ 109 Figura 62: Especificao do processo UML Components gerada pelo X-Packager.......... 110 Figura 63: Telas para especificao de reas de aplicao................................................. 111 Figura 64: Especificao de reas de aplicao gerada pelo X-Packager. ......................... 112 Figura 65: Telas para especificao de modelos de certificao........................................ 113 Figura 66: Especificao de modelo de certificao gerada pelo X-Packager................... 114 Figura 67: Telas para especificao de modelos de negcios. ........................................... 115 Figura 68: Especificao de modelo de negcios gerada pelo X-Packager. ...................... 116 Figura 69: Telas para especificao de modelos de componentes. .................................... 117 Figura 70: Especificao do modelo JavaBeans gerada pelo X-Packager. ........................ 118 Figura 71: Especificao do modelo EJB gerada pelo X-Packager. .................................. 118 Figura 72: Especificao do modelo .NET gerada pelo X-Packager. ................................ 119 Figura 73: Especificao da identificao do asset. ........................................................... 120 Figura 74: Especificao do arquivo que compe o asset. ................................................. 120 Figura 75: Especificao da classificao. ......................................................................... 121 Figura 76: Especificao de informaes sobre o processo adotado.................................. 121 Figura 77: Especificao dos assets reusados..................................................................... 122 Figura 78: Especificao da visibilidade. ........................................................................... 122

xv

Figura 79: Especificao da evoluo para um asset baseado em outra verso. ................ 123 Figura 80: Telas para especificao da certificao do asset. ............................................ 124 Figura 81: Indicao da certificao do produtor do asset. ................................................ 125 Figura 82: Especificao da certificao do asset. ............................................................. 125 Figura 83: Especificao das informaes de negociao.................................................. 126 Figura 84: A interface IMakeReservation. ......................................................................... 127 Figura 85: Telas para especificao de interfaces. ............................................................. 128 Figura 86: Especificao em X-ARM da interface IMakeReservation.............................. 129 Figura 87: Ilustrao do evento criado. .............................................................................. 130 Figura 88: Telas para especificao de eventos.................................................................. 131 Figura 89: Especificao em X-ARM do evento ReservationCreatedEvent...................... 132 Figura 90: Telas para especificao de excees. .............................................................. 133 Figura 91: Especificao em X-ARM da exceo InvalidReservationDetails................... 134 Figura 92: Telas para especificao das interfaces do componente. .................................. 136 Figura 93: Especificao em X-ARM do componente ReservationSystem. ...................... 137 Figura 94: Especificao em X-ARM do componente ReservationSystem. ...................... 138

xvi

Lista de Tabelas

Tabela 1: Comparao dos modelos de representao de artefatos de software. ................. 14 Tabela 2: Quantidades de formulrios por tipo de asset....................................................... 94 Tabela 3: Assets do X-ARM Model Profile criados no exemplo de uso. ............................ 99 Tabela 4: Assets gerados no workflow Requirements........................................................ 100 Tabela 5: Assets gerados no estgio Component Identification......................................... 101 Tabela 6: Assets gerados no estgio Component Interaction. ............................................ 103 Tabela 7: Assets gerados no estgio Component Specification. ........................................ 104 Tabela 8: Assets gerados no workflow Provisioning. ........................................................ 106

Introduo 1

1 Introduo

Assim como qualquer outra atividade, o desenvolvimento de software possui necessidades

relativas ao lanamento de produtos com maior qualidade, com menor custo e com mxima

rapidez. Uma das principais formas que podem ser encontradas na literatura e que foram

utilizadas no sentido de atender estes objetivos o reuso de software [McIlroy69]. Diversas

abordagens para viabilizar reuso tm sido propostas e utilizadas pela indstria ao longo dos

anos. Essas abordagens variam desde a utilizao de funes, em programas estruturados,

at o emprego de componentes de software, passando por reuso de projeto e a prpria

orientao a objetos [Frakes05].

Na construo de aplicaes a partir de componentes de software, tornou-se popular

o termo Desenvolvimento Baseado em Componentes (DBC). Neste sentido, diversas

definies de componentes foram propostas. Heineman e Council [Heineman01]

apresentam a seguinte definio: Um componente de software um elemento de software

que adere a um modelo de componente e pode ser independentemente implantado e

composto sem modificao de acordo com um padro de composio. J Sametinger

[Sametinger97] define um componente da seguinte forma: Componentes de software

reusveis so auto-contidos, artefatos claramente identificveis que descrevem e/ou

realizam funes especficas e tm interfaces claras, documentao apropriada e um status

de reuso definido. Nesta definio, o fato de ser auto-contido implica que para um

componente ser utilizado, no deve ser necessria a implantao de outros componentes. J

o status de reuso de um componente inclui informaes sobre seu proprietrio, quem o

mantm e quem pode ser contactado em caso de problemas, alm de informaes sobre a

qualidade do componente. Uma definio que tem tido boa aceitao a proposta por

Szyperski [Szyperski02], que diz: Um componente de software uma unidade de

Introduo 2

composio com interfaces contratualmente especificadas e dependncias de contexto

explcitas. Um componente de software pode ser implantado independentemente e sujeito

a composio por terceiros.

Em uma companhia ou projeto, o DBC possibilita uma diviso clara das atividades

dos desevolvedores, uma vez que componentes podem ser desenvolvidos de forma

independente por diferentes pessoas, possivelmente trabalhando em paralelo

[Sametinger97]. Outra vantagem desta abordagem no ter que empregar tempo em uma

soluo que realize as tarefas de componentes j desenvolvidos em outros contextos,

quando do desenvolvimento de uma nova aplicao. Por outro lado, torna-se necessrio que

os componentes utilizados em uma aplicao sejam confiveis, o que pode ser conseguido

com a certificao de componentes, processo que definido como o conjunto de

procedimentos regulamentados e padronizados que resultam na expedio de certificado ou

declarao de conformidade especfica para produtos ou servios de uma determinada rea

de atuao [ISO05].

Componentes de software so construdos seguindo-se um modelo de componentes,

conforme indicado em [Heineman01]. Um modelo de componentes define padres para

interoperabilidade, interfaces, nomeao, metadados, customizao, composio, evoluo

e instalao [Heineman01]. A indstria de software tem desenvolvido diversos modelos de

componentes, dentre os quais, vrios so vastamente utilizados na construo de aplicaes

de diversos tamanhos e nveis de complexidade. Alguns dos principais modelos de

componentes so CCM [CCM06], COM [Brooke01], EJB [Pharoah01a] e .NET

[Brooke01].

Os componentes provem interfaces para serem acessadas pelas unidades de

software que os utilizam. Uma interface representa um subconjunto das interaes que um

componente pode manter com outras entidades de software [Heineman01]. Normalmente

ela expressa como um conjunto de operaes que so providas por um componente ou

que so requeridas, no caso de um componente necessitar de operaes implementadas por

outro componente. Geralmente, interfaces so representadas em arquivos de descrio de

interfaces, que so dependentes do modelo de componentes, tais como CIDL e arquivos de

interfaces de Java. Uma mesma interface pode ser implementada por diversos

componentes.

Introduo 3

Na utilizao de componentes para o desenvolvimento de aplicaes, tem-se duas

facetas: o desenvolvimento para reuso e o desenvolvimento com reuso [Ribot94]. A

primeira realizada pelo produtor de componentes e refere-se atividade de desenvolver

componentes com a finalidade de distribu-los, de forma gratuita ou paga. J o

desenvolvimento com reuso realizado pelo consumidor e consiste em construir aplicaes

ou novos componentes utilizando componentes previamente desenvolvidos. Neste caso,

pode-se notar que a criao de componentes tambm pode ser considerada

desenvolvimento para reuso.

O desenvolvimento com reuso possui como fator limitante, a identificao dos

componentes que satisfazem os requisitos de aplicaes particulares sob desenvolvimento.

Desta forma, tem sido cada vez mais evidente a necessidade de desenvolvimento e

popularizao de repositrios de componentes. Algumas iniciativas abertas e proprietrias

foram propostas pela indstria e pela academia, tais como Component Source

[CompSource05], SPARS-J [Inoue03], OSCAR [Nutter03] e Agora [Seacord98].

Repositrios podem ser construdos levando-se em considerao caractersticas variadas,

como por exemplo, tipos de componentes suportados, controle de verses, tipo de interface

de busca e recuperao, suporte a certificao de componentes, modelos de negcios,

suporte a processos de desenvolvimento, mecanismos de classificao [Schuenck05].

Da mesma forma, a existncia de repositrios de componentes pode beneficiar o

desenvolvimento para reuso. Isto pode ser dito pelo fato de que, considerando componentes

como produtos comercializveis, um repositrio constitui um mercado onde consumidores

podem adquirir os componentes que desejarem, possivelmente com pagamento. Desta

forma, este mecanismo propicia a viabilizao da atividade de produo de componentes

como atividade comercial.

1.1 Motivao

De acordo com [Orso00] e [RAS05], um repositrio deve armazenar no somente

componentes de software, mas tambm metadados que os descrevam. Tais metadados

precisam ser representados em uma linguagem no ambgua e tm o objetivo de descrever o

que o componente , quais interfaces ele prov, as interfaces que ele requer, os eventos que

ele dispara e recebe, quais outros componentes o compem, a quais certificaes ele foi

Introduo 4

submetido e por quais entidades certificadoras, e quem pode recuper-lo, alm do preo e

das formas de pagamento possveis. Uma vez disponveis em um repositrio, metadados

podem ser utilizados na indexao e classificao de componentes, tornando possvel a

descoberta dos componentes adequados s necessidades dos consumidores.

Alm de componentes de software, repositrios tambm podem armazenar e manter

metadados de interfaces e dos demais artefatos que possam ser gerados no processo de

desenvolvimento de componentes para reuso ou utilizados no desenvolvimento de software

com reuso. Exemplos desses artefatos so especificaes de interfaces, documentao de

uso, casos de uso, diagramas de classes, planos de testes, cdigo fonte, dentre outros. No

contexto deste trabalho, seguindo a nomenclatura adotada em [RAS05], os diversos tipos de

artefatos mantidos em um repositrio so denominados genericamente assets.

Por outro lado, diversos processos de desenvolvimento baseados em componentes

foram propostos e tm sido utilizados na construo de componentes. Exemplos so UML

Components [Cheesman01], KobrA [Atkinson02] e Catalysis [DSouza99]. A utilizao de

um processo de DBC facilita o uso de componentes por meio da padronizao de

procedimentos que guiam o produtor desde a concepo das funcionalidades de um sistema

at ele estar pronto para ser utilizado, passando pela criao e reuso de componentes. Por

outro lado, o desenvolvimento com um processo gera um conjunto de artefatos previstos,

que auxiliam os consumidores na utilizao dos componentes, tornando possvel o correto

entendimento de suas funcionalidades.

Apesar da necessidade de repositrios representarem metadados de assets, poucos

deles tornaram pblicos seus modelos de representao, que se referem notao e s

informaes que so utilizadas na representao dos metadados dos artefatos que eles

mantm. Alm disto, informaes como modelos de negcios, certificao, informaes

sobre o processo de desenvolvimento, controle de acesso e composio por outros

componentes so aspectos pouco cobertos pelos modelos de metadados existentes na

literatura, principalmente se considerada a cobertura de todos eles simultaneamente.

1.2 Objetivos

Dada a escassez de abordagens para representao de metadados de assets, este trabalho

prope um modelo denominado X-ARM, acrnimo para XML-based Asset Representation

Introduo 5

Model. Conforme explcito no prprio nome, este modelo utiliza XML como meio de

representao e organizao dos dados. Este modelo foi primeiramente apresentado em

[Elias06a], como um modelo independente. Entretanto, uma nova verso do X-ARM foi

construda [Schuenck06] de forma a ser uma extenso do RAS [RAS05], visto que esta

especificao define as caractersticas bsicas aos objetivos do X-ARM. RAS um modelo

extensvel criado pela OMG para descrever assets, mas, apesar do prprio RAS definir uma

extenso para representao de componentes, ele apresenta deficincias relativas a reuso de

interfaces e eventos por mais de um componente, controle de acesso, suporte a certificao,

dentre outros, que sero vistos com mais detalhes na Seo 2.1.

O X-ARM tem como objetivo representar os tipos de assets cuja descrio se faz

necessria em um repositrio de componentes. Neste caso, incluem-se descries de

componentes, de interfaces, de eventos, de artefatos gerados ao longo da construo de um

componente e dos demais arquivos de suporte ao funcionamento do repositrio, tais como

os prprios esquemas do X-ARM.

Alm disto, o X-ARM tambm tem como objetivo apoiar o desenvolvimento de

componentes criados com quaisquer processos. Para que isto seja possvel, utilizada uma

abordagem em que cada processo descrito por um documento XML, no qual possvel a

representao das etapas com seus respectivos artefatos. A partir disto, torna-se possvel o

estabelecimento de correlaes dos artefatos gerados com os tipos previstos na descrio do

processo empregado.

Alm de especificar o modelo X-ARM, este trabalho tambm tem o objetivo de

apresentar a ferramenta X-Packager, criada como um plug-in para o ambiente Eclipse

[Eclipse06] com o objetivo de facilitar a descrio e o empacotamento de assets de acordo

com o modelo X-ARM.

1.3 Organizao do trabalho

O restante deste trabalho est organizado da seguinte forma: no Captulo 2 so discutidas

algumas abordagens correlacionadas; o Captulo 3 apresenta o modelo X-ARM; o Captulo

4 apresenta a ferramenta X-Packager e um exemplo de uso envolvendo o empacotamento

de assets; por fim, o Captulo 5 trata das consideraes finais.

Trabalhos Relacionados 6

2 Trabalhos Relacionados

Idealmente, os metadados dos assets mantidos em um repositrio devem seguir sintaxes

bem definidas, possibilitando que ferramentas construdas para lidar com os assets

consigam interpretar as informaes que os descrevem de forma previsvel e adequada. No

entanto, poucos modelos de representao foram definidos com o propsito de descrever

diferentes tipos de unidades de software, incluindo diversos artefatos utilizados no DBC.

Alm disso, as propostas existentes apresentam algumas deficincias. Assim, as prximas

sees apresentam alguns destes modelos, que constituem trabalhos relacionados ao

modelo proposto neste trabalho.

Neste captulo so apresentados modelos baseados em XML. Para facilitar a

compreenso, exemplos destes modelos so apresentados com apoio de notao UML. As

classes UML representam elementos XML e os atributos das classes representam atributos

XML. A opcionalidade de atributos e as quantidades de ocorrncias de elementos so

expressas com esteretipos e cardinalidades, respectivamente. A representao de

elementos filhos de outros elementos feita utilizando-se uma notao onde classes so

compostas por outras.

2.1 RAS

O RAS [RAS05] uma proposta da OMG cujo objetivo definir um padro de

empacotamento e descrio de assets. Neste contexto, o termo asset define um

agrupamento de artefatos gerados em um ciclo de desenvolvimento de software com

objetivo de atender um determinado problema ou grupo de problemas. Exemplos desses

artefatos so modelos, requisitos, arquivos de cdigo fonte, descritores de instalao, casos

de teste, scripts, dentre outros.


RAS define formas de organizao dos arquivos que compem um asset, nas quais

as metainformaes de descrio ficam armazenadas em um arquivo nomeado

manifest.rmd, conhecido como manifesto, que descreve em XML os artefatos relacionados

e as caractersticas do asset. So identificados trs cenrios diferentes de organizao dos

arquivos: um no qual todos os arquivos do asset so empacotados em um nico arquivo

com o algoritmo de compresso ZIP [Moffat97]; um cenrio em que os arquivos dos

artefatos que compem um asset so dispostos em suas localizaes originais e o arquivo

manifest.rmd rene as informaes do asset como um todo e referencia todos os arquivos

que compem o asset em questo; e, por fim, o cenrio em que para comporem o asset, os

arquivos precisam de alguma adaptao, sendo copiados para localizaes diferentes de

onde esto os arquivos originais, com o manifesto referenciando as cpias [RAS05].

Os manifestos podem representar diferentes caractersticas com seus elementos

XML, dependendo do tipo de asset que ele descreve. As caractersticas consideradas como

bsicas a todos os tipos de assets so descritas por uma categoria do RAS chamada Core

RAS. Por outro lado, para a representao de caractersticas particulares dos diferentes tipos

de assets, RAS utiliza uma organizao baseada em profiles, que consistem de extenses

das caractersticas do Core RAS e que podem ser estendidos recursivamente a fim de

permitir a representao de tipos de assets mais especializados. Cada profile definido com

esquemas XML. RAS define trs profiles principais: o Default Profile, que na prtica uma

realizao do Core RAS , representando o grupo principal de caractersticas de assets; o

Default Component Profile, que uma extenso do Default Profile e adiciona elementos

XML relacionados representao de componentes; e o Default Web Service Profile, que

tambm uma extenso do Default Profile, adicionando caractersticas relacionadas a Web

services. A hierarquia dos profiles definidos pelo RAS ilustrada na Figura 1.

Figura 1: Hierarquia de profiles do RAS.


Visto que o X-ARM uma extenso do RAS, detalhes de cada um destes profiles

so apresentados nas prximas subsees. Como o Default Profile uma realizao do

Core RAS, no adicionando novos elementos, ambos so apresentados na mesma subseo.

2.1.1 Core RAS e Default Profile

Alm de dados de identificao, RAS considera cinco tipos de informaes como sendo

essenciais para a descrio de quaisquer tipos de assets, que so representadas no Core

RAS. A organizao dos principais elementos definidos pelo Core RAS, usados para a

representao destas informaes ilustrada na Figura 2.

Figura 2: Principais elementos definidos pelo Core RAS.

O elemento representa metadados que possibilitem descrever os

assets de forma que estes possam ser encontrados dentro de um conjunto de assets. A fim

de representar os arquivos que compem o asset, empregado o elemento . O

terceiro tipo de informao utilizado para auxiliar nos procedimentos para instalao,

customizao e uso dos assets e representado pelo elemento . definido tambm

o elemento , usado para descrever os relacionamentos entre assets. Por fim,

informaes sobre o tipo de asset descrito so representadas com o elemento .

Alm destes, definido o elemento asset, que o elemento raiz nos documentos XML de

descrio dos assets. Para representar todas as suas informaes, cada um destes elementos

possui atributos e elementos filhos. Mais detalhes podem ser encontrados na especificao

do RAS [RAS05].

Em um manifesto, pode ser indicado o arquivo que contm o esquema XML

empregado. Isto feito no prprio elemento raiz, , com o atributo

xsi:schemaLocation, que comumente utilizado em documentos XML para indicar os

esquemas XML que os validam [Benz03]. Considerando a utilizao de um repositrio


distribudo, esta caracterstica constitui um ponto fraco do RAS, visto que com isto, no se

consegue transparncia de localizao do esquema XML adotado.

2.1.2 Default Component Profile

O Default Component Profile uma extenso do Default Profile que adiciona elementos a

fim de permitir a representao de componentes. Ele considera vrios conceitos e princpios

definidos pelo processo UML Components [Cheesman01]. Neste sentido, para permitir a

representao dos diferentes tipos de artefatos que compem um componente, so definidos

quatro elementos principais [RAS05]: , usado para indicar os artefatos

gerados na fase destinada ao levantamento de requisitos; , que descreve os

arquivos gerados durante o projeto do componente; , que indica os

arquivos que contm a implementao do componente; e , empregado para

representar artefatos relevantes a testes sobre o componente. A organizao destes

elementos apresentada na Figura 3, onde a maioria dos elementos definidos pelo Core

RAS esto implcitos, com exceo de e , alm de , que um

elemento filho de , definido pelo Core RAS.

Figura 3: Principais elementos do Default Component Profile.

Da mesma forma como apresentado no caso do Core RAS, cada um destes

elementos possui atributos e outros elementos como filhos. Nota-se que, apesar de

considerar o processo UML Components, no existe um mapeamento direto entre as fases

deste processo e os elementos definidos no Default Component Profile. Alm disso, o

elemento permite representar artefatos que no se encaixem em quaisquer dos


quatro elementos introduzidos neste profile, o que proporciona certa flexibilidade na

organizao dos artefatos. Porm, esta flexibilidade limitada, j que componentes

construdos em processos que envolvam um nmero maior de fases podem ter artefatos de

diferentes fases misturados em diversos elementos .

Alm disto, possvel destacar outras trs desvantagens deste profile. A primeira

reside justamente no fato do Default Component Profile considerar aspectos particulares de

UML Components, tal como a especificao de um modelo de informao, que pode no se

aplicar descrio de componentes desenvolvidos com outros processos. Outra

desvantagem refere-se ao fato deste profile representar em um s documento XML, o

componente e suas partes, no oferecendo suporte reusabilidade de descries. Por

exemplo, na prtica, interfaces so bastante reusadas entre diferentes componentes, mas

com o Default Component Profile no possvel o reuso da descrio de uma interface.

Finalmente, este profile no possibilita a descrio de outras caractersticas de

componentes, tais como eventos, propriedades, requisitos no funcionais, composio por

outros componentes, certificao e modelos de negcios.

2.1.3 Default Web Service Profile

RAS prov meios para a descrio das funcionalidades de Web Services do ponto de vista

de seus clientes [RAS05]. Assim, o objetivo do Default Web Service Profile representar

apenas os artefatos gerados ao longo do desenvolvimento de um Web Service alm de

referenciar um arquivo WSDL [W3C04a].

Em geral, a organizao do profile para Web Services do RAS segue a mesma

estrutura do profile para descrio de componentes, diferindo-se basicamente sobre como

descrevem as interfaces. No Default Component Profile, as interfaces de um componente

so especificadas dentro do elemento , onde so detalhadas em termos de

operaes e modelo de informao. Por outro lado, o Default Web Service Profile,

simplesmente prov um elemento para indicar sees dentro de um arquivo WSDL que

descrevem as interfaces providas de um Web Service [RAS05]. Porm, esta indicao

feita usando-se atributo textual, no existindo uma padronizao sobre como referenciar

estas sees.


Outra diferena em relao ao Default Component Profile que a descrio de Web

services com RAS inclui um elemento, filho do elemento , para

referenciar a URL que contm o documento WSDL.

2.2 OSD

OSD (Open Software Description) um vocabulrio XML que tem o objetivo de descrever

pacotes de software e seus relacionamentos com outros pacotes. Em OSD, possvel

expressar diversas caractersticas de softwares tais como versionamento, estrutura interna

dos pacotes e dependncias existentes [Hoff97].

O propsito de OSD oferecer suporte para ambientes de distribuio automatizada

de software. Neste sentido, uma ferramenta responsvel por ler e interpretar um arquivo

OSD e recuperar as informaes necessrias para fazer o download e instalar ou atualizar o

respectivo pacote de software, levando em considerao suas dependncias.

importante destacar que, embora o foco de OSD seja a descrio da distribuio

de softwares em geral, ele trata vrias caractersticas relacionadas s tecnologias de

componentes. Por exemplo, OSD cobre a representao de caractersticas como nomeao,

versionamento, dependncias e requisitos no funcionais [Hoff97]. Entretanto, devido ao

objetivo de OSD ser basicamente a descrio de software pronto para execuo por

usurios finais [Hoff97], diversas particularidades de componentes no so tratadas. Por

exemplo, OSD no especifica interfaces, informaes de modelos de negcios, certificao,

visibilidade e eventos.

2.3 CDML

A CDML [Varadarajan01] o meio de descrio de componentes empregado pelo

ComponentXchange [Varadarajan01], que um sistema projetado para intermediar a

interao entre consumidores e produtores de componentes. Descries de componentes em

CDML representam quatro tipos de informaes, denominadas pelo autor como aspectos:

sintticos, funcionais, no-funcionais, e de licena e comercializao. Os primeiros

descrevem as interfaces providas, requeridas e eventos. Os aspectos funcionais so

descritos na forma de chave/valor e os aspectos no-funcionais so descritos em uma

abordagem semelhante adotada por QML [Frolund98], em que as informaes so

descritas em termos de nomes, valores e os tipos de relacionamentos entre estes dois. Por


fim, para os aspectos de licena e comercializao, a CDML d suporte apenas a licenas

do tipo pay-per-use.

Apesar de ser adequado aos requisitos do sistema ComponentXchange, a CDML

apresenta diversas desvantagens em relao ao X-ARM. Por exemplo, CDML descreve

interfaces e eventos, porm, uma mesma descrio de um destes itens no pode ser reusada

por mais de um componente, o que possvel em X-ARM. Diversas outras informaes

representadas por X-ARM no so descritas pela CDML, tais como informaes sobre

classificao, propriedades, certificao dos componentes, processo de desenvolvimento

adotado na construo dos componentes, histrico de mudanas, arquivos que compem os

componentes. Alm disto, mesmo no caso de licenas do tipo pay-per-use, informaes

importantes como forma de pagamento e tempo de suporte no so descritas por CDML.

2.4 Modelo proposto por Redolfi et al.

Em [Redolfi05] proposto um modelo para descrio de componentes sem um nome

especfico. Apesar de tambm poder ser empregado para auxiliar as buscas por

componentes, seu principal propsito facilitar a utilizao de componentes pelos

desenvolvedores que os adquirirem. Outro objetivo deste modelo ser usado para guiar a

definio de um repositrio capaz de armazenar, catalogar, buscar e recuperar

componentes. O modelo no define uma notao especfica a ser usada para representao

das informaes, tal como XML, adotada pelos demais modelos apresentados neste

captulo.

Assim como o X-ARM, o modelo apresentado em [Redolfi05] descreve no apenas

componentes, mas tambm qualquer artefato gerado durante o processo de

desenvolvimento. Estes artefatos compem a especificao do componente, que, da mesma

forma adotada no X-ARM, separada da implementao do componente. A especificao

de um componente descrita apenas com diagramas e artefatos textuais, no sendo

definidos mecanismos padronizados para sua representao. Alm disto, os artefatos da

especificao de um componente podem referenciar outros artefatos. Por exemplo, um

diagrama de classes pode referenciar um modelo de casos de uso a partir do qual ele foi

gerado.


J a implementao de um componente inclui informaes sobre a linguagem de

programao, a plataforma de execuo e sobre sua documentao, alm de dados sobre

testes realizados e sobre as interfaces. Os testes indicam as condies sob as quais o

componente funciona corretamente, porm, ao contrrio das certificaes representadas

pelo X-ARM, eles so realizados pelos prprios produtores de componentes, e no por uma

entidade de certificao externa. Associar interfaces s implementaes faz com que uma

mesma interface tenha que ser especificada para todo componente que a implementar.

2.5 Consideraes Finais

Nota-se que a maioria dos modelos apresentados neste captulo baseada em XML,

permitindo a interpretao das informaes dos assets de forma programtica por

aplicaes de software. Isto atende um requisito do modelo proposto neste trabalho, j que

as descries sero utilizadas principalmente por repositrios e ferramentas para

manipulao de assets.

A fim de sumarizar os aspectos descritos pelos modelos apresentados, a Tabela 1

apresenta um comparativo com o modelo X-ARM, que ser apresentado em detalhes no

Captulo 3.

RAS OSD CDML Redolfi et

al.X-ARM

Nomeao Sim Sim Sim Sim Sim

Versionamento Sim Sim No Sim Sim

Requisitos no funcionais

No Sim Sim Sim Sim

Interfaces providas Sim (sem

reuso) No

Sim (sem reuso)

Sim (sem reuso)

Sim (com reuso)

Interfaces requeridas No NoSim (sem

reuso) Sim (sem

reuso) Sim (com

reuso)

Eventos No No Sim No Sim

Propriedades No No No No Sim

Modelos de negcios No NoSim

(rudimentar)No Sim

Certificao do asset No No No Sim (teste) Sim

Certificao do produtor No No No No Sim


Classificao Sim

(rudimentar) No No No Sim

Informaes sobre o processo de desenvolvimento

Sim (UML Components)

No No NoSim

(Qualquer processo)

Composio de componentes

No No No No Sim

Controle de visibilidade Sim

(rudimentar) No No No Sim

Tabela 1: Comparao dos modelos de representao de artefatos de software.

Nomeao e versionamento so caractersticas que precisam ser representadas a fim

de identificar os assets e suas diferentes verses. Nota-se que todos os modelos

apresentados representam os nomes de seus artefatos e apenas a CDML no representa

dados de verses.

A representao de requisitos no funcionais importante para que o consumidor

possa saber se um asset adequado s restries de seus recursos de software e hardware

[Chung99]. Neste sentido, com exceo de RAS, todos os outros modelos suportam a

representao de requisitos no funcionais.

Quando os artefatos descritos so componentes, natural que suas interfaces sejam

representadas. Assim, apenas OSD no descreve interfaces, j que seu objetivo no

descrever componentes. Podem ser identificados dois tipos de interfaces: providas e

requeridas. Os modelos que representam componentes descrevem ambos os tipos de

interfaces, com exceo de RAS, que descreve apenas interfaces providas. Alm disto, estes

modelos adotam uma abordagem em que para cada componente que prov ou requer uma

determinada interface, esta interface deve ser novamente descrita. Por outro lado, X-ARM

adota uma abordagem em que uma mesma interface descrita apenas uma vez, fazendo

com que os componentes apenas indiquem suas interfaces providas ou requeridas.

Eventos so elementos que permitem a comunicao assncrona entre componentes,

sendo teis para notificao de componentes quando determinadas condies forem

satisfeitas em outros componentes [Szyperski02]. Dentre os modelos apresentados, nota-se

que apenas CDML suporta eventos, tambm suportados por X-ARM.


Componentes podem possuir propriedades, que so atributos usados para

customizao, normalmente acessados por meio de mtodos de acesso (getters e setters)

[Szyperski02]. Alm de X-ARM, nenhum outro modelo apresentado representa

propriedades.

A representao de modelos de negcios importante no contexto de um repositrio

de componentes porque possvel que os produtores estejam interessados em receber

algum retorno financeiro da sua atividade de produo de componentes. Dentre os modelos

pesquisados, apenas CDML representa informaes sobre negociao, porm, em

comparao com X-ARM, tal modelo no permite a especificao de informaes sobre

possveis formas de pagamento. Alm disto, CDML no permite que informaes

adicionais, no descritas pelos elementos XML definidos pelo modelo, sejam especificadas.

Principalmente se considerado que reuso de software normalmente envolve

produtores e consumidores diferentes, importante que a qualidade e confiabilidade dos

assets sejam atestadas por processos de certificao [Wohlin94] [Wallnau04]. Dentre os

modelos apresentados, nenhum deles representa informaes sobre certificao, porm, o

modelo apresentado em [Redolfi05] chega a permitir a representao das condies sob as

quais os componentes foram testados, e sob as quais eles funcionam corretamente. Isto no

significa que os componentes tm qualidade e so confiveis, j que possivelmente quem

informa os dados dos testes so os prprios produtores dos componentes, ao contrrio do

X-ARM, que possibilita que entidades certificadoras testem e certifiquem os assets. Alm

de assets individuais, o prprio produtor de assets pode ser certificado. No entanto, alm do

X-ARM, nenhum outro modelo apresentado representa esta caracterstica.

A fim de facilitar a busca por assets til a adoo de um esquema de classificao

[Sametinger97]. Apenas o RAS adota este mecanismo, permitindo a associao de

palavras-chave a um asset. Alm deste mecanismo, X-ARM tambm adota um esquema de

especificao de reas de aplicao aplicveis para o asset, aderentes a um ou mais

conjuntos de reas.

A representao de informaes sobre o processo de desenvolvimento adotado na

construo dos assets importante para que consumidores possam conhecer os demais

assets gerados no mesmo projeto de um asset especfico. Assim, por exemplo, se um


consumidor est interessado em um componente, possvel conhecer os diagramas UML

relacionados quele componente e que podem auxiliar na compreenso de suas

funcionalidades. As informaes sobre o processo tambm podem ser teis para os prprios

produtores, ao possibilitar que a partir do modelo de representao sejam informados os

assets j gerados e os que ainda restam ser gerados em um processo de desenvolvimento.

Dentre os modelos apresentados, apenas RAS mantm este tipo de informaes, mas elas

so referentes apenas ao processo de desenvolvimento UML Components [Cheesman01]. O

modelo apresentado em [Redolfi05] tambm permite relacionar diferentes artefatos, porm,

sem definir significados para estes relacionamentos e sem associar informaes sobre

algum processo de desenvolvimento.

Componentes so unidades de composio [Szyperski02]. Ou seja, eles podem ser

compostos a fim de formar componentes maiores ou mesmo aplicaes. Assim, quando um

componente for composto por outros, torna-se til conhecer quais componentes o

compem, a fim de facilitar a compreenso das funcionalidades do componente composto.

Dentre os modelos apresentados, nenhum representa informaes sobre composio de

componentes.

Considerando-se que um repositrio pode armazenar assets de um projeto ainda em

andamento, no qual outros assets ainda sero produzidos, torna-se interessante que os

assets possam se tornar pblicos apenas aps o trmino do projeto. Por outro lado, os assets

tambm podem ficar visveis apenas para um conjunto de produtores que possam estar

trabalhando no mesmo projeto. Assim, um esquema de visibilidade se torna importante para

definir os produtores autorizados a acessar os assets mantidos em um repositrio. Apenas

RAS representa alguma informao sobre permisses de acesso, mas apenas como um

nico atributo textual, ao contrrio do X-ARM, que define uma estrutura de elementos para

representao de produtores autorizados e proibidos de acessar os assets.

X-ARM 17

3 X-ARM

A representao de metadados de assets pode ser utilizada em diversos aspectos das

funcionalidades de um repositrio de componentes, incluindo controle de visibilidade,

suporte a processos de desenvolvimento, classificao, modelos de negcios, certificao,

composio por outros componentes, requisitos no funcionais e representao de

componentes de acordo com diversos modelos de componentes.

Visando representar informaes sobre estes aspectos, este trabalho define um

modelo para representao de assets denominado X-ARM. Uma primeira verso deste

modelo foi apresentada em [Elias06a], consistindo de um modelo independente. No

entanto, uma nova verso foi construda [Schuenck06] com um grupo de profiles que

estendem as caractersticas do Default Profile do RAS [RAS05]. Esta alterao foi

realizada pelo fato de que esta especificao define os elementos bsicos aos propsitos do

X-ARM, alm de que o RAS um padro proposto pela OMG e adotado por importantes

empresas da indstria de software.

3.1 Assets em X-ARM

No contexto do X-ARM, o termo asset representa qualquer artefato de software gerado por

um processo de desenvolvimento, tais como: casos de uso, cdigo fonte, cdigo executvel,

planos de testes, etc. Alm destes, outros tipos de assets representam modelos, que so

usados para descrever conceitos associados ao DBC. Na prtica, estes modelos podem

restringir valores associados a algumas caractersticas dos assets, como, por exemplo, o

modelo de componentes adotado, que representa os possveis tipos de interfaces e eventos

que um componente daquele modelo deve possuir.

Conforme ilustrado na Figura 4, no X-ARM, os assets esto divididos em 4

categorias, especificadas por seus respectivos profiles (Artifact Profile, Interaction Profile,

X-ARM 18

Component Profile e Model Profile). Por sua vez, estas categorias esto subdivididas em 18

tipos de assets, que representam artefatos gerados por processos de desenvolvimento ou

modelos que descrevem conceitos associados ao DBC. As categorias e seus tipos de assets

so detalhados nas prximas subsees.

X-ARM X-ARM

Component Profile

Independent Component Specification

Dependent Component Specification

Component Implementation

Model Profile

Business Model

Certification Model

Development Process

Component Model

Application Areas

Artifact Profile

X-ARM XML Schema

License

Categoria

Tipo

Interaction Profile

Independent Exception

Dependent Interface

Independent Interface

Dependent Exception

Independent Event

Dependent Event

Producer Certification

Resource

Figura 4: Categorias e tipos de assets do X-ARM.

3.1.1 Especificao e Implementao de Componentes

Considerando que um consumidor normalmente acessa um repositrio de componentes

procura de componentes, eles podem ser considerados os principais tipos de assets. No X-

ARM, componentes so especificados usando o X-ARM Component Profile e podem ser

representados em trs nveis de abstrao, que definem diferentes tipos de assets:

x Independent Component Specification: representa a especificao de um

componente de forma independente de qualquer modelo de componente.

x Dependent Component Specification: representa a especificao de um componente

de forma dependente de seu modelo de componente. Neste caso, a especificao do

componente considera as caractersticas particulares do modelo de componente

adotado, tais como CCM, JavaBeans, EJB, COM e Web services.

x Component Implementation: representa a implementao do componente

constituda dos cdigos fonte e executvel correspondentes a uma especificao

dependente do modelo de componente.

X-ARM 19

Desta forma, no X-ARM, uma determinada especificao de componente

independente de modelo pode derivar vrias especificaes de componentes dependentes de

modelo. Por sua vez, cada especificao de componente dependente de modelo pode

derivar diversas implementaes de componentes.

3.1.2 Interfaces, Eventos e Excees

Interfaces, eventos e excees so especificados usando o X-ARM Interaction Profile.

Interfaces so colees de operaes que so utilizadas para especificar os servios

providos e requeridos pelos componentes. Desta forma, as interfaces descrevem o

comportamento dos seus respectivos componentes e so definidas levando em considerao

as interaes que so importantes para os clientes dos componentes [RAS05]. No X-ARM,

as especificaes de interfaces so descritas em dois nveis de abstrao, que representam

diferentes tipos de assets:

x Independent Interface: representa a especificao de uma interface de forma

independente dos modelos de componentes adotados pelas implementaes de

componentes que possuem aquela interface como provida ou requerida.

x Dependent Interface: representa a especificao de uma interface de forma

dependente dos modelos de componentes, adotados pelas implementaes de

componentes que possuem aquela interface como provida ou requerida. Neste caso,

a especificao da interface considera as caractersticas particulares do modelo de

componente adotado.

Geralmente, interfaces dependentes de modelo so tambm descritas usando uma

linguagem de descrio, especfica do respectivo modelo de componente. Por exemplo,

componentes CCM e JavaBeans tm suas interfaces descritas usando a linguagem CIDL e

a prpria linguagem Java, respectivamente. Vale ressaltar que as especificaes de

interfaces dependentes de modelo contm os seus arquivos de descrio expressos nas

linguagens padronizadas pelos respectivos modelos de componentes.

Eventos so mecanismos de interao assncrona [Pyarali00], que basicamente se

caracterizam pela existncia de fontes de eventos, que disparam mensagens que comunicam

receptores de eventos registrados sobre a ocorrncia de determinadas situaes. Para o

registro dos receptores de eventos, as fontes provem operaes especficas para adio e

X-ARM 20

remoo de receptores de eventos. Alm disto, as mensagens trocadas para notificao dos

receptores tm como parmetros estruturas de dados ou objetos que representam os

eventos.

As descries de interfaces e as descries de eventos so utilizadas nas

especificaes dos componentes, definindo seus comportamentos e formas de interaes.

De forma semelhante s interfaces, no X-ARM, os eventos tambm podem ser

especificados em dois nveis de abstrao, tambm representando diferentes tipos de assets:

x Independent Event: representa a especificao de um evento de forma independente

dos modelos de componentes, adotados pelos componentes que podem dispar-lo

ou receb-lo.

x Dependent Event: representa a especificao de um evento de forma dependente dos

modelos de componentes, adotados pelos componentes que podem dispar-lo ou

receb-lo. Neste caso, a especificao do evento considera as caractersticas

particulares do modelo de componente adotado.

Excees so recursos utilizados para descrever erros que podem acontecer durante

a execuo de uma operao. Os erros podem ser representados por estruturas de dados ou

objetos. Considerando que um determinado tipo de exceo pode acontecer em diversas

operaes, no X-ARM as excees so descritas de forma independente das operaes,

proporcionando assim o reuso das mesmas. De forma semelhante s interfaces e eventos, as

excees tambm podem ser especificadas em dois nveis de abstrao, representado

diferentes tipos de assets:

x Independent Exception: representa a especificao de uma exceo de forma

independente dos modelos de componentes, adotados pelos componentes que

podem dispar-la ou receb-la.

x Dependent Exception: representa a especificao de uma exceo de forma

dependente dos modelos de componentes, adotados pelos componentes que podem

dispar-la ou receb-la. Neste caso, a especificao da exceo considera as

caractersticas particulares do modelo de componente adotado.

X-ARM 21

Como pode ser observado, interfaces, eventos e excees podem ser representadas

em dois nveis de abstrao. O primeiro o nvel independente de modelo de componente,

onde se tem uma descrio abstrata que pode ser reutilizada para a gerao de descries

dependentes de modelo. O segundo o nvel dependente de modelo de componente, onde

se tem uma descrio que depende do modelo de componente adotado. As especificaes

dependentes de modelo podem referenciar suas respectivas especificaes independentes de

modelo. Desta forma, as especificaes dependentes de modelo reusam as especificaes

independentes de modelo.

3.1.3 Artefatos

Artefatos so quaisquer outros produtos de software, diferentes de componentes, interfaces,

eventos e excees, gerados durante um processo de desenvolvimento, tais como:

diagramas de atividade e de classes, casos de uso e planos de testes. Em alguns casos,

artefatos podem ser reutilizados integralmente entre verses de um mesmo componente. No

entanto, em outros casos, artefatos tambm podem ser reutilizados com adaptaes e servir

de base para a construo de outros componentes de software.

Artefatos so especificados usando o X-ARM Artifact Profile. Alm de representar

produtos de software gerados por um processo de desenvolvimento, este profile tambm

representa outros trs diferentes tipos de assets. Desta forma, esta categoria de assets

dividida nos seguintes tipos de assets:

x X-ARM XML Schema: armazena um esquema XML que descreve um determinado

profile do X-ARM. O esquema mantido neste tipo de asset usado para validar as

especificaes X-ARM de outros assets, que so instncias daquele profile.

x License: armazena uma determinada licena de uso (GPL, MPL, etc.). Este asset

reusado pelos demais assets que adotam aquela licena especfica.

x Producer Certification: descreve as informaes da certificao do processo de

software adotado por um determinado produtor.

x Resource: descreve quaisquer outros artefatos de software, diferentes de

componentes, interfaces, eventos e excees, gerados por um processo de

desenvolvimento.

X-ARM 22

Na realidade, estes diferentes tipos de assets foram subdivididos apenas para

facilitar a identificao e diferenciao dos mesmos em um repositrio. No entanto, as

estruturas de representao destes tipos so similares.

3.1.4 Modelos

No X-ARM, diversas informaes descritas nos assets devem adotar ou seguir um

determinado padro, modelo ou processo. Por exemplo, um componente deve: adotar um

modelo de componente, ser gerado usando um processo de desenvolvimento, ser

classificado usando um padro de classificao, e suportar um conjunto de modelos de

negcio. Para ser possvel especificar os padres, modelos ou processos adotados pelos

diversos assets, o X-ARM Model Profile est subdividido em cinco tipos de assets:

x Development Process: define um processo de desenvolvimento de software baseado

em componentes, identificando suas fases e respectivos tipos de artefatos gerados.

x Certification Model: descreve um processo de certificao de componentes,

identificando os diferentes parmetros avaliados e seus possveis conceitos.

x Business Model: define um modelo de negcio, identificando as diferentes

caractersticas e seus possveis valores.

x Component Model: especifica um modelo de componentes, enumerando os

diferentes tipos de caractersticas e elementos que o compem.

x Application Areas: define um esquema de classificao baseado em reas de

aplicao.

Os tipos de assets gerados a partir do X-ARM Model Profile representam os

conjuntos de valores possveis de serem utilizados nos demais profiles, assegurando um

mecanismo uniforme de descrever e indicar os padres, modelos ou processos associados.

Por exemplo, na definio das reas de aplicao de um asset, somente sero aceitos

valores especificados em um determinado asset do tipo especificao de reas de aplicao

(Application Areas). Os outros tipos desta seo seguem lgica similar ao exemplo,

envolvendo o uso destas especificaes por outros tipos de assets.

X-ARM 23

3.1.5 Empacotamento de assets

No contexto do X-ARM, todo asset deve ser descrito em um arquivo de manifesto para

descrio de assets, chamado manifest.xml. Os arquivos que compem o asset devem estar

dentro do arquivo de pacote e devem ser referenciados pelo manifesto. O manifesto e todos

os arquivos referenciados so empacotados em um nico arquivo usando o algoritmo de

compresso ZIP [Moffat97].

Os arquivos de manifesto habilitam: (a) verificao de consistncia dos arquivos

empacotados antes do armazenamento de um asset em um repositrio, garantindo que os

assets referenciados j esto registrados no repositrio; (b) o download de assets requeridos

em tempo de execuo ou desenvolvimento; e (c) detectar dependncias entre assets,

tornando possvel assegurar que um asset somente pode ser excludo de um repositrio

quando nenhum outro asset depende dele.

3.1.6 Identificao nica

Para garantir a unicidade de identificao, independncia e transparncia de localizao dos

assets mantidos em um repositrio, o X-ARM adota um esquema de nomeao hierrquico,

similar a uma URL [Berners-Lee94], mas sem referenciar a localizao fsica.

Em um repositrio compatvel com o X-ARM, os assets armazenados so

logicamente agrupados em zonas e domnios. Nesta abordagem, zonas representam os

produtores de assets, enquanto domnios so usados basicamente para agrupar famlias de

produtos. Uma zona pode possuir domnios, que por sua vez, sempre so subordinados a

alguma zona. A Figura 5 exemplifica a hierarquia de nomes, onde a zona raiz

representada por um ponto.

Figura 5: Hierarquia de nomes no X-ARM.

X-ARM 24

De acordo com a Figura 5, pode-se dizer que br.compose.xmlParser identifica o

asset cujo nome xmlParser, produzido por desenvolvedores pertencentes zona ou

domnio br.compose. Uma subzona ou subdomnio qualquer zona ou domnio abaixo de

outro em uma hierarquia de zonas e domnios. Por exemplo, br.ufpb uma subzona ou

subdomnio da zona ou domnio br.

A fim de possibilitar que atividades relacionadas a gerncia de configurao possam

ser realizadas, torna-se necessrio que as verses dos produtos gerenciados possam ser

identificadas [Conradi98]. Neste sentido, X-ARM define um esquema de versionamento

simples, onde a verso do asset definida por uma seqncia de nmeros inteiros

separados por pontos. Por exemplo, 2.0.2. Ressalta-se que a nova verso de um asset

obrigatoriamente deve ser maior do que a verso anterior.

Para gerar o identificador nico de um asset, une-se o seu nome sua verso,

separando-os por um hfen (-). Como exemplo, considerando o componente

br.compose.xmlParser em sua verso 2.0.2, a identificao nica deste asset

br.compose.xmlParser-2.0.2. Vale ressaltar que o atributo version definido pelo RAS

usado para indicar a verso do asset em termos comerciais, tal como, por exemplo, a verso

2.0 do aplicativo OpenOffice. Por outro lado, a verso para identificar um asset em um

repositrio sempre concatenada ao nome do asset.

3.2 Hierarquia de Profiles

O X-ARM considerado compatvel com o RAS porque estende o Default Profile. Assim,

proposto o X-ARM Artifact Profile, que acrescenta elementos para representao de

informaes sobre controle de visibilidade, processo de desenvolvimento adotado, reas de

aplicao, histrico da evoluo de assets e modelos de negcios. Com os elementos

definidos neste profile, possvel descrever os assets do tipo X-ARM XML Schema,

License, Producer Certification e Resource. Este profile especializado em trs outros,

para representao das demais categorias e tipos de assets:

x X-ARM Component Profile: usado para descrever especificaes e implementaes

de componentes.

x X-ARM Interaction Profile: tem a funo de representar as caractersticas de

interfaces, eventos e excees.

X-ARM 25

x X-ARM Model Profile: descreve especificaes de processos de desenvolvimento,

reas de aplicao, modelos de certificao, modelos de negcios e modelos de

componentes.

A hierarquia de profiles, a partir do Core RAS e do Default Profile, ambos definidos

pelo RAS, apresentada na Figura 6. Nesta figura, a classe Asset representa o Core RAS,

cuja realizao feita pelo Default Profile. Nos exemplos adotados no texto, assume-se que

uma instncia de um profile automaticamente uma instncia do profile superior tambm.

Figura 6: Hierarquia de profiles do X-ARM.

O CoreRAS define como elemento raiz, onde, por meio de seus atributos e

elementos, possvel representar algumas caractersticas bsicas de assets, tais como a

identificao e o produtor do asset, os arquivos empacotados, o profile referente ao asset

descrito e palavras-chave utilizadas para classificao. A organizao e as funcionalidades

dos elementos definidos no elemento podem ser encontradas com detalhes na

especificao do RAS [RAS05]. Desta forma, as prximas sees deste documento apenas

descrevem e discutem os elementos e atributos introduzidos pelos profiles do X-ARM.

3.3 X-ARM Artifact Profile

Em RAS, o objetivo do Default Profile especificar os elementos que representam as

caractersticas bsicas das descries dos assets. Quando da criao de novos profiles, estas

caractersticas j esto automaticamente incorporadas. No contexto deste trabalho, foi

identificada a necessidade de representar novas caractersticas, no suportadas pelo Default

Profile do RAS. Esta necessidade motivou a criao do X-ARM Artifact Profile.

X-ARM 26

A representao do X-ARM Artifact Profile apresentada na Figura 7. Para ser

possvel distinguir as classes definidas em profiles mais genricos das classes definidas em

profiles mais especializados (neste caso as classes do Default Profile e as classes do X-ARM

Artifact Profile, respectivamente), a seguinte notao adotada: as classes brancas so

aquelas definidas no profile mais genrico, mas que no foram alteradas; as classes com o

esteretipo so provenientes do profile mais genrico, mas foram alteradas

por meio da adio de atributos ou de alteraes semnticas; e as classes na cor cinza so as

classes definidas pelo profile mais especializado. Esta notao tambm empregada na

apresentao dos demais profiles descritos neste trabalho.

Figura 7: X-ARM Artifact Profile.

Os elementos adicionados foram , , ,

, e , que representam,

respectivamente, informaes relativas aos assets utilizados para a gerao de um

determinado asset, indicao do tipo de artefato ao qual se refere o asset e do processo de

X-ARM 27

desenvolvimento adotado, controle da visibilidade pelos consumidores, certificao do

asset, histrico da evoluo do asset e representao de modelos de negcios. Estes

elementos so detalhados nas prximas subsees.

O elemento foi alterado de forma a adicionar os atributos owner, last-

change e language. O primeiro indica o nome do produtor. O segundo representa a data da

ltima mudana realizada no asset, sem que fosse gerada uma nova verso. O terceiro e

ltimo atributo, language, responsvel por indicar o idioma no qual o manifesto do asset

foi descrito. O valor do atributo language deve ser um dos valores especificados no ISO

639 Language Codes [ISO05b]. Alm da adio destes atributos, o elemento foi

alterado de forma a ter seus atributos state e access-rights desconsiderados, j que eles so

opcionais e que no contexto de X-ARM estes atributos no so necessrios.

No elemento foi adicionado o atributo type e um elemento . O atributo type usado para indicar o tipo do asset descrito e tem como valores

possveis, aqueles indicados na Figura 4. J o elemento indica um asset do

tipo X-ARM XML Schema que representa o arquivo XML Schema usado para validar o

manifesto do asset. Neste caso, o valor do atributo relationship-type do elemento X-ARM XML Schema.

O elemento permite indicar um asset relacionado, identificado pelo

atributo id. A este elemento foi adicionado o atributo required, que indica se o asset atual

s funciona adequadamente se o asset relacionado for recuperado. Tambm foi adicionado

o atributo opcional artifact-id. Se este atributo no usado, o asset relacionado est

armazenado no repositrio. Por outro lado, se o atributo artifact-id usado, o asset

relacionado est armazenado no prprio pacote do asset descrito. Neste caso, o atributo

artifact-id representa o identificador do arquivo que contm o asset relacionado dentro do

pacote do asset descrito.

O elemento utilizado para incluir uma descrio sobre algum

elemento definido pelo X-ARM. Esta descrio pode ser realizada de duas formas. Na

primeira, o elemento contm um pequeno texto que descreve o respectivo

elemento associado. Na segunda, o elemento contm o atributo artifact-id,

cujo propsito apontar para um arquivo interno do pacote, indicado em um elemento

X-ARM 28

, que contm uma descrio mais detalhada. O elemento

empregado por diversos elementos nos profiles definidos pelo X-ARM.

As prximas subsees tratam das funcionalidades dos elementos introduzidos pelo

X-ARM Artifact Profile.

3.3.1 Artefatos do Processo de Desenvolvimento

Um processo de desenvolvimento normalmente organizado como um conjunto de fases,

constitudas por atividades, mtodos, prticas e transformaes, usados para atingir um

objetivo especfico. Este objetivo associado a um ou mais resultados concretos finais, que

so os produtos da execuo do processo [Cheesman01]. Tais produtos so artefatos

especficos gerados em cada fase, tais como diagramas, especificaes de interfaces, cdigo

fonte e o prprio componente. Por exemplo, o processo de desenvolvimento UML

Components [Cheesman01] tem como artefatos de sada do workflow Requirements: o

modelo conceitual do negcio, que um diagrama de classes; e o modelo de casos de uso,

que um diagrama de casos de uso. Estes artefatos, segundo a classificao definida pelo

X-ARM, so considerados assets do tipo Resource, descritos pelo X-ARM Artifact Profile.

A identificao da fase do processo de desenvolvimento na qual o artefato foi

gerado permite oferecer mecanismos que possam verificar e validar se um determinado tipo

de artefato pode ser gerado naquela fase do processo. Por outro lado, considerando a

identificao da fase do processo, possvel controlar o conjunto e a seqncia de artefatos

que devem ser gerados ao longo do processo.

Para indicar o processo de desenvolvimento adotado, o X-ARM Artifact Profile

define o elemento , cuja estrutura apresentada na Figura 8. O atributo

phase indica a fase do processo na qual o asset foi gerado. O atributo output-type indica o

tipo de artefato associado quele asset. Considerando que as fases dos processos podem ser

organizadas hierarquicamente em diversos nveis, o valor do atributo phase representado

usando os nomes individuais das fases, que compem a hierarquia, separados por pontos.

Por exemplo, no caso do processo UML Components, cuja fase (workflow) Specification

possui a subfase (estgio) Component Identification, o valor do atributo phase

Specification.Component Identification.

X-ARM 29

Figura 8: Representao de processo de desenvolvimento adotado.

Opcionalmente, cada elemento tambm pode ter um elemento

, que contm uma descrio do processo, a fase e o tipo de artefato. O asset

que especifica o processo de desenv

X-ARM: Um Modelo de Representação de Artefatos de Software

Documents

Transcript of X-ARM: Um Modelo de Representação de Artefatos de Software