Академический Документы
Профессиональный Документы
Культура Документы
Dissertao de Mestrado
Natal RN
Agosto de 2006
ii
Natal RN
Agosto de 2006
iii
RN/UF/BSE-CCET
CDU 004.4
iv
Banca Examinadora:
_________________________________________
Prof. Dr. Gldson Elias da Silveira
Orientador
_________________________________________
Prof. Dr. Bruno Motta de Carvalho
_________________________________________
Prof. Dr. Itana Maria de Souza Gimenes
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
ix
Abstract
Glossrio
xi
Sumrio
Resumo ...............................................................................................................................viii
Abstract ................................................................................................................................ix
Glossrio ................................................................................................................................ x
Sumrio ................................................................................................................................xi
Lista de Figuras .................................................................................................................xiii
Lista de Tabelas .................................................................................................................xvi
1
Introduo ..................................................................................................................... 1
1.1
MOTIVAO ............................................................................................................ 3
1.2
OBJETIVOS ............................................................................................................... 4
1.3
ORGANIZAO DO TRABALHO ................................................................................. 5
2
Trabalhos Relacionados ............................................................................................... 6
2.1
RAS ........................................................................................................................ 6
2.1.1
Core RAS e Default Profile ............................................................................ 8
2.1.2
Default Component Profile............................................................................. 9
2.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 ........................................................................................................................ 17
3.1
ASSETS EM X-ARM .............................................................................................. 17
3.1.1
Especificao e Implementao de Componentes........................................ 18
3.1.2
Interfaces, Eventos e Excees..................................................................... 19
3.1.3
Artefatos ....................................................................................................... 21
3.1.4
Modelos ........................................................................................................ 22
3.1.5
Empacotamento de assets............................................................................. 23
3.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.................................................. 28
3.3.2
Rastreabilidade do Processo de Desenvolvimento....................................... 30
3.3.3
Classificao Baseada em reas de Aplicao............................................ 33
xii
3.3.4
Controle de Visibilidade............................................................................... 35
3.3.5
Histrico da Evoluo do Asset ................................................................... 37
3.3.6
Certificao .................................................................................................. 38
3.3.7
Informaes de Negociao ......................................................................... 42
3.4
X-ARM MODEL PROFILE ...................................................................................... 46
3.4.1
Processos de Desenvolvimento..................................................................... 48
3.4.2
Classificao Baseada em reas de Aplicao............................................ 52
3.4.3
Modelo de Certificao ................................................................................ 53
3.4.4
Modelos de Negcio ..................................................................................... 55
3.4.5
Modelos de Componentes............................................................................. 57
3.5
X-ARM INTERACTION PROFILE ............................................................................ 61
3.5.1
Interfaces ...................................................................................................... 64
3.5.2
Eventos ......................................................................................................... 68
3.5.3
Excees ....................................................................................................... 73
3.6
X-ARM COMPONENT PROFILE .............................................................................. 75
3.6.1
Especificaes de Componentes................................................................... 80
3.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 ........................................................................................................ 99
4.2.2
Workflow Requirements.............................................................................. 100
4.2.3
Workflow Specification............................................................................... 100
4.2.4
Workflow Provisioning ............................................................................... 105
4.3
DESCRIO DOS ASSETS USANDO X-PACKAGER ................................................. 107
4.3.1
X-ARM Model Profile................................................................................. 108
4.3.2
X-ARM Artifact Profile............................................................................... 119
4.3.3
X-ARM Interaction Profile ......................................................................... 127
4.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
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
Introduo
1 Introduo
Introduo
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
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
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
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.
Trabalhos Relacionados
2 Trabalhos Relacionados
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
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.
Trabalhos Relacionados
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.
Trabalhos Relacionados
distribudo, esta caracterstica constitui um ponto fraco do RAS, visto que com isto, no se
consegue transparncia de localizao do esquema XML adotado.
Trabalhos Relacionados
10
Trabalhos Relacionados
11
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
mas
tambm
qualquer
artefato
gerado
durante
processo
de
Trabalhos Relacionados
13
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
Sim (sem
reuso)
No
Sim (sem
reuso)
Sim (sem
reuso)
Sim (com
reuso)
Interfaces requeridas
No
No
Sim (sem
reuso)
Sim (sem
reuso)
Sim (com
reuso)
Eventos
No
No
Sim
No
Sim
Propriedades
No
No
No
No
Sim
Modelos de negcios
No
No
Sim
(rudimentar)
No
Sim
Certificao do asset
No
No
No
Sim (teste)
Sim
Certificao do produtor
No
No
No
No
Sim
Interfaces providas
Trabalhos Relacionados
14
Classificao
Sim
(rudimentar)
No
No
No
Sim
Informaes sobre o
processo de
desenvolvimento
Sim (UML
Components)
No
No
No
Sim
(Qualquer
processo)
No
No
No
No
Sim
Sim
(rudimentar)
No
No
No
Sim
Composio de
componentes
Controle de visibilidade
Trabalhos Relacionados
15
Trabalhos Relacionados
16
X-ARM
17
3 X-ARM
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
Artifact Profile
Component Profile
License
Producer Certification
Component Implementation
Resource
Model Profile
Interaction Profile
Development Process
Independent Interface
Certification Model
Dependent Interface
Business Model
Independent Exception
Component Model
Dependent Exception
Application Areas
Independent Event
Categoria
Dependent Event
Tipo
Component
Implementation:
representa
implementao
do
componente
X-ARM
19
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
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
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
License: armazena uma determinada licena de uso (GPL, MPL, etc.). Este asset
reusado pelos demais assets que adotam aquela licena especfica.
X-ARM
22
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
X-ARM
23
X-ARM
24
X-ARM
x
25
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.
X-ARM
26
<change-history>
<business-info>,
que
representam,
X-ARM
27
X-ARM
28
X-ARM
29
12. </asset>
X-ARM
30
X-ARM
31
Para indicar a fase do processo na qual os assets reusados foram gerados utilizado
o elemento <phase>. O atributo name indica o nome da fase. Como as fases podem ser
organizadas hierarquicamente, o valor deste atributo representado com os nomes das fases
e subfases separados por pontos, da mesma forma que o atributo phase do elemento
<process-info>, apresentado na Seo 3.3.1.
Para representar os assets reusados e seus tipos utilizado o elemento <type>, cujo
atributo name informa o tipo de artefato (definido pelo processo de desenvolvimento) ao
qual o asset se refere. Para indicar os prprios assets reusados, utilizado o elemento
<related-asset> que, neste caso, tem em seu atributo relationship-type o valor
reusedAsset.
Alm de permitir a representao dos assets reusados que foram criados seguindo
processos de desenvolvimento, X-ARM tambm possibilita a representao do reuso de
assets que foram produzidos sem qualquer processo. Assim, o prprio elemento <reusedassets> pode ter elementos <related-asset>, usados para informar as identificaes dos
assets reusados. Neste caso, o valor do atributo relationship-type de <related-asset>
reusedAsset.
Na representao dos assets reusados, como ilustrado na Figura 11, o X-ARM
permite a adoo de trs abordagens de rastreabilidade. Na Figura 11, as setas indicam as
referncias a assets reusados. Na abordagem de rastreabilidade por asset (esquerda da
Figura 11) cada asset referencia os demais assets diretamente reusados. Nesta abordagem,
para identificar todos os assets reusados ao longo do processo, necessrio a adoo de um
procedimento recursivo que explora os assets reusados por cada asset. Por outro lado, esta
abordagem permite que, a qualquer momento do processo de desenvolvimento, seja
possvel rastrear os assets reusados.
X-ARM
32
Asset
Legenda:
Projeto
Asset
Fase
Fase
Andamento
do Processo
Produto Final
X-ARM
33
esta abordagem apresenta um esforo adicional, j que um novo asset deve ser gerado para
agrupar as referncias.
Ressalta-se que estas trs abordagens no so as nicas possveis, pois o X-ARM
tambm permite a combinao das mesmas. Por exemplo, possvel adotar a abordagem
por asset ao longo do processo de desenvolvimento, e, ao final, nas implementaes dos
componentes, tambm adotar a abordagem por projeto. Desta forma, por um lado, ao longo
do projeto, as informaes de rastreabilidade podem ser recuperadas recursivamente. Por
outro lado, ao final do projeto, as informaes de rastreabilidade podem ser rapidamente
recuperadas diretamente das implementaes de componentes.
X-ARM
34
X-ARM
35
do
atributo
relationship-type
do
elemento
<related-asset>
deve
ser
appAreasSchema.
A Figura 13 ilustra um trecho da descrio de um asset, em que apresentada a
classificao por reas de aplicao. Como indicado no elemento <related-asset>, o
esquema de classificao adotado especificado no asset cujo identificador nico
br.areas-1.0. No primeiro elemento <descriptor>, o valor Entertainment.Game.Computer
representa uma hierarquia de reas de aplicao, onde Entertainment o nvel mais alto e
Computer o nvel mais baixo e mais especializado. Vale ressaltar que, neste exemplo,
todas as reas de aplicao indicadas devem ter sido previamente definidas no asset
relacionado, denominado br.areas-1.0, que especifica o esquema de classificao adotado.
1. <classification>
...
2. <context name="X-ARM Application Areas" id="19">
...
3.
<descriptor-group>
4.
<related-asset name="Areas" id="br.areas-1.0" relationship-type="appAreasSchema" required="false"/>
5.
<descriptor name="Entertainment.Game.Computer"/>
6.
<descriptor name="Entertainment.Music.MP3.Decoder"/>
7.
</descriptor-group>
8. </context>
9. </classification>
X-ARM
36
X-ARM
37
1. <visibility>
2. <allow domain="br.compose">
3.
<deny domain="br.compose.tmp"/>
4. </allow>
5. </visibility>
X-ARM
38
com relao s verses anteriores. Como pode ser observado, ao elemento <changehistory>, pode-se opcionalmente associar uma descrio textual sobre a evoluo ocorrida.
3.3.6 Certificao
A fim de oferecer maior confiabilidade aos usurios de um repositrio, necessrio que os
assets armazenados apresentem um nvel mnimo de qualidade, visto que o reuso tem como
fundamento a utilizao de assets desenvolvidos por terceiros. Neste sentido, torna-se
importante o papel de entidades certificadoras, responsveis por avaliar a qualidade dos
assets [Wallnau04]. Estas entidades podem adotar diferentes metodologias de certificao,
X-ARM
39
cujas descries podem ser expressas usando termos especficos definidos por cada
entidade certificadora. Outra abordagem tambm adotada a certificao do produtor, em
que o processo de software adotado pelo produtor do asset deve atender uma srie de
requisitos impostos por uma entidade certificadora.
No sentido de representar a certificao dos assets e dos seus produtores, o X-ARM
define o elemento <certification-info>, cuja estrutura ilustrada na Figura 18. Este
elemento opcional, no devendo ocorrer em assets que no possuem qualquer tipo de
certificao.
<producer-certification>
<certification>.
elemento
X-ARM
40
um asset do tipo Certification Model do X-ARM Model Profile, descrito na Seo 3.4.3.
Portanto, a certificao dos assets deve adotar um modelo de certificao. No elemento
<related-asset>, o atributo relationship-type deve possuir o valor certificationModel.
No elemento <certification>, os atributos type e date identificam o tipo de modelo
de certificao adotado e a data que foi realizada a certificao, respectivamente. O valor
do atributo type deve estar definido no asset de especificao de modelo de certificao,
indicado no elemento <related-asset>. Para permitir que um repositrio possa autenticar
uma certificao, o elemento <certification> define o atributo certifier-id, que usado para
representar o identificador nico da respectiva entidade certificadora. Neste caso, entidades
certificadoras podem estar registradas no repositrio ou no, desde que possam ser
identificadas de alguma forma, como por exemplo, por URLs. Desta forma, um repositrio
que suporte o X-ARM pode acessar os dados da entidade certificadora, inclusive a sua
chave pblica. De forma semelhante a outros elementos, o elemento <certification> pode
possuir uma descrio textual para auxiliar no entendimento da certificao, que pode ser
representada usando o elemento <description>.
Para assegurar que o certificado foi de fato emitido pela entidade certificadora, o XARM define o elemento <signature>, que contm uma assinatura digital do certificado,
emitida pela prpria entidade certificadora. No elemento <signature>, o atributo digestalgorithm indica o algoritmo de hash usado para gerar o Digest e o atributo sign-algorithm
indica o algoritmo usado para gerar a assinatura digital.
A assinatura digital pode ser informada de duas formas. Na primeira, o atributo
artifact-id referencia um arquivo existente dentro do pacote do asset, que possui a
assinatura digital gerada pela entidade certificadora. Na segunda, a assinatura
representada como contedo do prprio elemento <signature>, no formato Base64.
A assinatura digital gerada considerando todas as partes no modificveis do
manifesto, que so os elementos XML do manifesto que, se alterados, produzem uma nova
verso do asset. Estas partes no modificveis devem ser definidas pelo prprio repositrio.
No entanto, para exemplificar, provvel que um repositrio que adote o X-ARM defina
que informaes sobre modelos de negcios podem ser modificadas sem gerar novas
verses dos assets, afinal, o preo de um asset pode variar de acordo com fatores
X-ARM
41
econmicos. Alm disto, para gerao da assinatura digital tambm so considerados todos
os arquivos indicados nos elementos <artifact> do manifesto, com exceo do arquivo que
contm a prpria assinatura, quando o mesmo existir. Neste caso, o nome do arquivo que
contm a assinatura j deve ser previsto antes da assinatura ser criada, j que o manifesto
indica o nome do arquivo de assinatura. Desta forma, os consumidores podem confiar que o
certificado foi de fato emitido pela entidade certificadora, considerando todos os arquivos
que compem o asset.
Os detalhes da certificao so representados por uma hierarquia de elementos
<certification-item>, que permitem representar diversos tipos de parmetros de certificao.
Para cada elemento <certification-item>, o atributo key permite a especificao de um
parmetro do modelo de certificao adotado, enquanto o elemento <value> representa o
valor relacionado a este parmetro. O atributo key identifica o nome do parmetro e o
atributo value indica o resultado da avaliao daquele parmetro. Como mencionado
anteriormente, os detalhes da certificao devem seguir um modelo de certificao,
especificado como um asset do tipo Certification Model do X-ARM Model Profile.
De forma semelhante a outros elementos previamente discutidos, o elemento
<certification-item> pode possuir uma descrio associada que auxilie no entendimento,
especificada usando o elemento <description>.
A Figura 19 apresenta um exemplo de representao de certificao de asset.
X-ARM
42
1. <certification-info>
2. <certification type="ISO 9126-based" certifier-id="br.compose.compsign" certificate-id=A date="2005-10-05">
3.
<related-asset id="br.compsign.certification-1.0" name=ISO 9126-based relationship-type="certificationModel"
required="true"/>
4.
<certification-item key="Accuracy">
5.
<certification-item key="Correctness">
6.
<value>87</value>
7.
</certification-item>
8.
</certification-item>
9.
<certification-item key="Security">
10.
<certification-item key="Data Encryption">
11.
<value>yes</value>
12.
</certification-item>
13.
<certification-item key="Controllability">
14.
<value>98</value>
15.
</certification-item>
16.
<certification-item key="Auditability">
17.
<value>yes</value>
18.
</certification-item>
19.
</certification-item>
20.
<signature digest-algorithm="SHA1" sign-algorithm="RSA">
e+1x6YuUMCEAP/Wvz2CwC0kKtOLgWvJaNVVfMLNuhYpp5DjXX/ZzPJwXec
nR/w7SjoMP55pkWh5jPzWBudsKMaA7f0bf3zO5+5NFQwb+p9OBuTXeChQ+cx/A5x
gxA9+q8mI7LoRbXHbEgyGgxHV/pSCiyiwH1N7y9b5ZixcrvUAIdp/XJBlB8QGiEE
AKEJFIyC9oBvoL+m0cnTdt7y+F1rQKDNYIGpDgNf+9uVlbGAKOJToU14U5TmwQmJ
Ogqx5vhr3HaslI69ZdU8ijh5Hlucjzd/6KQgn1LbQT+oQzKTAB4T61FllOf7SQZm
21.
</signature>
22. </certification>
23. </certification-info>
X-ARM
43
X-ARM
44
X-ARM
45
string, o termo * indica que o item pode possuir qualquer valor. Tambm possvel
combinar valores discretos, mltiplos valores discretos e intervalos de valores, como por
exemplo: 1..10, 25, 30..40, 50, 60.
De forma semelhante a outros elementos previamente discutidos, o elemento
<business-item> pode possuir uma descrio associada que auxilie no entendimento,
especificada usando o elemento <description>.
A Figura 21 ilustra um exemplo de descrio das informaes de negociao de um
asset. O asset representado segue um modelo de negcios do tipo pay-per-copy, que no
distribudo livremente.
1. <business-info>
2. <business type="pay-per-copy">
3.
<related-asset relationship-type="businessModel" id="br.business.paypercopy-1.0" required="false"/>
4.
<business-item key="copies">
5.
<value>1..10</value>
6.
<business-item key="unitary price">
7.
<value>150,00</value>
8.
</business-item>
9.
<business-item key="currency">
10.
<value>R$</value>
11.
</business-item>
12.
</business-item>
13.
<business-item key="copies">
14.
<value>11..100</value>
15.
<business-item key="unitary price">
16.
<value>140,00</value>
17.
</business-item>
18.
<business-item key="currency">
19.
<value>R$</value>
20.
</business-item>
21.
</business-item>
22.
<business-item key="credit-card">
23.
<value>Visa</value>
24.
</business-item>
25.
<license type="GPL">
26.
<related-asset relationship-type="license" id="org.gnu.gpl -1.0" required="true"/>
27.
</license>
28.
<support time="2" unit="years"/>
29.
<broker id=com.compsource/>
30. </business>
31. </business-info>
X-ARM
46
de
informao
para
representao
de
aspectos
como
processos
de
X-ARM
47
ESTRUTURA
=
MODELO
=
A
...
...
B
=
C
Propriedades
Realizao
D
E
DESCRIO DO
ASSET
F
A
G
E
Valores das
Propriedades
X-ARM
48
principais
<process-model>,
<business-model>,
<certification-model>,
<component-model> e <app-areas-model>.
X-ARM
49
organizados como conjuntos de fases, nas quais podem ser gerados um ou mais artefatos,
de tipos determinados pelos processos. Assim, para especificao de processos de
desenvolvimento com o X-ARM, so utilizados assets do tipo Development Process,
descritos com X-ARM Model Profile. Estes assets permitem a validao das fases e tipos de
artefatos, no X-ARM Artifact Profile, conforme mencionado nas Sees 3.3.1 e 3.3.2. A
organizao dos elementos para a especificao de processos de desenvolvimento no XARM Model Profile apresentada na Figura 24.
X-ARM
50
10. </process-model>
X-ARM
51
Component Implementation
Development Process
<asset id=br.process.umlc-2.0 date=2006-01-01
last-change=2006-01-01 owner=Cheesman
language=en>
<process-model>
<phasename="Requirements"
name="Requirements"type="workflow">
type="workflow">
<phase
<output type="Use
type="Use Case
Case Model/>
Model/>
<output
<output
type="Business
Concept
<output type="Business ConceptModel/>
Model/>
</phase>
</phase>
<phase name=Specification" type="workflow">
<phase name=Specification" type="workflow">
<phase stage=Identification type=stage>
<phase stage=Identification type=stage>
<output type=Business Type Model/>
<output type=Business Type Model/>
<output type=Business Interfaces/>
<output type=Business Interfaces/>
<output type=System Interfaces/>
<output type=System Interfaces/>
<output type=Component Spec & Architecture/
<output type=Component Spec & Architecture/>
</phase>
</phase>
...
</process-model>
</asset>
br.compose.sofia.sofiacomp-2.0
br.process.umlc-2.0
Resource
<asset id=br.compose.sofia.usecases-2.0 date=2006-01-10 last-change=2006-01-20
owner=Compose language=en>
<process-info phase="Requirements output-type=Use Case Model>
<related-asset relationship-type=processModel id=br.process.umlc-2.0
required=true/>
</process-info>
<solution>
<artifact id=1 type=jude reference=ucm.jude/>
<artifact id=2 type=doc reference=usecase.doc/>
</solution>
</asset>
br.compose.sofia.usecases-2.0
Resource
<asset id=br.compose.sofia.concept-1.0 date=2006-01-10 last-change=2006-01-20
owner=Compose language=en>
<process-info phase=Requirements output-type=Business Concept Model">
<related-asset relationship-type=processModel id=br.process.umlc-2.0
required=true/>
</process-info>
<solution>
<artifact id=4 type=jude reference=btm.jude/>
</solution>
</asset>
br.compose.sofia.concept-1.0
X-ARM
52
que ambos foram gerados na fase Requirements e que so dos tipos Use Case Model e
Business Concept Model, respectivamente.
Para representar a rastreabilidade com a abordagem por projeto, utilizada uma
implementao de componente (identificada por br.compose.sofia.sofiacomp-2.0) que faz a
referncia aos outros trs assets. Ela referencia (setas 1 e 2) a especificao do processo de
desenvolvimento no sentido de informar qual processo foi seguido para a construo do
componente. Esta implementao tambm referencia dois artefatos (setas 5 e 6) gerados
durante o seu desenvolvimento de acordo com a fase do processo em que eles foram
gerados.
X-ARM
53
15. </app-areas-model>
16. </asset>
X-ARM
54
X-ARM
55
2.
<certification-model>
3.
<certification-item key="Accuracy" mandatory="false">
4.
<certification-item key="Correctness" mandatory="false">
5.
<allowed-value value="0..100" value-type="integer"/>
6.
</certification-item>
7.
</certification-item>
8.
<certification-item key="Security" mandatory="false">
9.
<certification-item key="Data Encryption" mandatory="false">
10.
<allowed-value value="yes" value-type="string"/>
11.
<allowed-value value="no" value-type="string"/>
12.
</certification-item>
13.
<certification-item key="Controllability" mandatory="false">
14.
<allowed-value value="0..100" value-type="integer"/>
15.
</certification-item>
16.
<certification-item key="Auditability" mandatory="false">
17.
<allowed-value value="yes" value-type="string"/>
18.
<allowed-value value="no" value-type="string"/>
19.
</certification-item>
20.
</certification-item>
21.
<certification-item key="Resource Behavior" mandatory="false">
22.
<certification-item key="Memory Utilization" mandatory="false">
23.
<allowed-value value="*" value-type="integer"/>
24.
</certification-item>
25.
<certification-item key="Disk Utilization" mandatory="false">
26.
<allowed-value value="*" value-type=" integer "/>
27.
</certification-item>
28.
</certification-item>
29.
</certification-model>
30. </asset>
X-ARM
56
X-ARM
57
float e unsigned float. O atributo value pode ter um nico valor discreto, mltiplos valores
discretos ou intervalos de valores numricos. Mltiplos valores discretos so representados
pelos valores discretos separados por vrgula, por exemplo: visa, mastecard, american
express. Para representar um intervalo de valores numricos, deve-se utilizar a seguinte
notao: valor_mnimo..valor_mximo. Por exemplo, o valor 1..10 representa um
intervalo de 1 a 10. Para especificar um intervalo de valor ilimitado utiliza-se o termo *.
Por exemplo, o valor 1..* representa um intervalo de 1 at infinito. No caso do tipo
string, o termo * tambm indica que o item pode possuir qualquer valor. Por fim,
possvel combinar valores discretos, mltiplos valores discretos e intervalos de valores,
como por exemplo: 1..10, 25, 30..40, 50, 60.
A Figura 32 ilustra a especificao de um modelo de negcio. Neste exemplo
definido o modelo de negcio pay-per-copy. Para este tipo de modelo de negcio, as
descries de assets que adotam este modelo devem informar a quantidade de cpias
desejadas (que pode ser um valor entre 1 e 100), o preo unitrio e a moeda utilizada. Para
o modelo pay-per-copy definido ainda que os cartes de crdito que podem ser
especificados para pagamento dos assets so Visa e MasterCard.
1. <asset id=br.compose.ppc-1.0 name=pay-per-copy >
2.
<business-model>
3.
<business-item key="copies" mandatory="true">
4.
<allowed-value value="1..100" value-type="integer"/>
5.
<business-item key="unitary price" mandatory="true">
6.
<allowed-value value="0..*" value-type="unsigned float"/>
7.
</business-item>
8.
<business-item key="currency" mandatory="true">
9.
<allowed-value value="R$" value-type="string"/>
10.
<allowed-value value="US$" value-type="string"/>
11.
</business-item>
12.
</business-item>
13.
<business-item key="credit-card" mandatory="true">
14.
<allowed-value value="Visa, Mastercard" value-type="string"/>
15.
</business-item>
16. </business-model>
X-ARM
58
modelos podem ser desenvolvidos no futuro, ou mesmo, novas caractersticas podem ser
agregadas aos modelos j existentes. Neste sentido, existe a necessidade de que o modelo
de descrio do X-ARM seja genrico a ponto de conseguir representar diferentes modelos
de maneira nica. Alm disso, o modelo de descrio deve suportar a evoluo dos modelos
de componentes e permitir a extrao de informaes referentes a caractersticas
particulares dos mesmos. A extrao de informaes pode ser bastante til para engenhos
de buscas.
Para atender esta necessidade, o X-ARM define uma abordagem onde os modelos
de componentes tm suas caractersticas descritas separadamente em relao s descries
de componentes particulares, sendo realizado com instncias do X-ARM Model Profile.
Desta forma, na descrio de um componente usando o X-ARM Component Profile,
necessrio indicar o modelo de componentes adotado, definido como um asset do tipo
Component Model no X-ARM Model Profile. A utilizao da especificao de um modelo
de componentes em uma descrio de componente ser discutida na apresentao do
X-ARM Component Profile na Seo 3.6.
Conforme indicado na Figura 33, o X-ARM Model Profile define o elemento
<component-model>, cujo propsito permitir a especificao de modelos de
componentes.
X-ARM
59
X-ARM
60
X-ARM
61
X-ARM
62
X-ARM
63
exception addition: Indica a adio de uma exceo para uma operao de uma
interface.
exception removal: Indica a remoo de uma exceo para uma operao de uma
interface.
X-ARM
64
O atributo changed-unit usado para indicar a parte do asset que foi alterada. Por
exemplo, no caso de uma interface cujo atributo type possui o valor operation addition, o
atributo changed-unit pode indicar a operao que foi adicionada verso anterior da
interface, representada pelo elemento <related-asset> associado ao elemento <evolution>.
Conforme j informado na Seo 3.3.5, neste caso, o atributo relationship-type de <relatedasset> tem o valor baseAsset.
3.5.1 Interfaces
No X-ARM Interaction Profile, o elemento <interface> usado para especificar uma
interface, descrevendo as suas operaes, invariantes, pr-condies e ps-condies. O
elemento <interface> permite especificar interfaces independentes e dependentes de
modelo de componente com estruturas bastante similares.
3.5.1.1 Interface Independente (Independent Interface)
A Figura 37 ilustra a estrutura adotada pelo elemento <interface> para especificar uma
interface de forma independente de modelo de componente. Como pode ser observado,
adotando uma abordagem similar a outros elementos, o elemento <interface> pode possuir
uma descrio textual adicional, que pode ser representada usando o elemento
<description>.
X-ARM
65
representadas
pelos
elementos
<pre-condition>
<post-condition>,
X-ARM
66
...
1. <interface>
2. <description> Interface principal de gerenciamento de clientes.<description>
3. <operation name="getCustomerMatching">
4.
<return type="Integer">
5.
<description>Retorna 0 se o cliente foi achado. Retorna 1 se no existe o cliente. Retorna 2 se o cdigo no
foi fornecido e atravs do nome retornou mais de um cliente.</description>
6.
</return>
7.
<parameter name="custD" type="CustomerDetails" direction="out"/>
8.
<parameter name="cusId" type="int" direction="in"/>
9. </operation>
10. <operation name="createCustomer">
11.
<description>Insere um cliente na base de dados.</description>
12.
<return type="Boolean"/>
13.
<parameter name="custD" type="CustomerDetails" direction="in" />
14.
<parameter name="cusId" type="int" direction="out" />
15. </operation>
16. <operation name="getCustomerDetails">
17.
<description>Retorna os dados de um cliente.</description>
18.
<return type="CustomerDetails"/>
19.
<parameter name="cus" type="int" direction="in"/>
20.
<pre-condition language-spec="OCL">
21.
<description> customer->exists(c, c.id = cus) </description>
22.
</pre-condition>
23.
<post-condition language-spec="OCL">
24.
<description> Let theCust = customer->select(c, c.id = cus) in
result.name = theCust.name and
result.postCode = theCust.postCode and
result.email = theCust.email
25.
</description>
26.
</post-condition>
27. </operation>
28. <operation name="notifyCustomer">
29.
<description>Envia uma mensagem de notificao para um cliente.</description>
30.
<return type="void"/>
31.
<parameter name="cus" type="CustId" direction="in"/>
32.
<parameter name="msg" type="String" direction="in"/>
33. </operation>
34. </interface>
...
X-ARM
67
X-ARM
68
3.5.2 Eventos
O mecanismo de eventos permite que dados trafeguem assincronamente entre componentes
[Sun97]. Assim, um componente fonte dispara eventos quando determinadas condies so
alcanadas. Por exemplo, aps uma mudana de estado monitorada, o componente fonte
emite um evento ao componente receptor informando a mudana ocorrida. No X-ARM
Interaction Profile, assume-se que a emisso e a recepo de eventos so realizadas com
interfaces, conforme ilustrado na Figura 40.
A
Fonte
Receptor
Evento
X-ARM
69
como uma estrutura de dados ou um objeto, que contm informaes que descrevem o
evento ou operaes que permitem a manipulao do evento.
No X-ARM Interaction Profile, o elemento <event> usado para especificar um
evento, permitindo descrever as suas informaes e operaes associadas, como tambm,
indicar as interfaces que devem ser providas por componentes fonte e receptor. De forma
similar ao elemento <interface>, o elemento <event> tambm permite especificar eventos
independente e dependente de modelo de componente.
3.5.2.1 Evento Independente (Independent Event)
A Figura 41 ilustra a estrutura adotada pelo elemento <event> para especificar um evento
de forma independente de modelo de componente. Como pode ser observado, adotando
uma abordagem similar a outros elementos, o elemento <event> pode possuir uma
descrio textual adicional, que pode ser representada usando o elemento <description>.
so
indicadas
pelos
elementos
<source-interface>
<sink-interface>,
X-ARM
70
<sink-interface> adotam o elemento <related-asset>, cujo valor do atributo relationshiptype deve ser independentInterface.
Como pode ser observado na Figura 41, os elementos <source-interface> e <sinkinterface> so opcionais, a fim de permitir a representao de eventos que no se baseiem
na existncia de interfaces tanto para a fonte quanto para o receptor de eventos. De acordo
com a figura, podem existir diversas ocorrncias dos elementos <source-interface> e <sinkinterface>. Esta abordagem utilizada para permitir que um mesmo evento possa ser
gerado ou recebido por diferentes interfaces, incrementando o reuso da especificao do
evento. Alm disso, estes elementos podem possuir uma descrio associada, representada
pelo elemento <description>.
Como apresentado na Figura 41, as informaes do evento so representadas como
propriedades usando o elemento <property>. Por outro lado, as operaes do evento so
representadas pelo elemento <operation>.
Em cada propriedade, os atributos name e type do elemento <property> representam
o nome e o tipo de dado associado propriedade. Alm disso, o atributo permission indica
como a propriedade pode ser acessada: somente leitura (read), escrita (write) ou leitura e
escrita (readwrite).
A especificao de operaes de um evento adota uma estrutura similar quela
usada na especificao de operaes de uma interface. No entanto, a especificao de
interfaces inclui os elementos <pre-condition> e <post-condition>, que no so relevantes
no contexto de eventos. Deste modo, os mesmos no devem ser usados na especificao de
operaes de um evento, e, por isso, no so apresentados na Figura 41.
Como ilustrado na Figura 41, os elementos <property>, <operation>, <parameter>
e <return> podem possuir uma descrio associada, representada pelo elemento
<description>.
A Figura 42 apresenta um exemplo de especificao de evento independente de
modelo de componente. Este exemplo descreve um evento que prov a operao
getEmailId. Os componentes fonte e receptor devem implementar as interfaces
br.compose.IReceivedEmailSource-1.0 e br.compose.IReceivedEmailListener-1.0.
X-ARM
71
1. <event>
2. <description>Evento de notificao de recebimento de novo email.</description>
3. <operation name="getEmailId">
4.
<return type="Integer"/>
5. </operation>
6. <source-interface>
7.
<related-asset name="IReceivedEmailSource" id="br.compose.IReceiveEmailSource-1.0"
relationship-type="interface" required="true"/>
8. </source-interface>
9. <sink-interface>
10.
<related-asset name="IReceivedEmailListener" id="br.compose.IReceiveEmailListener-1.0"
relationship-type="interface" required="true"/>
11. </sink-interface>
12. </event>
X-ARM
72
X-ARM
73
que as mesmas j tenham sido especificadas como assets, os produtores devem referencilas no elemento <throws> como assets relacionados, indicados no elemento <relatedasset>. Esta abordagem permite a adoo do X-ARM antes que as excees especficas de
modelos de componentes tenham sido especificadas.
3.5.3 Excees
Excees so geradas quando algo no ocorre como esperado na execuo de uma
operao, permitindo representar informaes sobre o erro ocorrido. Em linguagens de
programao orientadas a objeto, excees so normalmente expressas na forma de objetos.
Assim, excees podem possuir operaes e propriedades. Como vrias interfaces podem
reusar as mesmas excees, a especificao de excees tambm realizada na forma de
assets.
No X-ARM Interaction Profile, o elemento <exception> usado para especificar
uma exceo, permitindo descrever as suas propriedades e operaes associadas. De forma
similar aos elementos <interface> e <event>, o elemento <exception> tambm permite
especificar excees independente e dependente de modelo de componente.
3.5.3.1 Exceo Independente (Independent Exception)
A Figura 44 ilustra a estrutura adotada pelo elemento <exception> para especificar uma
exceo de forma independente de modelo de componente. Como pode ser observado, o
elemento <exception> pode possuir uma descrio textual adicional, representada usando o
elemento <description>.
X-ARM
74
X-ARM
75
X-ARM
76
dependentes
de
modelos
so
representados
com
esteretipo
elementos
principais:
<<dependent>>.
O
X-ARM
Component
Profile
define
dois
X-ARM
77
X-ARM
78
X-ARM
x
79
so:
x
X-ARM
80
Os demais aspectos das representaes dos tipos de assets descritos pelo X-ARM
Component Profile so detalhados nas prximas subsees.
X-ARM
81
Interfaces
Uma especificao de componente pode referenciar um conjunto de interfaces. Para tal, o
X-ARM Component Profile define o elemento <interface>. Este elemento possui os
elementos <provided> e <required>, responsveis por indicar as interfaces providas e
requeridas do componente com elementos <related-asset>. Em ambos os casos, o valor do
atributo relationship-type do elemento <related-asset> independentInterface. Um
exemplo da representao de interfaces em uma especificao independente de modelo
apresentada na Figura 49.
1. <component-specification>
2. <interface>
3.
<required>
4.
<related-asset id="br.ufpb.compose.IEditor-1.0" relationship-type="independentInterface" required="true"/>
5.
</required>
6.
<provided>
7.
<related-asset id="br.ufpb.compose.IMgt-1.0" relationship-type="independentInterface" required="true"/>
8.
<description>Interface de Gerenciamento</description>
9.
</provided>
10.
<provided>
11.
<related-asset id="br.ufpb.compose.ISpell-1.0" relationship-type="independentInterface" required="true"/>
12.
</provided>
13. </interface>
14. </component-specification>
Eventos
Para poder representar os possveis eventos gerados ou recebidos por um componente, o XARM Componente Profile define o elemento <event>, ilustrado na Figura 44. Este elemento
possui outros dois elementos, <sink> e <source>, usados para indicar os eventos (assets do
tipo Independent Event) nos quais a especificao de componente receptor ou fonte,
respectivamente. Para referenciar os eventos, utilizado o elemento <related-asset>, cujo
valor do atributo relationship-type independentEvent. Na Figura 50 exemplificado um
X-ARM
82
1. <component-specification>
2. <event>
3.
<sink>
4.
<related-asset id="br.compose.events.editorAlert-1.0" relationship-type="independentEvent" required="true"/>
5.
</sink>
6.
<source>
7.
<related-asset id="br.compose.events.Email-1.2" relationship-type="independentEvent" required="true"/>
8.
</source>
9.
</event>
10. </component-specification>
Propriedades
Propriedades constituem valores associados a um componente que possibilitam a sua
customizao. Geralmente, a manipulao das propriedades permite a configurao do
estado do componente. Para representar propriedades foi criado o elemento <property>,
ilustrado na Figura 48, que possui trs atributos: name, usado para identificar o nome da
propriedade; type, que identifica o tipo de dado da propriedade; e permission, que indica a
permisso de acesso propriedade, podendo possuir apenas os valores read, write ou
readwrite. A Figura 51 apresenta um exemplo de descrio de propriedades.
1. <component-specification>
2. <property name="username" type="String" permission="readwrite">
3.
<description>Obtm e altera o valor do nome do usurio.</description>
4. </property>
5. </component-specification>
X-ARM
83
X-ARM
84
X-ARM
85
X-ARM
86
27. </asset>
respectivamente.
especificao
de
componente
dependente de modelo exemplificada inclui uma interface requerida e duas providas. Alm
disso, o componente que implementar esta especificao ser receptor do evento
br.compose.ccm.editorAlert-1.0 e fonte do evento br.compose.ccm.Email-1.2.
X-ARM
87
X-ARM
88
X-ARM
89
X-ARM
90
O elemento <nonfunctional-requirements> agrupa uma srie de elementos prdefinidos a fim de padronizar um conjunto de requisitos no funcionais. So definidos seis
elementos pr-definidos: <language>, <OS>, <platform>, <processor>, <disk-size> e
<mem-size>. O elemento <language> usado para indicar a linguagem de programao
utilizada no desenvolvimento do componente. <OS> identifica sistemas operacionais
compatveis com o componente. O elemento <platform> indica plataformas de execuo
que podem ser usadas na execuo do componente. O elemento <processor> usado para
informar o tipo de processador requerido. Por fim, os elementos <disk-size> e <mem-size>
so usados para informar os espaos em disco e em memria requeridos, respectivamente.
No caso dos elementos <disk-size> e <mem-size>, o atributo value indica a quantidade de
memria requerida e o atributo unit indica a unidade na qual esta memria medida, como
por exemplo, Kb, Mb e Gb. Apesar de pr-definir um conjunto de elementos, requisitos
adicionais podem ser especificados atravs do elemento <optional>, cujos atributos key e
value representam o nome e o valor do requisito no funcional especificado. Para ilustrar, a
Figura 56 apresenta uma possvel representao dos requisitos no funcionais de um
componente.
1. <nonfunctional-requirements>
2.
<OS value="Windows" version="XP"/>
3.
<platform value="Windows .NET" version="1.3"/>
4.
<language value="C#"/>
5.
<processor value="0x86"/>
6.
<optional key="video memory" value="32Mb"/>
7. </nonfunctional-requirements>
X-ARM
91
X-ARM
92
93
4 Ferramenta de Descrio e
Empacotamento de Assets
Uma grande quantidade de informaes de assets representada pelo modelo X-ARM. Isto
pode tornar bastante trabalhosa e complicada a tarefa de descrever um asset utilizando
apenas editores de texto ou de documentos XML. A fim de facilitar esta atividade, foi
desenvolvida uma ferramenta denominada X-Packager, que tem a finalidade de gerar
descries de assets na forma de arquivos de manifesto e agrupar estes e os demais
arquivos que compem os assets em pacotes nicos. Assim, este captulo apresenta a
ferramenta X-Packager e um exemplo de sua utilizao, que buscam servir como prova de
conceito e exemplo para emprego do modelo X-ARM.
A ferramenta X-Packager foi construda na forma de um plug-in para a verso 3.1.x
deste ambiente, dadas as facilidades do ambiente Eclipse [Eclipse06]. Dentre estas
facilidades, destaca-se a prpria caracterstica de que plug-ins possam ser incorporados ao
ambiente, de forma que uma variedade de tipos de tarefas possa ser executada, permitindo a
produo de diversos tipos de artefatos.
O X-Packager foi construdo em Java, usando JDK 1.5.0. Para o desenvolvimento
de interfaces grficas, foi utilizado o pacote SWT e para a realizao de tarefas
relacionadas manipulao de dados XML utilizou-se a implementao de Java da API
DOM [W3C04b]. A implementao da ferramenta possui cerca de 41 mil linhas de cdigo,
distribudas em 410 classes e 86 pacotes Java. O espao em disco requerido pela ferramenta
de 1,98 Mb para o cdigo compilado (bytecode) e 2,32 Mb para o cdigo fonte.
94
Quantidade de formulrios
12
Component Implementation
95
96
descrio de assets pode ser uma tarefa relativamente longa, considerada a grande
quantidade de caractersticas representadas pelo X-ARM e considerado que o usurio pode
no possuir algumas informaes quando estiver empacotando um asset. Por exemplo, no
momento do empacotamento, o usurio, que normalmente ser um desenvolvedor, pode
no ter conhecimento de informaes no tcnicas, tais como os modelos de negcios
permitidos para o asset, ou quem estar autorizado a acessar o asset. Assim, a fim de evitar
que informaes j inseridas sejam perdidas, o X-Packager permite que o empacotamento
do asset seja interrompido, fazendo com que o pacote do asset, ou mesmo apenas o
manifesto, seja gerado mesmo antes que todas as informaes tenham sido fornecidas.
Quando as informaes restantes forem conseguidas, o usurio pode acessar novamente a
ferramenta e pedir para carregar um pacote X-ARM ou um manifesto que foi gerado
anteriormente de maneira incompleta. No caso de um pacote, o X-Packager carrega um
arquivo .zip, e no caso de um manifesto, a ferramenta carrega arquivos .xml ou .rmd. Desta
forma, o plug-in apresentar as informaes j preenchidas, permitindo a modificao das
mesmas e a insero das informaes que restavam.
No entanto, depois que o usurio gera um pacote ou manifesto incompleto, ele pode
continuar desenvolvendo seus artefatos e, enquanto isso, arquivos podem ser adicionados
ao seu projeto no Eclipse. Portanto, quando o empacotamento de um asset reiniciado, o
X-Packager destaca os arquivos que foram adicionados ao projeto do Eclipse,
possibilitando que o usurio possa optar por adicionar ou no os novos arquivos ao pacote
do asset. A Figura 58 ilustra o formulrio do plug-in que mostra os arquivos existentes no
projeto do Eclipse.
97
Figura 58: Tela para especificao dos arquivos que compem o asset.
Alm de permitir o carregamento de informaes de manifestos incompletos, o XPackager tambm possibilita que manifestos de outros assets possam ser carregados para
auxiliar a descrio de um asset. Este recurso til para evitar que informaes que se
repetem em vrios assets tenham que ser introduzidas novamente para cada asset. Desta
forma, para a descrio de um asset, todas as informaes do manifesto de um asset j
descrito podem ser carregadas, de forma que seja necessrio alterar apenas aqueles dados
que so diferentes no asset que est sendo empacotado.
98
99
com exceo dos modelos, que foram criados e so apresentados primeiro, dado que so
utilizados por diversos outros assets.
4.2.1 Modelos
No contexto de um sistema de repositrio de componentes, normalmente a descrio do
asset com X-ARM precisa referenciar outros assets, que j precisam estar descritos,
empacotados e registrados no repositrio. Dentre os principais tipos de assets que podem
ser referenciados por outros esto os modelos, representados com o X-ARM Model Profile.
Isto se deve ao fato de que informaes sobre classificao, modelos de negcios,
certificao, modelos de componentes e processos de desenvolvimento precisam referenciar
os assets que descrevem os respectivos modelos utilizados. Portanto, a realizao do
exemplo de uso foi iniciada com a criao dos modelos, que so assets do X-ARM Model
Profile, apresentados na Tabela 3.
Nome do Asset
Tipo do Asset
br.compose.umlcomponents-1.0
Development Process
br.compose.certificationmodel-1.0
Certification Model
br.compose.businessmodel-1.0
Business Model
br.compose.javabeanscomponentmodel-1.0
br.compose.ejbcomponentmodel-1.0
Component Model
br.compose.dotnetcomponentmodel-1.0
br.compose.areas-1.0
Application Areas
100
Identificador do Asset
Business Process
Business Process.uad
br.compose.businessprocess-1.0
Business Concept
Model
br.compose.bcm-1.0
Use Cases
br.compose.usecases-1.0
Tipo
Resource
Tipo de Artefato
Identificador do Asset
Business Type
Model
br.compose.btm-1.0
Business Interfaces
Business Interfaces.ucd
br.compose.businessinterfaces-1.0
System Interfaces
and Opers
System Interfaces.ucd
br.compose.systeminterfaces-1.0
Tipo
Resource
Tipo de Artefato
101
br.compose.initialarchitecture-1.0
102
Identificador do Asset
Tipo
br.compose.businessoperations-1.0
Resource
Tipo de Artefato
BO IMakeReservation.uld
BO ICancelReservation.uld
Business
Operations
BO IUpdateReservation.uld
BO ITakeUpReservation.uld
BO IProcessNoShow.uld
BO IIdentifyReservation.uld
iimakereservation.ucd
br.compose.iimakereservation-1.0
iicancelreservation.ucd
br.compose.iicancelreservation-1.0
iiupdatereservation.ucd
br.compose.iiupdatereservation-1.0
iitakeupreservation.ucd
br.compose.iitakeupreservation-1.0
Independent
Interface
Interfaces and
Opers
103
iiprocessnoshow.ucd
br.compose.iiprocessnoshow-1.0
iidentifyreservation.ucd
br.compose.iidentifyreservation
-1.0
iihospedemgt.ucd
br.compose.iihospedemgt-1.0
iihotelmgt.ucd
br.compose.iihotelmgt-1.0
br.compose.ihotelmgr-1.0
Component Specs
and Architecture
br.compose.ireservationsystem-1.0
Resource
br.compose.architecture-1.0
Ind. Comp.
Spec.
br.compose.icustomermgr-1.0
Arquivos
IIM IMakeReservation.ucd
IIM ICancelReservation.ucd
Identificador do Asset
br.compose.iim-1.0
Tipo
104
IIM IUpdateReservation.ucd
IIM ITakeUpReservation.ucd
Interface
Information
Models
IIM IProcessNoShow.ucd
br.compose.iim-1.0
IIM IIdentifyReservation.ucd
IIM IHospedeMgt.ucd
IIM IHotelMgt.ucd
PrePostConditions.txt
br.compose.prepostconditions-1.0
Component
Interface
Constraints
Component-Interface
Constraints.txt
br.compose.cic-1.0
SDImakeReservation.ucd
br.compose.sdimakereservation-1.0
SDICancelReservation.ucd
br.compose.sdicancelreservation-1.0
SDIupdateReservation.ucd
br.compose.sdiupdatereservation-1.0
SDItakeUpReservation.ucd
br.compose.sditakeupreservation-1.0
SDIprocessNoShow.ucd
br.compose.sdiprocessnoshow-1.0
SDIidentifyReservation.ucd
br.compose.sdiidentifyreservation
-1.0
SDIhospedeMgt.ucd
br.compose.sdihospedemgt-1.0
SDIhotelMgt.ucd
br.compose.sdihotelmgt-1.0
Interface
Specification
Diagrams
Resource
Operation
Pre/postconditions
105
InvalidReservationDetails.java
br.compose.javainvalidreservationdetails1.0
InvalidReservationDetails.cs
br.compose.csinvalidreservationdetails1.0
InvalidRoom.java
br.compose.javainvalidroom-1.0
InvalidRoom.cs
br.compose.csinvalidroom-1.0
InvalidCustomer.java
br.compose.javainvalidcustomer-1.0
InvalidCustomer.cs
br.compose.csinvalidcustomer-1.0
InvalidHotelDetails.java
br.compose.javainvalidhoteldetails-1.0
InvalidHotelDetails.cs
br.compose.csinvalidhoteldetails-1.0
IMakeReservation (.java e
.cs)
br.compose.dimakereservation-1.0
ICancelReservation (.java e
.cs)
br.compose.dicancelreservation-1.0
IUpdateReservation (.java e
.cs)
br.compose.diupdatereservation-1.0
ITakeUpReservation (.java e
.cs)
br.compose.ditakeupreservation-1.0
br.compose.diprocessnoshow-1.0
IIdentifyReservation (.java e
.cs)
br.compose.diidentifyreservation
-1.0
Tipo
Dependent Interface
Components
Identificador do Asset
Dependent Exception
Components
Arquivos
br.compose.dihospedemgt-1.0
br.compose.dihotelmgt-1.0
106
br.compose.djbreservationsystem-1.0
br.compose.dejbreservationsystem-1.0
br.compose.djbcustomermgr-1.0
Nenhum
br.compose.dejbcustomermgr-1.0
br.compose.ddotnetcustomermgr-1.0
br.compose.djbhotelmgr-1.0
br.compose.dejbhotelmgr-1.0
Dependent Component
Specification
br.compose.ddotnetreservationsystem-1.0
br.compose.ddotnethotelmgr-1.0
br.compose.cijbreservationsystem-1.0
br.compose.ciejbreservationsystem-1.0
br.compose.cidotnetreservationsystem-1.0
br.compose.cijbcustomermgr-1.0
CustomerMgr.jar (JavaBeans
e EJB) e CustomerMgr.dll
br.compose.ciejbcustomermgr-1.0
br.compose.cidotnetcustomermgr-1.0
br.compose.cijbhotelmgr-1.0
HotelMgr.jar (JavaBeans e
EJB) e HotelMgr.dll
br.compose.ciejbhotelmgr-1.0
Component Implementation
ReservationSystem.jar
(JavaBeans e EJB) e
ReservationSystem.dll
br.compose.cidotnethotelmgr-1.0
107
108
109
2
1
110
e Component Specification, que tambm podem possuir outras fases aninhadas. O trecho XARM gerado na especificao do processo UML Components apresentado na Figura 62.
1. <asset id="br.compose.umlcomponents-1.0" ...>
2.
<process-model>
3.
<phase name="Requirements" type="workflow">
4.
<output type="Business Process"/>
5.
<output type="Business Concept Model"/>
6.
<output type="Use Cases"/>
7.
<description artifact-id="1"/>
8.
</phase>
9.
<phase name="Specification" type="workflow">
10
<phase name="Component Identification" type="stage">
11
<output type="Business Type Model"/>
12
<output type="Business Interfaces"/>
13.
<output type="System Interfaces and Opers"/>
14.
<output type="Initial Comp Specs and Architecture"/>
15.
</phase>
16.
<phase name="Component Interaction" type="stage">
17.
<output type="Business Operations"/>
18.
<output type="Interfaces and Opers"/>
19.
<output type="Component Specs and Architecture"/>
20.
</phase>
21.
<phase name="Component Specification" type="stage">
22.
<output type="Interface Information Models"/>
23.
<output type="Operation Pre/Postconditions"/>
24.
<output type="Component Interface Constraints"/>
25.
<output type="Interfaces"/>
26.
</phase>
27.
<description>The second workflow defined by UML Components.</description>
28.
</phase>
29.
<phase name="Provisioning" type="workflow">
30.
<output type="Components"/>
31.
</phase>
32.
<phase name="Assembly" type="workflow">
33.
<output type="Applications"/>
34.
</phase>
35.
<phase name="Test" type="workflow">
36.
<output type="Tested applications"/>
37.
</phase>
38.
<phase name="Deployment" type="workflow"/>
39.
</process-model>
...
40. </asset>
111
112
113
114
30. </asset>
115
2
1
116
identificados. Por fim, a Tela 3 apresenta a tela apresentada pelo X-Packager para alterao
de valores permitidos.
A especificao completa do modelo de negcios pay-per-copy gerada pelo XPackager apresentada na Figura 68.
1. <asset id="br.compose.businessmodel-1.0 name=pay-per-copy >
2.
<business-model>
3.
<business-item key="copies" mandatory="true">
4.
<allowed-value value="1..100" value-type="integer"/>
5.
<business-item key="unitary price" mandatory="true">
6.
<allowed-value value="0..*" value-type="unsigned float"/>
7.
</business-item>
8.
<business-item key="currency" mandatory="true">
9.
<allowed-value value="R$" value-type="string"/>
10.
<allowed-value value="US$" value-type="string"/>
11.
</business-item>
12.
</business-item>
13.
<business-item key="credit-card" mandatory="true">
14.
<allowed-value value="Visa, Mastercard" value-type="string"/>
15.
<allowed-value value="American Express" value-type="string"/>
16.
</business-item>
17.
</business-model>
...
18. </asset>
117
118
14. </asset>
119
11. </asset>
120
121
4.3.2.3 Classificao
Parte da especificao da classificao do asset se baseou nas reas de aplicao
especificadas na Seo 4.3.1.2. Outra parte da classificao foi especificada de forma
aleatria, sem considerar um conjunto de reas de aplicao. A Figura 75 ilustra a descrio
completa da classificao.
1. <classification>
2.
<context name=X-ARM Application Areas>
3.
<descriptor-group>
4.
<related-asset name="App Areas" id="br.compose.areas-1.0"
relationship-type="appAreas" required="false"/>
5
<descriptor name="Business.Tourism.Hotels"/>
6.
</descriptor-group>
7.
</context>
8.
<descriptor-group name="Reservation Systems">
9.
<descriptor name="Hotels.Reservations"/>
10. </descriptor-group>
11.</classification>
122
123
124
125
1. <certification-info>
2.
<producer-certification>
3.
<related-asset name="CompSign - Compose" id="br.compose.producercertification-1.0"
relationship-type="producerCertification" required="false"/>
4.
</producer-certification>
5. </certification-info>
certificao
apresentado
na
Seo
4.3.1.3,
identificado
por
126
127
128
129
29. </asset>
130
interface
ReservationCreatedSource,
que
possui
os
mtodos
Fonte
Receptor
ReservationSystem
ReservationCreatedListener
SinkBean
ReservationEvent
131
132
24. </asset>
133
1
2
134
1. <asset id=br.compose.javainvalidreservationdetails-1.0>
2.
<exception>
3.
<operation name="InvalidReservationDetails"/>
4.
<operation name="InvalidReservationDetails">
5.
<parameter name=message type=String direction=in/>
6.
</operation>
7.
<operation name="InvalidReservationDetails">
8.
<parameter name=message type=String direction=in/>
9.
<parameter name=cause type=Throwable direction=in/>
10.
</operation>
11.
<operation name="InvalidReservationDetails">
12.
<parameter name=cause type=Throwable direction=in/>
13.
</operation>
14.
<operation name="InvalidReservationDetails">
15.
<parameter name=message type=String direction=in/>
16.
<parameter name=res type=ReservationDetails direction=in/>
17.
</operation>
18.
<operation name="getReservationDetails">
19.
<return type=ReservationDetails/>
20.
</operation>
21.
<operation name="getCause">
22.
<return type=Throwable/>
23.
</operation>
24.
<operation name="getMessage">
25.
<return type=String/>
26.
</operation>
27.
<operation name="printStackTrace">
28.
<return type=void/>
29.
</operation>
30.
</exception>
31.
<model-dependency>
32.
<related-asset name="JavaBeans Component Model" relationship-type="componentModel"
id="br.compose.javabeanscomponentmodel-1.0" required="false"/>
33.
</model-dependency>
34. </asset>
inclui
duas
novas
operaes,
com
as
seguintes
assinaturas:
135
136
137
1. <asset id=br.compose.djbreservationsystem-1.0>
2.
<component-specification>
3.
<interface>
4.
<required>
5
<related-asset name="ICustomerMgt" id="br.compose.dicustomermgt-1.0"
relationship-type="dependentInterface" required="true"/>
6.
</required>
7.
<required>
8
<related-asset name="IHotelMgt" id="br.compose.dihotelmgt-1.0"
relationship-type="dependentInterface" required="true"/>
9.
</required>
10.
<required>
11.
<related-asset name="IBilling" id="br.compose.dibilling-1.0"
relationship-type="dependentInterface" required="true"/>
12.
</required>
13.
<provided>
14.
<related-asset name="IMakeReservation" id="br.compose.dimakereservation-1.0"
relationship-type="dependentInterface" required="true"/>
15.
</provided>
16.
<provided>
17.
<related-asset name="ICancelReservation"
id="br.compose.dicancelreservation-1.0"
relationship-type="dependentInterface" required="true"/>
18.
</provided>
19.
<provided>
20.
<related-asset name="IUpdateReservation"
id="br.compose.diupdatereservation-1.0"
relationship-type="dependentInterface" required="true"/>
21.
</provided>
22.
<provided>
23.
<related-asset name="ITakeUpReservation"
id="br.compose.ditakeupreservation-1.0"
relationship-type="dependentInterface" required="true"/>
24.
</provided>
25.
<provided>
26.
<related-asset name="IProcessNoShow"
id="br.compose.diprocessnoshow-1.0"
relationship-type="dependentInterface" required="true"/>
27.
</provided>
28.
<provided>
29.
<related-asset name="IIdentifyReservation"
id="br.compose.diidentifyreservation-1.0"
relationship-type="dependentInterface" required="true"/>
30.
</provided>
31.
</interface>
32.
<event>
33.
<source>
34.
<related-asset name="ReservationCreatedEvent"
id="br.compose.dreservationcreatedevent -1.0"
relationship-type="dependentEvent" required="true"/>
35.
</source>
36.
</event>
37.
</component-specification>
38.
<model-dependency>
39.
<related-asset name="JavaBeans Component Model" relationship-type="componentModel"
id="br.compose.javabeanscomponentmodel-1.0" required="false"/>
40.
</model-dependency>
41. </asset>
138
32. </asset>
139
140
Consideraes Finais
141
5 Consideraes Finais
Neste trabalho, foi especificado um modelo de representao de assets, denominado XARM, cuja representao feita em XML, sendo til na indexao, busca e recuperao
padronizadas de assets mantidos em um repositrio. O modelo proposto dividido em
quatro categorias e 18 tipos, permitindo a representao das caractersticas dos diferentes
tipos de assets de maneira apropriada.
Apesar da existncia de outros modelos com objetivos semelhantes, o X-ARM
constitui uma importante contribuio para o DBC, uma vez que supera algumas limitaes
significativas de outros modelos. Exemplos de limitaes superadas so: representao de
diversos modelos de negcios, controle de visibilidade, representao da certificao de
assets, reuso de interfaces e eventos, suporte a diferentes processos de desenvolvimento,
representao de componentes de diversos modelos de componentes existentes atualmente
na indstria (tais como CCM, EJB, .NET e COM) e a representao de componentes de
possveis futuros modelos.
Alm das caractersticas apresentadas, no suportadas por outros modelos de
descrio de assets, outras funcionalidades, herdadas do modelo RAS [RAS05], tambm
esto presentes no modelo, tais como identificao, classificao, informaes sobre uso
dos assets e o prprio empacotamento dos artefatos que compem os assets.
Neste trabalho tambm foi apresentada a ferramenta X-Packager, desenvolvida com
o objetivo de facilitar a descrio e empacotamento de assets conforme o modelo X-ARM.
A necessidade da existncia de uma ferramenta como esta surge da grande quantidade de
caractersticas descritas pelo X-ARM, o que praticamente impossibilita a descrio e
empacotamento dos assets de maneira ad-hoc. A ferramenta foi desenvolvida como um
Consideraes Finais
142
5.1 Contribuies
Alm da variedade de caractersticas descritas pelo modelo X-ARM, apresentadas na seo
anterior, a definio deste modelo seguiu um conjunto de abordagens centradas na
flexibilidade e no reuso de especificaes de assets.
A primeira abordagem introduzida refere-se ao fato do X-ARM adotar o uso de
modelos, o que permite um nmero ilimitado de modelos de negcios e de componentes,
dentre outros. Assim, o modelo X-ARM no restringe a sintaxe e a semntica adotadas na
descrio de determinadas informaes, j que assets podem ser comercializados sob
diferentes modelos de negcios e certificados sob diferentes modelos de certificao, por
exemplo. Ao invs disto, o X-ARM adota uma abordagem em que certas caractersticas so
descritas em pares de chave/valor, bastando apenas que estes pares sigam as especificaes
dos modelos que os assets adotam, descritos com o X-ARM Model Profile. Por exemplo, se
um modelo de negcios cuja especificao com o X-ARM Model Profile diz que o carto de
Consideraes Finais
143
crdito deve ser informado, assets que seguem este modelo devem informar o carto de
crdito que pode ser usado na aquisio do asset, possivelmente especificando o termo
carto de crdito como chave e o nome do carto de crdito como valor.
Ao contrrio do prprio RAS, o modelo X-ARM descreve separadamente as
especificaes e as implementaes de componentes. Assim, torna-se possvel que uma
mesma especificao de componente seja implementada em diferentes linguagens e
modelos de componentes. Esta distino importante no contexto de um repositrio de
componentes, quando um usurio realiza uma busca por uma especificao com
determinadas caractersticas desejadas. A partir da especificao retornada que for mais
adequada, ele escolhe aquelas implementaes que aderem s suas necessidades em termos
de linguagem de programao, de modelo de componentes, de requisitos no funcionais e
da existncia ou no de cdigo fonte e documentao.
Outra abordagem adotada pelo X-ARM trata-se da separao entre as especificaes
de componentes e as interfaces e eventos. Desta forma, quando uma especificao de
componente prov ou requer uma interface, ela precisa indicar o asset referente a esta
interface. O mesmo ocorre quando uma especificao de componente fonte ou receptora
de um evento. Com esta abordagem, habilita-se o reuso de interfaces e eventos por
diferentes especificaes de componentes, evitando que interfaces e eventos tenham que ser
descritos em cada especificao de componentes que os utilizar. Por outro lado, no contexto
de um repositrio, esta abordagem facilita as buscas por especificaes de componentes,
uma vez que se um usurio descobriu as interfaces e eventos desejados, basta procurar as
especificaes de componentes que adotem tais interfaces e eventos.
Por fim, tem-se como importante abordagem introduzida, a distino entre assets
independentes e dependentes de modelos de componentes. Neste caso, assets independentes
de modelos podem ser vistos como assets gerados para atender requisitos funcionais,
enquanto que assets dependentes de modelos de componentes acrescentam caractersticas
particulares, relativas aos modelos seguidos. Assim, esta abordagem tambm auxilia nas
buscas por assets, uma vez que se um usurio encontrou um asset independente de modelo
de componentes que atende seus requisitos, basta encontrar os assets dependentes que
seguem o modelo desejado e que sejam baseados no asset independente que ele encontrou.
Outro aspecto positivo desta abordagem refere-se ao fato de que ela incrementa ainda mais
Consideraes Finais
144
o reuso de descries de assets, j que um asset independente pode dar origem a vrios
assets dependentes de modelos.
Consideraes Finais
145
ferramenta X-Packager pode, por exemplo, utilizar reflexo [Sun98] para extrao de
informaes sobre interfaces, operaes, eventos, excees, dentre outros, tirando proveito
de convenes de codificao [Sun99a] existentes em implementaes dos componentes.
De forma semelhante, tambm existe a possibilidade de que a ferramenta X-Packager seja
integrada a ferramentas de gerao de diagramas UML, tais como diagramas de atividade,
de casos de uso e de classes. Assim, informaes sobre assets que contenham artefatos
referentes a diagramas destes tipos tambm podem ser automaticamente mapeadas para
descries X-ARM.
Referncias
146
6 Referncias
[Atkinson02]
[Benz03]
Benz, Brian; Durant, John R. XML Programming Bible. Wiley Publishing, Inc.,
New York, 2003.
[Berners-Lee94]
RFC1738.
December
1994.
Disponvel
em:
[Barnett02]
[CC06]
[CCM06]
[Cheesman01]
[Chung99]
Chung, Lawrence; Nixon, Brain A.; Yu, Eric; Mylopoulos, John. NonFunctional Requirements in Software Engineering. Springer, 1999.
Referncias
[CompSource05]
147
Component
Source.
http://www.componentsource.com.
Acessado
em
06/05/2005.
[Conradi98]
[DSouza99]
[DeMichiel01]
[Eclipse06]
[Elias06a]
Elias, Gldson; Schuenck, Michael; Negcio, Yuri; Dias Jr., Jorge; Miranda
Filho, Sindolfo. X-ARM: An Asset Representation Model for Component
Repository Systems. Symposium on Applied Computing (SAC2006), Dijon,
France, April 2006.
[Elias06b]
Elias, Gldson; Dias Jr., Jorge; Miranda Filho, Sindolfo; Cavalcanti, Gustavo;
Schuenck, Michael; Negcio, Yuri. Improving Reuse of Off-the-Shelf
Components with Shared, Distributed Component Repository Systems. The 9th
International Conference on Software Reuse (ICSR), Lecture Notes in
Computer Science, Springer-Verlag, Torino, Italy, 2006.
[Frakes05]
Frakes, William. Kang, Kyo. Software Reuse Research: Status and Future.
IEEE Transactions On Software Engineering, Vol.31, N 7, July 2005.
[Frolund98]
[Guimares04]
[GPL91]
[Heineman01]
Referncias
[Hoff97]
148
Hoff, Arthur van; Partovi, Hadi; Thai, Tom. The Open Software Description
Format (OSD). Submission to the World Wide Web Consortium (W3C), 1997.
Disponvel em: http://www.w3.org/TR/NOTE-OSD. Acessado em 21/06/2005.
[Inoue03]
Makoto;
Kusumoto,
Shinji.
Component
Rank:
Relative
[ISO05]
[ISO05b]
Disponvel
em:
http://www.oasis-open.org/cover/iso639a.html.
[McIlroy69]
[Moffat97]
Moffat, A.; Bell, T. C.; Witten, I. H. Lossless compression for text and images.
International Journal of High Speed Electronics and Systems 8 (1), pp. 179231, 1997.
[Nutter03]
[Omondo06]
Referncias
[Orso00]
149
Orso, A., Harrold, M. J., and Rosenblum, D. S. Component Metadata for
Software Engineering Tasks. In Proc. 2nd International Workshop on
Engineering Distributed Objects (EDO 2000), pp. 126-140, Springer, Berlin,
2000.
[OMG01]
[Pharoah01a]
[Pyarali00]
Object
International
Computing
Symposium
on
Middleware.
Proceedings,
IEEE/IFIP
Object-Oriented
Real-Time
Distributed
Reusable
Asset
Specification.
2005.
Disponvel
em:
[Ribot94]
Ribot, Denielle; Bongard, Blandine; Villermain, Claude. Development lifecycle WITH reuse. In: Proceedings of the 1994 ACM Symposium on Applied
Computing, Phoenix, Arizoa, United States, 1994.
[Sametinger97]
[Schuenck05]
Schuenck, Michael; Tanure, Carla; Dias Jr., Jos Jorge L.; Miranda, Sindolfo;
Negcio, Yuri; Elias, Gldson. Anlise de Repositrios de Componentes para a
Identificao das Solues mais Adotadas. Workshop de Desenvolvimento
Baseado em Componentes (WDBC2005), pp. 9-26, Juiz de Fora, Brasil,
Novembro de 2005.
Referncias
[Schuenck06]
150
Schuenck, Michael; Negcio, Yuri; Elias, Gldson; Miranda Filho, Sindolfo;
Dias Jr., Jorge; Cavalcanti, Gustavo. X-ARM: A Step Towards Reuse of
Commercial and Open Source Components. The 9th International Conference
on Software Reuse (ICSR), Lecture Notes in Computer Science, SpringerVerlag, Torino, Italy, 2006.
[Seacord98]
Seacord, Robert C.; Hissam, Scott A.; Wallnau, Kurt C. Agora: A Search
Engine for Software Components. CMU/SEI-98-TR-011, 1998.
[SourceForge06]
[Sun97]
Sun Microsystems, Inc. JavaBeans API Specification. Version 1.01. July 1997.
[Sun98]
Sun
Microsystems,
Inc.
Using
Java
Reflection.
Disponvel
em:
Revised
April
20,
1999.
Disponvel
em:
Szyperski,
Clemens.
Component
Software:
Beyond
Object-Oriented
[W3C04a]
[W3C04b]
World Wide Web Consortium (W3C). Document Object Model (DOM) Level 3
Core Specification. Disponvel em: http://www.w3.org/TR/2004/REC-DOMLevel-3-Core-20040407/. Acessado em: 07/06/2006.
[Wallnau04]
[Wohlin94]