X-ARM: Um Modelo de Representação de Artefatos de Software
-
Upload
michael-schuenck -
Category
Documents
-
view
9 -
download
0
description
Transcript of 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
Michael Schuenck dos Santos
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
Michael Schuenck dos Santos
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.
-
Trabalhos Relacionados 7
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.
-
Trabalhos Relacionados 8
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
-
Trabalhos Relacionados 9
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
-
Trabalhos Relacionados 10
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.
-
Trabalhos Relacionados 11
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
-
Trabalhos Relacionados 12
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.
-
Trabalhos Relacionados 13
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
-
Trabalhos Relacionados 14
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.
-
Trabalhos Relacionados 15
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
-
Trabalhos Relacionados 16
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