Embed Size (px)
Citation preview
Andre Luiz Peron Martins Lanna
Reuso de Processos de Software baseado na
componentizacao de Processos e
Conhecimento
Belo Horizonte
Dezembro de 2009
Andre Luiz Peron Martins Lanna
Reuso de Processos de Software baseado na
componentizacao de Processos e
Conhecimento
Dissertacao de mestrado apresentada comorequisito parcial para a obtencao do tıtulode mestre em Engenharia Eletrica
Orientador:
Carlos Alberto Marques Pietrobon
Pontifıcia Universidade Catolica de Minas GeraisPrograma de Pos-Graduacao em Engenharia Eletrica
Belo Horizonte
Dezembro de 2009
FICHA CATALOGRÁFICA Elaborada pela Biblioteca da Pontifícia Universidade Católica de Minas Gerais
Lanna, André Luiz Peron Martins L292r Reúso de processos de software baseado na componentização de processos e
conhecimento. / André Luiz Peron Martins Lanna. Belo Horizonte, 2009. 107f. : il. Orientador: Carlos Alberto Marques Pietrobon Dissertação (Mestrado) – Pontifícia Universidade Católica de Minas Gerais. Programa de Pós-Graduação em Engenharia Elétrica. 1. Software – Reutilização. 2. Software – Desenvolvimento. 3. Dispositivos
eletromecânicos. I. Pietrobon, Carlos Alberto Marques. II. Pontifícia Universidade Católica de Minas Gerais. Programa de Pós-Graduação em Engenharia Elétrica. III. Título.
CDU:681.3.06
Andre Luiz Peron Martins Lanna
Reuso de Processos de Software baseado na componentizacao de Processos
e Conhecimento
Dissertacao de Mestrado apresentada no Programa de Pos-graduacao em Engenharia
Eletrica, da Pontifıcia Universidade Catolica de Minas Gerais, como parte dos requisitos
para obtencao do grau de Mestre em Engenharia Eletrica. Belo Horizonte, 17 de dezembro
de 2009.
Prof. Dr. Carlos Alberto Marques Pietrobon – PUCMinas
Orientador
Prof. Dr. Carlos Augusto Paiva da Silva Martins –PUC Minas
Prof. Dr. Ricardo de Almeida Falbo – UFES
Aos meus pais Maria Celia e Carlos,
e a todos os familiares que estiveram comigo
nesta caminhada.
Agradecimentos
– Ao meu orientador, professor Dr. Carlos Alberto Marques Pietrobon, pelo profis-
sionalismo com o qual conduziu esta pesquisa e pelas orientacoes, conselhos e conversas
nos momentos de ansiedade e incertezas.
– Aos professores do PPGEE pelas boas discussoes e conhecimentos transmitidos em
sala de aula e nos corredores do PPGEE.
– Aos meus pais por sempre estarem presentes, acreditando, incentivando e dando
todo o suporte para que pudesse chegar ao termo desta jornada. A voces meu muito
obrigado!
– Aos amigos de Ouro Preto sobretudo Ricardo Duarte, com quem aprendi a ter gosto
pela pesquisa e pela sala de aula.
– Aos novos amigos de Guanhaes pelas conversas semanais sempre produtivas e en-
gracadas. Muito obrigado a Dorirley, Joao Paulo e Roberto.
– Aos amigos do PPGEE, pelo companheirismo no tempo em que estivemos juntos.
– Aos irmaos, cunhadas, tias, tios e demais familiares pela torcida e incentivo.
– Aos meus amigos por entenderem o meu afastamento, sobretudo nos ultimos dias.
Sem eles tenho certeza que teria sido muito mais difıcil.
Resumo
Atualmente as organizacoes desenvolvedoras de software tem se preocupado com a
qualidade de seus produtos disponibilizados ao mercado. Dentre as diversas abordagens
de melhorias destacam-se o reuso de software e os processos de software. Atraves do reuso
e possıvel atingir nıveis mais elevados de qualidade a medida que pedacos de software vao
sendo desenvolvidos, implantados, avaliados e melhorados, de modo que em uma futura
reutilizacao um novo software se beneficiara destas alteracoes. O aumento da qualidade
do produto tambem pode ser obtido por meio de melhorias em seu processo de desenvol-
vimento, devido a estreita relacao entre processos e produto, de modo que processos com
qualidade tendem a gerar produtos com qualidade. Outro fator de impacto na qualidade
e o nıvel de conhecimento organizacional acerca do processo. Contudo acredita-se que, se
tais abordagens forem consideradas de modo conjunto, os resultados obtidos podem ser
ainda maiores. Este trabalho assemelha-se ao Desenvolvimento Baseado em Componente
tradicional e propoe a definicao de processos de software por meio da reutilizacao de pro-
cessos ja conhecidos, executados, avaliados e melhorados pela organizacao. Inicialmente
foi definida uma estrutura reutilizavel, denominada componente de processo, capaz de
representar pedacos de processos de software e armazenar o conhecimento adquirido em
suas execucoes passadas. Este trabalho tambem apresenta um metodo atraves do qual
tais componentes de processo sao compostos, de modo a definir novos processos de soft-
ware. Este metodo contempla a busca de componentes no repositorio, a qualificacao e a
adaptacao atraves das caracterısticas e do conhecimento inerente aos processos. Por fim,
foi proposta uma ferramenta capaz de automatizar a busca, qualificacao e adaptacao de
componentes de processo.
Palavras-chave: reuso de software, componentes de software, processos de software,
qualidade de software, reuso de processos de software, componentes de processos de soft-
ware.
Abstract
Currently, software development organizations have been concerned with the quality
of its products available to the market. Among the various approaches for improvement
software reuse and software processes are included. Through the reuse it is possible to
achieve higher levels of quality, as pieces of software are developed, implemented, evalua-
ted and improved, so that in a future, new software will benefit from these changes. The
increase in product quality can also be obtained through improvements in their develop-
ment process due to the close relationship between process and product so that quality
processes tend to generate high-quality products. Another factor of impact on quality
is the level of organizational knowledge about the process. However, it is believed that,
if such approaches are considered jointly, the results may be even greater. This work is
similar to component-based development and proposes the definition of software processes
through the reuse of known, performed, assessed and improved processes by the organi-
zation. Initially it was defined a reusable structure, called process component, capable of
representing pieces of software processes and that stores the knowledge acquired in their
past executions. This work also presents a method by which such process components are
composed in order to define new software processes. This approach involves the search for
components in the repository, the qualification and adaptation through the characteristics
and inherent knowledge of the processes. Finally it was proposed a tool to automate the
search, qualification and adaptation of process components.
Keywords: software reuse, software components, software processes, software qua-
lity, software process reuse, software process components.
Lista de Figuras
1 Ciclo de melhoria de processos . . . . . . . . . . . . . . . . . . . . . . . p. 19
2 Nıveis de processo de software . . . . . . . . . . . . . . . . . . . . . . . p. 20
3 Representacao do CMMI por estagios. . . . . . . . . . . . . . . . . . . p. 23
4 Representacao contınua do CMMI. . . . . . . . . . . . . . . . . . . . . p. 24
5 Construcao do modelo MPS.Br. . . . . . . . . . . . . . . . . . . . . . . p. 25
6 Estrutura do MPS.Br. . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
7 Estrutura de nıveis de maturidade . . . . . . . . . . . . . . . . . . . . . p. 26
8 Diferenca entre conteudo de metodos e processos em SPEM. . . . . . . p. 28
9 Elementos basicos do SPEM para representacao de processos. . . . . . p. 29
10 Espiral de criacao de conhecimento . . . . . . . . . . . . . . . . . . . . p. 33
11 Relacao entre conceitos e instancias de ontologias. . . . . . . . . . . . . p. 36
12 Modelo de visualizacao de processos simplificado. . . . . . . . . . . . . p. 37
13 Panorama de reuso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41
14 Modelo de desenvolvimento baseado em componentes . . . . . . . . . . p. 42
15 Elementos de um modelo de componentes. . . . . . . . . . . . . . . . . p. 43
16 Associacao de componentes por meio de interfaces . . . . . . . . . . . . p. 45
17 Processo de desenvolvimento “com” reuso. . . . . . . . . . . . . . . . . p. 48
18 Modelo de processos proposto. . . . . . . . . . . . . . . . . . . . . . . . p. 55
19 Modelo da proposta DPBC. . . . . . . . . . . . . . . . . . . . . . . . . p. 56
20 Representacao de um processo por meio de diagrama de componentes da
UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 63
21 Estrutura XML para especificacao de interfaces de componentes de pro-
cesso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 65
22 Especificacao da interface de um componente de processo . . . . . . . . p. 65
23 Descricao dos aspectos e conhecimento de um processo. . . . . . . . . . p. 69
24 Trecho de codigo em RDF para definicao de metadados. . . . . . . . . . p. 70
25 Descricao de processos de software por meio de tags OWL. . . . . . . . p. 72
26 Proposta de descricao de processos de software . . . . . . . . . . . . . . p. 72
27 Algoritmo para insercao do componente de processo no repositorio . . . p. 74
28 Definicao de processos “com” reuso de componentes. . . . . . . . . . . p. 75
29 Diagrama de atividades para a etapa de busca de componentes. . . . . p. 79
30 Diagrama de atividades para a etapa de qualificacao de componentes . p. 82
31 Adaptacao de componentes de processo por ontologias. . . . . . . . . . p. 83
32 Adaptacao de componentes de processo por componentes adaptadores. p. 84
33 Fase de adaptacao de processos . . . . . . . . . . . . . . . . . . . . . . p. 85
34 Implantacao de componentes de processo. . . . . . . . . . . . . . . . . . p. 86
35 Modelagem de domınio da ferramenta DPBC. . . . . . . . . . . . . . . p. 92
36 Busca de componente no repositorio por metadados atraves da ferramenta. p. 94
37 Informacoes do componente atraves da ferramenta. . . . . . . . . . . . p. 95
38 Qualificacao e classificacao de componentes atraves da ferramenta. . . . p. 96
39 Adaptacao de componentes atraves da ferramenta. . . . . . . . . . . . p. 97
Lista de Tabelas
1 Nıveis de maturidade, processos e atributos de processos do MPS.Br . . p. 27
2 Relacao entre as abordagens DBC e DPBC . . . . . . . . . . . . . . . . p. 58
3 Metadados de componentes de processo de software. . . . . . . . . . . . p. 67
Sumario
1 Introducao p. 13
1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14
1.3 Metodologia do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15
1.4 Organizacao da dissertacao . . . . . . . . . . . . . . . . . . . . . . . . . p. 16
2 Processos de software e Gerencia de Conhecimento p. 17
2.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17
2.2 Processos de software . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
2.2.1 Nıveis de processos de software . . . . . . . . . . . . . . . . . . p. 20
2.2.2 Modelos de melhoria de processos . . . . . . . . . . . . . . . . p. 21
2.2.2.1 CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
2.2.2.2 MPS.Br . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24
2.2.3 SPEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
2.3 Gerencia de conhecimento . . . . . . . . . . . . . . . . . . . . . . . . . p. 31
2.3.1 Conhecimento Tacito e Explıcito . . . . . . . . . . . . . . . . . p. 32
2.3.2 Gerencia de conhecimento . . . . . . . . . . . . . . . . . . . . . p. 33
2.3.3 Ontologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34
2.3.4 Projeto Discovery . . . . . . . . . . . . . . . . . . . . . . . . . p. 36
2.4 Consideracoes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 38
3 Reuso de software p. 40
3.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 40
3.2 Desenvolvimento baseado em componentes . . . . . . . . . . . . . . . . p. 41
3.3 Componente de software . . . . . . . . . . . . . . . . . . . . . . . . . . p. 43
3.3.1 Descricao de componente de software . . . . . . . . . . . . . . . p. 45
3.4 Desenvolvimento para reuso . . . . . . . . . . . . . . . . . . . . . . . . p. 46
3.5 Desenvolvimento com reuso . . . . . . . . . . . . . . . . . . . . . . . . p. 47
3.5.1 Busca de componentes . . . . . . . . . . . . . . . . . . . . . . . p. 48
3.5.2 Qualificacao de componentes . . . . . . . . . . . . . . . . . . . p. 49
3.5.3 Adaptacao de componentes . . . . . . . . . . . . . . . . . . . . p. 49
3.5.4 Implantacao de componentes . . . . . . . . . . . . . . . . . . . p. 50
3.5.5 Atualizacao de componentes . . . . . . . . . . . . . . . . . . . p. 51
3.6 Consideracoes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52
4 Uma Abordagem de Reuso de processos de software p. 53
4.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53
4.2 Modelo de processo de software . . . . . . . . . . . . . . . . . . . . . . p. 54
4.3 Definicao de Processos de Software Baseado em Componentes (DPBC) p. 56
4.4 Componente de processo de software . . . . . . . . . . . . . . . . . . . p. 58
4.4.1 Estrutura de componentes de processos de software . . . . . . . p. 59
4.4.2 Formatos de representacao de um componente de processo de
software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 62
4.4.3 Interfaces de componentes de processos de software . . . . . . . p. 64
4.4.4 Descricao de um componente de processo de software . . . . . . p. 65
4.4.4.1 Descricao do componente de processo por metadados . p. 66
4.4.4.2 Descricao do processo por aspectos e conhecimento atraves
de ontologia . . . . . . . . . . . . . . . . . . . . . . . . p. 68
4.4.4.3 Resumo sobre a descricao de componentes de processo
e processo para a proposta . . . . . . . . . . . . . . . . p. 69
4.5 Definicao de componentes de processo para reuso de processos . . . . . p. 71
4.6 Definicao de processos com reuso de componentes de processo . . . . . p. 74
4.6.1 Busca de componentes . . . . . . . . . . . . . . . . . . . . . . . p. 75
4.6.1.1 Matching de especificacoes de componentes . . . . . . p. 76
4.6.2 Qualificacao de componentes . . . . . . . . . . . . . . . . . . . p. 80
4.6.3 Adaptacao de componentes . . . . . . . . . . . . . . . . . . . . p. 82
4.6.4 Implantacao de componentes . . . . . . . . . . . . . . . . . . . p. 84
4.6.5 Atualizacao de componentes . . . . . . . . . . . . . . . . . . . p. 87
4.7 Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 87
4.8 Consideracoes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 89
5 Ferramenta p. 91
5.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 91
5.2 Busca de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 94
5.3 Qualificacao de componentes . . . . . . . . . . . . . . . . . . . . . . . p. 95
5.4 Adaptacao de componentes . . . . . . . . . . . . . . . . . . . . . . . . p. 96
5.5 Consideracoes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 98
6 Conclusoes p. 99
6.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 99
6.2 Conclusao e contribuicoes . . . . . . . . . . . . . . . . . . . . . . . . . p. 99
6.3 Perspectivas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 101
Referencias p. 103
13
1 Introducao
1.1 Motivacao
As organizacoes desenvolvedoras de software tem procurado atingir nıveis maiores de
qualidade de seus produtos para que se mantenham competitivas no mercado em que
atuam. Varias abordagens de melhoria sao utilizadas por tais empresas, dentre as quais
se destacam o reuso de software e a melhoria dos processos de software.
Dentre as tecnicas de reuso de software, destaca-se o “desenvolvimento baseado em
componentes (DBC)”. Neste caso o aumento da qualidade ocorre como consequencia da
reutilizacao de componentes mais estaveis quando comparados com os produtos originados
do desenvolvimento a “partir do zero”. Um indıcio de qualidade de um componente e o
numero de vezes que ele foi reutilizado: quanto maior for este numero, possivelmente maior
sera seu nıvel de qualidade. Ademais o DBC traz como vantagens as reducoes do tempo
e custo de desenvolvimento do produto, sendo este ultimo decorrente da amortizacao dos
investimentos realizados para a criacao dos componentes reutilizaveis.
Em se tratando de processos de software advoga-se que processos com qualidade ten-
dem a gerar produtos com qualidade(SOMMERVILLE, 2007). Assim, investir em processos
e uma maneira de garantir a melhoria do produto de software. Entretanto, processos sao
intrinsecamente complexos devido as diversas caracterısticas que devem abordar. Alem
de definir os aspectos tecnicos (ex.: a ordem em que as atividades devem ser executadas,
os artefatos produzidos e utilizados em sua execucao, ferramentas, dentre tantos outros),
um processo de software deve ainda considerar os aspectos organizacionais e humanos do
ambiente em que sera executado. Definir um processo que seja capaz de harmonizar todos
estes aspectos nao e uma tarefa simples e geralmente e realizada por uma pessoa de maior
capacidade. Utilizar processos que ja funcionaram e conhecimento gerado por eles pode
ajudar nesta atividade.
Outra caracterıstica importante acerca de processos e o fato destes serem dotados de
14
muito conhecimento. Quanto mais as pessoas conhecem o processo com o qual estao en-
volvidas, menores sao as chances destas introduzirem falhas em sua execucao, favorecendo
a qualidade do produto gerado. Portanto, nao e indicado que este conhecimento se faca
presente apenas na mente dos envolvidos no processo, pois deste modo pode-se perder
valioso conhecimento quando algum indivıduo se desvincula da organizacao. E necessario
que se estabeleca algum modo de armazenamento e disseminacao de conhecimento adqui-
rido ao longo do tempo, o que representaria uma memoria organizacional. Essa memoria
permitira ainda a descentralizacao de responsabilidades entre os membros da organizacao
a medida que pessoas menos capacitadas vao adquirindo conhecimento.
De fato as duas tecnicas apresentadas anteriormente contribuem para o aumento da
qualidade dos produtos de software apesar de serem abordagens bem distintas. Pode-se
dizer que o DBC propoe a melhoria dos produtos de um modo mais direto, pois suas acoes
sao realizadas diretamente sobre o produto em desenvolvimento. Por outro lado o aumento
da qualidade atraves de processos de software ocorre de modo indireto, uma vez que as
acoes realizadas sobre o processo de desenvolvimento terao efeitos no produto de software
resultante. Contudo, estas abordagens, na pratica, sao realizadas de modo independente
sendo que, se realizadas de forma conjunta, poderao potencializar os resultados obtidos
por cada abordagem separadamente (LUCREDIO et al., 2008).
O reuso de componentes esta mais avancado quando comparado ao reuso de processos,
no que tange a pratica e a pesquisa. Neste trabalho aborda-se o reuso de processos, espe-
rando que as vantagens apresentadas na pratica do reuso de software se facam presentes
no contexto de processos, e que o metodo de reuso de processos apresentado neste texto
contribua com pesquisas na area de reuso de processos.
1.2 Objetivos
O objetivo deste trabalho e definir uma nova abordagem baseada nos conceitos de
DBC, para realizar a definicao de novos processos de software atraves da reutilizacao de
processos ja executados e conhecidos. Portanto processos de software deverao ser repre-
sentados atraves de uma estrutura reutilizavel denominada “componente de processo de
software”. Tal componente devera ser capaz de representar os aspectos tecnicos, orga-
nizacionais e humanos de um processo de software, alem de armazenar o conhecimento
adquirido ao longo de suas execucoes passadas. Alem disto, o tamanho de um compo-
nente de processo devera ser variavel, de modo a contemplar os diversos nıveis de expres-
15
sabilidade de um processo, quais sejam (em ordem decrescente de tamanho): processos,
atividades ou tarefas. Por fim, e necessario que tanto o processo de software representado
pelo componente quanto o proprio componente de processo sejam descritos de modo a
facilitar sua futura reutilizacao. Deste modo foram estabelecidas algumas estruturas de
descricao voltadas para o processo e para o componente de processo, alem da criacao de
um repositorio onde tais componentes serao armazenados.
Este trabalho tambem propoe um metodo capaz de realizar a definicao de novos pro-
cessos de software atraves da reutilizacao de componentes de processo. Este metodo devera
ser capaz de satisfazer aos requisitos do processo em definicao a partir da composicao dos
diversos componentes recuperados do repositorio. Para isto e necessario definir como a
busca no repositorio sera realizada levando em consideracao os aspectos de um processo
e o conhecimento agregado a ele, estabelecer mecanismos capazes de informar o quanto
um componente de processo atende aos requisitos do novo processo em definicao, realizar
adaptacoes sobre os componentes de processo de modo que eles possam ser compostos
para formarem o novo processo, alem da implantacao do novo processo no ambiente de
execucao.
Tambem e objetivo deste trabalho desenvolver uma ferramenta que implemente o
metodo proposto para a definicao de processos de software. Essa ferramenta devera rea-
lizar a busca de componentes no repositorio, permitir a selecao dos componentes (dentre
aqueles recuperados) que melhor atendam aos requisitos do processo em definicao, identi-
ficar as inconsistencias entre os componentes selecionados e propor alteracoes de modo a
torna-los compatıveis com as novas necessidades e, por fim, agrupa-los de modo a definir
o novo processo de software.
1.3 Metodologia do trabalho
Este trabalho iniciou-se com a realizacao do levantamento bibliografico acerca dos
temas principais, a saber: processos de software, Engenharia de Conhecimento e reuso
de software. Estes levantamentos foram realizados atraves de revisoes sistematicas nas
principais bibliotecas digitais da area. Como existem diversas propostas para reuso de
software, apos analise do material obtido pela primeira revisao sistematica, optou-se por
escolher o DBC como tecnica de reuso a ser abordada nesta proposta. Por isto fez-
se necessario uma nova revisao sistematica, para que pudesse ser recuperado material
relevante sobre esta tecnica de reuso.
16
Com base nas referencias obtidas pelas revisoes, estabeleceu-se o modelo de reuso
de processos a partir de componentes. No primeiro momento o componente de processo
foi definido de modo que sua estrutura fosse capaz de representar todos os aspectos de
um processo de software (em todos os seus nıveis – processo, atividade ou tarefa) e que
fosse capaz de armazenar o conhecimento. Posteriormente foi estabelecida a definicao de
processos com reuso para esta proposta. Ela foi definida a partir de analogias realizadas
sobre o desenvolvimento com reuso estabelecido pelo DBC, de modo que as adaptacoes
sugeridas foram necessarias para contemplar as caracterısticas inerentes aos processos de
software e representadas pelos componentes de processo (aspectos e conhecimento). A
partir de entao, foi realizado o desenvolvimento da ferramenta que implementa o modelo
de reuso de processos proposto.
Antes de iniciar a escrita deste documento, tomou-se o cuidado de realizar novamente
as revisoes sistematicas definidas no inıcio do trabalho, como forma de buscar a atualizacao
desta proposta. Nao foram encontradas novidades significativas que pudessem invalidar
a proposta de reuso, iniciando-se entao a escrita deste documento.
1.4 Organizacao da dissertacao
O capıtulo 1 apresenta a motivacao, os objetivos, a metodologia e a organizacao
desta dissertacao. O capıtulo 2 apresenta dois dos principais temas desta proposta que
estao fortemente relacionados: processos de software e gerencia de conhecimento. O
capıtulo 3 apresenta o desenvolvimento baseado em componentes (DBC), enfatizando
seus principais conceitos. O capıtulo 4 apresenta inicialmente o modelo de processos de
software definido por esta proposta, onde sao descritos os aspectos de um processo de
software e os tipos de conhecimento que este pode armazenar. A partir de entao, atraves
de uma abordagem top-down, inicialmente e mostrada uma macro-visao da proposta de
reuso de processos e posteriormente sao apresentados os detalhes de cada um dos ıtens
que a compoem. Ao final deste capıtulo encontra-se tambem uma comparacao com outras
propostas de reuso de processos de software encontradas na literatura. No capıtulo 5 e
apresentada a ferramenta desenvolvida como suporte ao metodo proposto. Por fim, o
capıtulo 6 apresenta as conclusoes deste texto, as contribuicoes desta proposta bem como
os trabalhos futuros.
17
2 Processos de software eGerencia de Conhecimento
2.1 Introducao
A qualidade de um produto de software nao e obtida somente atraves de melhorias
realizadas sobre o produto em desenvolvimento, por meio da utilizacao das melhores fer-
ramentas, linguagens, dentre outros. Desde os anos 80 pesquisadores tem reconhecido a
qualidade do produto de software como sendo consequencia de seu processo de desenvolvi-
mento. Portanto, ha uma relacao estreita entre processo e produto de software, de modo
que processos com qualidade tendem a gerar produtos com qualidade.
Entretanto um processo de software e inerentemente complexo devido as diversas
caracterısticas que ele aborda. Ao definir um novo processo de software, e necessario
levar em consideracao os diversos aspectos do ambiente em que sera implantado, tais como
tecnologias empregadas, papeis desempenhados pelos membros da organizacao, restricoes
aplicadas ao processo, dentre tantos outros. Deste modo nao e aconselhavel a definicao
de processos a partir do zero para cada projeto de uma organizacao.
Outro fator de possıvel impacto na qualidade de um produto e o conhecimento or-
ganizacional, principalmente o conhecimento referente ao processo de desenvolvimento
do software. A medida que os membros de uma organizacao aumentam o conhecimento
acerca dos processos executados para construcao de um software, menores sao as chances
de introduzir falhas na execucao desses processos.
Este capıtulo apresenta os conceitos relativos a dois dos principais temas deste tra-
balho e que possuem impacto na qualidade do produto de software: processos de software
e gerencia de conhecimento. Na secao 2.2 sao apresentados os processos de software, dois
dos principais modelos de melhoria de processos existentes na atualidade e um metamo-
delo para definicao de processos de software, denominado SPEM. A secao 2.3 apresenta
os temas relativos a gerencia de conhecimento, quais sejam: definicao de conhecimento,
18
gerencia de conhecimento e ontologias. Nesta secao ainda e apresentado o projeto Disco-
very, do qual este trabalho faz parte. Esse projeto se caracteriza pela utilizacao de formas
de visualizacao aplicadas ao conhecimento relativo a processos de software. Por fim, na
secao 2.4 sao apresentadas as conclusoes deste capıtulo.
2.2 Processos de software
Na literatura sao encontradas varias definicoes para processos de software. Dentre
elas, tres sao de particular interesse para este trabalho. Segundo Fuggetta (2000), um
processo de software pode ser definido como o conjunto coerente de polıticas, estruturas
organizacionais, tecnologias, procedimentos e artefatos necessarios para conceber, desen-
volver, implantar e manter um produto de software.
Para Sommerville (2007), um processo de software e um conjunto de atividades que
leva a producao de um software. Para o autor, os processos de software sao intelectuais
e criativos (ao contrario dos processos produtivos tradicionais) e por este motivo depen-
dem do julgamento humano. Esforcos tem sido realizados para auxiliar os envolvidos na
execucao de um processo de software, principalmente atraves de ferramentas de auxılio
(denominadas ferramentas CASE - computer-aided sofware engineering). Entretanto a
eficiencia de tais esforcos esbarram na diversidade de processos de software, pois cada
organizacao estabelece sua abordagem especıfica para desenvolvimento de software. Nao
ha um processo ideal, de modo que cada organizacao deve definir seu processo levando
em conta suas capacidades e as caracterısticas do software em desenvolvimento. O autor
finaliza dizendo que processos de software podem ser aprimorados atraves de alguma pa-
dronizacao, pois alem de reduzir a diversidade de processos existentes em uma organizacao,
ela ainda promove o aprimoramento da comunicacao e reduz o tempo de treinamento dos
envolvidos.
Por fim, a terceira definicao considerada foi estabelecida por Pressman (2006). Ele
afirma que a elaboracao de software e um processo iterativo de aprendizagem e o resultado
e uma integracao de conhecimentos coletados, destilados e organizados, a medida que
o processo e conduzido. Um processo de software define a abordagem que e adotada
quando o software e elaborado e pode ser visto como uma estrutura de tarefas necessarias
a construcao de software. O autor ainda afirma que os elementos que constituem um
processo de software (tais como ferramentas, metodos e tecnicas) devem se adaptar ao
produto a ser construıdo e as demandas do mercado.
19
Figura 1: Ciclo de melhoria de processos. Adaptado de (SOMMERVILLE, 2007).
E importante notar que todas as tres definicoes nao consideram os processos de soft-
ware apenas sob o aspecto tecnico. A definicao de Fuggetta considera processos de software
tambem sob os aspectos organizacionais. Os aspectos humanos sao enfatizados por Som-
merville, demostrando que um processo de software e uma atividade intelectual e criativa,
o que difere do desenvolvimento de produtos tradicionais. Por fim, Pressman considera o
processo de software como um processo de contınuo aprendizado pela organizacao. Por-
tanto, um processo de software deve ser visto como sendo o conjunto de aspectos tecnicos,
organizacionais, humanos e de conhecimento.
Ainda segundo Sommerville (2007), a estreita relacao entre processos e produtos tem
levado organizacoes a melhorarem seus processos de desenvolvimento como maneira de
aumentar a qualidade de seus produtos. Geralmente esta melhoria e realizada atraves de
tres etapas, iniciando-se pela medicao do processo, atividade que busca mensurar os atri-
butos do projeto ou produto. Posteriormente e realizada a analise do processo, onde sao
identificados os pontos fracos do processo e estabelecidas as propostas de melhorias. Por
fim e realizada a mudanca de processo, atividade responsavel por implantar no processo
as mudancas sugeridas. Contudo, a melhoria de processos de software deve ser uma ati-
vidade cıclica e constante em uma organizacao, de modo a buscar continuamente pontos
fracos do processo, propor e implantar melhorias. Este ciclo esta representado na figura
1.
O interesse pelos processos de software fez surgir modelos de maturidade de processo,
tais como o CMMI (SEI, 2006) e o MPS.Br (SOFTEX, 2009a), sendo este ultimo voltado
para a realidade brasileira. Cada um dos modelos citados determina seu modo de melhoria
contınua de processo, mas ambos estao de acordo com o ciclo apresentado na figura 1.
20
Figura 2: Nıveis de processo de software. Adaptado de (ROCHA; MALDONADO; WEBER,2001) apud (BERTOLLO; SEGRINI; FALBO, 2006)
2.2.1 Nıveis de processos de software
Um processo de software deve ser bem definido de modo a indicar as atividades a
serem executadas, os recursos requeridos, os artefatos consumidos e produzidos e os pro-
cedimentos a serem adotados (metodos, tecnicas, modelos de documentos, dentre outros).
No entanto esta nao e uma tarefa simples, pois processos de software devem ser definidos
caso a caso, considerando caracterısticas especıficas do projeto em questao, tais como
domınio de aplicacao, equipe de desenvolvimento, tecnologia a ser usada e restricoes de
custos e prazos(BERTOLLO; SEGRINI; FALBO, 2006).
No entanto e possıvel estabelecer um conjunto de ativos de processo organizacionais
que pode ser usado na definicao de processos de software para projetos especıficos. Esses
ativos de processo de software sao usualmente organizados em um processo padrao orga-
nizacional. Desse modo a definicao de processos de software pode ser feita em diferentes
nıveis de abstracao. Primeiro, um processo de software padrao e definido para a orga-
nizacao. Baseado nesse processo organizacional, processos padrao especializados podem
ser definidos considerando paradigma, tecnologia ou domınio de aplicacao especıficos.
Finalmente, processos de projeto podem ser instanciados a partir de processos padrao
(especializados ou nao). Portanto e necessaria uma abordagem flexıvel e configuravel
para a definicao de processos, de modo a facilitar a adaptacao de processos as necessi-
dades especıficas de cada projeto (ROCHA; MALDONADO; WEBER, 2001) apud (BERTOLLO;
SEGRINI; FALBO, 2006). Tal abordagem esta representada pela figura 2.
Interessante notar que nesta abordagem o processo padrao e responsavel por acomodar
21
todos os tipos de iniciativas de desenvolvimento em uma organizacao de modo que atenda
as necessidades de todos os projetos, contudo sem fornecer apoio especıfico as atividades
individuais do projeto. No nıvel intermediario, o processo padrao da organizacao pode
ser especializado para considerar algumas classes de tipos de software, paradigmas ou
domınios de aplicacao atraves da adicao e/ou modificacao de ativos de processos. Por
ultimo, o processo padrao especializado mais indicado pode ser instanciado para um
projeto especıfico. Durante a instanciacao do processo de projeto, particularidades desse
projeto e caracterısticas da equipe devem ser levadas em conta. Nesse momento, o modelo
de ciclo de vida deve ser definido e novas atividades, assim como artefatos consumidos
e produzidos, recursos requeridos e procedimentos podem ser adicionados (BERTOLLO;
SEGRINI; FALBO, 2006).
2.2.2 Modelos de melhoria de processos
Nao existe um processo ideal que seja capaz de atender qualquer organizacao de-
senvolvedora de software, pois cada uma deve considerar seus aspectos particulares. No
entanto, segundo Schwartz (1975) apud Soares (2008), as principais fases de um processo
de desenvolvimento de software tıpico sao a especificacao de requisitos, o projeto de sis-
tema, a codificacao e o teste e integracao. Ao contrario do que possa parecer, nao existe
uma sequencia obrigatoria nessas fases, pois na pratica elas acontecem de modo interativo
e cıclico(REIS, 2001).
Neste contexto surgem as normas e os modelos de melhoria de processos de software.
Tais normas e modelos nao determinam um processo de desenvolvimento de software para
ser seguido a risca. Do contrario, apenas especificam estruturas a serem adotadas pela
organizacao na definicao de seus processos. Fica entao a cargo das proprias organizacoes
a definicao dos processos que irao compor tais estruturas.
A norma ISO/IEC 12207:2008 estabelece uma arquitetura comum para o ciclo de
vida de processos de software com uma terminologia bem definida. Contem processos,
atividades e tarefas a serem aplicadas durante o fornecimento, aquisicao, desenvolvimento,
operacao, manutencao e descarte de produtos de software, bem como partes de software
de um sistema. A norma tambem se aplica a aquisicao de sistemas, produtos de software
e servicos(SOFTEX, 2009a). Portanto essa norma esta intimamente relacionada ao modo
como o processo de desenvolvimento de software sera definido.
A norma ISO/IEC 15504 trata de avaliacoes de processos de software com vistas a
melhoria de processos e a determinacao da capacidade de processos de uma organizacao.
22
Caso o objetivo seja a melhoria de processos, a organizacao pode realizar uma avaliacao
para a elaboracao de um plano de melhorias. A analise dos resultados identifica os pontos
fortes, os pontos fracos e os riscos inerentes aos processos. No caso de avaliacao com o
intuito de determinar a capacidade de seus processos, a organizacao tem o objetivo de
avaliar um fornecedor em potencial, obtendo o seu perfil de capacidade. O perfil de capa-
cidade permite ao contratante estimar o risco associado a contratacao daquele fornecedor
em potencial para auxiliar na tomada de decisao de contrata-lo ou nao (SOFTEX, 2009a).
Em se tratando de modelo de maturidade, Khoshgoftar e Osman (2009) afirmam que
seu proposito e prover uma estrutura para melhoria dos resultados atraves da analise dos
pontos fortes e fracos de uma organizacao na gerencia de seus projetos. Isto permite a
comparacao com outras organizacoes e uma medida de correlacao entre o nıvel de gerencia
de projetos da organizacao e a performance dos projetos atuais. Ainda de acordo com os
autores as organizacoes utilizam tais modelos com base em suas metas e objetivos, pois
os modelos de maturidade diferem uns dos outros pelas suas caracterısticas e propositos.
Atualmente existem varios modelos de maturidade. Dentre os modelos existentes
destacam-se o CMMI e o MPS.Br, sendo este ultimo voltado para o mercado brasileiro.
Na realidade ambos possuem muitas similaridades e sao detalhados a seguir.
2.2.2.1 CMMI
Em 1995, o Software Engineering Institute (SEI) criou um modelo de maturidade e
capacidade para organizacoes de software, o SW-CMM. O SW-CMM baseou-se em algu-
mas ideias importantes da qualidade industrial, mas por ser especıfico a area de software,
nao contemplava outras areas da empresa, tais como recursos humanos e financas. Com
o sucesso do SW-CMM, novos modelos foram propostos para cobrir as areas faltantes,
tais como a gestao de recursos humanos (P-CMM), de aquisicao de software (CA-CMM)
e de engenharia de sistemas (SE-CMM). Devido ao fato desses modelos apresentarem
seus proprios formatos, estruturas e termos, havia dificuldades na utilizacao deles em
um mesmo ambiente. Foi entao projetado o CMMI, um novo modelo de capacitacao de
processos estabelecido como uma extensao do SW-CMM, capaz de integrar os modelos
adicionais e permitir futuras extensoes.
O proposito do CMMI e prover orientacao para melhorar os processos de uma orga-
nizacao e sua habilidade para gerenciar o desenvolvimento, aquisicao e manutencao de
produtos e servicos(KOSCIANSKI; SOARES, 2007). Ha duas formas de representacao: por
estagios (baseada na maturidade da organizacao) e contınua (baseada na capacidade do
23
processo), de modo que as organizacoes podem optar por qual forma de representacao
melhor se adapta ao seu contexto.
O CMMI e estruturado em termos de areas de processo (Process Area - PA), que
consistem em praticas relacionadas que coletivamente satisfazem um conjunto de objeti-
vos. Um objetivo generico descreve a institucionalizacao requerida para atingir um nıvel
de capacidade (representacao contınua) ou de maturidade (representacao por estagio).
Cada objetivo generico e associado a um conjunto de praticas genericas que descrevem
atividades requeridas para a institucionalizacao de processos em uma determinada area de
processo. Cada area de processo contem, ainda, objetivos especıficos e praticas especıficas,
que descrevem atividades essenciais no atendimento aos objetivos especıficos(BERTOLLO,
2006; CURTIS; PHILLIPS; WESZKA, 2002).
Figura 3: Representacao do CMMI por estagios. Adaptado de (KOSCIANSKI; SOARES,2007)
Na representacao por estagios, as melhorias sao medidas em cinco nıveis de matu-
ridade, representados na figura 3. Esta forma de representacao prescreve a ordem para
implementacao de cada area de processo de acordo com os nıveis de maturidade, definindo,
assim, um caminho de melhoria para uma organizacao do nıvel inicial para o nıvel otimi-
zado. Atingindo um nıvel de maturidade, garante-se uma base adequada para buscar o
proximo estagio(RASSA; GARBER; ETTER, 2002; BERTOLLO, 2006; KOSCIANSKI; SOARES,
2007). Importante destacar que nesta forma de representacao, quando uma organizacao
atinge um determinado nıvel, ela deve praticar todos os requisitos dos nıveis anteriores.
Portanto, em uma organizacao de maior maturidade, o conjunto de processos organiza-
cionais, tomados como um todo, e de maior capacidade do que em uma organizacao de
menor maturidade.
A representacao contınua e baseada na capacidade dos processos, isto e, pelo al-
cance dos resultados esperados que podem ser atingidos ao se adotar o processo. Essa
representacao prove flexibilidade para organizacoes escolherem quais processos serao en-
24
fatizados ao realizarem melhorias, bem como o quanto tais processos serao melhorados. A
representacao contınua permite a selecao da ordem de melhoria de processos que melhor
atende aos objetivos da organizacao. Isto permite que uma organizacao possua areas de
processos implantadas em diferentes nıveis de capacidade, conforme mostra a figura 4. Os
nıveis de capacidade sao usados para medir uma area, indo de um processo nao executado
para um processo otimizado.
Figura 4: Representacao contınua do CMMI. Adaptado de (SOMMERVILLE, 2007)
As duas representacoes contem os mesmos componentes, usando os mesmos conceitos.
A diferenca entre as representacoes esta na abordagem para melhoria de processos. Se
uma organizacao planeja atingir uma maturidade organizacional, deve selecionar a repre-
sentacao por estagios. Se uma organizacao tem interesse na capacidade de um processo
especıfico, deve selecionar a representacao contınua(BERTOLLO, 2006).
2.2.2.2 MPS.Br
O MPS.Br e um modelo de processo de software voltado para atender ao mercado
brasileiro, principalmente as micro e pequenas empresas que querem implantar melhorias
em seus processos e nao dispoem de muitos recursos para faze-lo. Ele vem sendo desen-
volvido e mantido desde 2003 pelo governo brasileiro, pela Associacao para Promocao da
Excelencia do Software Brasileiro (SOFTEX) e por universidades ligadas ao modelo.
A base tecnica para a construcao e aprimoramento deste modelo de melhoria e ava-
liacao de processo de software e composta pelas normas ISO/IEC 12207:2008 e ISO/IEC
15504. Alem dessas normas, o modelo foi definido em conformidade com o CMMI. De-
vido a utilizacao de normas reconhecidas internacionalmente, espera-se que o modelo MPS
25
Figura 5: Construcao do modelo MPS.Br. Adaptado de (KOSCIANSKI; SOARES, 2007)
seja compatıvel com os padroes de qualidade aceitos internacionalmente e que se bene-
ficie de toda a competencia existente nos padroes e modelos de melhoria de processo ja
disponıveis(SOFTEX, 2009a). A construcao deste modelo pode ser representada por meio
da figura 5.
Figura 6: Estrutura do MPS.Br. Adaptado de (SOFTEX, 2009a)
O MPS.Br e composto por tres modelos. O modelo de referencia (MR-MPS) e res-
ponsavel por definir os nıveis maturidade atraves da combinacao de processos e da ca-
pacitacao1 de processos(SOFTEX, 2009a). Esse modelo tambem estabelece uma docu-
mentacao complementar para empresas que pretendem realizar a aquisicao de software
ou servicos(SOFTEX, 2009b). O modelo de avaliacao (MA-MPS) contem o processo de
avaliacao, os requisitos para os avaliadores e os requisitos para averiguacao da conformi-
dade ao modelo MR-MPS(SOFTEX, 2009c). O modelo de negocios (MN-MPS) contem a
descricao das regras de implementacao do MR-MPS pelas empresas de consultoria, de soft-
ware e de avaliacao(KOSCIANSKI; SOARES, 2007). Cada um desses modelos que compoem
o MPS e descrito por meio de guias ou documentacoes, conforme mostra a figura 6.
1Uma caracterizacao da habilidade do processo atingir aos objetivos de negocio atuais ou futuros.
26
Figura 7: Estrutura de nıveis de maturidade. Adaptado de (KOSCIANSKI; SOARES, 2007).
O modelo de referencia MR-MPS define sete nıveis de maturidade, onde cada nıvel e
uma combinacao de processo com capacitacao de processo, conforme mostra a figura 7. A
escala de maturidade se inicia no nıvel G e progride ate o nıvel A, de modo a possibilitar
uma implementacao e avaliacao adequada as micros, pequenas e medias empresas, alem
de permitir visualizar os resultados de melhoria em prazos mais curtos. Para cada um
desses sete nıveis de maturidade e atribuıdo um conjunto de processos que indica onde a
organizacao deve colocar o esforco de melhoria(SOFTEX, 2009a).
O modelo MPS-Br estabelece 19 processos dividos entre os sete nıveis. Cada processo
do MPS.Br e descrito em termos de seus propositos (objetivos a serem atingidos com
sua execucao) e os resultados esperados. Esses resultados devem ser evidenciados por
artefatos produzidos ou mudancas significativas ao se executar o processo.
A capacidade do processo expressa o grau de refinamento e institucionalizacao com
que o processo e executado na organizacao, de modo que, a medida em que a organizacao
evolui, um maior nıvel de capacidade deve ser atingido. A capacidade do processo e ex-
pressa em termos de atributos de processo (AP) e o atendimento aos resultados esperados
dos atributos de processo (RAP). Todos os processos de um mesmo nıvel devem atender
aos AP’s daquele nıvel, sendo que eles sao acumulativos. Deste modo, nıveis de capa-
citacao mais altos devem atender aos AP’s de seus nıveis inferiores. Abaixo se encontram
os atributos de processo do MPS.Br.
• AP 1.1 – O processo e executado.
• AP 2.1 – O processo e gerenciado.
• AP 2.2 – Os produtos de trabalho do processo sao gerenciados.
• AP 3.1 – O processo e definido.
27
Nıvel Processos Atributos de ProcessoA - Em otimizacao AP 1.1, AP 2.1, AP 2.2, AP
3.1, AP 3.2, AP 4.1, AP 4.2,AP 5.1 e AP 5.2
B - Gerenciado Quantitativamente Gerencia de Projetos - GPR (evolucao) AP 1.1, AP 2.1, AP 2.2, AP3.1, AP 3.2, AP 4.1 e AP 4.2
C - DefinidoGerencia de Riscos - GRI AP 1.1, AP 2.1, AP 2.2, AP 3.1Desenvolvimento para reutilizacao -DRU
e AP 3.2
Gerencia de Decisoes - GDE
D - Largamente definido
Verificacao - VER AP 1.1, AP 2.1, AP 2.2, AP 3.1Validacao - VAL e AP 3.2Projeto e Construcao do Produto -PCPIntegracao do Produto - ITPDesenvolvimento de Requisitos - DRE
E - Parcialmente definido
Gerencia de projetos - GPR (evolucao) AP 1.1, AP 2.1, AP 2.2, AP 3.1Gerencia de Reutilizacao - GRU e AP 3.2Gerencia de Recursos Humanos - GRHDefinicao do Processo Organizacional -DFPAvaliacao e Melhoria do Processo Or-ganizacional - AMP
F - Gerenciado
Medicao - MED AP 1.1, AP 2.1 e AP 2.2Garantia da Qualidade - GQAGerencia de Portfolio de Projetos -GPPGerencia de Configuracao - GCOAquisicao - AQU
G - Parcialmente gerenciadoGerencia de Requisitos - GRE AP 1.1 e AP 2.1Gerencia de Projetos - GPR
Tabela 1: Nıveis de maturidade e processos do MPS.Br. Adaptado de (SOFTEX, 2009a)
• AP 3.2 – O processo esta implementado.
• AP 4.1 – O processo e medido.
• AP 4.2 – O processo e controlado.
• AP 5.1 – O processo e objeto de melhorias e inovacoes.
• AP 5.2 – O processo e otimizado continuamente.
A tabela 1 apresenta os sete nıveis de maturidade do MPS.Br, os processos que os
constituem e os atributos de processo estabelecidos para cada nıvel.
Note que nao ha processos especıficos para o nıvel A, pois ele e composto dos processos
dos nıveis de maturidade anteriores (G ao B). Neste caso a diferenca ocorre apenas nos
atributos de processo que devem ser atendidos por todos os processos pela organizacao
neste nıvel.
2.2.3 SPEM
Um modelo de processo estabelece um conjunto de itens por meio do qual e possıvel
descrever um processo de software. Geralmente um modelo e expresso em uma linguagem
28
de modelagem de processo (do ingles Process Modelling Language - PML). Uma variedade
de propostas tem sido apresentadas para modelar processos de software(FIORINI, 2001).
Dentre elas destaca-se o metamodelo SPEM.
O SPEM e um metamodelo de processo mantido pelo consorcio W3C(OMG, 2008).
Por meio dele e possıvel representar processos de software, de modo a definir quais sao os
papeis desempenhados pelos membros da organizacao no processo de software, os artefatos
gerados e consumidos pelo processo, alem do proprio processo de software e suas atividades
e tarefas. O intuito do consorcio W3C e transformar o SPEM em um padrao para descricao
de processos de software, o que permitiria que processos fossem executados em qualquer
ambiente que o adote.
Este metamodelo permite que processos de software sejam representados de duas
formas:
• Conteudo de metodos (Method Contents): descreve a estrutura dos processos, as
atividades que o compoem, os artefatos produzidos e consumidos de modo indepen-
dente do ciclo de vida de desenvolvimento. Nesta forma de representacao e possıvel
ainda definir os objetivos a serem atingidos pelo processo representado.
• Processos (Processes): a partir da reutilizacao dos conteudos de metodos, sao de-
finidas as sequencias nas quais os elementos do processo sao dispostos, de modo a
estabelecer o ciclo de vida de desenvolvimento. Normalmente isto e realizado para
cada projeto.
Figura 8: Diferenca entre conteudo de metodos e processos em SPEM. Adaptado de (OMG,2008)
Como exemplo pode-se citar o OpenUP2. Os processos que compoem o OpenUP
2OpenUP e um processo enxuto, baseado no Processo Unificado, elaborado com uma filosofia agil e
29
(tambem conhecidos como disciplinas) sao representados por conteudos de metodos em
SPEM, pois sao independentes do ciclo de vida. Entretanto, no momento em que um
projeto adota o OpenUP como processo de desenvolvimento, e necessario estabelecer o
ciclo de vida do processo, momento este em que serao definidos o numero de iteracoes
do processo, a ordem com que as atividades serao executadas, dentre outros. Esta re-
presentacao sera realizada por meio de processos descritos em SPEM. Este cenario esta
representado na figura 8.
Figura 9: Elementos basicos do SPEM para representacao de processos. Adaptado de(OMG, 2008)
Cada uma das formas citadas anteriormente possui alguns elementos utilizados para
a representacao de processos. Esses elementos estao apresentados na figura 9 e, dentre
eles, convem destacar:
• Artefato de software (work product definition): e o elemento que e utilizado, modi-
ficado e produzido por tarefas do processo de software.
• Papel (role definition): e o elemento que define um conjunto de habilidades rela-
cionadas, competencias e responsabilidades. Esse elemento serve para relacionar
tarefas do processo a membros da organizacao.
• Tarefa (task definition): e o elemento que define o trabalho a ser realizado por
algum papel do processo. Ele esta associado a artefatos de processo de entrada e
saıda, sendo que os artefatos de entrada podem ser classificados como obrigatorios
ou opcionais.
focado na natureza colaborativa do desenvolvimento de software.
30
• Atividade (activity): e o elemento que agrupa uma serie de outros elementos des-
critos pelo SPEM, dentre eles outras atividades (de modo a formar sub-atividades),
tarefas e papeis.
• Processo (process): elemento que define todo o processo de software. E composto
por um conjunto de atividades.
• Guia (guidance): e o elemento que prove informacoes adicionais relacionadas aos
outros elementos que formam o processo. Podem ser classificados em alguns tipos,
tais como: orientacoes, templates, checklists, ferramentas de suporte, estimativas,
materiais de suporte, relatorios, conceitos, dentre outros.
E importante salientar o papel que os guias possuem no SPEM. Guias sao elementos
relacionados a conhecimento acerca do processo e podem ocorrer de diversas formas.
Portanto, o metamodelo considera a importancia do conhecimento sobre processos de
software, tanto na representacao de conteudos de metodos quanto na representacao de
processos. Deste modo os guias sao ferramentas de apoio para a definicao de processos
de software (quando ainda estao relacionados a elementos que formam o conteudo de
metodo) e para a execucao do processo, quando estao ligados a elementos que formam o
processo (OMG, 2008).
Ambientes de Desenvolvimento de Software Orientados ao Processo (ou PSEE’s –
Process-Centered Software Engineering Environments) constituem um tipo especial de
ambientes de desenvolvimento de software. O objetivo desses ambientes e apoiar a de-
finicao de processos de software e automatizar a gerencia do desenvolvimento. Tais am-
bientes geralmente proveem servicos para analise, simulacao, execucao e reutilizacao das
definicoes de processos, de modo a buscar a melhoria contınua de processos. Portanto
o papel de um PSEE e auxiliar na interpretacao e execucao dos modelos de processos
descritos atraves de PMLs, de modo a coordenar as atividades realizadas por pessoas e
por ferramentas (FIORINI, 2001; REIS, 2002).
Atualmente o ambiente EPF (Eclipse Process Framework) tem sido amplamente uti-
lizado pelas organizacoes, por permitir a descricao de processos de software atraves de
paginas HTML, bem como a propria execucao dos processos. Alem disto e uma ferra-
menta completamente aderente ao SPEM, de modo que basta um processo ser represen-
tado atraves do metamodelo, que ele podera ser executado pelo EPF(HAUMER, 2007a;
HAUMER, 2007b). Isto e de fundamental importancia, pois vai de encontro ao tema deste
trabalho: reuso de processos de software.
31
2.3 Gerencia de conhecimento
A gerencia de conhecimento e um tema que tem sido amplamente discutido por di-
versas linhas de pesquisas academicas e, por isto, sofre diversas influencias (ALMEIDA,
2006). As discussoes sao baseadas em diversos pontos de vista e perspectivas e abrangem
desde questoes filosoficas ate questoes empiricistas e interacionalistas(ALAVI; LEIDNER,
1999) apud (MONTONI, 2003). Portanto, antes de avancar no tema Gerencia de Conheci-
mento e necessario estabelecer os termos dado, conhecimento e informacao que nortearao
o restante da discussao.
De acordo com Almeida (2006), dados sao simples fatos e estao fora da mente de uma
pessoa. A partir do momento em que um contexto relevante para um indivıduo incorpora-
se aos dados, surgem entao as informacoes. Para Laudon (1996) dado e materia prima
para pesquisa e informacao e dado que se transformou pela inclusao de significado dentro
de um contexto, uma colecao de dados que podem ser entendidos. Coadic (2003) afirma
que a informacao e um conhecimento inscrito (gravado) sob a forma escrita (impressa ou
numerica), oral ou audiovisual, se comportando, assim, como um elemento de sentido. De
acordo com Oliveira (2006), informacao significa fabricacao, formacao e concepcao.
Em se tratanto de conhecimento, Almeida (2006) afirma que e aquilo o que o in-
divıduo sabe e envolve processos mentais, compreensao, aprendizado. Rochester (1996)
advoga que dados sao transformados em informacao, informacoes sao transformadas em
conhecimento e conhecimentos sao transformados em inteligencia.
Por fim, Barroso e Gomes (2007) afirmam que a informacao pode representar conhe-
cimento, mas apenas isto, de modo que o conhecimento e resultado de um processo que
combina o saber acumulado e a informacao adquirida. Portanto o conhecimento e de
natureza dinamica ja que o contexto muda rapidamente.
De fato, conforme afirma Almeida (2006), nao ha definicoes muito claras para os ter-
mos dado, conhecimento e informacao. Considerando-os conforme a visao da computacao,
percebe-se que esta area se resume a defini-los conforme sua forma de representacao e ar-
mazenamento.
Setzer (1999) define bem as diferencas entre esses conceitos. Para o autor, dado e uma
sequencia de sımbolos quantificados ou quantificaveis. Mesmo se incompreensıvel para o
leitor, qualquer texto constitui um dado ou uma sequencia de dados. Sendo quantificados
ou quantificaveis, eles podem ser armazenados em um computador e processados por ele.
32
Informacao e uma abstracao informal que esta na mente de alguem, representando
algo significativo para essa pessoa. Informacao pode ser recebida por meio de sua repre-
sentacao simbolica como dados, figuras, sons, etc. Uma distincao fundamental entre dado
e informacao e que o primeiro e puramente sintatico e a segunda contem semantica.
Conhecimento e caracterizado como uma abstracao interior, pessoal, de algo que foi
experimentado ou vivenciado por alguem. O conhecimento esta no ambito subjetivo do
homem. Enquanto a informacao esta associada a semantica, o conhecimento esta asso-
ciado com a pragmatica, algo que existe no mundo real e do qual se tem uma experiencia
direta.
Sendo assim, representa-se o conhecimento atraves de informacoes, utilizando concei-
tos relacionados a sımbolos e palavras. Por sua vez, as informacoes sao representadas por
meio de dados. Deste modo, tanto o conhecimento quanto a informacao sao representados
atraves de dados, que so farao algum sentido quando forem vistos e interpretados.
Davenport e Prusak (1998) definem conhecimento como um conjunto de experiencias,
valores, informacoes contextuais e insights de especialistas que proveem uma forma para
avaliar e incorporar experiencias e informacao; e originado e se aplica na mente das
pessoas; nas organizacoes, geralmente, encontra-se espalhado nao so em documentos ou
repositorios, mas tambem nas rotinas organizacionais, processos, praticas e normas.
Numeros e fatos que nao tem significado proprio sao considerados dados. A associacao
de um determinado contexto a um conjunto de dados adiciona um significado aos dados
e transforma-os em uma informacao (COOK, 2000). Informacoes permitem interpretar
eventos ou objetos de diferentes formas. Conhecimento, entao, compreende o conjunto
de informacoes cujas interpretacoes podem ser aplicadas em decisoes e acoes (ALAVI;
LEIDNER, 1999).
2.3.1 Conhecimento Tacito e Explıcito
Em se tratando de conhecimento, este pode ocorrer de duas maneiras: conhecimento
tacito e conhecimento explıcito. O conhecimento tacito esta relacionado a modelos men-
tais, crencas e perspectivas dos indivıduos, nao e facil expressa-lo, de difıcil articulacao e
sua documentacao em papeis e arquivos e complicada (NONAKA; TAKEUCHI, 1997).
O conhecimento explıcito e o conhecimento codificado e que pode ser armazenado,
memorizado, transacionado, reutilizado, reproduzido e comercializado. Isto o transforma
em um objeto com caracterısticas bem definidas(LEMOS, 1999). Portanto e necessario que
33
Figura 10: Espiral de criacao de conhecimento. Adaptado de (NONAKA; TAKEUCHI, 1997)
haja mecanismos que facilitem sua recuperacao e gerenciamento.
Archibugi e Lundvall (2002) apresentam a relacao entre conhecimento tacito e explıcito
ao dizer que o conhecimento explıcito refere-se ao conhecimento que pode ser transformado
em uma mensagem, podendo ser manipulado como uma informacao. Ja o conhecimento
tacito nao pode ser explicitado formalmente ou ser facilmente transferido, pois refere-se
aos conhecimentos implıcitos. Para a transmissao deste conhecimento e necessario que
haja algum tipo de interacao social.
Nonaka e Takeuchi (1997) tratam a criacao de conhecimento como um processo inter-
ativo entre o racional e o empırico, entre a mente e o corpo e entre o implıcito e o explıcito.
Tambem defendem que o principal conhecimento e o tacito. Para isto os autores definiram
um ciclo de criacao de conhecimento, apresentado na figura 10. Os processos de conversao
de conhecimento sao a socializacao, exteriorizacao, combinacao e internalizacao.
Lemos (1999) alerta para os limites inerentes ao processo de codificacao do conheci-
mento. Nao se deve supor que todo conhecimento tacito pode ser codificado e que os dois
tipos de conhecimento podem ser tratados de forma substitutiva e excludente. Por isto
nao basta a conversao de um tipo de conhecimento para o outro, mas tambem deve-se
buscar a transformacao de conhecimento tacito para tacito e de explıcito para explıcito.
2.3.2 Gerencia de conhecimento
Nota-se que os conhecimentos envolvidos na geracao de inovacoes podem ser tanto
explıcitos quanto tacitos, publicos ou privados e vem se tornando cada vez mais inter-
relacionados. A informacao e o conhecimento codificados podem ser facilmente disse-
minados, mas o conhecimento que permanecer apenas tacito, so e transferido se houver
interacao social, sendo que esta se da de forma localizada e em organizacoes e locais
especıficos. No entanto, o conhecimento sobre novos processos deve estar presente em
34
diferentes nıveis organizacionais(BJORSON, 2007).
Para entender a formacao do conhecimento, deve-se levar em consideracao as especifi-
cidades das relacoes estabelecidas dentro das organizacoes e entre diferentes organizacoes,
as relacoes industriais em nıveis local, nacional e regional, alem de outros fatores insti-
tucionais, que contribuem para a compreensao das diferencas nas formas de aquisicao de
conhecimento (LEMOS, 1999).
A gerencia de conhecimento age como um metodo que simplifica o processo de com-
partilhar, distribuir, criar, capturar e entender o conhecimento de uma empresa. Um
grande desafio da gestao do conhecimento e criar mecanismos que possibilitem a re-
presentacao eficiente do conhecimento tacito. Enormes esforcos vem sendo realizados
para tornar novos conhecimentos apropriaveis e para estimular a interacao entre os dife-
rentes agentes economicos e sociais para sua difusao e consequente geracao de inovacoes.
Portanto, o conhecimento e a base fundamental e o aprendizado interativo e a melhor
forma para indivıduos, empresas, regioes e paıses estarem aptos a enfrentar mudancas em
curso, intensificarem as inovacoes e se capacitarem para uma insercao mais positiva nesta
fase. O processo de inovacao e interativo, realizado com a contribuicao de varios agentes
economicos e sociais que possuem diferentes tipos de informacoes e conhecimentos. Esta
interacao se da em diversos nıveis, entre diversos departamentos de uma mesma empresa
ou entre empresas distintas (LEMOS, 1999).
Ideias do campo da gerencia de conhecimento sao uteis para os esforcos em melho-
rias de processos. Em Bjorson (2007) encontra-se um estudo da aplicacao de tecnicas e
metodos para captura e disseminacao de conhecimento relativos a processos de software,
de modo a buscar atingir nıveis mais altos de qualidade. Em Borges e Falbo (2001) e
apresentada uma ferramenta para apoiar a disseminacao do conhecimento. A ferramenta
trabalha com a estruturacao do conhecimento, a partir das licoes aprendidas na realizacao
do projeto. As licoes aprendidas abrangem determinados objetos, tais como: atividade,
artefato, procedimento. A ideia dos autores e apoiar a adaptacao do processo de desen-
volvimento, a partir de um processo padrao e das experiencias adquiridas com as licoes
aprendidas.
2.3.3 Ontologia
O termo ontologia tem origem no grego ontos = ser e logos = estudo. Esse termo
foi apresentado originalmente pela Filosofia com o objetivo de estudo do ser nas variadas
ciencias naturais. Quem lhe deu a origem foi a palavra categoria, utilizada para designar
35
o ato de classificar e caracterizar alguma coisa. Outras definicoes para o termo surgiram
ao longo do tempo. Utilizado desde o inıcio dos anos 90 pela Ciencia da Computacao e
pela Ciencia da Informacao, ele vem sendo considerado em pesquisas para representacao
de conhecimento em Inteligencia Artificial (ALMEIDA, 2006).
Varias definicoes tem sido propostas pela Ciencia da Computacao e pela Ciencia da In-
formacao. A definicao mais utilizada foi proposta por Gruber (1993) e trata uma ontologia
como sendo uma especificacao formal e explıcita de uma conceituacao compartilhada, de
modo que o conhecimento de um domınio e representado por um formalismo declarativo,
o conjunto de objetos e as relacoes entre eles. Assim pode-se estabelecer uma ontolo-
gia de uma area ao definir um conjunto de termos representacionais e as relacoes entre
eles. Nessa definicao, formal significa legıvel por computadores, especificacao explıcita
corresponde ao fato dos conceitos, atributos e relacoes serem explicitamente definidos e
compartilhado determina que ha um consenso em relacao as definicoes (BORST, 1997;
GRUBER, 2007).
Em Guarino (1998) encontra-se uma definicao de ontologia voltada para a Engenharia
de Software. O autor afirma que uma ontologia se refere a um artefato de engenharia de
software, em que e constituıdo um vocabulario especıfico para descrever certa realidade
e um conjunto de suposicoes explıcitas a respeito dos significados para as palavras do
vocabulario. Cada palavra do vocabulario e denominada conceito. Uma ontologia descreve
uma hierarquia de conceitos ao relaciona-los por meio de classificacoes ou atraves de
axiomas que expressam relacoes entre os conceitos de modo a restringir a interpretacao
pretendida para eles.
Outra definicao para ontologia mais simples, porem muito utilizada pela Computacao
foi estabelecida por Uschold e Jasper (1999) apud (BREITMAN, 2005). Os autores afirmam
que uma ontologia pode assumir varios formatos, mas necessariamente deve incluir um
vocabulario de termos e alguma especificacao de seu significado. Esta deve abranger
definicoes e uma indicacao de como os conceitos estao interrelacionados, o que resulta na
estruturacao do domınio e nas restricoes de possıveis interpretacoes de seus termos.
Importante ressaltar que, de acordo com a definicao Uschold e Jasper (1999), uma
ontologia pode assumir diversos formatos. De fato, na Computacao existe uma serie de
linguagens criadas para a definicao de ontologias, sendo a OWL (Ontology Web Language)
definida como padrao pelo W3C. Para permitir o compartilhamento das definicoes de
seus termos, toda ontologia deve ser disponibilizada em uma URI (Uniform Resource
Identifier), conforme defende (GRUBER, 1993; GRUBER, 2007).
36
Figura 11: Relacao entre conceitos e instancias de ontologias.
Com base nestas definicoes este trabalho estabelece que uma ontologia e uma especi-
ficacao de um determinado domınio, onde os elementos do mundo real sao representados
por meio de conceitos. Estes sao interrelacionados por associacoes de classificacao (de
modo a formar estruturas hierarquicas) ou por relacionamentos que estabelecem restricoes
no entendimento acerca dos conceitos. Uma ontologia ainda deve ser descrita atraves de
alguma linguagem, em um formato passıvel de ser processada por computadores e dispo-
nibilizada em algum endereco URI de modo a permitir seu compartilhamento por outras
organizacoes e pessoas.
Como exemplo podemos citar uma ontologia definida para descrever os elementos do
processo OpenUP. Alguns dos conceitos que este processo estabelece em seu domınio sao
disciplinas, atividades e artefatos. A partir do momento em que sao atribuıdos valores
para cada um desses conceitos, realiza-se sua instanciacao, de modo a descrever uma
entidade presente no OpenUP. A figura 11 representa parte da ontologia estabelecida
para o OpenUP e mostra a relacao entre conceitos e instancias. Os elementos ovais
representam conceitos. A partir deles sao criadas diversas instancias, sendo que podem
ser estabelecidas relacoes entre elas. Na figura as relacoes estao representadas pelas setas.
2.3.4 Projeto Discovery
O projeto Discovery foi projetado para facilitar o acesso as informacoes do processo,
permitindo aos envolvidos obter o conhecimento necessario para realizar suas atividades
de desenvolvimento ou avaliacao do processo e do produto de software.
O objetivo principal deste projeto e a visualizacao de informacoes relacionadas ao
37
Figura 12: Modelo de visualizacao de processos simplificado. Adaptado de (PIETROBON,2007)
conhecimento gerado pelo processo de desenvolvimento de software. O ambiente de vi-
sualizacao a ser desenvolvido pretende ser hipermıdia, multimıdia e interativo.
A visualizacao de informacoes possibilita que diversas informacoes sejam disponibili-
zadas de uma unica vez na tela. Segundo Pietrobon (2007), a engenharia de software ja
faz uso da visualizacao, como a UML por exemplo. No entanto essa visualizacao apre-
senta aspectos estruturais e comportamentais de um sistema, sem se preocupar com o
processo e o conhecimento gerados a partir do processo. As diversas ferramentas e am-
bientes existentes relacionados ao processo de software estao focados principalmente na
captura e armazenamento dos dados do processo, apresentando interfaces com o usuario
que pouco apoiam a compreensao e/ou divulgacao do conhecimento. Isso acontece pois
as ferramentas sao normalmente textuais, baseadas em navegacao por janelas e utilizam
poucos recursos graficos. O Discovery se propoe a fornecer uma interface mais interativa,
baseada em metaforas e outros recursos visuais que facilitem o processo de cognicao do
usuario.
O projeto Discovery define um modelo para visualizacao de conhecimento acerca de
processos de software. Basicamente esse modelo e formado pelos elementos processo,
conhecimento e visualizacao. Esses elementos estao representados pela figura 12. Pela
figura percebe-se que, dado um item de processo, e possıvel obter um conhecimento utili-
zando um recurso visual. Diversas abordagens podem ser usadas pelo usuario para utilizar
o modelo acima. Numa primeira abordagem, dado um item de processo P, determinamos
o que se quer saber (item de conhecimento - IC) e entao se escolhe a forma de visualizacao
38
que vai ser a mais adequada para se obter este conhecimento. Outra possıvel abordagem
e, dado um item de processo, escolhe-se uma possıvel forma de visualizacao para adquirir
conhecimento sobre aquele item de processo(PIETROBON, 2007). Portanto o modelo e
flexıvel ao ponto de permitir que cada um de seus elementos seja obtido com base nos
outros dois restantes.
Varias ferramentas tem sido propostas para integracao no ambiente Discovery, como
resultados de dissertacoes de mestrado. Ha trabalhos para visualizacao de verificacao de
processos de software por meio de rastreabilidade (GUEDES, 2007), utilizacao de metas
e rastreabilidade para manipulacao do conhecimento de uma pequena empresa (JuNIOR,
2007), apoio a atividades de testes atraves de ambientes virtuais (SOARES, 2008) e o uso de
StoryTelling para representacao do conhecimento acerca de processos de software(ASSIS,
2008).
2.4 Consideracoes finais
Este capıtulo apresentou dois dos principais assuntos deste trabalho: processos de
software e gerencia de conhecimento. Ambos sao considerados de grande importancia
para a qualidade dos produtos de software, de modo que a medida que a equipe conhece
e entende o processo de software, menores sao as chances de ocorrerem falhas durante sua
execucao. Portanto iniciativas de melhorias em organizacoes podem ser realizadas por
meio de alteracoes sobre o processo de software, por meio da captura e disseminacao do
conhecimento organizacional aos membros da equipe, ou por ambos.
Em relacao a processos de software foi apresentada a abordagem em nıveis, definida em
Rocha, Maldonado e Weber (2001) que visa facilitar a adaptacao de processos a contextos
especıficos. Processos podem ser do tipo padrao, especializados e instanciados. Processos
padrao e especializados descrevem caracterısticas validas para toda a organizacao ou para
tipos de processo semelhantes. Ja os projetos instanciados sao definidos ao levar em
consideracao o projeto que sera desenvolvido e o ciclo de vida adotado. Tambem foi
apresentado o metamodelo SPEM, utilizado para representar processos de software. Seus
elementos sao agrupados em conteudos de metodos e processos, sendo que os elementos de
conteudo de processo sao utilizados para descrever caracterısticas genericas do processo.
Tais elementos sao organizados de modo a definir o ciclo de vida a ser seguido pelo projeto.
Quando isto ocorre e definido um processo em SPEM. Portanto, como se pode perceber,
ha uma grande similaridade entre a abordagem de processos em nıveis e o metamodelo
39
SPEM. Processos do tipo padrao e especializados podem entao ser representados por meio
dos elementos definidos nos conteudos de metodos do SPEM, ao passo que os processos
instanciados podem ser representados por meio dos elementos definidos nos “processos”
do SPEM.
Por fim e interessante notar que o SPEM tambem considera o conhecimento como
um elemento importante em processos de software. Por meio de guias, tanto os elementos
de conteudo de metodos quanto os elementos de processo podem ser descritos e estarao
disponıveis no momento da definicao e da execucao do processo de software. Portanto, e
possıvel afirmar que o SPEM esta em linha com as propostas que vem sendo estabelecidas
para melhorias de software, quais sejam processos de software e gerencia de conhecimento.
40
3 Reuso de software
3.1 Introducao
Nas engenharias tradicionais os produtos sao criados a partir da reutilizacao de pro-
dutos ou sistemas ja existentes, experimentados e testados em outros sistemas. A Engen-
haria de Software baseada em reuso e uma estrategia semelhante para desenvolvimento
de software e tem sido reconhecida desde o final dos anos 60 (GIMENES; HUZITA, 2005).
No entanto somente nos ultimos anos ela vem sendo efetivamente adotada como forma
sistematica de desenvolvimento. O movimento para o desenvolvimento baseado em reuso
foi uma resposta as demandas por menores custo de producao e manutencao de software,
entregas mais rapidas de sistemas e aumento da qualidade do software(SOMMERVILLE,
2007).
Varias definicoes para o termo reuso de software podem ser encontradas na literatura.
Basili e Rombach (1988) definem o reuso como sendo o uso de todas as coisas associadas
com um software, incluindo o conhecimento. Krueger (1992) entende o reuso como sendo
o processo de criar software a partir de software existente ao inves de construı-lo do
zero. Cooper (1994) trata o reuso como sendo a capacidade de um item previamente
desenvolvido ser usado novamente ou repetidamente, em parte ou no todo, com ou sem
modificacao.
Muitas propostas para reuso formam o panorama de reuso da Engenharia de Software,
como denota a figura 13. Dentre os varios benefıcios comuns a tais propostas destacam-se
a reducao dos custos envolvidos no desenvolvimento, o aumento da confianca dos produtos,
a diminuicao dos riscos do processo de desenvolvimento e o desenvolvimento acelerado.
No entanto elas apresentam problemas, tais como o custo aumentado de manutencao do
software, custo elevado para criacao e manutencao de uma biblioteca de itens reutilizaveis
e falta de apoio de ferramentas CASE. Entretanto a maior dificuldade em implantar
uma abordagem de reuso ocorre pelo proprio processo de desenvolvimento com reuso: e
necessario estabelecer uma maneira efetiva para realizar a busca, compreensao e adaptacao
41
Figura 13: Panorama de reuso de software. Adaptado de (SOMMERVILLE, 2007).
dos itens reutilizaveis a aplicacao (SOMMERVILLE, 2007).
Dentre as propostas de reuso apresentadas na figura 13, este capıtulo versa sobre o De-
senvolvimento Baseado em Componentes (DBC). Utilizando uma abordagem top-down,
inicialmente na secao 3.2 e apresentada uma macro-visao do DBC, onde sao identifica-
dos os principais elementos que formam esta proposta, sendo tais elementos detalhados
nas secoes seguintes. Na secao 3.3 e apresentado o principal elemento desta tecnica: o
componente de software. A secao 3.4 apresenta como os componentes sao desenvolvi-
dos visando sua reutilizacao futura, atraves do processo conhecido como desenvolvimento
“para” reuso. A secao 3.5 apresenta o desenvolvimento de software atraves da integracao
de componentes reutilizaveis, atraves do processo chamado desenvolvimento “com” reuso.
Por fim, na secao 3.6 sao feitas as conclusoes deste capıtulo.
3.2 Desenvolvimento baseado em componentes
Na literatura encontram-se algumas definicoes para o Desenvolvimento Baseado em
Componentes (DBC). Brown e Short (1997) definem DBC como sendo o desenvolvimento
de software atraves da integracao planejada de componentes de software pre-existentes.
Para D’Souza e Wills (1998), o DBC e uma abordagem para desenvolvimento de software
em que todos os artefatos – do codigo executavel ate as especificacoes de interfaces e ar-
quiteturas – podem ser construıdos montando, adaptando e interconectando componentes
existentes em diversas configuracoes. Ja Sommerville (2007) afirma que e um processo
de definicao, implementacao e integracao ou composicao de componentes independentes
e nao firmementes acoplados ao sistema.
42
Esta proposta de reuso de software foi estabelecida na decada de 1990 e tipicamente
e formada pelos seguintes elementos:
• Componente de software: e o principal elemento do DBC. Deve ser independente
e completamente especificado por suas interfaces, de modo que haja uma clara
separacao entre interface do componente e sua implementacao, para que a imple-
mentacao de um componente possa ser substituıda por outra sem mudanca no sis-
tema.
• Repositorio de componentes: e uma base preparada para o armazenamento e re-
cuperacao de componentes. Para que a recuperacao ocorra de maneira efetiva e
necessario que sejam armazenadas informacoes adicionais e relevantes sobre o com-
ponente (SAMETINGER, 1997).
• Desenvolvimento “para” reuso: e o processo de desenvolvimento responsavel pela
criacao de componentes de software e o armazenamento destes no repositorio.
• Desenvolvimento “com” reuso: e o processo de desenvolvimento responsavel pela
recuperacao de componentes no repositorio, adaptacoes e implantacao em alguma
estrutura de modo a formar o novo software.
Esses quatro elementos estao diretamente relacionados e interagem entre si de modo
a formarem o DBC. Eles estao representados na figura 14.
Figura 14: Modelo de desenvolvimento baseado em componentes
43
Figura 15: Elementos de um modelo de componentes. Adaptado de (SOMMERVILLE,2007)
Ha ainda outros dois elementos definidos para o DBC que visam facilitar a reutilizacao
de componentes de software. O primeiro elemento e chamado framework de componentes
e e nele que sera realizada a integracao de componentes para a construcao do software. Seu
papel e prover uma infraestrutura comum a todos componentes do software, de modo que
eles possam comunicar entre si atraves deste framework. O segundo elemento, denominado
modelo de componentes, e uma definicao de padroes para implementacao, documentacao
e implantacao de componentes, para assegurar que os componentes possam operar entre
si (SOMMERVILLE, 2007). Geralmente quando um modelo de componentes e estabelecido,
tanto os componentes quanto o framework em que serao compostos sao aderentes a tal
modelo, visando facilitar a integracao entre eles. Portanto um modelo de componentes es-
pecifica como as interfaces devem ser definidas e como seus elementos (nome de operacoes,
parametros, excecoes) devem ser incluıdos na definicao da interface. A figura 15 apresenta
os elementos basicos de um modelo de componente.
3.3 Componente de software
E possıvel considerar o componente de software como o principal elemento da aborda-
gem DBC, pois ele e que sera reutilizado para a construcao de software. Um componente
de software pode ser definido como uma unidade de composicao que encapsula seu projeto
e implementacao e oferece seus servicos ao ambiente externo por meio de interfaces bem
definidas (GIMENES; HUZITA, 2005; SZYPERSKI, 2002). Nesta definicao o termo “unidade
de composicao” indica que componentes de software podem ser agrupados de modo a
formar unidades maiores e mais complexas, ou seja, outros componentes de maior granu-
laridade ou o software como um todo.
As interfaces de um componente de software possuem grande importancia para sua
44
reutilizacao. Alem de especificarem os servicos que o componente implementa, e atraves
delas que as comunicacoes serao realizadas. Por meio delas serao trafegados os recursos
necessarios e os resultados dos servicos executados pelo componente.
Alem disto, as interfaces realizam as especificacoes dos componentes. Especificar os
servicos significa descrever as funcionalidades daquele componente bem como os recursos
necessarios e providos por ele. Um componente de software pode ser especificado em
varios nıveis de abstracao, tais como interface, comportamento, qualidade, dentre outros.
O tipo de especificacao mais utilizado ocorre no nıvel de interfaces atraves da linguagem
IDL (Interface Description Language, definida pela OMG) em que sao descritos os servicos
do componente, os nomes e os tipos dos dados presentes na interface.
Para aumentar o nıvel de expressao em especificacoes de interfaces, trabalhos tem
sido propostos considerando outras caracterısticas do componente e o significado dos
elementos presentes na interface. No trabalho de Ardimento et al. (2007), os autores
propoem uma estrutura que descreva nao somente as interfaces, mas tambem as diversas
caracterısticas dos componentes de software, tais como custo, casos de sucesso em sua
adocao, estabilidade de interfaces, dentre outras. Em Korthaus, Schwind e Seedorf (2007)
e definida uma abordagem de especificacao baseada em web-semantica, na qual elementos
da interface dos componentes sao especificados atraves de seus significados, estabelecidos
por uma ontologia.
Um componente pode ter mais de uma interface e cada uma dessas interfaces pode ter
mais de um servico. Normalmente a interface e um conjunto de metodos os quais receberao
alguns parametros (dados ou objetos) e retornarao algum resultado. As interfaces de um
componente de software podem ser dos tipos “requeridas” ou “providas”.
As interfaces requeridas especificam servicos que devem ser fornecidos pelos outros
componentes no sistema, de modo que, se nao estiverem disponıveis, o componente nao
funcionara. Tipicamente tais interfaces recebem algumas informacoes para a execucao
dos seus servicos e geralmente nao retornam resultados. Sao como entradas de dados
para o componente. Os dados que compoem essas interfaces podem ser classificados como
obrigatorios ou opcionais.
Interfaces providas especificam os servicos fornecidos pelo componente. Elas especi-
ficam os metodos que podem ser chamados pelo cliente do componente e por onde serao
obtidos os resultados da execucao de tais servicos. Uma interface provida pode especi-
ficar varios servicos, os quais definem os dados a serem disponibilizados ao cliente do
componente.
45
Figura 16: Associacao de componentes por meio de interfaces
A figura 16 apresenta a representacao da ligacao entre dois componentes de software
atraves de suas interfaces. Nota-se que para cada tipo de interface ha uma forma de re-
presentacao diferente, de modo que uma interface “provida” se encaixa em uma interface
do tipo “requerida”. Por fim, deve-se ressaltar que as interfaces apenas descrevem os
servicos do componente e nao os implementam. A implementacao fica a cargo do proprio
componente atraves da linguagem de programacao na qual o componente foi desenvol-
vido, o que permite a interoperabilidade entre componentes implementados em diferentes
linguagens.
3.3.1 Descricao de componente de software
O desenvolvimento baseado em componentes estabelece que os componentes sejam
descritos de modo a facilitar sua reutilizacao futura. Normalmente esta descricao e defi-
nida pelo repositorio utilizado, atraves de alguns valores que deverao ser informados no
momento do armazenamento do componente, chamados de metadados. A funcao dos me-
tadados e descrever as diversas caracterısticas de um componente de software, tais como a
identificacao do componente, sua origem, suas formas de utilizacao, os contextos em que
pode ser reutilizado, formas de adaptacao, grau de maturidade e qualidade, documentacao
existente, dentre tantas outras. Em Redolfi et al. (2004) e apresentado como resultado de
um vasto estudo na area de identificacao de componentes, uma proposta de metadados a
ser utilizada em qualquer componente de software.
Uma outra proposta de metadados foi estabelecida em 1994 para que recursos dispo-
nibilizados na WEB pudessem ser descritos. Esta proposta ficou conhecida como Dublin-
Core e caracteriza-se por um conjunto de elementos que possam ser utilizados na descricao
de recursos em areas multidisciplinares. Logo apos o Dublin-Core tornou-se um padrao
para metadados (BREITMAN, 2005).
E importante salientar que os metadados sao utilizados para descrever apenas as ca-
racterısticas do componente. Nao e o intuito desses metadados realizar a descricao dos
46
servicos prestados pelo componente, pois, conforme visto na secao anterior, isto fica a
cargo da especificacao das interfaces. No entanto este tipo de descricao nao deve descar-
tar a especificacao dos servicos da interface, pois descrevem objetos distintos. Por fim,
e necessario considerar que a descricao de componentes, seja por metadado especıficos
ou pelo framework Dublin-Core, e passıvel de ser alterada conforme as necessidades da
organizacao.
3.4 Desenvolvimento para reuso
O processo de desenvolvimento para reuso e um dos processos de desenvolvimento que
formam o DBC. Esse processo e responsavel pela criacao de um componente de software
reutilizavel a partir de uma especificacao de requisitos. Segundo Sommerville (2007),
geralmente o desenvolvimento de componentes e realizado dentro da propria empresa que
reutilizara o componente e tem como base componentes ja existentes e usados em outras
aplicacoes. Sao raros os casos em que o componente e desenvolvido desde o inıcio voltado
para o reuso, pois na grande maioria das vezes ele e gerado a partir de adaptacoes feitas
em componentes ja existentes.
Ainda segundo Sommerville (2007), geralmente os componentes desenvolvidos interna-
mente nao sao imediatamente reutilizaveis, pois trazem consigo caracterısticas e interfaces
da aplicacao de origem que sao improvaveis de serem aproveitadas em outras aplicacoes.
Portanto, para serem reutilizaveis, e necessario que tais componentes sejam adaptados,
de modo a se criar uma versao mais generica e consequentemente mais reutilizavel. Este
tipo de desenvolvimento traz consigo um custo associado, o que faz o custo de desenvolvi-
mento de um componente ser mais alto do que o custo de um desenvolvimento de software
tradicional.
Alem do fator economico, o nıvel de reusabilidade de um componente e um fator a ser
considerado. Quanto mais generico se torna o componente, maiores sao as chances dele ser
reusado. Entretanto, isto significa que ele apresentara mais metodos, sera mais complexo
e, por isto, se tornara mais difıcil de ser compreendido e utilizado. A reusabilidade
adiciona complexidade e isto reduz a facilidade de compreensao do componente. Portanto,
ao projetar um componente, o desenvolvedor deve sempre estar atento a generalidade do
componente e a facilidade de sua utilizacao (GIMENES; HUZITA, 2005; SOMMERVILLE,
2007).
Conforme visto na secao 2.2.2, assim como o processo de desenvolvimento de soft-
47
ware tradicional, o desenvolvimento de componentes tambem e especıfico para cada or-
ganizacao. A diferenca entre tais processos e decorrente da necessidade dos componentes
serem mais genericos do que os software tradicionais, o que faz o desenvolvimento para
reuso ser mais complexo e oneroso. A partir do momento em que o componente foi criado,
ele devera ser descrito e armazenado no repositorio para se tornar disponıvel a futuras
reutilizacoes. Este processo de descricao e armazenamento do componente vai variar
conforme o repositorio, pois cada repositorio define seu conjunto de metadados e o modo
de armazenamento dos componentes.
3.5 Desenvolvimento com reuso
O outro processo estabelecido pelo DBC e o desenvolvimento “com” reuso. Esse
processo e responsavel pela construcao do software a partir da reutilizacao de componentes
de software vindos do repositorio. De um modo geral, esse processo ocorre em 5 etapas,
conforme estabelecido por (BROWN; SHORT, 1997):
• Busca: etapa que consiste em recuperar do repositorio os componentes que pos-
sivelmente atenderao aos requisitos do software em desenvolvimento. Nesta etapa
e necessario confrontar os requisitos do software com os requisitos implementados
pelo componente, atraves de uma operacao denominada matching (ou equivalencia).
Nem sempre e possıvel encontrar um componente que possua uma equivalencia total
com os requisitos do software e, por este motivo, o nıvel de equivalencia entre as
especificacoes pode variar.
• Qualificacao: etapa que consiste em avaliar detalhadamente os componentes que
atendem em um certo grau aos requisitos do software em construcao, de modo
a definir qual devera ser utilizado no software. Essa etapa consiste em avaliar nao
somente as interfaces do componente, mas tambem toda a documentacao disponıvel,
alem de discussoes com desenvolvedores e usuarios e execucoes de teste.
• Adaptacao: etapa que ira realizar algumas alteracoes no componente de modo a
solucionar possıveis erros, conflitos e inconsistencias entre os componentes que irao
integrar o software.
• Implantacao: etapa que realizara a implantacao dos componentes no framework de
modo a formarem a aplicacao. E nesta fase que ocorre a reutilizacao do componente
de modo efetivo.
48
Figura 17: Processo de desenvolvimento “com” reuso. Figura adaptada de (BROWN;
SHORT, 1997)
• Atualizacao: etapa que realizara a troca de um componente por outro mais novo
ou que apresente comportamento e interfaces equivalentes.
Todas estas etapas de DBC estao representadas na figura 17 e geralmente sao realiza-
das com base nos valores dos metadados definidos pelo componente e nas especificacoes
de suas interfaces. Ainda de acordo com Brown e Short (1997), apesar das etapas acima
sugerirem uma sequencia entre elas (e na pratica e comum que essa sequencia ocorra),
esta ordem nao deve necessariamente ocorrer, pois as etapas sao independentes umas das
outras. A seguir sao apresentadas breves descricoes de cada uma delas.
3.5.1 Busca de componentes
A busca de componentes de software e responsavel por recuperar do repositorio com-
ponentes que possivelmente atenderao aos requisitos do software em desenvolvimento.
Esta e uma atividade de grande importancia, pois o sucesso de uma abordagem DBC
depende diretamente da habilidade de identificar e selecionar os componentes de software
conforme afirmam (MAHMOOD; LAI; KIM, 2007).
Esta etapa inicia-se com uma pesquisa dos potenciais componentes que atendem aos
requisitos do software. Geralmente ela e realizada ao atribuir valores para os metada-
dos e em comparacoes realizadas entre as especificacoes das interfaces dos componentes.
Para determinar se as funcionalidades de um componente atendem as funcionalidades
requeridas no software em desenvolvimento e aplicada uma operacao sobre as interfaces,
denominada matching. Tal operacao determina o grau de equivalencia de componentes
de software atraves de suas interfaces.
49
3.5.2 Qualificacao de componentes
No entanto nem sempre e possıvel garantir uma equivalencia total, pois pode haver
casos em que nenhum componente no repositorio atenda a todos os requisitos do software
em construcao. Nestes casos a operacao de matching podera ser flexibilizada, de modo a
aceitar pequenas divergencias entre as especificacoes de requisitos/interfaces. Em Zarem-
ski e Wing (1995) sao apresentadas varias operacoes de matching para serem realizadas
sobre as especificacoes das interfaces de componentes.
O resultado final desta etapa e um conjunto de componentes que atendem em um certo
grau aos requisitos da aplicacao em desenvolvimento. Estes componentes sao chamados
de qualificados.
3.5.3 Adaptacao de componentes
Uma vez que os componentes foram qualificados, pode-se iniciar a reutilizacao deles.
Entretanto, e raro ocorrer a reutilizacao desses componentes logo apos a etapa de quali-
ficacao, pois, na maioria das vezes, sao necessarias algumas adaptacoes de modo a contor-
nar situacoes que impossibilitam seu reuso (XIE; ZHANG, 2007; BASTIDE, 2006).
Essas situacoes sao decorrentes da variedade de ambientes e infraestruturas nas quais
os componentes serao implantados (nos casos em que nao ha um modelo de componentes),
mas principalmente devido a diferencas entre as especificacoes dos componentes qualifica-
dos e as especificacoes de requisitos do usuario, muitas vezes originadas pela flexibilizacao
da operacao de matching(XIE; ZHANG, 2007). Nestes casos as divergencias mais comuns
decorrem de diferencas entre nomes, parametros e tipos de dados presentes nas especi-
ficacoes dos componentes e da aplicacao. Entretanto, pode haver casos em que os servicos
sao de fato diferentes.
Segundo (XIE; ZHANG, 2005; XIE; ZHANG, 2006) para estes casos e possıvel realizar as
seguintes adaptacoes:
• mudancas de nomes de interfaces, de modo a estabelecer equivalencia entre os nomes
das interfaces do componente e da aplicacao,
• mudancas de parametros de interfaces, para solucionar casos em que ha divergencias
entre o numero, o tipo ou a ordem em que parametros aparecem nas interfaces do
componente e da aplicacao,
50
• adaptacao de funcao, para solucionar casos em que ha diferencas entre o comporta-
mento esperado pela aplicacao e o comportamento definido pelo componente,
• QoS (Quality of Services) para casos em que o componente nao atende aos requisitos
nao-funcionais de uma aplicacao.
As adaptacoes a serem realizadas podem acontecer em diversos pontos dos compo-
nentes. O caso mais simples e quando a divergencia decorre da diferenca de nomes entre
as interfaces, bastando que sejam realizadas adaptacoes nas interfaces divergentes. Entre-
tanto, nos casos em que ha diferenca no numero de parametros, divergencias nas funcio-
nalidades do componente ou este nao atende aos requisitos nao-funcionais, as adaptacoes
geralmente sao realizadas na implementacao do componente e certamente refletirao em
suas interfaces.
Uma vez que os componentes foram adaptados, e esperado que nao haja mais proble-
mas de conexoes em suas interfaces. Portanto o resultado desta etapa sao componentes
que ja estao prontos para serem conectados ao framework de componentes. Neste ponto,
os componentes satisfazem aos requisitos do software em desenvolvimento e nao apresen-
tam problemas de integracao.
3.5.4 Implantacao de componentes
E na fase de implantacao que o reuso de componentes ocorre de modo efetivo. No
DBC essa fase e marcada pela integracao de componentes com a estrutura que executara
seus servicos, sendo que esta ligacao ocorre atraves das interfaces dos componentes e os
pontos de conexao do framework. Geralmente essa ligacao e estabelecida pelo modelo de
componentes. Nos casos em que nao ha o modelo de componentes, a integracao nao e
realizada de modo planejado e controlado, sendo necessario incluir algum codigo entre
o componente e o framework, de modo que eles possam se comunicar (BROWN; SHORT,
1997). Este tipo de abordagem e denonimada de “codigo cola” (do ingles, glue-code).
Os componentes de software podem se apresentar na forma de codigo compilado (ge-
ralmente chamado de binarios) ou na forma de codigo-fonte. Quando eles ocorrem na
forma de binario, a reutilizacao do componente ocorre pela execucao dos seus servicos de
modo direto, ao passo que, quando o componente se apresenta na forma de codigo-fonte,
sua reutilizacao geralmente se da pela interpretacao de seus servicos. Seja qual o formato
do componente, percebe-se claramente que ha a reutilizacao de seus servicos quando o
componente e interligado com o ambiente de execucao.
51
O resultado desta fase do desenvolvimento com reuso e o software em execucao, que
reutiliza os servicos prestados pelos componentes que o integram.
3.5.5 Atualizacao de componentes
Com o passar do tempo o software deve sofrer operacoes de manutencao em virtude da
inclusao de novos requisitos ou para melhorar a performance e retirar seus erros. No caso
de um software desenvolvido atraves de DBC, deve-se levar em conta que tal operacao sera
realizada sobre alguns componentes e, caso seja necessario realizar sua substituicao, deve-
se garantir que o novo componente sera compatıvel com aquele que esta sendo trocado.
Esta compatibilidade deve ser tanto sintatica (em termos dos elementos que compoem a
interface) quanto semantica (em relacao aos servicos providos pelo componente) (MAH-
MOOD; LAI; KIM, 2007).
A atualizacao de componentes compreende uma nova busca no repositorio, a fim de
encontrar um componente que atenda aos requisitos daquele componente que esta sendo
trocado. Note que a operacao de matching neste caso e realizada entre as especificacoes de
dois componentes, de modo a identificar quais componentes do repositorio sao semelhantes
ao que estava sendo utilizado. Para isto, geralmente busca-se realizar a operacao de
matching que nao permite nenhuma divergencia entre as especificacoes, pois caso encontre
um componente que satisfaca a esta operacao, pode-se dizer que ele e equivalente ao
componente a ser trocado (ZAREMSKI; WING, 1995). A partir de entao, e necessario
realizar a integracao do novo componente ao software.
Como se pode perceber, a fase de atualizacao de um componente e similar a todo o
processo de definicao com reuso. Na realidade essa fase compreende as fases de busca,
qualificacao, adaptacao e integracao do DBC. A unica ressalva que se faz nela e o uso
da operacao de matching mais restritiva, de modo a buscar os componentes que nao
apresentem divergencias.
Todas as etapas da definicao com reuso apresentadas anteriormente, geralmente sao
realizadas com base nas especificacoes sintaticas das interfaces. Elas consideram as de-
finicoes de nomes de servicos, tipos de dados e o numero de parametros presentes nas
interfaces. Entretanto pesquisadores tem buscado formas mais efetivas de realizar a de-
finicao com reuso no que tange a expressabilidade dos termos que compoem as interfaces.
A grande maioria dos trabalhos encontrados nesta area tem utilizado ontologias para
52
definirem os termos das interfaces dos componentes.
Neste sentido a operacao de matching tem sido evoluıda de modo a considerar o
significado dos elementos que compoem a interface. Em Hemer (2004) e proposto um
algoritmo baseado em logica de alta ordem para automatizacao do processo de matching.
Em Korthaus, Schwind e Seedorf (2007) os autores utilizam ontologias para especificarem
os elementos que compoem a interface do componente. Por fim, Xie e Zhang (2007) estabe-
lecem um mecanismo de adaptacao de componentes a partir de especificacoes semanticas.
3.6 Consideracoes finais
Este capıtulo apresentou inicialmente as vantagens e as dificuldades, bem como al-
gumas abordagens existentes para tratar o reuso de software. Dentre as abordagens
apresentadas foi escolhido o Desenvolvimento Baseado em Componentes como objeto de
estudo deste trabalho. A partir de entao, ele foi apresentado mostrando seus princi-
pais elementos, a saber: componente de software, processos de desenvolvimento “para” e
“com” reuso.
Atualmente ha pesquisas sendo realizadas para facilitar o desenvolvimento baseado
em componentes. E o caso do trabalho de Hemer (2004), em que uma ferramenta foi
proposta para a realizacao do matching de componentes, e do trabalho de Bastide (2006),
em que uma ferramenta para adaptacao de componentes foi proposta. Entretanto alguns
pesquisadores buscam melhorar a efetividade do reuso de componentes melhorando a
recuperacao e selecao de componentes. Tais melhorias na grande maioria das pesquisas
tem sido realizadas atraves da inclusao de ontologias para a especificacao das interfaces
do componente.
A inclusao de termos de ontologias em interfaces nao provoca mudancas apenas na
fase de busca de componente, mas em todas restantes do DBC. Apesar de nao terem sido
encontradas referencias que apontassem claramente os ganhos de utilizacao de ontologias
em componentes de software, este parece ser um caminho promissor para pesquisas em
DBC.
53
4 Uma Abordagem de Reuso deprocessos de software
4.1 Introducao
A proposta deste trabalho e estabelecer um metodo para a definicao de processos
de software atraves da reutilizacao de processos e do conhecimento agregado a eles. Em
Osterweil (1987), Osterweil (1997) e dito que software e processos de software possuem
muitas similaridades, pois ambos podem ter seus requisitos definidos, modelados, imple-
mentados e avaliados. Alem disto o autor afirma que, devido a tais similaridades, tecnicas
que sao aplicadas em software podem ser aplicadas (certamente com alguma adaptacao)
em processos de software.
Baseado nas similaridades defendidas por Osterweil (1987), Osterweil (1997), foi es-
tabelecido neste trabalho um metodo para definicao de processos de software a partir
dos conceitos principais de DBC. Chamado de “Definicao de Processos Baseada em Com-
ponentes” (DBPC), esse metodo estabelece que partes de processos sao representados
atraves de componentes de processos, armazenados em um repositorio. De modo analogo
ao DBC, a DPBC tambem estabelece os processos “para” reuso e “com” reuso, sendo o
primeiro responsavel por criar os componentes de processos que irao popular o repositorio
e o segundo o responsavel por definir novos processos de software atraves da composicao
dos componentes vindos do repositorio.
Este capıtulo apresenta o metodo proposto para reuso de processos de software ba-
seado na tecnica de componentizacao de software. Inicialmente a secao 4.2 apresenta o
modelo de processos de software estabelecido nesta proposta, de modo que um processo
seja representado atraves de aspectos tecnicos, organizacionais e humanos e armazene
conhecimento adquirido ao longo de suas execucoes passadas. A partir de entao, este
capıtulo adota uma abordagem top-down para apresentacao do trabalho. Inicialmente na
secao 4.3 e apresentada uma macro-visao do metodo para definicao de processos por meio
54
da reutilizacao de componentes. Essa secao apresenta brevemente os quatro elementos
principais da proposta e o modo como eles estao relacionados. Tais elementos sao o com-
ponente de processo de software, o repositorio de componentes, a definicao “para” reuso
e a definicao “com”reuso. Cada um desses elementos e detalhado nas secoes seguintes. A
secao 4.4 apresenta o objeto reutilizavel que e capaz de representar um processo, deno-
minado componente de processo. Serao apresentados a estrutura interna do componente
de processo, a definicao de suas interfaces e como um componente e descrito de modo
a facilitar sua futura recuperacao do repositorio e reutilizacao. A secao 4.5 apresenta
a definicao de processos “para” reuso, responsavel pela criacao de componentes de pro-
cesso e seu armazenamento no repositorio. Na secao 4.6 a definicao de processos “com”
reuso e apresentada com mais detalhes, pois e atraves dela que novos processos de soft-
ware serao definidos baseados em componentes de processo. Tambem sao apresentadas
as diferencas entre a abordagem de reuso aplicada em processos e o reuso tradicional de
componentes de software. A secao 4.7 apresenta trabalhos relacionados a esta proposta e
realiza uma comparacao entre eles. Por fim, a secao 4.8 apresenta as consideracoes finais
deste capıtulo.
4.2 Modelo de processo de software
Como visto na secao 2.2, um processo de software e definido como sendo um conjunto
de elementos que sao organizados de determinada maneira para a producao de software.
Os elementos que compoem o processo sao os mais diversos possıveis, tais como atividades
e tarefas a serem realizadas, membros da equipe responsaveis pela execucao do processo,
ferramentas de suporte a execucao, culturas e polıticas organizacionais ou externas, dentre
tantos outros. Portanto e possıvel estabelecer categorias de modo a organizar tais ele-
mentos que constituem um processo.
Este trabalho sugere tres categorias para representar os aspectos de um processo e
agrupar os elementos que o constituem, a saber: tecnico, organizacional e humano. Os
aspectos tecnicos estao relacionados ao modo como um processo e executado pela orga-
nizacao e como o produto de software e desenvolvido por ele. Portanto, elementos como
sub-processos, atividades, tarefas, artefatos de software, ferramentas utilizadas, lingua-
gens, dentre tantos outros, podem ser descritos por meio deste grupo. No entanto pode-se
afirmar que nesta categoria os elementos principais para a descricao de um processo de
software sao os elementos processo, atividades e tarefas, pois sao elementos basicos para
a definicao de qualquer processo.
55
Os aspectos organizacionais representam caracterısticas presentes na organizacao e
que influenciam o processo de software. Exemplos de elementos organizacionais de um
processo sao os papeis desempenhados pelos membros da organizacao, as restricoes (de
tempo, custo, pessoal, dentre outras) impostas ao processo, as polıticas adotadas, metas
estipuladas, dentre outras. Apesar dessas caracterısticas serem definidas pela organizacao,
elas possuem impacto no processo de software e por este motivo devem ser consideradas.
Os aspectos humanos representam caracterısticas relativas aos membros da orga-
nizacao que podem impactar o processo de software. Exemplos dessas caracterısticas
sao as habilidades individuais, o conhecimento tecnico e as experiencias dos membros.
Sao caracterısticas inerentes as pessoas que trabalham no processo, que podem auxiliar a
execucao de um processo de software.
Alem desses aspectos, como visto no capıtulo 2, processos de software possuem muito
conhecimento adquirido ao longo de suas execucoes. O conhecimento e de grande im-
portancia para a qualidade do processo de software, pois a medida que os membros enten-
dem mais do processo diminuem as chances destes introduzirem falhas em sua execucao.
Esse conhecimento, conforme definido por Montoni (2003), pode ocorrer por meio de
ideias, duvidas, descricoes de processo, casos e licoes.
Figura 18: Modelo de processos proposto. Esta figura representa o modelo de processosestabelecido para esta abordagem.
Portanto, como se pode perceber, um processo de software tem varias facetas, sendo
cada uma delas impactante na sua qualidade. Deste modo, este trabalho apresenta um
modelo de processos de software que aborda todas estas caracterısticas de um processo.
Por isto um processo pode ser definido como o conjunto de aspectos tecnicos, organizacio-
nais, humanos e de conhecimento. A figura 18 apresenta o modelo de processos definido
por esta proposta.
56
Figura 19: Modelo da proposta DPBC.
4.3 Definicao de Processos de Software Baseado em
Componentes (DPBC)
Como visto no capıtulo 3, um software pode ser construıdo a partir da composicao de
unidades reutilizaveis. Devido as similaridades apontadas por Osterweil (1987), Osterweil
(1997), considerou-se a possibilidade de definir processos de software a partir de elementos
reutilizaveis capazes de representar pedacos de processo. Deste modo foi possıvel definir
uma abordagem similar a DBC, entretanto adaptada para o contexto de processos de
software.
Denominada “Definicao de Processos Baseada em Componentes (DPBC)”, esta pro-
posta e muito similar ao DBC, sendo constituıda por quatro elementos: componente de
processo de software, repositorio de processos de software, definicao de processos “para”
reuso e definicao de processos “com” reuso. A figura 19 apresenta esses quatro elementos
e o modo como eles estao interligados.
O componente de processo de software e o elemento equivalente ao componente de
software definido em “DBC”. Pode-se dizer que nesta proposta ele e o elemento principal,
pois tem a funcao de representar uma parte de um processo de software em todos os
seus aspectos (tecnico, organizacional e humano) alem de armazenar o conhecimento
adquirido pelas execucoes passadas do processo. Como visto mais adiante neste trabalho,
esse componente tem tamanho variavel de modo a representar um processo de software
em diferentes nıveis de detalhes. As adaptacoes realizadas em DBC que permitiram a
definicao desse componente ocorreram na estrutura interna do componente, de modo que
57
fosse possıvel representar as caracterısticas de um processo.
O repositorio de processos equivale ao repositorio de componentes de software em
“DBC”. Ele e responsavel por armazenar e prover os componentes de processos de soft-
ware durante a definicao de um novo processo. Como esta proposta utiliza ontologias na
representacao de caracterısticas de processos, e necessario que tais ontologias tambem es-
tejam disponıveis no momento da reutilizacao dos componentes. Portanto o repositorio de
processos consiste de dois sub-repositorios: um para o armazenamento dos componentes
de processo e outro para o armazenamento das ontologias utilizadas pelos componentes
de processo. Esta sub-divisao ocorrida no repositorio de processos e uma caracterıstica
que o difere do repositorio DBC.
A definicao “para” reuso e a atividade responsavel por criar componentes de processos
reutilizaveis e armazena-los juntamente com sua ontologia no repositorio de componentes
de processo. Essa definicao e equivalente ao desenvolvimento “para” reuso estabelecido
no DBC. Apesar de ter sido considerada neste trabalho, ela nao foi detalhada por fugir do
escopo desta pesquisa, pois o foco desta e o reuso de processos para a definicao de novos
processos.
Por fim a definicao “com” reuso e o tema principal desta pesquisa. Equivalente ao
desenvolvimento “com” reuso em DBC, ela e responsavel por, partindo dos requisitos do
novo processo de software, pesquisar o repositorio em busca de componentes que possivel-
mente atendam aos requisitos do novo processo, qualifica-los de modo a permitir selecionar
os componentes que serao efetivamente reusados, adapta-los de modo corrigir possıveis
inconsistencias entre eles e implanta-los no ambiente de execucao de processo. E ainda
responsabilidade desta atividade realizar a atualizacao de um componente de processo por
um outro. As diferencas entre esta atividade e sua equivalente em DBC ocorrem devido
as caracterısticas inerentes a processos de software que devem ser consideradas. Deste
modo todas as etapas para reutilizacao de um componente de software foram adaptadas
de modo a considerar os aspectos e o conhecimento de um processo de software.
Como se pode perceber ha de fato muitas similaridades entre DBC e a DPBC proposta
neste trabalho. A tabela 2 apresenta a definicao nas duas abordagens para os 4 elementos
supra-citados.
58
Elemento Definicao em DBC (SZY-
PERSKI, 2002)Definicao em DPBC
Componente Estrutura de software que im-plementa algumas funcionalidades.Componentes serao reutilizados eagrupados para formarem unidadesde software maiores.
Estrutura que representa um pro-cesso de software (ou partes dele).Serao reutilizadas e agrupadaspara formarem processos maiscomplexos.
Repositorio Local onde os componentes de soft-ware sao armazenados.
Local onde os componentes de pro-cesso sao armazenados.
Processo“para” reuso
Processo responsavel pela geracaode componentes de software reu-tilizaveis. Seus produtos (compo-nentes) serao armazenados no repo-sitorio para futuras reutilizacoes.
Processo responsavel pela geracaode componentes de processos desoftware. Esses componentes seraoarmazenados no repositorio de com-ponentes de processo para futurasdefinicoes de novos processos.
Processo“com” reuso
Processo pelo qual um novo soft-ware e construıdo atraves da reuti-lizacao de componentes de softwareextraıdos do repositorio.
Processo pelo qual novos processosde software sao definidos atraves dareutilizacao de componentes de pro-cesso vindos do repositorio.
Tabela 2: Relacao entre as abordagens DBC e DPBC: esta tabela aponta a relacao exis-tente entre os componentes para as duas abordagens.
4.4 Componente de processo de software
Considerando as relacoes diretas entre os elementos das abordagens DBC e DPBC, um
componente de processo de software necessariamente deve apresentar as caracterısticas
citadas na secao 3.3 para um componente de software tradicional. Deste modo um com-
ponente de processo de software e definido como sendo:
• Unidade de composicao com interfaces e dependencias de contexto bem definidas.
• Unidade capaz de representar um processo de software ou partes dele, em seus tres
aspectos (tecnico, organizacional e humano), seja qual for o nıvel de abstracao que
ele represente (sub-processo, atividade ou tarefa).
• Unidade capaz de armazenar o conhecimento agregado a porcao do processo repre-
sentado pelo proprio componente.
Assim como um componente de software, um componente de processo de software e
uma unidade que por si so nao existe. Ele deve ser agrupado a outros componentes de
processo, de modo a compor estruturas maiores e mais complexas que ao final definirao o
processo como um todo. Alem disto, para que esses componentes sejam reutilizados com
sucesso, e necessario que o ambiente em que serao implantados forneca os recursos ne-
cessarios para a execucao do processo representado por eles. Deste modo a DPBC tambem
estabelece a dependencia de contexto para os componentes de processos de software.
59
4.4.1 Estrutura de componentes de processos de software
Outra caracterıstica de um componente de processo de software e o grau de abstracao
com que ele representa um processo de software. Como visto na secao 2.2, um processo de
software pode ser decomposto em unidades menores, a saber (em ordem decrescente de
tamanho): sub-processos, atividades e tarefas. Esta classificacao estabelece que um com-
ponente de processo de software deve ser capaz de representar um processo em qualquer
um destes nıveis de abstracao citados. Deste modo e possıvel que componentes de mesmo
nıvel de abstracao sejam agrupados para formar um componente do nıvel de abstracao
imediatamente superior. Por exemplo, varios componentes do tipo “Tarefa” podem ser
agrupados para formarem um componente do tipo “Atividade”. Esse componente, por
sua vez, podera ser agrupado com outros componentes de mesmo nıvel para formarem um
componente do tipo “Processo”, e assim sucessivamente. Importante notar, ainda, que o
modelo de processos de software apresentado na secao 4.2 e valido para qualquer granu-
laridade de componente, nao importando se este representa um processo, uma atividade
ou uma tarefa. Portanto um componente de processo pode ser definido como:
(∀x)ComponenteProcesso(x)→ (∃y, z, w, k)(tecnico(y) ∧
organizacional(z) ∧
humano(w) ∧
conhecimento(k)) (4.1)
onde x representa um componente de processo, y, z e w representam respectivamente os
aspectos tecnicos, organizacionais e humanos do processo e k representa o conhecimento
do processo.
A granularidade de um componente de processo esta diretamente relacionada ao as-
pecto tecnico do processo, pois e esse aspecto que vai determinar o nıvel de detalhamento
e complexidade. Portanto, e a partir desta estreita ligacao entre processos e componente
que foram definidas as granularidades de componente dos tipos “Processo”, “Atividade” e
“Tarefa”. A granularidade e o aspecto tecnico de um componente sao entao equivalentes
e podem ser definidos como sendo:
(Granularidade(x)⇔ Tecnico(x))→ (Processo(x) ∨
Atividade(x) ∨
Tarefa(x)) (4.2)
60
A definicao acima pode ser entendida como: sendo x um componente de processo pode-se
dizer que sua granularidade e definida pelo seu aspecto tecnico de tal modo que x e um
processo, uma atividade ou uma tarefa.
Se o componente representar um processo, ele pode conter componentes de granula-
ridade “Atividade” ou “Processo”. De acordo com o modelo de processos definido, fica
clara a relacao entre os componentes processo e atividade, de modo que um processo e
composto de varias atividades. No entanto processos podem ser formados por outros
processos. Estes, por sua vez, sao estruturalmente iguais a um processo, sendo apenas
agrupados de modo a formar um processo maior. Deste modo pode-se definir formalmente
um componente de granularidade “Processo” como sendo:
(∀x)Processo(x)→ (∃y)(Processo(y) ∨ Atividade(y) ∧
compoe(y, x)) (4.3)
Esta definicao mostra que, sendo x um componente de granularidade “Processo”, ele pode
ser composto por outros componentes y, tal que y seja um componente de granularidade
“processo” ou “atividade”.
Por fim, um componente que representa uma atividade pode ser composto a par-
tir de diversos componentes do tipo tarefa, sendo uma tarefa o componente de menor
granularidade. Esta relacao pode ser definida formalmente como:
(∀x)Atividade(x)→ (∃y)(Tarefa(y) ∧ compoe(y, x)) (4.4)
Esta definicao estabelece que, sendo x um componente de processo de granularidade
“atividade”, ele pode ser composto de componentes y, tal que y seja um componente de
processo de granularidade “tarefa”.
Ainda de acordo com o modelo de processos estabelecido na secao 4.2, um processo
de software apresenta os aspectos organizacional e humano. Consequentemente o compo-
nente de processo de software deve ser capaz de representar tais aspectos, seja qual for
sua granularidade. Seguindo tal modelo de processos, os aspectos organizacionais de um
processo em um componente podem ser formalmente definidos como sendo:
(∀x)Organizacional(x)→ (∃y)(papel(y) ∨ restricao(y) ∨
politica(y) ∨meta(y)) ∧ descreve(y, x) (4.5)
Neste caso acima, sendo x um aspecto organizacional ele pode ser descrito por itens de
61
descricao y, os quais podem ser um conjunto formado por papeis, restricoes, polıticas ou
metas.
Os aspectos humanos podem ser formalmente definidos como sendo:
(∀x)Humano(x)→ (∃y)(HabilidadeIndividual(y) ∨
ConhecimentoTecnico(y) ∨ Experiencia(y)) ∧
descreve(y, x) (4.6)
A definicao acima apresenta que, sendo x um aspecto humano de um processo, ele pode ser
descrito por itens de descricao y, os quais formam um conjunto de habilidades individuais,
conhecimentos tecnicos ou experiencias.
Alem desses aspectos, o componente e capaz de armazenar o conhecimento adquirido
ao longo das execucoes passadas do processo que ele representa. Cada fato ocorrido e
registrado em um processo de software e definido como sendo um item de conhecimento de
modo que um processo pode apresentar varios itens de conhecimento. Conforme proposto
por Montoni (2003), os itens de conhecimento que podem ocorrer em um processo de
software podem ser classificados como sendo descricoes de processo, casos ocorridos, licoes
aprendidas, ideias e duvidas. O componente de processo permite que varios itens de
conhecimento sejam armazenados em sua estrutura e classificados conforme um dos tipos
supra-citados. Deste modo o conhecimento em um componente de processo de software
pode ser definido formalmente como sendo:
(∀x)Conhecimento(x)→ (∃y)(DescricaoProcesso(y) ∨
Caso(y) ∨ LicaoAprendida(y) ∨
Ideia(y) ∨Duvida(y)) ∧
compoe(y, x) (4.7)
Neste caso sendo x o conhecimento do processo e y um item de conhecimento, que pode
ser do tipo descricao de processo, caso, licao aprendida, ideia ou duvida, x sera o conjunto
formado pelos itens de conhecimento y.
Apesar deste trabalho estabelecer conjuntos iniciais para descricao de aspectos e de
conhecimentos de um processo (conforme 4.5, 4.6, 4.7), e importante salientar que eles
podem ser alterados. Na realidade tais conjuntos deverao ser estendidos de modo que
representem as caracterısticas do ambiente em que serao reutilizados.
62
4.4.2 Formatos de representacao de um componente de processode software
O componente de processo de software pode ser representado de forma grafica ou de
forma descritiva. A forma grafica e ideal para realizar a modelagem do processo como um
todo a partir de ıcones que representam componentes de processos, ao passo que o formato
descritivo serve para representar o processo de modo mais detalhado, apresentando como o
processo e definido internamente pelo componente. Essas formas de representacao de um
processo de software foram definidas a partir de formas de representacao de componentes
de software tradicionais.
A forma grafica e indicada para representar aspectos estruturais e de comunicacao dos
componentes que formam o processo de software. No entanto, esse diagrama nao apresenta
detalhes do processo de software. Sua representatividade nao e suficiente a ponto de
descrever um processo de software, os atores envolvidos em sua execucao, os artefatos
requeridos e produzidos, a ordem com que as atividades sao realizadas no processo, dentre
tantos outros aspectos. Para descrever um processo de software tao detalhadamente
utiliza-se a forma descritiva.
A forma grafica para representacao de um componente de processo foi definida a partir
do diagrama de componentes da UML. Esse diagrama quando aplicado no contexto de
software tradicional representa como o software foi projetado a partir de componentes de
software e como ocorrem as relacoes entre os componentes que formam o software, de modo
a indicar os servicos e as comunicacoes estabelecidas entre eles. Este tipo de visao e de
grande importancia para o contexto de processos de software, pois deste modo e possıvel
aplicar nıveis de abstracao em processos de software. Com o diagrama de componentes
da UML aplicado em processos de software, e possıvel projetar o processo de software a
partir das unidades que o irao compor, estabelecer as relacoes e comunicacoes entre tais
unidades, nao sendo necessario entrar em detalhes de cada um desses componentes.
A representacao grafica de um componente de processo de software pode, entao, ser
realizada atraves do conceito de estereotipo da UML. Todo componente de processo devera
apresentar o estereotipo <<componente de processo>> de modo a revelar sua natureza.
No entanto e importante tambem representar o nıvel de granularidade do componente,
para que, ao projetar um processo de software, fique bem claro como os diferentes compo-
nentes estao sendo agrupados para formarem o novo processo. Para isto deve-se adicionar
tambem os estereotipos que indicam a granularidade dos componentes, sendo estes defi-
nidos como <<processo>>, <<atividade>> e <<tarefa>>. A figura 20 apresenta um
63
Figura 20: Representacao de um processo por meio de diagrama de componentes da UML.Esta figura mostra um processo sendo “projetado” a partir de componentes de processode granularidade menor. Para cada componente de processo ha um estereotipo indicandosua granularidade.
cenario hipotetico onde um processo esta sendo projetado com base em varios compo-
nentes de processo de granularidade menor. Note que o processo em definicao e tambem
representado por um componente de processo.
Conforme apresentado na secao 2.4 este trabalho utiliza o SPEM como metamodelo
de processos de software. O W3C estabeleceu uma extensao da linguagem XML para
representar os conceitos estabelecidos pelo metamodelo atraves de uma linguagem es-
truturada. Portanto, um processo descrito em SPEM e representado em um arquivo
XML atraves de marcacoes (tags) definidas para cada elemento do SPEM. Isto permite
estabelecer uma relacao direta entre as duas formas de representacao de componentes
de processo consideradas nesta proposta, pois o componente representado visualmente
atraves de um diagrama de componentes da UML sera representado por meio de um ar-
quivo XML. Definindo-se desta maneira pode-se novamente estabelecer um paralelo com
o DBC, pois nesta tecnica componentes de software representados atraves da UML sao
implementados por um ou mais arquivos escritos em alguma linguagem de programacao.
No DBPC ocorre de modo muito similar, pois um componente de processo de software
representado em UML sera “implementado” atraves da linguagem XML. No entanto essa
implementacao ocorrera apenas em um arquivo.
64
4.4.3 Interfaces de componentes de processos de software
Assim como ocorre no DBC, para a DPBC estabeleceu-se uma definicao de interfaces
para componentes de processo de software. Para qualquer nıvel de granularidade de
componente de processo e necessario definir os servicos daquele componente, bem como
os artefatos que ele utiliza ou produz em sua execucao. Os artefatos de um servico de
um processo sao instancias de algum termo descrito pela ontologia adotada pelo processo.
Deste modo, para cada artefato presente na definicao da interface, deve-se indicar qual
e o seu tipo. Alem disto e necessario informar para cada interface se ela sera a entrada
para algum servico do componente (interface requerida) ou saıda de resultados de servicos
do componente (interface provida). A figura 21 apresenta a definicao da interface de um
componente de processo. Uma interface pode ser definida formalmente como segue:
(∀x)interface(x) ∧ (requerida(x) ∨ provida(x))→
(∃y)(servico(y) ∧ compoe(y, x)) ∧
(∃z)(artefato(z) ∧ (entrada(z) ∨ saida(z)) ∧ pertence(z, y)) ∧
(∃w)tipoArtefato(w) ∧ instancia(w, z) (4.8)
Esta definicao indica que sendo x uma interface de componente do tipo requerida ou
provida, ela e composta por um ou mais servicos y. Seja z um artefato de processo, ele
deve ser entrada ou saıda e pertencera a um ou mais servicos y de uma interface x. Por
fim, seja w um tipo de artefato definido por uma ontologia, cada artefato z deve ser uma
instancia de um w.
Para a DPBC foi definida uma estrutura em linguagem XML capaz de especificar as
interfaces de componentes de processos de qualquer granularidade. Esta estrutura esta
em conformidade com a definicao 4.8 e um exemplo (generico) e apresentado na figura 22.
Vale ressaltar que esta definicao e valida para todos os nıveis de granularidade de
componentes de processo de software. Apesar de componentes do tipo “processo” ou “ati-
vidade” serem maiores do que um componente do tipo “tarefa”, a execucao dos servicos
daqueles componentes, bem como o consumo e producao de artefatos ocorrerao atraves da
execucao das “tarefas” que formam os componentes maiores. Deste modo os servicos es-
pecificados pelos componentes maiores serao, em algum momento, implementados atraves
de um componente de granularidade “tarefa”.
Por fim e importante considerar o uso de termos da ontologia na especificacao das
interfaces. As interfaces possuem um importante papel na DPBC, pois, de modo similar
65
<?xml version=” 1 .0 ” encoding=”UTF−8”?>
<componente>< i n t e r f a c e nomeInter face=” I n t e r f a c e 1 ” providaRequer ida=” provida ”>
<s e r v i c o nomeServico=” Serv i co1 ” numArtefatosEntrada=”3” numArtefatosSaida=”2”><a r t e f a t o nomeArtefato=”A1” entradaSaida=” entrada ”>t i po do a r t e f a t o</ a r t e f a t o><a r t e f a t o nomeArtefato=”A2” entradaSaida=” entrada ”>t i po do a r t e f a t o</ a r t e f a t o><a r t e f a t o nomeArtefato=”A3” entradaSaida=” entrada ”>t i po do a r t e f a t o</ a r t e f a t o><a r t e f a t o nomeArtefato=”A4” entradaSaida=” sa ida ”>t i po do a r t e f a t o</ a r t e f a t o><a r t e f a t o nomeArtefato=”A5” entradaSaida=” sa ida ”>t i po do a r t e f a t o</ a r t e f a t o>
</ s e r v i c o>
<s e r v i c o nomeServico=” Serv i co2 ” numArtefatosEntrada=”2” numArtefatosSaida=”2”><a r t e f a t o nomeArtefato=”A6” entradaSaida=” entrada ”>t i po do a r t e f a t o</ a r t e f a t o><a r t e f a t o nomeArtefato=”A7” entradaSaida=” entrada ”>t i po do a r t e f a t o</ a r t e f a t o><a r t e f a t o nomeArtefato=”A8” entradaSaida=” sa ida ”>t i po do a r t e f a t o</ a r t e f a t o><a r t e f a t o nomeArtefato=”A9” entradaSaida=” sa ida ”>t i po do a r t e f a t o</ a r t e f a t o>
</ s e r v i c o></ i n t e r f a c e>
</componente>
Figura 21: Estrutura XML para especificacao de interfaces de componentes de processo.
Figura 22: Especificacao da interface de um componente de processo. Esta figura apre-senta como uma interface de um componente pode ser especificada. Adaptada de (KOR-
THAUS; SCHWIND; SEEDORF, 2007)
ao DBC, e atraves de sua analise que sao conhecidos os servicos bem como os artefatos
utilizados pelo processo. No entanto o uso de termos de ontologias permite atingir um
nıvel maior de descricao e representacao dos artefatos do processo. Por isto a descricao
das interfaces se torna mais poderosa no que tange a expressabilidade.
4.4.4 Descricao de um componente de processo de software
Componentes de processo de software devem ser descritos de modo a facilitar sua
futura recuperacao e reutilizacao. Esta descricao deve contemplar as caracterısticas do
componente, tais como criacao, modos de reutilizacao, numero de versoes, dentre outras,
mas, principalmente, os aspectos e o conhecimento agregado ao processo representado.
Portanto a DPBC estabeleceu duas formas de descricao: a utilizacao de metadados em
componentes e a utilizacao de termos de ontologias em aspectos e conhecimento do pro-
66
cesso.
4.4.4.1 Descricao do componente de processo por metadados
Novamente atraves das similaridades apontadas por Osterweil (1987), Osterweil (1997)
foi possıvel considerar a utilizacao dos metadados definidos por Redolfi et al. (2004) para
o contexto de processos de software. Para a utilizacao desses metadados em compo-
nentes de processo, foram necessarias algumas adaptacoes em seus significados de modo
a contemplar as caracterısticas dos processos de software.
Alem disto o Dublin-Core apresentou alguns metadados que tambem seriam de grande
utilidade na descricao de componentes de processo. Isto foi possıvel devido a proposta
interdisciplinar do Dublin-Core, que visa a descricao de qualquer recurso disponibilizado
na Web.
Deste modo atraves de adaptacoes realizadas em ambas propostas, foi definido um
conjunto de metadados para a descricao do componente de processo de software. Esse
conjunto estabelece 5 grupos, cada qual formado por varios metadados que estao forte-
mente relacionados entre si e que buscam descrever caracterısticas similares do compo-
nente de processo. Tais grupos estao especificados a seguir:
• Identificacao: grupo de metadados que identifica o componente de processo, descre-
vendo caracterısticas como nome, fonte, data de criacao, dentre outros.
• Uso: grupo de metadados que apresenta aspectos relacionados a utilizacao do com-
ponente, descrevendo domınio do componente, tipo de processo representado, de-
pendencias com outros componentes, dentre outros.
• Maturidade: grupo de metadados que apresenta o grau de qualidade e maturidade
do componente, descrevendo versao e o numero de reutilizacoes daquele componente.
• Documentacao: grupo de metadados que descreve o processo de software, tais como
descricao do processo, modelo de processo adotado, idioma utilizado, dentre outros.
• Alteracoes: indica as possıveis formas de adaptacao daquele processo.
A tabela 3 apresenta os grupos citados acima com uma breve descricao de cada um
dos seus metadados.
67
Grupo Metadado Descricao
Identificacao
Identificador Numero ou string para representar unicamente aquelecomponente.
Nome Nome de identificacao do componente.Granularidade Tamanho do componente, ou seja, processo, atividade ou
tarefa.Fonte Informa de onde partiu o processo representado pelo com-
ponente (organizacao / projeto).Criador Informa o responsavel pela geracao do componente.Outro agente Pessoas que fizeram contribuicoes significativas para o
processo / componente.Data Data de criacao do componente.
Uso
Area Informa a area de foco do componente. Ex.: analise derequisitos, analise OO, testes, etc...
Proposito Informa para qual funcionalidade o componente pode serusado / qual o problema ele visa resolver.
Domınio Informa o domınio em que o processo descrito pelo com-ponente devera ser executado
Restricoes Define as restricoes do componente de processo.Tipo de pro-cesso
Determina se o componente de processo devera ser reu-sado em processo padrao, adaptado ou instanciado.
Relacionamento Apresenta os relacionamentos com outros componentes epossıveis dependencias.
Componentessimilares
Informa outros componentes que tem por finalidade aten-der um proposito muito similar.
MaturidadeNumero dereutilizacoes
Informa o numero de vezes que ele foi adotado. E umindicativo de maturidade do componente.
Versoes Informa as versoes disponıveis daquele componente.
Documentacao
Descricao Descricao sucinta acerca do componente e do processo.Modelo de pro-cesso
Informa o modelo adotado para representacao do pro-cesso.
Especificacaodas interfaces
Descreve as funcionalidades especificadas pelas interfacesbem como os artefatos utilizados e produzidos.
Cobertura Localizacao espacial e duracoes temporais do proceso.Direitos Direitos acerca do processoIdioma Idioma utilizado na descricao do processo.
Alteracoes Formas deadaptacao
Descreve possıveis pontos de adaptacao do componente aser reusado.
Tabela 3: Metadados de componentes de processo de software. Esta tabela apresenta osmetadados definidos a partir da proposta de (REDOLFI et al., 2004) e do Dublin-Core.
68
4.4.4.2 Descricao do processo por aspectos e conhecimento atraves de onto-logia
Os metadados apresentados na secao anterior sao utilizados para descrever o com-
ponente de processo de software. Eles nao apresentam um nıvel de expressao capaz de
considerar detalhes do processo representado pelo componente. O metadado que esta
mais proximo do processo e “Descricao” (definido no grupo documentacao). Entretanto
de acordo com sua propria definicao, trata-se de uma descricao sucinta e que nao expressa
detalhadamente as caracterısticas do processo. Deste modo os metadados auxiliarao ape-
nas na descricao do componente de processo e nao do processo em si.
Para descrever o processo de software e necessaria uma forma de descricao mais po-
derosa em termos de expressabilidade, capaz de considerar seus 3 aspectos (tecnico, or-
ganizacional e humano), alem do conhecimento adquirido ao longo de suas execucoes.
Isto permitira que, alem da descricao do componente atraves de metadados, exista uma
descricao detalhada do processo representado pelo componente em questao.
Entretanto cabe considerar que o modo como os aspectos e o conhecimento sao des-
critos pode variar consideravelmente, inclusive dentro de uma organizacao. Um exemplo
simples: um mesmo termo acerca do processo tem significados (entendimentos) diferentes
para diferentes membros da organizacao, ou o contrario, termos diferentes tem o mesmo si-
gnificado para distintos membros da organizacao. Portanto, deve haver algum mecanismo
capaz de formalizar os termos utilizados para a descricao do processo de software, que seja
capaz de exprimir o significado (semantica) do termo alem de estabelecer relacoes com
outros termos do processo. Uma maneira possıvel de realizar esta formalizacao necessaria
para descricao de processos de software e atraves de ontologias.
Portanto, os aspectos de um processo e o conhecimento agregado a ele deverao ser
descritos com base em um vocabulario padrao, estabelecido e mantido por uma ontologia.
A ontologia servira de base para definir alguns termos relativos ao processo de software
(armazenado em um componente). No entanto a descricao de um processo de software
ocorrera no momento em que for atribuıdo um valor a um termo da ontologia e relaciona-lo
a um aspecto ou conhecimento.
Para manter a conformidade com o modelo de processos apresentado na secao 4.2, a
descricao de um processo de software foi dividida conforme os aspectos e os tipos de conhe-
cimento estabelecidos nesta proposta. Deste modo cada uma dessas unidades de descricao
podera armazenar diversos itens de descricao de processo, sendo que cada um destes itens
devera atribuir valores aos termos definidos pela ontologia adotada pelo processo. A unica
69
Figura 23: Descricao dos aspectos e conhecimento de um processo.
excecao acontece para o aspecto tecnico pelo fato deste ter sido definido com base nos
elementos do SPEM. Para a descricao desse aspecto optou-se por atribuir valor a algum
elemento da ontologia e incluı-lo no elemento tecnico. Por isto nao ha ıtens de descricao
para os aspectos tecnicos, pois essa descricao ocorre atraves dos proprios elementos SPEM
que compoem o processo. A figura 23 apresenta a relacao entre as categorias e os ıtens
de descricao.
Note que este metodo proposto nao estabelece uma ontologia de processo, pois deste
modo o reuso de componentes de processo estaria restrito apenas aos componentes des-
critos por esta ontologia. De modo contrario o modelo de processos apresentado na secao
4.2 e a estrutura do componente definida na secao 4.4.1 foram estabelecidos de modo
a permitir a descricao das caracterısticas do processo independentemente da ontologia
adotada pelo processo. Essa independencia de ontologias vai permitir aumentar o nıvel
de reuso de componentes nas definicoes de novos processos. Devido a este fato, esta pro-
posta estabelece que todo componente de processo devera indicar o endereco da ontologia
utilizada para representacao de seu processo, pois ela sera fundamental, principalmente
durante o processo “com” reuso.
4.4.4.3 Resumo sobre a descricao de componentes de processo e processopara a proposta
A descricao de componentes em DPBC foi definida com base na descricao de compo-
nentes estabelecida em DBC, pois em ambos os casos tais descricoes sao de fundamental
importancia para recuperacao, analise e reutilizacao de componentes. Entretanto algu-
mas alteracoes foram realizadas em DPBC para levar em consideracao as caracterısticas
inerentes a processos de software.
70
<?xml version=” 1 .0 ” encoding=”UTF−8”?><rdf:RDF xml:base=” ht tp : // l o c a l h o s t /” xmlns:owl=” ht tp : //www. w3 . org /2002/07/ owl#”>
<rd f : componenteProcesso>< r d f : i d e n t i f i c a c a o>
< r d f : i d e n t i f i c a d o r> </ r d f : i d e n t i f i c a d o r><rdf :nome> </ rdf :nome><r d f : g r a n u l a r i d a d e> </ r d f : g r a n u l a r i d a d e><r d f : f o n t e> </ r d f : f o n t e><r d f : c r i a d o r> </ r d f : c r i a d o r><rd f : ou t ro sAgen t e s>
<r d f : a g e n t e> </ r d f : a g e n t e><r d f : a g e n t e> </ r d f : a g e n t e>
</ rd f : ou t ro sAgen t e s><r d f : d a t a> </ r d f : d a t a>
</ r d f : i d e n t i f i c a c a o>
<r d f : u s o><r d f : a r e a></ r d f : a r e a><r d f : p r o p o s i t o> </ r d f : p r o p o s i t o><rd f :domin io> </ rd f :domin io>< r d f : r e s t r i c o e s> </ r d f : r e s t r i c o e s><r d f : t i p o P r o c e s s o> </ r d f : t i p o P r o c e s s o><r d f : r e l a c i o n a m e n t o> </ r d f : r e l a c i o n a m e n t o><rd f : componente sS imi l a r e s> </ rd f : componente sS imi l a r e s>
</ r d f : u s o>
<rd f :matur idade><rd f : numReut i l i z a coe s> </ rd f : numReut i l i z a coe s><r d f : v e r s o e s> </ r d f : v e r s o e s>
</ rd f :matur idade>
<rdf :documentacao><r d f : d e s c r i c a o> </ r d f : d e s c r i c a o><rdf:modeloDeComponentes> </ rdf:modeloDeComponentes><r d f : e s p e c i f i c a c a o I n t e r f a c e s> </ r d f : e s p e c i f i c a c a o I n t e r f a c e s><r d f : c o b e r t u r a> </ r d f : c o b e r t u r a>< r d f : d i r e i t o s> </ r d f : d i r e i t o s><r d f : i d i om a> </ rd f : i d i o ma>
</ rdf :documentacao>
<r d f : a l t e r a c o e s><rdf : formasAdaptacao> </ rdf : formasAdaptacao>
</ r d f : a l t e r a c o e s></ rdf :componenteProcesso>
Figura 24: Trecho de codigo em RDF para definicao de metadados.
A descricao em DPBC ocorre de duas formas bem distintas: atraves da descricao
do componente de processo e da descricao do processo. A descricao do componente de
processo e realizada atraves dos metadados definidos pela tabela 3, de modo a contem-
plar apenas caracterısticas do componente de processo. Cada um desses metadados sera
representado no componente de processo de software atraves de uma marcacao (tag) de-
finida na linguagem RDF1 (Resource Description Framework). A figura 24 apresenta a
estrutura de um codigo RDF para descricao de um componente de processo. Este trecho
de codigo sera incluıdo no proprio componente de processo.
1Esta linguagem e uma extensao da linguagem XML e atualmente e mantida pelo consorcio W3C. Elafoi concebida de tal modo que seus usuarios pudessem definir suas proprias tags para representacao demetadados.
71
Os aspectos e conhecimentos relativos a um processo de software serao descritos por
meio de itens (de descricao ou de conhecimento), de modo que um aspecto ou tipo de
conhecimento podera conter varios itens de descricao / conhecimento. Cada um desses
itens podera utilizar em seu texto elementos que foram definidos pela ontologia de pro-
cesso, bastando para isto incluir tags OWL 2 com algum valor estabelecido pelo processo
representado pelo componente. A partir destas tags e de seus valores sera possıvel recupe-
rar os componentes do repositorio com base nos significados dos termos estabelecidos pela
ontologia. O trecho de codigo da figura 25 apresenta a estrutura para descricao de um
processo de software. Note que em um unico arquivo e possıvel descrever todos os aspectos
de um processo de software, sendo que, no caso do aspecto tecnico, a descricao e reali-
zada no proprio elemento definido pelo SPEM. Para os outros aspectos (organizacional e
humano), e possıvel estabelecer trechos de codigo XML para tratarem especificamente da
descricao do processo.
Uma caracterıstica importante desta proposta e a utilizacao de diversas linguagens
estabelecidas como padrao pelo W3C e representadas atraves da linguagem XML. O com-
ponente de processo e representado pelos elementos do SPEM, a descricao do componente
e realizada atraves de metadados definidos utilizando-se RDF e a descricao de processos e
realizada atraves de elementos definidos em OWL. Todas essas linguagens tem como base
a XML e por isto podem ser utilizadas de modo conjunto. Isto permite que para cada
arquivo XML contendo um componente de processo de software (representado atraves
de tags SPEM), sejam inseridas tambem tags RDF para a descricao por metadados e
tags OWL para descricao do processo. Deste modo um unico arquivo XML e capaz de
representar o componente de processo de software e armazenar os dois tipos de descricao
estabelecidos para a DPBC. A figura 26 descreve esta proposta de representacao e des-
cricao de um componente de processo de software.
4.5 Definicao de componentes de processo para reuso
de processos
Para que seja possıvel a definicao de processos a partir de componentes de processo, e
necessario que o repositorio seja populado com alguns componentes. De modo similar ao
DBC, foi estabelecida a “definicao para reuso”. E de responsabilidade desta definicao a
criacao do componente de processo e o armazenamento deste no repositorio. Para isto essa
2A linguagem OWL foi estabelecida pelo W3C como a linguagem padrao para representacao doselementos definidos por uma ontologia.
72
<?xml version=” 1 .0 ” encoding=”UTF−8”?>
<Process><annotat ion>
<documentation>d e s c r i c a o de um p r o c e s s o : nesta d e s c r i c a o poderao s e rusadas <tagsOWL/> r e l a t i v a s a termos da o n t o l o g i a .
</ documentation></ annotat ion><Act iv i ty>
<annotat ion><documentation>d e s c r i c a o de uma at i v idade do p r o c e s s o : nesta de s c r i−
cao poderao s e r usadas<tagsOWL/> r e l a t i v a s a termosda o n t o l o g i a .
</ documentation></ annotat ion><task>
<annotat ion><documentation>d e s c r i c a o de uma t a r e f a da a t i v i d a d e : nesta de s c r i−
cao poderao s e r usadas <tagsOWL/> r e l a t i v a s a termosda o n t o l o g i a .
</ documentation></ annotat ion>
</ task></ Act i v i ty>
<d e s c r i c a o O r g a n i z a c i o n a l><i t emDescr i cao t ipo=” papel ”>d e s c r i c a o de um papel com <tagsOWL/> representando
elementos d e f i n i d o s pe la o n t o l o g i a .</ i temDescr i cao><i t emDescr i cao t ipo=” r e s t r i c a o ”>d e s c r i c a o de uma r e s t r i c a o com <tagsOWL/> re−
presentando elementos d e f i n i d o s pe la o n t o l o g i a .</ i temDescr i cao>( . . . )
</ d e s c r i c a o O r g a n i z a c i o n a l>
<descricaoHumana><i t emDescr i cao t ipo=” h a b i l i d a d e s I n d i v i d u a i s ”>d e s c r i c a o de uma hab i l i dade ind i−
v idua l com <tagsOWL/> para e lementos da o n t o l o g i a .</ i temDescr i cao>
</descricaoHumana>
<conhecimento><itemConhecimento t ipo=” i d e i a ”></ itemConhecimento>
</ conhecimento></ Process>
Figura 25: Descricao de processos de software por meio de tags OWL.
Figura 26: Proposta de descricao de processos de software. Esta figura apresenta asdescricoes propostas nesta dissertacao. O componente e descrito atraves de metadadosrepresentados por tags RDF e o processo e descrito em todos seus aspectos e conhecimentoutilizando tags OWL.
73
definicao deve definir o escopo do componente de processo, criar o componente atraves
dos elementos definidos pelo SPEM, descrever o componente de metadados e o processo
atraves da utilizacao dos termos da ontologia e por fim, realizar sua insercao no repositorio
de componentes. Ao final da definicao para reuso o componente estara devidamente
armazenado e descrito no repositorio, o que significa que podera ser recuperado em futuras
buscas de componentes, tanto por metadados quanto pelas caracterısticas de seu processo.
A definicao para reuso abordada neste trabalho nao apresenta um processo para
criacao do componente de processo. Ela apenas estabelece que, para ser armazenado
no repositorio e ser reutilizado futuramente, um componente de processo de software
devera:
• ser representado por apenas um arquivo XML,
• utilizar o metamodelo SPEM para definicao do processo, representando-o no arquivo
XML atraves das tags SPEM,
• ser descrito atraves da atribuicao de valores aos metadados por meio das tags RDF
e,
• armazenar itens de descricao dos aspectos do processo e itens de conhecimento
relativos ao seu processo, os quais utilizam termos definidos pela ontologia atraves
da insercao de tags OWL.
A partir do momento em que o componente apresentar essas caracterısticas, ele podera
ser armazenado e referenciado no repositorio. Isto se da em tres etapas:
1. insercao do arquivo XML no repositorio,
2. indexacao dos metadados do componente,
3. indexacao dos termos utilizados nas descricoes do processo com base na ontologia
utilizada.
O primeiro passo devera garantir que o componente foi armazenado com sucesso no
repositorio e que sera identificado de modo unico. No segundo passo deve-se buscar os
valores de todos os metadados e incluı-los no repositorio, de modo a referenciar o compo-
nente. Por fim, o mesmo devera ocorrer com as descricoes do processo. Entretanto esta
atividade e mais complexa, pois antes de indexar as descricoes dos aspectos do processo
74
Inserir o componente (arquivo SPEM) no repositorio.para todo metadado do repositorio faca
buscar o valor no arquivo do componenteinserir o valor no repositorioreferenciar o valor ao componente armazenado no repositorio
fim parase ontologia nao foi inserida no repositorio entao
Incluir ontologia no repositoriopara todo termo da ontologia faca
Inserir o termo e sua descricao no repositorioRelacionar o termo a ontologia cadastrada
fim parafim separa todo aspecto do componente faca
para todo item de descricao facaReferenciar no repositorio a utilizacao dos termos da ontologia ao aspecto do componente
fim parafim parapara todo tipo de conhecimento do componente faca
para todo item de conhecimento facaReferenciar no repositorio a utilizacao dos termos da ontologia ao item de conhecimento do componente
fim parafim para
Figura 27: Algoritmo para insercao do componente de processo no repositorio
e do conhecimento no repositorio, e necessario garantir que a ontologia utilizada esta
disponıvel no repositorio. Caso nao esteja, deve-se inicialmente incluı-la no repositorio
juntamente com todos os seus termos e seus significados. Isto garante que os termos uti-
lizados na descricao do processo ja estarao disponıveis no repositorio no momento de seu
armazenamento. Finalmente deve-se estabelecer a relacao entre o termo da ontologia e
o item de descricao do componente em que ele foi utilizado. Este processo de armazena-
mento e indexacao de um componente no repositorio esta descrito atraves do algoritmo
representado na figura 27.
4.6 Definicao de processos com reuso de componentes
de processo
Como visto na secao 3.5, o desenvolvimento “com” reuso em DBC e responsavel pela
efetiva reutilizacao dos componentes de software para a construcao de um novo software.
Este tipo de desenvolvimento e tipicamente realizado atraves das 5 etapas apontadas por
(BROWN; SHORT, 1997), representados na figura 17.
Para a DPBC foi estabelecido um processo similar (ver figura 28), capaz de definir no-
vos processos de software a partir da reutilizacao de componentes de processo de software
extraıdos de um repositorio.
Chamado de “Definicao com Reuso” esse processo tambem e composto das 5 etapas
estabelecidas no desenvolvimento com reuso do DBC, quais sejam: busca, qualificacao,
75
Figura 28: Definicao de processos “com” reuso de componentes. Figura adaptada de(BROWN; SHORT, 1997) para a DPBC.
adaptacao, implantacao e atualizacao.
No entanto a definicao de processos “com” reuso tem que levar em consideracao as
descricoes dos aspectos e do processo e os itens de conhecimento relativos ao processo
de software, alem dos metadados e das especificacoes de interfaces do componente de
processo. Sendo essas descricoes de aspectos e conhecimento feitas com base nos termos
definidos pela ontologia adotada pelo processo, a definicao com reuso foi estabelecida
atraves de modificacoes realizadas no desenvolvimento “com” reuso tradicional de modo
a contemplar tambem a descricao de processos atraves de ontologias. Portanto cada uma
das 5 fases da definicao com reuso foi modificada de modo a considerar os elementos
definidos pela ontologia. Cada uma de suas fases esta descrita nas secoes seguintes.
4.6.1 Busca de componentes
Esta etapa da definicao com reuso tem como objetivo pesquisar o repositorio em
busca de componentes que possivelmente irao atender aos requisitos do novo processo de
software. Alem de extrair os componentes do repositorio, ela tenta estabelecer um nıvel
de equivalencia (atraves de operacoes denominadas matching) entre a especificacao de
76
requisitos do processo de software em definicao e a especificacao dos componentes vindos
do repositorio.
Duas fases bem distintas formam esta etapa: a primeira e responsavel apenas pela
busca de componentes candidatos no repositorio e a segunda aplica as operacoes de mat-
ching para estabelecer nıveis de equivalencia entre as especificacoes do novo processo e
dos componentes. A busca dos componentes no repositorio pode ser realizada atraves dos
metadados dos componentes, atraves dos termos da ontologia utilizados nas descricoes do
processo e conhecimento, ou por ambos. A operacao de matching e realizada sobre as
especificacoes das interfaces do componente e esta descrita a seguir.
4.6.1.1 Matching de especificacoes de componentes
Matching serve para comparar duas especificacoes de componentes de processo. A
equivalencia entre duas especificacoes de componentes e realizada atraves de suas inter-
faces, tendo como base a definicao de interfaces estabelecida na figura 22. A operacao de
matching pode variar indo desde a mais rıgida (hard), que nao permite divergencias entre
as especificacoes, ate a mais maleavel (soft), capaz de tolerar pequenas diferencas.
Foram definidos tres nıveis de equivalencia para componentes de processos de software:
1. Matching equivalente
2. Matching de numeros de parametros de entrada e saıda
3. Matching de numeros e tipos de parametros de entrada / matching de numeros e
tipos de parametros de saıda
Matching equivalente
Atraves deste matching e possıvel determinar se dois componentes sao equivalentes,
isto e, podem ser substituıdos, pois apresentam o mesmo comportamento definido.
Para o matching equivalente (ou exato) e necessario garantir que, para cada interface
do componente C1, haja uma interface equivalente no componente C2. Para que ocorra
esta equivalencia e necessario que ambas interfaces sejam do mesmo tipo (requerida ou
provida) e que para cada servico da interface do componente 1 exista um servico equi-
valente na interface do componente 2. Novamente, para que um servico seja considerado
equivalente a outro, e necessario que para cada um dos artefatos utilizados por ele exista
77
um equivalente (se for de entrada o equivalente tambem sera de entrada, do mesmo modo
para artefatos de saıda) e que eles sejam de mesmo tipo.
Portanto dois componentes de processo C1 e C2, sao equivalentes conforme:
(∀i1)interface(i1, C1)→ (∃i2)interface(i2, C2) ∧ (tipo(i1) = tipo(i2)) ∧
(∀s1)servico(s1, i1)→ (∃s2)servico(s2, i2) ∧
(∀a1)artefato(a1, s1)→ (∃a2)artefato(a2, s2) ∧
(tipoArtefato(a1) = tipoArtefato(a2)) ∧
((saida(a1) ∧ saida(a2)) ∨ (entrada(a1) ∧ entrada(a2))) (4.9)
Matching de numeros de artefatos de entrada e saıda
Esta equivalencia tem por objetivo garantir um alto nıvel de similaridade entre as es-
pecificacoes de dois componentes, sem garantir a equivalencia total entre eles, ao permitir
divergencias entre tipos de artefatos correspondentes em cada camponente. Ela estabelece
que, para cada servico definido na interface do componente C1, existe um correspondente
na interface do componente C2. Esta correspondencia devera garantir que ambas inter-
faces sejam de mesmo tipo (requerida ou provida) e que os numeros de artefatos de cada
servico das interfaces sejam iguais. Deste modo busca-se garantir a correspondencia entre
um servico presente na interface C1 com um servico presente na interface C2. No entanto,
o tipo dos artefatos em cada uma das interfaces podera variar. Esta especificacao esta
descrita abaixo:
(∀i1)interface(i1, C1)→ (∃i2)interface(i2, C2) ∧ (tipo(i1) = tipo(i2)) ∧
(∀s1)servico(s1, i1)→ (∃s2)servico(s2, i2) ∧
(∀a1)artefato(a1, s1)→ (∃a2)artefato(a2, s2) ∧
((saida(a1) ∧ saida(a2)) ∨ (entrada(a1) ∧ entrada(a2))) (4.10)
Matching de numeros e tipos de artefatos de entrada
Esta operacao tem por objetivo estabelecer equivalencia entre dois componentes bus-
cando por similaridades nos artefatos de entrada dos seus servicos. A restricao quanto
ao tipo da interface se mantem, sendo que ambas interfaces devem ser do tipo requerida.
Para cada servico presente na interface de C1, deve existir um correspondente na interface
de C2, sendo formado por artefatos equivalentes entre si (de mesmo tipo). Deste modo a
78
flexibilizacao ocorre nos artefatos de saıda do componente. Nao ha necessidade de haver
equivalencia de numero ou tipo para os artefatos de saıda. Este matching esta definido
como se segue:
(∀i1)interface(i1, C1)→ (∃i2)interface(i2, C2) ∧ tipoInterface(i1, i2,′′ entrada′′) ∧
(∀s1)servico(s1, i1)→ (∃s2)servico(s2, i2) ∧
(∀a1)artefato(a1, s1)→ (∃a2)artefato(a2, s2) ∧
(entrada(a1) ∧ entrada(a2))(4.11)
Matching de numeros e tipos de parametros de saıda
Esta equivalencia e similar a equivalencia de numeros e tipos de parametros de entrada.
No entanto ela busca estabelecer equivalencias nos artefatos de saıda do componente, nao
importando quais os artefatos estejam presentes em sua entrada. Deste modo, dados
os componentes C1 e C2, e necessario que as interfaces a serem comparadas sejam de
mesmo tipo (providas) e que, para cada servico presente em uma interface de entrada de
C1, exista um correspondente em C2. O numero e o tipo dos artefatos presentes em um
servico de saıda de C1 devem ser iguais aos do seu correspondente em C2. Este matching
esta formalizado por:
(∀i1)interface(i1, C1)→ (∃i2)interface(i2, C2) ∧ tipoInterface(i1, i2,′′ saida′′) ∧
(∀s1)servico(s1, i1)→ (∃s2)servico(s2, i2) ∧
(∀a1)artefato(a1, s1)→ (∃a2)artefato(a2, s2) ∧ (saida(a1) ∧ saida(a2))(4.12)
A etapa de busca da definicao com reuso esta representada graficamente atraves da
figura 29. A primeira parte da figura apresenta como os componentes sao recuperados do
repositorio de componentes. Esta recuperacao pode ser realizada com base em metadados,
com base em termos definidos pela ontologia que descrevem o processo ou em ambos.
No caso de metadados e necessario atribuir um valor a ser pesquisado para cada um
dos metadados desejados, tendo como resposta aqueles componentes de processo que
apresentarem os valores definidos. Para a busca atraves de descricao de processos e itens
de conhecimento de processos, e necessario pesquisar no repositorio qual componente
utiliza o termo da ontologia desejado e, caso haja mais de uma definicao para aquele
termo (pois um termo pode ser definido por mais de uma ontologia) deve-se escolher qual
o significado para que seja realizada a pesquisa. A partir de entao sao recuperados do
79
Figura 29: Diagrama de atividades para a etapa de busca de componentes. Este diagramarepresenta como a etapa de busca de componentes e realizada.
repositorio aqueles componentes cujos processos sao descritos por termos que utilizam o
significado desejado.
A segunda etapa e responsavel por aplicar as operacoes de matching nas especificacoes
dos componentes de modo a estabelecer nıveis de equivalencia entre eles e o processo em
definicao. Para isto e necessario agrupar os componentes recuperados pela busca por
metadados e pela busca por termos da ontologia. Este agrupamento pode ser realizado
atraves da uniao ou da intersecao dos componentes resultantes das duas buscas. A partir
de entao, para cada componente recuperado aplica-se as operacoes de matching de modo
a estabelecer o nıvel que ele equivale a especificacao do novo processo.
Portanto a busca de componentes de processos de software assemelha-se a busca de
componentes de software tradicionais, ao pesquisar o repositorio de componentes atraves
de metadados e estabelecer nıveis de equivalencia entre duas especificacoes com base nas
interfaces do componente. No entanto, devido ao contexto de processos de software,
para estabelecer a etapa de busca de componentes de processo foram necessarias algumas
alteracoes.
80
A primeira delas consiste em realizar a busca no repositorio por termos de ontologias
utilizados na descricao dos processos armazenados. Isto ja representa um grande avanco,
pois ao inves de realizar a busca somente atraves de dados que descrevem o componente,
e possıvel recuperar componentes de processo com base nos significados dos termos uti-
lizados nas descricoes e no conhecimento do processo representado pelo componente. De
fato, e uma busca muito mais poderosa no que tange a expressabilidade dos termos de
pesquisa utilizados.
A segunda alteracao necessaria foi a adequacao da operacao de matching de modo que
ela pudesse contemplar a estrutura de interfaces proposta pela figura 22. Esta operacao
de matching estabelece nıveis de equivalencia entre duas especificacoes, variando desde a
mais rıgida (que nao permite divergencias entre os servicos e os tipos de artefatos de cada
processo) ate a mais maleavel (em que podem ocorrer divergencias entre as interfaces de
entrada ou saıda de um componente de processo). Vale considerar que os tipos de artefatos
presentes na interface do componente sao descritos atraves de termos da ontologia. Isto
significa que a operacao de matching e parcialmente realizada com base no significado do
artefato.
4.6.2 Qualificacao de componentes
A etapa de qualificacao de componentes tem como objetivo determinar quais com-
ponentes serao reutilizados para a definicao de um novo processo de software. Tomando
como base os componentes vindos do repositorio atraves da etapa de “busca”, e necessario
estabelecer algum parametro que informe quais dos componentes recuperados poderao ser
reutilizados no novo processo.
Portanto, nessa etapa os componentes candidatos ao reuso serao avaliados detalha-
damente em todos seus aspectos, de modo a identificar vantagens e desvantagens em
sua reutilizacao. Esta avaliacao devera compreender a especificacao dos componentes de
processo (atraves de suas interfaces), as implementacoes dos processos, discussoes com
os responsaveis pela criacao dos componentes e suas execucoes em ambientes de testes.
Entretanto um fator muito importante a ser considerado durante essa etapa e o conheci-
mento armazenado nos componentes. Este item e de fundamental importancia, pois ele
sera uma ferramenta de suporte durante a escolha, a definicao e principalmente durante a
execucao do processo. Portanto, um dos aspectos que deve ser analisado cuidadosamente
nesta etapa e o nıvel de conhecimento provido pelos componentes, de modo que se possa
estabelecer como metrica o numero de itens de conhecimento armazenados pelo compo-
81
nente. Deste modo e sugerido que se dois componentes sao concorrentes diretos ao reuso,
aquele componente que apresentar o maior numero de itens de conhecimento devera ser
escolhido, pois espera-se que ele vai prover maior suporte a equipe durante a execucao do
processo.
Essa etapa pode, entao, ser dividida em tres fases. Tendo em vista que os requisitos do
processo em definicao nao necessariamente serao satisfeitos por apenas um componente,
ou seja, estarao distribuıdos em varios componentes, e necessario que os componentes
sejam avaliados utilizando o mesmo criterio. Isto implica que componentes deverao ser
agrupados conforme os requisitos que eles implementam. A primeira fase dessa etapa
consiste, entao, em identificar os componentes que concorrem entre si (seus processos
atendem aos mesmos requisitos) e agrupa-los em uma unidade comum. Para que sejam
agrupados e avaliados sob o mesmo criterio, e necessario que os componentes apresentem
a mesma granularidade.
Cada um dos agrupamentos sera utilizado na segunda fase da qualificacao de compo-
nentes. Essa fase e responsavel por estabelecer um criterio de inclusao do componente,
de modo que esse criterio deve-se fazer presente no componente para que este nao seja
excluıdo da etapa de qualificacao do componente. O criterio de inclusao pode ser definido
com base na especificacao do componente de processo (atraves das interfaces, como por
exemplo, utilizacao de determinado artefato como entrada de processo, presenca de de-
terminado servico em uma interface de saıda, etc...) ou atraves das descricoes do processo
ou dos itens de conhecimento. Deste modo e possıvel garantir, por exemplo, que deter-
minados papeis de membros da organizacao sao utilizados no processo componentizado,
que determinado tipo de conhecimento possui descricoes no componente, que determinada
ferramenta e utilizada pelo processo, dentre outros.
Por fim a terceira fase dessa etapa e responsavel por estabelecer um criterio de clas-
sificacao dos componentes de processo, de modo a identificar aqueles que possivelmente
irao trazer melhores resultados durante sua reutilizacao. Varios criterios podem ser esta-
belecidos como forma de classificacao dos componentes de processo, entretanto, o numero
de itens de conhecimento e uma importante metrica, pois indicara aquele componente que
possivelmente dara maior suporte durante sua execucao. Este criterio pode ser estabe-
lecido como sendo o numero total de itens de conhecimento acerca do processo ou para
um dado tipo de conhecimento (descricao, ideia, dentre outros). Portanto, mais de um
criterio de classificacao pode ser estabelecido na etapa de qualificacao de componentes de
processo. Toda essa etapa esta representada na figura 30.
82
Figura 30: Diagrama de atividades para a etapa de qualificacao de componentes. Estaetapa e responsavel por definir quais componentes serao utilizados na composicao do novoprocesso.
4.6.3 Adaptacao de componentes
Os componentes resultantes da fase de qualificacao serao reutilizados para a definicao
do novo processo de software. Entretanto, tal como ocorre em DBC, sao raros os casos em
que os componentes recuperados ja apresentam interoperabilidade. Na grande maioria das
vezes, sao necessarias pequenas adaptacoes em suas interfaces de modo que eles possam
se comunicar e trocar artefatos. A fase de adaptacao de componentes foi estabelecida com
o proposito de resolver inconsistencias identificadas entre as interfaces dos componentes
que irao compor o novo processo.
Pelo fato desta proposta adotar o SPEM como metamodelo de processos de software,
espera-se que nao ocorram adaptacoes para tornar compatıveis os componentes de pro-
cesso de software e os ambientes em que serao executados. Esta expectativa se justifica se
for possıvel garantir que tanto o componente de processo de software quanto o ambiente
de execucao estao em conformidade com o SPEM, pois deste modo o SPEM estara agindo
como um modelo de componentes3.
3Modelos de componentes sao padroes a serem respeitados tanto pelos ambientes de execucao quanto
83
Figura 31: Adaptacao de componentes de processo por ontologias.
Deste modo para esta proposta sao necessarias apenas as adaptacoes decorrentes de di-
vergencias entre especificacoes de servicos dos componentes e especificacoes de servicos do
novo processo. Essas divergencias tem como origem a flexibilizacao do matching realizado
na operacao de busca no repositorio ou o uso de diferentes ontologias pelos componentes.
As possıveis divergencias sao:
• diferencas entre nomes de servicos, nomes de artefatos e seus tipos, entre compo-
nentes de processo qualificados.
• os requisitos do processo em definicao sao satisfeitos parcialmente pelo componente
qualificado.
Para a primeira divergencia, considera-se que a diferenca ocorre entre os termos utili-
zados nos elementos das interfaces dos componentes, sendo provavelmente ocasionado por
componentes que utilizam diferentes ontologias. Caso os elementos das interfaces inconsis-
tentes difiram apenas na nomenclatura, mas sao essencialmente equivalentes (dois termos
utilizados para representar um mesmo elemento de software), deve-se estabelecer que os
termos das ontologias adotadas sao sinonimos o que permite entao a compatibilidade entre
as interfaces. Este cenario esta descrito na figura 31.
Para a segunda divergencia considera-se que alguns elementos das interfaces sao in-
compatıveis por serem realmente diferentes. Nestes casos e necessario que uma abordagem
similar ao “Glue Code” estabelecido em DBC seja aplicada, de modo que seja inserido
pelos componentes, para que sejam inter-operaveis(REDOLFI et al., 2004)
84
entre os componentes um outro componente para interliga-los. Este componente adapta-
dor necessariamente devera utilizar as ontologias dos outros dois componentes, pois ele
sera responsavel por compatibilizar elementos de dois processos descritos por ontologias
distintas. Este cenario esta representado na figura 32. O componente adaptador devera
ser recuperado do repositorio de componentes de processo ou entao ser definido “a partir
do zero”, caracterizando assim uma definicao “para” reuso.
Figura 32: Adaptacao de componentes de processo por componentes adaptadores.
A fase de adaptacao de componentes consiste de duas fases. A primeira e responsavel
por identificar se as inconsistencias entre os componentes ocorrem pela utilizacao de onto-
logias diferentes ou se os elementos das interfaces dos componentes sao realmente distintos.
A partir de entao, e definida a adaptacao a ser realizada nos componentes. Caso sejam
apenas divergencias entre termos utilizados para descrever os elementos de processo, deve-
se considera-los como sinominos. Entretanto caso sejam elementos realmente distintos,
deve-se pesquisar o repositorio em busca de um componente adaptador. Note que este
componente sera recuperado atraves de uma nova definicao “com reuso” ou seja, pelas
etapas de busca, qualificacao, adaptacao e implantacao de componentes estabelecidas pelo
DPBC. No entanto esta nova definicao “com” reuso tem um proposito muito especıfico:
encontrar um componente adaptador para outros dois componentes de processo.
A fase de adaptacao de componentes de processo esta representada na figura 33.
4.6.4 Implantacao de componentes
Assim como ocorre no DBC, a fase de implantacao e responsavel pela efetiva reuti-
lizacao de um componente de processo. Ela e responsavel por inserir os componentes de
processo adaptados no ambiente em que serao executados. Esta implantacao nao deve
85
Figura 33: Fase de adaptacao de processos
abranger somente os aspectos do processo (tecnicos, organizacionais e humanos), mas
tambem o conhecimento armazenado nos componentes, de modo que ele esteja disponıvel
aos membros da organizacao durante a execucao do processo.
No entanto o reuso de componentes de processo difere do reuso tradicional em de-
correncia da natureza do componente reutilizavel. Lembrando que o componente de pro-
cesso de software e definido atraves de elementos SPEM representados em XML, essa
linguagem nao tem capacidade de ser executada ou interpretada, haja visto que ela nao
prove funcionalidades. Ela simplesmente representa todo o processo de software atraves
da definicao de uma estrutura hierarquica, onde cada elemento representa uma entidade
constituinte do processo. Por isto nao faz sentido falar que o componente de processo
de software estabelecido por esta proposta sera integrado ao ambiente de execucao de
processos e seus servicos serao executados pelo proprio componente, tal qual ocorre no
DBC.
Portanto, o reuso efetivo de um componente de processo de software ocorre atraves da
importacao da descricao do processo armazenado no componente no ambiente de execucao.
Importante notar que o modelo de processos (SPEM) continuara agindo como o modelo
de componentes, pois, ao ser adotado, ele estabelece que tanto o ambiente de execucao de
86
Figura 34: Implantacao de componentes de processo.
processos quanto o componente devem utilizar os mesmos elementos para representacao
de um processo. Deste modo qualquer ferramenta aderente ao SPEM podera ser capaz
de importar as descricoes de processos armazenadas em componentes de processo. Para
que a ferramenta possa prover o reuso de componentes de processo, ela devera definir
sua rotina de importacao de processo com base nos elementos estabelecidos pelo modelo
de processo. Deste modo percebe-se que a importacao de um processo e dependente do
modelo e da ferramenta em que sera implantada.
O ambiente de execucao do processo tambem deve levar em consideracao o conheci-
mento armazenado junto com o componente. Por isto, cada um dos itens de conhecimento
relativos ao processo deve ser importado para a ferramenta, mas esta atividade tende a ser
mais complexa se comparada a importacao do processo, devido ao fato deste ultimo agir
como um contrato a ser respeitado entre componente e ferramenta. No caso do conhe-
cimento, este pode ocorrer de diversas maneiras (como definido na secao 4.2) e utilizar
termos definidos por varias ontologias. Deste modo, para a importacao do conhecimento
do processo, a ferramenta devera ser capaz de armazenar as definicoes de termos estabe-
lecidas pela ontologia e os itens de conhecimento relativos ao processo.
A implantacao de um componente de processo de software esta representada pela
figura 34. Ela devera ser iniciada pela inclusao dos termos da ontologia na ferramenta,
haja visto que termos definidos por ela podem aparecer tanto nos diversos aspectos do
processo quanto nos itens de conhecimento. Posteriormente o processo de software deve ser
incluıdo na ferramenta, tomando-se o cuidado de ligar os aspectos tecnicos, organizacionais
e humanos com os termos definidos pela ontologia. Por fim, a importacao dos itens de
conhecimento sera realizada, novamente, fazendo a ligacao desses itens com os termos
87
da ontologia. Ao final desta fase o processo e seus itens de conhecimento terao sido
importados para o ambiente de execucao do processo e estarao disponıveis para serem
executados.
4.6.5 Atualizacao de componentes
A fase de atualizacao de componentes e responsavel pela troca de um componente por
um outro de qualidade mais alta e cujos servicos apresentem mais vantagens. Para realizar
esta substituicao e necessario identificar os requisitos do componente a ser substituıdo,
pesquisar no repositorio quais os componentes que possivelmente irao atende-los, escolher
dentre eles aquele que melhor ira substituı-lo, realizar as adaptacoes necessarias, caso haja
inconsistencias entre o novo componente com os demais e com o ambiente de execucao e,
por fim, realizar sua implantacao. Portanto, como se pode perceber, a fase de atualizacao
de componentes compreende todas as outras fases previamente citadas, no entanto ela
tem como objetivo a substituicao de um componente ja implantado.
Esta caracterıstica de substituicao de componentes para a fase de atualizacao de
componentes implica no modo como a definicao com reuso e executada, principalmente
na busca de componentes de processo no repositorio. A alteracao de um componente
deve apresentar o menor impacto possıvel, no que tange a adaptacoes e modificacoes do
componente reutilizado. Portanto, esta proposta estabelece que, para a atualizacao de
componentes, deve-se tentar estabelecer um matching equivalente entre as especificacoes
do componente a ser substituıdo e os componentes armazenados no repositorio, pois desta
forma nao ha necessidade de alteracoes ou adaptacoes do novo componente.
Portanto, a fase de atualizacao de componentes pode ser definida como sendo a
execucao das outras 4 fases da DPBC (busca, qualificacao, adaptacao e implantacao),
mas com objetivos de substituicao de componentes presentes em processos ja implanta-
dos. Essa substituicao devera ocorrer de modo muito controlado, de modo a impactar o
mınimo possıvel nos demais componentes que formam o processo de software.
4.7 Trabalhos relacionados
Em Hollenbach e Frakes (1996) o reuso de processos e definido como “a utilizacao
da descricao de um processo na criacao da descricao de outro processo”, sendo ele mais
reusavel quando pode ser utilizado em diversas situacoes sem alterar os seus requisitos. No
entanto, os autores reconhecem a necessidade de adapta-lo no momento em que esta sendo
88
reusado. O trabalho apresenta ainda um metodo para criacao de processos reusaveis e sua
aplicacao na industria. A melhoria apresentada e da ordem de dez vezes em se tratando
de tempo e esforco necessarios para a definicao de um processo atraves da reutilizacao de
elementos pre-existentes.
Em Succi et al. (1997) o reuso de processos de software e definido como sendo a
replica de um conjunto de acoes de um processo (que ja foi instanciado) em um novo
ambiente. Portanto o trabalho nao lida com a adaptacao do processo ao ambiente em que
sera inserido, mas apenas com sua copia. Os autores o consideram de forma orientada por
objetos, representando seus aspectos estaticos e dinamicos atraves de diagramas UML, o
que vai de encontro com a posicao defendida por (OSTERWEIL, 1987; OSTERWEIL, 1997).
No modelo proposto foram identificadas quatro entidades que compoem um processo de
software: pessoas, papeis, processos e infraestrutura. Nota-se, entao, que a proposta leva
em consideracao os aspectos tecnicos, humanos e organizacionais.
De acordo com Henninger (1998) o reuso de processos e de artefatos de software devem
ser tratados juntos, pois se um processo e reusado varias vezes, os artefatos gerados por
cada uma de suas execucoes possuem grandes similaridades. A proposta consiste em
utilizar um repositorio como um esquema onde sao armazenadas solucoes para diversos
problemas relativos a processos de software (ou seja, conhecimento) alem dos artefatos
gerados em suas execucoes. Com base em varias perguntas feitas e conforme as respostas
obtidas, define-se um processo composto de elementos vindos do repositorio. Este passara
ainda por uma avaliacao para sua adequacao as necessidades do projeto, quando poderao
ocorrer adaptacoes.
Em Costa et al. (2007) os autores apresentam uma ferramenta de apoio a reutilizacao
de processos de software baseada na tecnica de reuso denominada “Template”. O tem-
plate e definido como sendo uma estrutura para representacao de modelos de processos
abstratos, em que sao descritos seus dados, comportamentos e funcionalidades e que pode
ser customizado para atender as especificidades do contexto em que vai ser reutilizado.
Durante a definicao pode-se utilizar todo o template ou apenas partes dele. Apesar do
trabalho mencionar sobre o conhecimento gerado durante a execucao do processo, ele nao
apresenta como o conhecimento e utilizado nos templates, ou seja, nao leva em conta o
conhecimento ao definir um processo de software.
Uma proposta para definicao de processos de software fortemente baseada em tecnicas
de reutilizacao vem sendo desenvolvida como tese de doutorado por Barreto, Murta e
Rocha (2007), Barreto, Murta e Rocha (2009). Nela sao apresentadas diversas tecnicas
89
de reutilizacao de software e como elas poderiam ser aplicadas no contexto de processos
de software. Aliado a estas tecnicas, o autor tambem propoe a utilizacao de Gerencia de
Conhecimento, uma vez que ele pretende reutilizar tambem o conhecimento gerado em
execucoes anteriores.
Cada projeto e unico em termos de requisitos de clientes, tecnologias, dentre outros,
o que faz necessario adaptar o processo padrao da organizacao aos projetos antes de sua
adocaoXu (2005). De acordo com o autor, uma forma de facilitar tal adaptacao e ter algum
tipo de conhecimento como suporte (de modo a diminuir as chances de erros e retrabalho)
e reutilizar produtos ou experiencias que tiveram exito no passado. Entretanto, a pesquisa
lida apenas com o conhecimento para a adaptacao de processos.
A partir da analise dos trabalhos mencionados anteriormente, percebe-se entao que
ha um movimento em direcao a reutilizacao de processos de software utilizando tecnicas
de gerencia de conhecimento como ferramenta de auxılio. E possıvel concluir que este
trabalho esta inserido neste contexto de reutilizacao de processos de software.
4.8 Consideracoes finais
Este capıtulo apresentou a proposta deste trabalho: um metodo para apioar a de-
finicao de processos de software a partir de componentes de processo. Essa proposta foi
baseada fortemente no Desenvolvimento Baseado em Componentes, buscando os concei-
tos mais significativos desta tecnica e alterando-os de modo a contemplar o contexto de
processos de software. Os elementos principais do DBC, quais sejam componente de soft-
ware, repositorio de componentes, desenvolvimento “para” reuso e desenvolvimento “com”
reuso, tambem formam o nucleo da DPBC. No entanto cada um desses elementos teve
que sofrer alteracoes de modo a contemplar as caracterısticas de processos de software
estabelecidas pelo modelo apresentado na secao 4.2.
A primeira grande diferenca entre as tecnicas esta na forma de representacao dos
componentes. Enquanto no DBC os componentes sao funcionalidades sob a forma de
binarios ou codigo-fonte, no DPBC o componente de processo representa a estrutura de
um processo atraves de uma linguagem estruturada. Portanto, o componente de processo
de software nao pode ser “executado” diretamente, tal como ocorre no DBC. A reutilizacao
do processo se da pela importacao da estrutura do processo de software em um ambiente
capaz de armazena-lo. Essa diferenca estabelece que o componente de processo nao vai ser
simplesmente “plugado” no ambiente de execucao: e necessario que o componente esteja
90
descrito no modelo de processos adotado pelo ambiente em que sera executado de modo
a permitir sua inclusao nesta.
A segunda diferenca surge na definicao de processos com reuso. Como visto, essa
definicao e equivalente ao desenvolvimento com reuso do DBC. Ja existem trabalhos que
aplicam ontologias em componentes de software tradicionais para facilitar a recuperacao,
principalmente na especificacao das interfaces e dos servicos que o componente prove.
Em DPBC ontologias tambem sao utilizadas para descricao do componente de processo e
dos servicos estabelecidos pelo processo. Alem disso, a DPBC permite que a recuperacao
de um componente de processo seja realizada atraves de termos que estao presentes nas
descricoes de outros elementos constituintes do componente, tais como os aspectos do
processo e os itens de conhecimento. Portanto, a reutilizacao de processos de software
pode ser feita nao apenas com base nas especificacoes do processo, mas tambem em outras
caracterısticas que podem ser de extrema relevancia para a organizacao.
91
5 Ferramenta
5.1 Introducao
Foi desenvolvida a ferramenta DPBC (Definicao de Processos Baseada em Compo-
nentes), de modo a auxiliar a definicao de processos de software a partir da reutilizacao
de componentes de processo. Os objetivos dessa ferramenta sao:
• buscar os componentes no repositorio;
• qualifica-los de modo a selecionar aqueles que tem potencial para serem reutilizados;
• identificar as inconsistencias entre interfaces e sugerir adaptacoes.
Como se pode perceber, os objetivos apresentados acima correspondem as tres pri-
meiras etapas do metodo proposto. A busca de componentes e responsavel por pesquisar
o repositorio por metadados, por termos definidos pelas ontologias de processo adotadas
pelos componentes, ou por ambos. A qualificacao de componentes define criterios de in-
clusao e classificacao do componente. A fase de adaptacao e responsavel por identificar
as inconsistencias e propor alteracoes.
As outras duas fases do metodo proposto (implantacao e atualizacao) nao foram consi-
deradas nesta ferramenta. Em se tratando da implantacao, esta e uma atividade muito
ligada ao ambiente de execucao do processo, pois cada ferramenta e responsavel por de-
terminar a sua forma de importacao de um processo de software. No caso da atualizacao
de componentes, conforme visto no capıtulo anterior, e uma atividade em que toda a
definicao “com” reuso e executada com vistas a obtencao de componentes equivalentes.
Deste modo a ferramenta ja oferece suporte a essa atividade.
Esta ferramenta foi desenvolvida utilizando o ambiente Borland C++ Builder, de
modo que aplicacao e o repositorio de componentes sao implantados no mesmo equipa-
mento. Tendo em vista que a definicao de processos geralmente e realizada por uma pessoa
92
(representando o papel de gerente de processos / projeto na organizacao), verificou-se que
nao era necessario que a ferramenta fosse distribuıda.
Figura 35: Modelagem de domınio da ferramenta DPBC.
Partindo da analise dos elementos basicos que definem o metodo de reuso proposto
neste trabalho, foi construıdo o modelo de domınio da ferramenta que esta representado na
figura 35. Como se pode perceber, o componente possui um papel central neste domınio,
pois ele e o responsavel por representar um processo de software. O componente pode ser
descrito atraves da atribuicao de valores a metadados, os quais podem ser agrupados em
categorias, conforme definido pela tabela 3. A atribuicao de valores a metadados para um
componente esta representada pela classe associativa DescricaoMetaDado.
Alem disto, o processo (representado pelo componente) possui aspectos que o descre-
vem, categorizados em tecnicos, organizacionais e humanos. A descricao de um processo
93
atraves de um desses aspectos e realizada atraves da atribuicao de algum texto descritivo
na classe associativa DescricaoAspecto presente entre as classes Componente e Aspecto.
O componente de processo de software pode possuir varios itens de conhecimento,
sendo que esses itens de conhecimento sao de algum tipo (ideia, duvida, descricao de
processo, dentre outros) conforme estabelecido no modelo de processo proposto na secao
4.2. A representacao de um item de conhecimento em um processo de software ocorre
atraves de sua descricao textual por meio da classe Conhecimento.
Entretanto estas duas formas de descricao de processos (por aspecto e por conheci-
mento) devem ser expressas atraves de termos cujos significados sejam conhecidos e com-
partilhados pela organizacao. Portanto, os termos que compoem cada uma das formas
de descricao sao estabelecidos e mantidos pela ontologia adotada pelo processo. Como
esta proposta nao se restringe a apenas uma ontologia, e possıvel que um termo seja
definido por mais de uma ontologia ao mesmo tempo o que significa que ele podera ter
significados diferentes. Deste modo a classe associativa DescricaoTermo, presente entre
as classes Ontologia e Termo e responsavel por armazenar a semantica de um determinado
termo em uma determinada ontologia. A partir dos significados dos termos das ontologias
representados pela classe DescricaoTermo serao descritos os itens de conhecimento e os
aspectos do processo de software.
A construcao do modelo de domınio ocorreu paralelamente com a construcao da ferra-
menta. Este capıtulo apresenta a ferramenta atraves de um exemplo simples de utilizacao.
Neste exemplo, um componente de granularidade “tarefa” e recuperado do repositorio,
qualificado e adaptado para que possa ser implantado em um ambiente de processo. Esse
componente representa a tarefa “Desenvolver visao tecnica”, definida no processo de re-
quisitos do OpenUP.
A secao 5.2 apresenta o suporte da ferramenta para a atividade de busca de com-
ponentes de processo no repositorio, atraves de metadados e de termos de ontologia. A
secao 5.3 apresenta como a ferramenta auxilia na tarefa de qualificacao e classificacao de
componentes de processo. Na secao 5.4 e apresentada como a ferramenta aborda a fase
de adaptacao de componentes de processo. Por fim, na secao 5.5 sao apresentadas as
conclusoes deste capıtulo.
94
Figura 36: Busca de componente no repositorio por metadados atraves da ferramenta.
5.2 Busca de componentes
Na secao 4.6.1 a atividade de busca de componentes foi apresentada. Essa atividade
e realizada atraves de duas etapas bem distintas: a busca por metadados ou por termos
definidos pela ontologia de processo e a uniao / intersecao dos resultados de cada uma das
buscas. A tela da ferramenta responsavel por automatizar esta pesquisa ao repositorio
esta apresentada na figura 36.
A recuperacao de componentes pode ser realizada ao atribuir valores de consulta
aos metadados ou pela procura de elementos da ontologia em descricoes de aspectos e
conhecimentos. Portanto esta tela apresenta as duas maneiras de realizar a pesquisa. O
resultado desta pesquisa sera determinado pela intersecao ou uniao dos resultados das
buscas por metadados e termos de ontologia. Para cada componente recuperado, pode-se
obter mais informacoes sobre ele, atraves de um duplo-clique na tabela de resultados.
A tela de informacoes sobre o componente esta representada na figura 37. Como se
pode notar, esta interface apresenta as formas de descricao de componentes por meio de
metadados (onde cada grupo de metadado e representado em uma aba) e dos aspectos e
conhecimento do processo.
95
Figura 37: Informacoes do componente atraves da ferramenta.
5.3 Qualificacao de componentes
Como visto na secao 4.6.2, a qualificacao de componentes e a atividade responsavel por
avaliar os componentes recuperados do repositorio, eliminar aqueles que nao apresentam
as caracterısticas desejadas para o novo processo e classifica-los segundo algum criterio.
A qualificacao de componentes deve ser realizada para um conjunto de componentes que
concorrem entre si por (possivelmente) atenderem ao mesmo requisito. Deste modo, para
cada requisito, deverao ser formados grupos de componentes candidatos, sendo que, para
tais grupos, serao definidos os criterios de inclusao e de classificacao. Este processo e
representado pelo diagrama da figura 30.
O criterio de inclusao e responsavel por permitir que o componente candidato prossiga
nas atividades de definicao com reuso. Caso o componente nao atenda a este criterio, ele e
descartado da etapa de qualificacao. Atualmente a ferramenta estabelece como criterio de
inclusao a presenca de termos da ontologia em algum item de descricao do componente.
Portanto, o responsavel pela definicao do processo devera indicar claramente quais os
termos da ontologia ele deseja que o componente utilize.
96
Figura 38: Qualificacao e classificacao de componentes atraves da ferramenta.
A ferramenta ainda estabelece o criterio de classificacao como sendo o numero de itens
de conhecimento armazenados pelos componentes. Com esse criterio, os componentes sao
apresentados em ordem decrescente, de modo que o componente que aparece no topo
da lista (possivelmente) ira prover o maior suporte durante a reutilizacao e execucao do
processo, pelo fato de ter um numero maior de conhecimento armazenado nele.
Na figura 38 esta apresentada a tela da ferramenta utilizada durante a qualificacao do
componente. Note que nessa tela podem ser incluıdos termos de varias ontologias como
criterio de inclusao. Para isto basta selecionar a ontologia no combobox. Neste momento
sao apresentados os termos definidos por ela. A partir de entao, adiciona-se o termo no
criterio de qualificacao.
5.4 Adaptacao de componentes
A atividade de adaptacao e responsavel por identificar as divergencias entre duas es-
pecificacoes de componente e propor adaptacoes de modo a torna-los compatıveis, como
visto na secao 4.6.3. As adaptacoes sugeridas para esta atividade podem ocorrer atraves
da definicao de sinonimos entre termos da ontologia (ver figura 33) ou por meio de com-
97
ponentes de processo adaptadores inseridos entre os componentes que apresentam incom-
patibilidades (ver figura 32).
Esta e a ultima atividade da definicao com “reuso” que a ferramenta oferece suporte,
sendo que, das duas formas de adaptacao sugeridas, foi considerada apenas a adaptacao
por meio de componente adaptador. Isto se deve ao fato desta ferramenta apenas utilizar
as ontologias de processo para estabelecer relacoes entre os componentes. Esta ferramenta
nao tem o intuito de operar as ontologias diretamente, ficando essa atividade a cargo de
outras ferramentas editoras de ontologia de processo.
A figura 39 apresenta um cenario em que duas especificacoes apresentam divergencias.
Na parte superior da tela esta representada a especificacao do servico “Desenvolver visao
tecnica”, que prove um artefato (saıda) chamado Visao. Na parte inferior da tela encontra-
se a especificacao do servico “Identificar requisitos”, que requer (entrada) os artefatos
visao, glossario e casos de uso. Pode-se perceber que ha uma relacao inconsistente entre
os dois componentes de processos especificados por essas interfaces. A primeira prove um
artefato para a segunda, enquanto esta requer mais dois artefatos para que seu servico
possa ser executado. Neste caso a solucao e encontrar algum componente adaptador capaz
de resolver esta inconsistencia. Isto se da pela procura de um componente no repositorio,
atraves da opcao “Buscar componente adaptador”.
Figura 39: Adaptacao de componentes atraves da ferramenta.
Esta opcao realiza uma pesquisa no repositorio para encontrar um componente que
apresente ao menos 2 interfaces, de modo que uma satisfaca a especificacao do primeiro
componente e a outra atenda a especificacao do segundo componente. Assim que este
componente for encontrado, deve-se avancar para a atividade seguinte responsavel pela
98
implantacao do componente no ambiente de execucao de processos. Conforme visto no
inıcio do capıtulo, esta e uma atividade a ser definida para cada ambiente de execucao de
processos e esta fora do escopo desta ferramenta.
5.5 Consideracoes finais
Este capıtulo apresentou a ferramenta desenvolvida para auxiliar a definicao “com”
reuso de processos. Inicialmente foram apresentados os objetivos da ferramenta e o seu
modelo de domınio. Embora a proposta deste trabalho seja definida atraves de cinco
atividades (busca, qualificacao, adaptacao, implantacao e atualizacao), o escopo da ferra-
menta cobre apenas as tres primeiras atividades. A maneira como a ferramenta aborda
cada uma dessas atividades foi apresentada posteriormente.
E importante notar que esta e uma ferramenta de auxılio a definicao de novos pro-
cessos. Ela nao tem a pretensao de automatizar toda a definicao com reuso, pois e
reconhecido que algumas decisoes durante a definicao de processos devem ser tomadas
com base na analise dos componentes pelo profissional responsavel por esta tarefa. No
entanto, a ferramenta auxilia a busca de componentes que satisfacam aos criterios.
99
6 Conclusoes
6.1 Introducao
Este trabalho apresentou uma proposta para reutilizacao de processos de software
junto com o conhecimento adquirido ao longo de suas execucoes passadas. A proposta
consiste em representar processos de software (ou partes dele) em estruturas reutilizaveis
denominadas componentes de processo.
Tais componentes abrangem os diversos aspectos de um processo de software (tecnicos,
organizacionais e humanos), alem de armazenar o conhecimento adquirido ao longo de suas
execucoes passadas. Foram estabelecidas duas formas de descricao nesta abordagem: a
descricao do componente de processo por metadados e a descricao de processos por termos
definidos em ontologias.
Foram, ainda, estabelecidas as definicoes “para” e “com” reuso, sendo a primeira
responsavel pela criacao de componentes de processo. A definicao “com” reuso e o tema
principal desta proposta e estabelece um metodo para definicao de processos de software
que vai desde a busca de componentes no repositorio ate a implantacao no ambiente de
execucao de processos. Neste caso a reutilizacao de processos e realizada com base nos
aspectos e no conhecimento armazenado em cada componente de processo. Por fim, foi
proposta uma ferramenta que auxilia nas atividades de busca, qualificacao e adaptacao
de componentes, as quais compoem a definicao “com” reuso.
Este capıtulo apresenta as conclusoes deste trabalho bem como as perspectivas futuras.
6.2 Conclusao e contribuicoes
Atualmente as organizacoes tem buscado atingir nıveis mais altos de qualidade, seja
atraves de tecnicas focadas no produto desenvolvido ou por meio de acoes realizadas sobre
o processo de desenvolvimento. Entretanto, uma proposta capaz de unir as duas aborda-
100
gens deve ser de grande ajuda a estas organizacoes, podendo, inclusive, potencializar os
resultados a serem obtidos quando elas sao consideradas separadamente. Neste contexto
este trabalho propos a adaptacao de um metodo de reuso tradicional para processos de
software, de modo que os benefıcios decorrentes tanto da tecnica de reutilizacao quanto
das melhorias de processo ocorram de forma conjunta.
Diante dos temas e da proposta apresentada neste trabalho, e possıvel afirmar que
software e processos de software possuem muitas caracterısticas em comum conforme
defende (OSTERWEIL, 1987; OSTERWEIL, 1997). De fato, foi possıvel adotar uma tecnica
de reuso de software no contexto de processos de software. Contudo, foram necessarias
varias alteracoes em toda a tecnica para que ela considerasse as diversas caracterısticas
de um processo de software. Todos os elementos que definem a DBC sofreram adaptacoes
para surgir, entao, a proposta DPBC.
A estrutura definida para o componente de processo foi capaz de representar os dife-
rentes aspectos e armazenar o conhecimento de um processo de software. Apesar de sugerir
conjuntos iniciais para cada aspecto do processo, tais conjuntos podem ser estendidos de
acordo com as necessidades da organizacao que adotar esta proposta. Considera-se, por-
tanto, esta flexibilidade como um fator positivo para a disseminacao e aceitacao deste
trabalho.
A definicao “para” reuso nao foi completamente estabelecida, pois cada organizacao
podera estabelecer sua maneira de criar componentes de processo. Entretanto, por esta-
belecer que todo processo de software deve ser definido com base em alguma ontologia de
processo, ela se mostrou apropriada para o armazenamento do componente no repositorio
e sua futura recuperacao. Isto ocorreu, devido ao fato desta definicao ser independente
de uma ontologia de processos especıfica, basta que o componente seja descrito por me-
tadados e o processo por termos de ontologia para que ele (o componente) possa ser
armazenado no repositorio.
Por fim, a definicao “com” reuso foi estabelecida com base no processo “com” reuso
tıpico de DBC. Essa nova abordagem diferenciou-se de sua equivalente em DBC, devido
ao fato de descrever caracterısticas do componente e do processo por meio de ontologias.
O nıvel de expressibilidade dos componentes da nova abordagem aumentou pois nao sao
considerados apenas os valores que definem os metadados de um componente, mas tambem
o significado dos termos que descrevem o processo de software. Portanto a definicao de
processos ocorre com base nas semanticas dos termos utilizados em sua descricao.
Concluindo, pode-se afirmar que este trabalho trouxe as seguintes contribuicoes:
101
• Definicao de um modelo para representacao de processos de software, em seus di-
versos aspectos e tipos de conhecimento;
• definicao de uma estrutura reutilizavel para representacao de processos de software
(componente de processo);
• definicao de formas de descricao voltadas ao componente de processo (metadados)
e ao processo representado pelo componente (atraves do uso de ontologias);
• definicao de um metodo para criacao e reutilizacao de componentes de processo
(durante a definicao de novos processos de software);
• criacao de uma ferramenta que apoia parcialmente a definicao de processos de soft-
ware;
• integracao de um novo metodo de visualizacao e de definicao de processos para o
projeto Discovery, em que processos sao vistos como estruturas reutilizaveis dotadas
de conhecimento.
6.3 Perspectivas futuras
Em trabalhos futuros pretende-se avancar os estudos realizados em processos de soft-
ware, reuso de software e gerencia de conhecimento e implementar melhorias no metodo
proposto. Para o metodo proposto destacam-se as seguintes melhorias:
• Avaliacao da completude e eficacia das operacoes de matching realizadas durante a
busca de componente de processo. Essas operacoes poderao tambem ser adaptadas
de modo a considerar a semantica dos elementos que definem as interfaces dos
componentes.
• Implementacao da adaptacao de componentes atraves da atribuicao de sinonimos
entre termos definidos em ontologias distintas.
• Implantacao de alguma forma de Gerencia de Conhecimento no repositorio de com-
ponentes de processo. Atualmente o repositorio serve para armazenar e referenciar
os componentes por meio do conhecimento. Entretanto nao ha uma gerencia de
conhecimento aplicada sobre o repositorio para identificar os itens de conhecimento
que de fato sao validos e descartar aqueles que nao tem mais valor.
102
• Utilizacao de formas de visualizacao aplicadas ao conhecimento dos componentes
presentes no repositorio como mecanismo para aumentar o entendimento dos mem-
bros da organizacao acerca do processo representado. Esta perspectiva sera de
grande auxılio durante a definicao “com” reuso, principalmente no momento da
qualificacao do componente de processo (em que se decide se o componente sera
reutilizado ou nao).
• Aplicar o metodo em uma organizacao para que sejam avaliados os possıveis be-
nefıcios trazidos pelo reuso. Inicialmente este estudo buscara estabelecer uma cor-
relacao entre a estabilidade do processo de software e seu nıvel de reuso. Este estudo
podera servir como forma de validar esta proposta.
103
Referencias
ALAVI, M.; LEIDNER, D. Knowledge management systems: Emerging views andpractices from the field. Hawaii International Conference on System Sciences, IEEEComputer Society, Los Alamitos, CA, USA, v. 7, p. 7009, 1999.
ALMEIDA, M. B. Um modelo baseado em ontologias para representacao da memoriaorganizacional. Tese (Doutorado) — Universidade Federal de Minas Gerais, BeloHorizonte, 2006.
ARCHIBUGI, D.; LUNDVALL, B. The globalizing learning economy. Oxford, 2002.
ARDIMENTO, P. et al. A maintenance oriented framework for software componentscharacterization. In: CSMR ’07: Proceedings of the 11th European Conference onSoftware Maintenance and Reengineering. Washington, DC, USA: IEEE ComputerSociety, 2007. p. 58–70. ISBN 0-7695-2802-3.
ASSIS, L. F. de. Representacao do Conhecimento Gerado no Processo de Desenvolvimentode Software por meio de StoryTelling. Dissertacao (Mestrado) — PUC-MG, BeloHorizonte, 2008.
BARRETO, A.; MURTA, L.; ROCHA, A. R. Uma abordagem de definicao de processosde software baseada em reutilizacao. In: Simposio Brasileiro de Qualidade de Software2007. [S.l.: s.n.], 2007.
BARRETO, A.; MURTA, L.; ROCHA, A. R. Componentizando processos legados desoftware visando a reutilizacao de processos. In: Simposio Brasileiro de Qualidade deSoftware 2009. [S.l.: s.n.], 2009.
BARROSO, A. C.; GOMES, E. B. Tentenado entender a gestao do conhecimento. 2007.Disponıvel em http://comunidade.rn.sebrae.com.br/uti/uploads/tentando entendergc.pdf.
BASILI, V. R.; ROMBACH, H. D. Towards a Comprehensive Framework for Reuse: AReuse-Enabling Software Evolution Environment. [S.l.], 1988.
BASTIDE, G. A refactoring-based tool for software component adaptation. In: SoftwareMaintenance and Reengineering, 2006. CSMR 2006. Proceedings of the 10th EuropeanConference on. [S.l.: s.n.], 2006. p. 4 pp.–318. ISSN 1052-8725.
BERTOLLO, G. Definicao de processos em um ambiente de desenvolvimento de software.Dissertacao (Mestrado) — Universidade Federal do Espırito Santo, Vitoria – ES, 2006.
BERTOLLO, G.; SEGRINI, B.; FALBO, R. de A. Definicao de processos de softwareem um ambiente de desenvolvimento de software baseado em ontologias. In: SimposioBrasileiro de Qualidade de Software. Vitoria, ES: [s.n.], 2006. p. 72–86.
104
BJORSON, F. O. Knowledge Management in Software Process Improvement. Tese(Doutorado) — Norwegian University of Science and Technology; Faculty of InformationTechnology, Mathematics and Eletrical Engineering, Department of Computer andInformation Science, Trondheim, Outubro 2007.
BORGES, L. da M. S.; FALBO, R. de A. Gerencia do conhecimento sobre processo desoftware. In: Anais do VIII Workshop de Qualidade de Software, XV Simposio Brasileirode Engenharia de Software. [S.l.: s.n.], 2001. p. 27–38.
BORST, W. Construction of engineering ontologies for knowledge sharing and reuse.Tese (Doutorado) — Twente University, 1997.
BREITMAN, K. K. Web Semantica: a internet do futuro. Rio de Janeiro: LTC, 2005.
BROWN, A. W.; SHORT, K. On components and objects: The foundations ofcomponent-based development. International Symposium on Assessment of SoftwareTools, IEEE Computer Society, Los Alamitos, CA, USA, v. 0, p. 0112, 1997.
COADIC, Y.-F. L. A ciencia da informacao. 2. ed. Brasılia: Briquet de Lemos, 2003.
COOK, J. H. Xml sets stage for efficient knowledge management. IT Professional, IEEEEducational Activities Department, Piscataway, NJ, USA, v. 2, n. 3, p. 55–57, 2000.ISSN 1520-9202.
COSTA, A. et al. Apoio a reutilizacao de processos de software atraves de templates eversoes. In: Simposio Brasileiro de Qualidade de Software 2007. [S.l.: s.n.], 2007.
CURTIS, P.; PHILLIPS, D. M.; WESZKA, J. Cmmi - the evolution continues! SystemsEngineering, v. 5, n. 1, p. 7 – 18, 2002. ISSN 10981241.
DAVENPORT, T. H.; PRUSAK, L. Working Knowledge: How Organizations ManageWhat They Know. Boston, USA: Harvard Business Press, 1998.
D’SOUZA, D.; WILLS, A. Objects, components and frameworks: the catalysis approach.1. ed. Boston: Addison-Wesley, 1998.
FIORINI, S. T. Arquitetura para reutilizacao de processos de software. Tese (Doutorado)— PUC-RJ, Rio de Janeiro, 2001.
FUGGETTA, A. Software process: a roadmap. In: ICSE ’00: Proceedings of theConference on The Future of Software Engineering. New York, NY, USA: ACM, 2000.p. 25–34. ISBN 1-58113-253-0.
GIMENES, I. M. de S.; HUZITA, E. H. M. Desenvolvimento Baseado em Componentes:conceitos e tecnicas. Rio de Janeiro: Editora Ciencia Moderna, 2005.
GRUBER, T. What is an ontology? 1993. Disponıvel em: http://www-ksl.stanford.edu/kst/what-is-an-ontology.html. Acesso em: 25/05/2009.
GRUBER, T. Ontology. 2007. Disponıvel em: http://tomgruber.org/writing/ontology-definition-2007.htm. Acesso em 02/06/2009.
GUARINO, N. Formal ontology in information systems. 1998. Disponıvelem:http://citeseer.ist.psu.edu/guarino98formal.html. Acesso em 29/05/2009.
105
GUEDES, F. C. Proposta de visualizacao da verificacao de processos de desenvolvimentode software por meio da rastreabilidade. Dissertacao (Mestrado) — PUC-MG, BeloHorizonte, 2007.
HAUMER, P. Eclipse Process Framework Composer Part 1: Key Concepts. 2. ed. [S.l.],April 2007a.
HAUMER, P. Eclipse Process Framework Composer Part 2: Authoring method contentand processes. 2. ed. [S.l.], April 2007b.
HEMER, D. High-order associative commutative pattern matching for componentretrieval. In: Eletronic Notes in Theoretical Computer Science. [S.l.]: Elsevier, 2004. p.116–133.
HENNINGER, S. An environment for reusing software processes. In: Software Reuse,1998. Proceedings. Fifth International Conference on. [S.l.: s.n.], 1998. p. 103–112. ISSN1085-9098.
HOLLENBACH, C.; FRAKES, W. Software process reuse in an industrial setting.In: ICSR ’96: Proceedings of the 4th International Conference on Software Reuse.Washington, DC, USA: IEEE Computer Society, 1996. p. 22. ISBN 0-8186-7301-X.
JuNIOR, F. C. de M. Utilizacao de metas e rastreabilidade baseada em lexico estendidopara manipulacao do conhecimento em uma pequena empresa. Dissertacao (Mestrado) —PUC-MG, Belo Horizonte, 2007.
KHOSHGOFTAR, M.; OSMAN, O. Comparison of maturity models. In: 2nd IEEEInternational Conference on Computer Science and Information Technology, 2009.ICCSIT 2009. [S.l.: s.n.], 2009. p. 297–301.
KORTHAUS, A.; SCHWIND, M.; SEEDORF, S. Leveraging semantic web technologiesfor business component specification. Web Semantics: Science, Services and Agents onthe World Wide Web, v. 5, n. 2, p. 130 – 141, 2007. ISSN 1570-8268.
KOSCIANSKI, A.; SOARES, M. dos S. Qualidade de software: aprenda as metodologiase tecnicas mais modernas para o desenvolvimento de software. Sao Paulo: Novatec, 2007.
KRUEGER, C. W. Software reuse. ACM Comput. Surv., ACM, New York, NY, USA,v. 24, n. 2, p. 131–183, 1992. ISSN 0360-0300.
LAUDON, K. C. Information Technology and Society. Belmont, California: Wadsworth,1996.
LEMOS, C. Inovacao na era do conhecimento. Sarita Informacao, 1999.
LUCREDIO, D. et al. Software reuse: The brazilian industry scenario. Journal ofSystems and Software, Elsevier Science Inc., New York, NY, USA, v. 81, n. 6, p.996–1013, 2008. ISSN 0164-1212.
MAHMOOD, S.; LAI, R.; KIM, Y. Survey of component-based software development.Software, IET, v. 1, n. 2, p. 57–66, April 2007. ISSN 1751-8806.
106
MONTONI, M. A. Aquisicao de conhecimento: uma aplicacao no processo dedesenvolvimento de software. Dissertacao (Mestrado) — Universidade Federal do Rio deJaneiro, 2003.
NONAKA, I.; TAKEUCHI, H. Criacao de conhecimento na empresa. [S.l.]: Campus,1997.
OLIVEIRA, M. N. Gestao do Conhecimento: Modelo proposto para a melhoria dosprocessos de diagnostico e tratamento medico. Dissertacao (Mestrado) — EscolaPolitecnica da Universidade Federal de Sao Paulo, Sao Paulo, 2006.
OMG. Software & Systems Process Engineering Meta-Model Specification. [S.l.], Abril2008.
OSTERWEIL, L. Software processes are software too. In: ICSE ’87: Proceedings of the9th international conference on Software Engineering. Los Alamitos, CA, USA: IEEEComputer Society Press, 1987. p. 2–13. ISBN 0-89791-216-0.
OSTERWEIL, L. J. Software processes are software too, revisited: an invited talk onthe most influential paper of icse 9. In: ICSE ’97: Proceedings of the 19th internationalconference on Software engineering. New York, NY, USA: ACM, 1997. p. 540–548. ISBN0-89791-914-9.
PIETROBON, C. A. M. Projeto Discovery. Belo Horizonte – MG, 2007.
PRESSMAN, R. S. Engenharia de Software. 6. ed. [S.l.]: McGraw-Hill, 2006.
RASSA, R. C.; GARBER, V.; ETTER, D. Capability maturity model integration(cmmi): A view from the sponsors. Systems Engineering, v. 5, n. 1, p. 3 – 6, 2002. ISSN10981241.
REDOLFI, G. et al. Especificando Informacoes para Componentes Reutilizaveis. PortoAlegre, Abril 2004.
REIS, C. Caracterizacao de um modelo de processo para projetos de software livre.Dissertacao (Mestrado) — Instituto de Ciencias Matematica e Computacao, Sao Carlos,Sao Paulo, 2001.
REIS, R. Q. APSEE-Reuse: um Meta-Modelo para Apoiar a Reutilizacao de Processosde Software. Tese (Doutorado) — Universidade Federal do Rio Grande do Sul, PortoAlegre, 2002.
ROCHA, A. R. C. da; MALDONADO, J. C.; WEBER, K. Qualidade de software: teoriae pratica. [S.l.]: Prenttice Hall, 2001.
ROCHESTER, J. B. Using computers and information: tools for knowledge workersstudy guide. Educational & Training, 1996.
SAMETINGER, J. Software engineering with reusable components. EUA: SpringerVerlag, 1997.
SCHWARTZ, J. Construction of Software. 1. ed. [S.l.]: Addison-Wesley, 1975.
107
SEI, S. E. I. CMMI for Development. Pittsburgh, PA, 2006.
SETZER, V. W. Dado, informacao, conhecimento e competencia. 1999. Disponıvel emhttp://www.ime.usp.br/ vwsetzer/dado-info.html.
SOARES, A. C. Abordagem para apoiar a atividade de teste no processo dedesenvolvimento de software atraves de um ambiente virtual. Dissertacao (Mestrado) —PUC-MG, Belo Horizonte, Minas Gerais, 2008.
SOFTEX, A. para Promocao da Excelencia do S. B. MPS.BR - Guia Geral. 2009a.
SOFTEX, A. para Promocao da Excelencia do S. B. MPS.BR - Guia de Aquisicao.2009b.
SOFTEX, A. para Promocao da Excelencia do S. B. MPS.BR - Guia de Avaliacao.2009c.
SOMMERVILLE, I. Engenharia de Software. 8. ed. Sao Paulo: Pearson Addison-Wesley,2007.
SUCCI, G. et al. Standardizing the reuse of software processes. StandardView, ACM,New York, NY, USA, v. 5, n. 2, p. 74–83, 1997. ISSN 1067-9936.
SZYPERSKI, C. Component Software: Beyond Object-Oriented Programming. Boston,MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2002. ISBN 0201745720.
USCHOLD, M.; JASPER, R. A framework for understanding and classifyingontology applications. In: Twelfth Workshop on Knowledge Acquisition Modeling andManagement KAW 99. [s.n.], 1999. Disponıvel em: <http://citeseerx.ist.psu.edu-/viewdoc/summary?doi=10.1.1.30.1927>.
XIE, X.; ZHANG, W. The current state of software component adaptation. In:Semantics, Knowledge and Grid, 2005. SKG ’05. First International Conference on.[S.l.: s.n.], 2005. p. 103–103.
XIE, X.; ZHANG, W. A checking mechanism of software component adaptation. In:Grid and Cooperative Computing, 2006. GCC 2006. Fifth International Conference. [S.l.:s.n.], 2006. p. 347–354.
XIE, X.; ZHANG, W. Research on software component adaptation based on semanticspecification. In: Network and Parallel Computing Workshops, 2007. NPC Workshops.IFIP International Conference on. [S.l.: s.n.], 2007. p. 969–974.
XU, P. Knowledge support in software process tailoring. In: System Sciences, 2005.HICSS ’05. Proceedings of the 38th Annual Hawaii International Conference on. [S.l.:s.n.], 2005. p. 87c–87c. ISSN 1530-1605.
ZAREMSKI, A. M.; WING, J. M. Specification matching of software components. In:SIGSOFT ’95: Proceedings of the 3rd ACM SIGSOFT symposium on Foundations ofsoftware engineering. New York, NY, USA: ACM, 1995. p. 6–17. ISBN 0-89791-716-2.
