Requisitos para Integração de Ferramentas de Engenharia de Software

Requisitos para Integrac¸˜ao de Ferramentas de Engenharia de

Software

Rodrigo Eduardo Silva1

1_{Departamento de Ciˆencia da Computac¸˜ao}

Universidade Federal de Minas Gerais (UFMG) – Belo Horizonte, MG – Brasil

rodes@dcc.ufmg.br

Resumo. Um grande n´umero de esforc¸os tem sido realizado dentro da comu-nidade de engenharia de software para fornecer suporte automatizado para as ´areas de processo de desenvolvimento de software. O desenvolivmento de grandes sistemas ´e uma tarefa importante e complexa. Um assunto chave no fornecimento de suporte automatizado para o desenvolvimento de software ´e a integrac¸˜ao de ferramentas em um ambiente de desenvolvimento de software. Muitas ferramentas foram produzidas, mas s˜ao aplicadas de forma indepen-dente e isolada nos projetos, al´em de suportarem somente uma fase em par-ticular do ciclo de desenvolvimento. Torna-se ent˜ao, desej´avel a construc¸˜ao de ambientes de suporte atrav´es da integrac¸˜ao das ferramentas existentes. O presente trabalho tem como objetivo apresentar um cat´alogo de requisitos ne-cess´arios para a integrac¸˜ao de ferramentas de engenharia de software, contri-buindo no desenvolvimento de novas ferramentas, assim como servir como uma fonte de referˆencia para que os usu´arios possam escolher melhor quais ferra-mentas far˜ao parte de seu ambiente de desenvolvimento de software integrado.

1. Introduc¸˜ao

Um grande n´umero de esforc¸os dentro da comunidade de engenharia de software tem sido realizado no intuito de fornecer suporte automatizado para as ´areas de processo de desen-volvimento de software [Brown 1992]. As diversas ferramentas, sistemas, e ambientes resultantes de tais esforc¸os, tˆem como objetivo dar suporte ou automatizar uma parte do processo de desenvolvimento de software para que o processo se torne mais prediz´ıvel, menos dispendioso, mais f´acil de gerenciar e que produza produtos de maior qualidade [Brown 1992]. O desenvolvimento de sistemas compreende um n´umero complexo de ta-refas e pode ser visto sob v´arias perspectivas, incluindo as do usu´ario, dos analistas e desenvolvedores, dos gerentes, dentre outros [Bosua and Brinkkemper 1995].

Um assunto chave quando se trata de fornecer suporte automatizado para o desen-volvimento de software de grande escala ´e a integrac¸˜ao de ferramentas em um ambiente de desenvolvimento de software, que enderecem os diferentes aspectos do processo de desenvolvimento [Bosua and Brinkkemper 1995] [Wasserman 1990]. Muitas ferramentas de desenvolvimento de sistemas foram desenvolvidas, mas estas ferramentas s˜ao produzi-das por diferentes fornecedores, fornecem suporte a m´etodos espec´ıficos e s˜ao aplicaproduzi-das de forma isolada no desenvolvimento de sistemas, al´em de que muitas dessas ferramen-tas, suportam apenas uma fase em particular do ciclo de desenvolvimento do software [Bosua and Brinkkemper 1995]. Gautier et al. [Gautier et al. 1995] afirma que `a medida que mais ferramentas de suporte ao desenvolvimento de software tornam-se dispon´ıveis,

a construc¸˜ao de ambientes de suporte atrav´es da integrac¸˜ao das ferramentas existentes torna-se mais desej´avel.

Thomas e Nejmeh [Thomas and Nejmeh 1992] definem integrac¸˜ao como “a me-dida na qual ferramentas concordam entre si”, isto ´e, a concordˆancia entre as ferramen-tas inclui formato de dados, padr˜oes de interface de usu´arios, uso de func¸˜oes comuns, ou outros aspectos de construc¸˜ao de ferramentas. Integrac¸˜ao ´e uma propriedade de interrela-cionamentos de ferramentas e atrav´es de seu entendimento, melhores ferramentas e me-canismos de integrac¸˜ao podem ser projetados [Thomas and Nejmeh 1992]. A integrac¸˜ao de ferramentas relaciona as t´ecnicas utilizadas para formar uni˜oes de ferramentas que for-necem um ambiente de suporte para algumas ou todas as atividades dentro do processo de engenharia de software [Wicks 2005].

Wasserman [Wasserman 1990] prop˜oe em seu trabalho um m´etodo para medir a associac¸˜ao entre ambientes, definindo cinco tipos ou “dimens˜oes” de integrac¸˜ao que po-dem fornecer uma escala contra a qual comparac¸˜oes popo-dem ser feitas. Estas dimens˜oes s˜ao: plataforma, que se preocupa com servic¸os de framework; apresentac¸˜ao, que se pre-ocupa com a interac¸˜ao do usu´ario; dados, que se prepre-ocupa com o uso de dados pelas ferramentas; controle, que se preocupa com a comunicac¸˜ao e interoperac¸˜ao; e processo, que se preocupa com o papel das ferramentas no processo de desenvolvimento de soft-ware [Wicks 2004]. No trabalho de Thomas e Nejmeh [Thomas and Nejmeh 1992] ´e feita uma extens˜ao do trabalho de Wasserman, enfatizando os relacionamentos entre as ferra-mentas que est˜ao sendo integradas, atrav´es de um melhor detalhamento das dimens˜oes de integrac¸˜ao de apresentac¸˜ao, dados, controle e processo.

Inserido neste contexto, o presente trabalho tem como objetivo apresentar um cat´alogo de requisitos necess´arios para a integrac¸˜ao de ferramentas de engenharia de soft-ware, contribuindo para que os desenvolvedores possam definir melhor as caracter´ısticas de integrac¸˜ao que far˜ao parte de suas ferramentas, baseando-se nos requisitos apresenta-dos e tamb´em direcionando futuros trabalhos. Os usu´arios de ferramentas tamb´em po-der˜ao se beneficiar deste cat´alogo como uma fonte de referˆencia para melhor escolher quais ferramentas far˜ao parte de seu ambiente de desenvolvimento de software integrado. O conceito de integrac¸˜ao no presente trabalho pode variar de acordo com o requisi-to que est´a sendo apresentado, podendo ser apresentando-se como um m´erequisi-todo (uma forma sistem´atica de se realizar tarefas) que o ambiente integrado de deve possuir, ou como uma ferramenta que possui um ambiente integrado que supre o requisito apresentado.

Este trabalho n˜ao cobre todos os aspectos apresentados na literatura relacio-nados a integrac¸˜ao de ferramentas. A base da qual os requisitos foram extra´ıdos vem de [Wasserman 1990] e [Thomas and Nejmeh 1992], focando-se nas dimens˜oes de integrac¸˜ao apresentadas nesses trabalhos, bem como de outros trabalhos relacionados a estes. Como forma de estrutura para apresentac¸˜ao dos requisitos, foi tomado como exem-plo o trabalho de [Hoffmann et al. 2004], listando-se cada um dos requisitos levantados, seguidos de uma breve explicac¸˜ao.

2. Modelos e Caracter´ısticas de Integrac¸˜ao de Ferramentas de Engenharia

de Software

Os requisitos apresentados no presente trabalho foram extra´ıdos, tendo como es-copo o trabalho pioneiro apresentado por Wasserman [Wasserman 1990]. Muitos ou-tros trabalhos [Thomas and Nejmeh 1992], [Pohl and Weidenhaupt 1997], [Brown 1992], [Wicks 2004], [Gautier et al. 1995] e [Bosua and Brinkkemper 1995] fazem referˆencia ao trabalho de Wasserman, seja atrav´es de cr´ıticas e/ou de mehorias, extens˜oes e aprofunda-mentos dos conceitos apresentados pelo autor.

Nesta sec¸˜ao ser˜ao apresentados alguns conceitos relacionados ao presente traba-lho, extra´ıdos das referˆencias apresentadas, que s˜ao importantes para o entendimento dos requisitos levantados e para uma compreens˜ao em mais alto n´ıvel do assunto tratado.

• Abaixo s˜ao descritos os tipos (dimens˜oes) de integrac¸˜ao de ferramentas conforme descritos no trabalho de Wicks [Wicks 2004]:

- Integrac¸˜ao de plataforma: est´a relacionada com o grau de uso de frameworks de servic¸os comuns entre ferramentas de software. Esta dimens˜ao mede o grau no qual as ferramentas usam o mesmo framework de servic¸os ou um framework similar.

- Integrac¸˜ao de apresentac¸˜ao: est´a relacionada com o grau no qual as met´aforas e estilos de interface de usu´ario s˜ao compartilhadas. Esta dimens˜ao mede o grau no qual estilos de apresentac¸˜ao comuns s˜ao compartilhados.

- Integrac¸˜ao de dados: est´a relacionada com o grau de troca de dados entre as ferramentas. Esta dimens˜ao mede o grau no qual dados podem ser trocados e entendidos entre ferramentas diferentes.

- Integrac¸˜ao de controle: est´a relacionada como grau de interoperabilidade das ferramentas de software. Esta dimens˜ao mede o grau no qual as ferramentas podem se intercomunicar de forma bem sucedida.

- Integrac¸˜ao de processo: est´a relacionada com o grau no qual as ferramentas s˜ao utilizadas dentro de um processo ou ciclo de vida completo e bem definido. Esta dimens˜ao mede o grau no qual as ferramentas participam de um processo de desenvolvimento comum e abrangente.

• Ferramenta CASE: Computer-Aided Software Engineering. _{E uma forma de}´ classificac¸˜ao para as ferramentas baseadas em computadores que tˆem como objetivo fornecer suporte `as atividades de Engenharia de Software.

• Ambientes de suporte a programac¸˜ao: Programming Support Environments (PSE) s˜ao uni˜oes de ferramentas de software que, quando combinadas, fornecem suporte ao processo de escrita de c´odigo de software.

• Ambientes de Engenharia de Software: Software Engineering Environments (SEE) s˜ao uni˜oes de ferramentas de software que, quando combinadas, fornecem suporte a um ciclo de vida em particular, incluindo tipicamente um meio de gravac¸˜ao tempor´ario, assim como um reposit´orio para os artefatos relevantes.

• Ambientes de Engenharia de Software Centrados em Processos: Process-centered Software Engineering Environments(PSEE) ´e um SEE que tem por objetivo for-necer um suporte de ferramentas integrado para todo ciclo de vida do projeto. Um processo de software completo ´e concretizado atrav´es da ativac¸˜ao de ferramentas apropriadas aos passos relevantes no processo, com a passagem de artefatos de forma similar entre ferramentas e passos.

• Passo de processo: ´E uma unidade de trabalho que produz um resultado.

• Evento de processo: ´E uma condic¸˜ao que surge durante um passo de processo, pondendo resultar na execuc¸˜ao de uma ac¸˜ao associada.

• Restric¸˜ao de processo: Limite ou restringe algum aspecto do processo.

3. Requisitos

Esta sec¸˜ao cont´em o cat´alogo de requisitos para integrac¸˜ao de ferramentas de engenharia de software. Os requisitos aqui apresentados foram extra´ıdos dos trabalhos referenciados e tamb´em atrav´es de conceitos estabelecidos na ind´ustria de desenvolvimento de soft-ware, al´em de ter como escopo os dom´ınios de integrac¸˜ao apresentados por Wasserman [Wasserman 1990].

• A ferramenta deve manter integridade entre artefatos do processo: As ferramentas do ambiente integrado devem garantir que todos os artefatos por elas manipulados e controlados, estejam consistentes entre si. Isto pode ser feito em tempo de execuc¸˜ao, impedindo a criac¸˜ao de artefatos inconsistentes e/ou atrav´es de relat´orios [Thomas and Nejmeh 1992] [Wasserman 1990]. Este requisito ´e interessante `a toda a equipe de desenvolvimento, desde a equipe de processos, passando pela gerˆencia do projeto, at´e os implementadores, pois os artefatos mantidos pela ferramenta ser˜ao utilizados por todos durante o ciclo de vida do sistema sendo desenvolvido.

• A ferramenta deve manter rastreabilidade entre artefatos do processo: As ferramentas do ambiente integrado devem permitir a criac¸˜ao, manutenc¸˜ao e consulta de ligac¸˜oes de rastreabilidade entre elementos dos artefatos, mostrando quando um elemento de um artefato e fundamentado por outro elemento de outro artefato [Thomas and Nejmeh 1992] [Wasserman 1990]. De forma similar, este requisito tamb´em interessa `a toda equipe de desenvolvimento, pois quando um artefato ´e alterado por um membro da equipe, todos os outros artefatos que utilizam este artefato como insumo devem ser revistos e se necess´ario alterados. Um exemplo seria quando um analista realiza uma alterac¸˜ao em um caso caso de uso de desenho que est´a presente em um artefato, todos os outros artefatos, tais como os casos de teste e procedimentos de teste, diagramas onde este caso de uso ´e referenciado e etc, poss´ıvelmente sofrer˜ao alterac¸˜oes.

• A ferramenta deve permitir a manutenc¸˜ao do projeto: As ferramentas do ambiente integrado devem permitir a manutenc¸˜ao do projeto atrav´es da criac¸˜ao, busca, alterac¸˜ao e remoc¸˜ao (CRUD) de seus artefatos, relac¸˜ao de recursos e outros. O ambiente integrado deve permitir que o usu´ario trabalhe nos m´odulos

(ferramentas que comp˜oem o ambiente integrado) num mesmo projeto. Este requisito pode ser extra´ıdo a partir das dimens˜oes de de integrac¸˜ao de controle, plataforma e dados apresentados no trabalho de Wasserman [Wasserman 1990]. Este requisito ´e importante para toda a equipe de desenvolvimento, pois cada grupo de pap´eis dentro da equipe, por exemplo, gerˆencia, analistas, programa-dores, testers, dever´a ser capaz de realizar determinadas alterac¸˜oes nos recursos e artefatos que s˜ao de sua competˆencia. Para a gerˆencia de configurac¸˜ao este requisito ´e bastante interessante, pois ´e necess´ario manter todos os artefatos e recursos catalogados e armazenados em suas respectivas linhas de base.

• A ferramenta deve permitir o trabalho colaborativo: As ferramentas do ambiente integrado devem permitir o trabalho em equipe de forma colaborativa [Biuk-Aghai 1998], respeitando as quest˜oes de n˜ao-redundˆancia, controle, con-sistˆencia e sincronizac¸˜ao dos dados. Pode-se utilizar, por exemplo, um framework que fornec¸a suporte ao desenvolvimento colaborativo de forma s´ıncrona e em tempo-real. Cook e Churcher [Cook and Churcher 2003] afirmam que para que haja um desenvolvimento colaborativo o framework deve introduzir as seguintes caracter´ısticas: um modelo central para cada projeto de software, um formato de gram´atica e ´arvore de parse, propagac¸˜ao de eventos e extensibilidade de ferramentas e linguagens suportadas. Este requisito ´e interessante principalmente para os analistas, que podem realizar, por exemplo, a construc¸˜ao de modelos de forma colaborativa e para os desenvolvedores na construc¸˜ao de c´odigo.

• A ferramenta deve possuir apresentac¸˜ao consistente: As ferramentas do ambiente integrado devem reduzir a carga cognitiva do usu´ario apresentando uma mesma aparˆencia [Wasserman 1990] [Wicks 2004]. Este requisito interessa `a toda a equipe de desenvolvimento, pois diferentes m´odulos do ambiente integrado poss´ıvelmente ser˜ao utilizados pelos membros da equipe em diferentes momentos do ciclo de desenvolvimento. As caracter´ısticas deste requisito foram transcritas de forma resumida a partir do trabalho de Thomas e Nejmeh [Thomas and Nejmeh 1992]:

– Aparˆencia e comportamento: trata da similaridade das ferramentas com relac¸˜ao `a aparˆencia de telas e comportamento de interac¸˜ao. Este requi-sito leva em considerac¸˜ao tanto os aspectos l´exicos (n´umero de cliques de mouse, formato de menus, dentre outros), quanto os aspectos sint´aticos (ordem sequencial dos comandos e parˆametros).

– Paradigma de interac¸˜ao: ´e a medida na qual as ferramentas utilizam met´aforas e modelos mentais similares para minimizar interferˆencias no aprendizado e utilizac¸˜ao. As ferramentas de um ambiente integrado devem utilizar as mesmas met´aforas e modelos mentais.

• A ferramenta deve manter a consistˆencia de dados: As ferramentas devem possuir um compartilhamento dos dados, mantendo a consistˆencia da informac¸˜ao, atrav´es de um gerenciamento dos relacionamentos das ferramentas com relac¸˜ao a estes dados [Wicks 2004] [Wasserman 1990]. Este requisito relaciona-se com o requisito de Manter a rastreabilidade dos artefatos do processo. Mais uma

vez, este requisito ´e interessante a todos os participantes da equipe de desen-volvimento, pois os dados manipulados por um m´odulo do ambiente integrado, devem ser poss´ıveis de serem manipulados por outras pessoas em outro m´odulo, caso tenham algum relacionamento direto. As caracter´ısticas deste requisito foram transcritas de forma resumida a partir do trabalho de Thomas e Nejmeh [Thomas and Nejmeh 1992]:

– Interoperabilidade: ´e tudo aquilo que deve ser feito para que as ferra-mentas vejam os dados como um conjunto consistente. A integrac¸˜ao de interoperabilidade est´a relacionada com a quantidade de trabalho que uma ferramenta dever´a exercer para fazer com que os dados vindos de outra ferramenta sejam manipul´aveis por ela. As ferramentas devem possuir tamb´em uma mesma vis˜ao dos dados, por exemplo atrav´es de uma estru-tura interna comum da informac¸˜ao que ´e manipulada.

– N˜ao redundˆancia: trata da redundˆancia dos dados que as ferramentas do ambiente integrado armazenam e manipulam de forma independente. Ferramentas bem integradas devem reduzir a redundˆancia de dados, ou seja, as ferramentas devem possuir poucos dados duplicados ou dados que podem ser automaticamente derivados de outros dados.

– Consistˆencia dos dados: trata da cooperac¸˜ao entre as ferramentas para manter as restric¸˜oes semˆanticas nos dados que elas manipulam. Cada fer-ramenta deve indicar suas ac¸˜oes e os efeitos em seus dados, que s˜ao os sujeitos das restric¸˜oes semˆanticas que tamb´em se referem aos dados ge-renciados por outra ferramenta.

– Troca de dados: trata das ac¸˜oes que devem ser feitas para que os dados (n˜ao persistentes) gerados por uma execuc¸˜ao de uma ferramenta sejam manipul´aveis por outras ferramentas. Os dados podem estar na forma de valores iniciais comunicados de uma ferramenta a outra quando a primeira comec¸a a sua execuc¸˜ao; ou pode ser atrav´es de valores passados para uma ferramenta enquanto ela est´a sendo executada. Um fator determinante ´e que as ferramentas devem concordar com o formato e a semˆantica dos dados. A integrac¸˜ao na troca de dados deve se preocupar com a quantidade de trabalho requerido nos formatos e semˆanticas dos dados para que as ferramentas sejam capazes de troc´a-los entre si.

– Sincronizac¸˜ao: uma ferramenta deve comunicar as outras ferramentas as mudanc¸as realizadas por ela nos dados n˜ao-persistentes comuns a elas, para que as outras ferramentas sincronizem seus valores de dados. Um mecanismo de renovac¸˜ao de tempo (refresh time) pode ser utilizado para comunicar mudanc¸as entre as ferramentas.

• A ferramenta deve possuir um controle de funcionalidade dos m´odulos: As ferramentas devem ser capazes de compartilhar suas funcionalidades, de notificar a ocorrˆencia de eventos umas `as outras, assim como de ativ´a-las atrav´es de um controle [Wasserman 1990]. As funcionalidades compartilhadas devem ser acess´ıveis a todas as ferramentas do ambiente. Thomas e Nejmeh [Thomas and Nejmeh 1992] afirmam que a integrac¸˜ao de controle complementa a integrac¸˜ao de dados pois as operac¸˜oes relacionadas `as funcionalidades

compar-tilhadas requerem a comunicac¸˜ao de dados. Este requisito tamb´em ´e interessante a toda a equipe, pois durante o ciclo de desenvolvimento os v´arios m´odulos que comp˜oem o ambiente integrado ser˜ao utilizados de forma simultˆanea por uma mesma pessoa ou pessoas distintas, que far˜ao uso de servic¸os oferecidos por um m´odulo em outro e vice-versa. As caracter´ısticas deste requisito fo-ram transcritas de forma resumida a partir do trabalho de Thomas e Nejmeh [Thomas and Nejmeh 1992]:

– Provis˜ao: ´e a medida na qual os servic¸os de uma ferramenta s˜ao utilizados por outras em um ambiente integrado. As ferramentas devem ser capazes de tanto oferecer quanto de requisitar servic¸os.

– Uso: est´a relacionada com a forma na qual uma ferramenta utiliza os servic¸os oferecidos por outras ferramentas no ambiente integrado. Para se alcanc¸ar uma alta integrac¸˜ao de uso, as ferramentas devem ser constru´ıdas de forma modular.

• A ferramenta deve possuir integrac¸˜ao com o processo utilizado: As ferramen-tas de gerˆencia de projeto devem ser integradas `as ferramenferramen-tas de desenvolvimento nas diferentes fases do desenvolvimento [Wasserman 1990], de forma que todo o conhecimento (ou concepc¸˜oes) embutido em cada ferramenta seja compat´ıvel com o conhecimento inserido nas outras ferramentas [Thomas and Nejmeh 1992]. Este requisito ´e interessante tanto para a gerˆencia quanto para a equipe t´ecnica do projeto. Para a gerˆencia ´e interessante pois todo o conhecimento gerencial do processo que est´a sendo aplicado ao projeto poder´a ser consultado e utilizado quando necess´ario. Isto se aplica de forma similar `a equipe t´ecnica com relac¸˜ao ao conhecimento t´ecnico do processo que est´a sendo seguido. As caracter´ısticas deste requisito foram transcritas de forma resumida a partir do trabalho de Thomas e Nejmeh [Thomas and Nejmeh 1992]:

– Passo de processo: est´a relacionada com a forma com que as ferramentas do ambiente integrado s˜ao combinadas para fornecer suporte ao desempe-nho de um passo de processo. Os objetivos de cada ferramenta devem ser uma parte coerente das subdivis˜oes do passo de processo que, ao serem atingidos, devem permitir que as outras ferramentas atinjam seus pr´oprios objetivos.

– Evento: trata do grau de consenso, com relac¸˜ao aos eventos de um pro-cesso, em que as ferramentas de um ambiente devem fornecer suporte. As ferramentas devem produzir e lidar com eventos de forma consistente, ou seja, se uma ferramenta produz um envento uma outra ferramenta dever responder a ele.

– Restric¸˜ao: trata da cooperac¸˜ao entre as ferramentas do ambiente para reforc¸ar uma restric¸˜ao. As func¸˜oes de uma ferramenta podem ser restringidas outras func¸˜oes ou as func¸˜oes de uma ferramenta podem restringir as func¸˜oes de outras ferramentas. As ferramentas devem ter um conhecimento comum sobre as restric¸˜oes e respeit´a-las. Todas as restric¸˜oes est˜ao relacionadas aos estados do processo e como elas afetam as ferramentas.

• A ferramenta deve possuir um m´etodo de integrac¸˜ao de plataforma: O ambiente de integrac¸˜ao deve fornecer um framework de servic¸os comuns para prover uma transparˆencia de rede e sistemas operacionais para as ferramentas do ambiente [Wasserman 1990] [Wicks 2004]. Nem todos os m´odulos do ambiente integrados devem necessariamente estar em um mesmo sistema operacional, mas eles devem ser capazes de se comunicar atrav´es de uma rede para que possam compartilhar arquivos e servic¸os. Este requisito ´e interessante para toda a equipe pois os m´odulos da ferramenta integrada poder˜ao, por exemplo, estar espalhados em diferentes m´aquinas onde cada m´odulo (ou servic¸os de um m´odulo) seria acessado de acordo com a necessidade de cada papel na equipe. Este requisito relaciona-se ao requisito de Permiss˜ao de trabalho colaborativo.

• A ferramenta deve coletar medidas: As ferramentas do ambiente integrado devem obter medidas (armazenadas de forma consistente) para sustentar m´etricas que ser˜ao utilizadas no processo ao qual fornecem suporte. Este requisito pode ser obtido atrav´es das dimens˜oes de controle, dados e processo apresentados por Wasserman [Wasserman 1990]. O maior interessado neste requisito ´e a gerˆencia, pois com uma base hist´orica e um maior conhecimento do andamento do projeto atual, novas predic¸˜oes e (re)negociac¸˜oes poder˜ao ser feitas ao longo do projeto ou para novos projetos, ajustando-se prazos, custos e escopo.

• A ferramenta deve possuir um m´etodo de integrac¸˜ao de ferramentas hete-rogˆeneas: O ambiente de integrac¸˜ao deve permitir a integrac¸˜ao de ferramentas heterogˆeneas (que fornecem suporte a diferentes m´etodos de desenvolvimento), levando em considerac¸˜ao as diferenc¸as semˆanticas entre as ferramentas, isto ´e, as diferenc¸as entre os paradigmas suportados pelas ferramentas. De acordo com Bo-sua e Brinkkemper [BoBo-sua and Brinkkemper 1995] esta integrac¸˜ao pode ser con-seguida com os seguintes passos: Metamodelagem dos m´etodos e das ferramentas, Determinac¸˜ao da associac¸˜ao-de-m´etodo de cada par m´etodo/ferramenta (relacio-namentos intr´ınsecos entre a ferramenta CASE e o m´etodo), Ligac¸˜ao de m´etodo e Ligac¸˜ao T´ecnica entre as ferramentas. Este requisito ´e interessante principalmente para a gerˆencia, que poder´a tomar decis˜oes sobre a viabilidade de aquisic¸˜ao ou de-senvolvimento de novos m´odulos para o ambiente. A equipe t´ecnica tamb´em est´a diretamente envolvida com este requisito, pois diferentes paradigmas poder˜ao ser utilizados durante o desenvolvimento.

4. Aspectos Pr´aticos e Operacionais

Para que os requisitos de integrac¸˜ao de ferramentas de engenharia de software apre-sentados neste trabalho possam ser implementados e melhor utilizados, alguns aspectos pr´aticos e operacionais relacionados a estes podem ser sugeridos. ´E valido enfatizar que os requisitos aqui apresentados tˆem como foco as dimens˜oes apresentadas no trabalho de Wasserman [Wasserman 1990], portanto outros requisitos podem ser elicitados para complementar o presente trabalho.

Para que haja tanto uma integrac¸˜ao de dados quanto uma manutenc¸˜ao de in-tegridade de artefatos de processo, alguns mecanismos, tais como “triggers”,

mensa-gens de procedimentos em bancos, ou arquivos intermedi´arios podem ser utilizados [Thomas and Nejmeh 1992].

A rastreabilidade de artefatos pode ser conseguida atrav´es de modelos comuns entre as ferramentas ou atrav´es de transformac¸˜oes necess´arias para que uma ferramenta possa converter um determinado modelo ou tipo de dado, em um formato entendido por ela.

A utilizac¸˜ao de uma linguagem comum tamb´em ´e muito importante para uma boa comunicac¸˜ao e integrac¸˜ao das ferramentas. Ossher et al. [Ossher et al. 2000] prop˜oe o uso de XML e Enterprise Java Beans para uma melhor integrac¸˜ao de controle e dados. De forma indireta, a integrac¸˜ao de plataforma e de processos, al´em do desenvolvimento colaborativo tamb´em s˜ao afetados por este aspecto.

Outro aspecto relatado por Biuk-Aghai [Biuk-Aghai 1998] para um ambiente in-tegrado de desenvolvimento colaborativo ´e a utilizac¸˜ao de um cat´alogo padr˜ao de nomes de servic¸os e mensagens com uma semˆantica bem definida.

5. Conclus˜ao

O estudo sobre integrac¸˜ao de ambiente e ferramentas de engenharia de software ´e um as-sunto que vem ganhando bastante importˆancia na ´area de desenvolvimento de software. Neste trabalho, foi apresentado um cat´alogo de requisitos para integrac¸˜ao de ferramen-tas engenharia de software, com o intuito de contribuir tanto com desenvolvedores, na definic¸˜ao das caracter´ısticas de integrac¸˜ao de suas ferramentas, quanto com usu´arios, na escolha das ferramentas que far˜ao parte de seu ambiente integrado de desenvolvimento de software.

A maior parte dos requisitos levantados, conforme apresentado, n˜ao s˜ao es-pec´ıficos para somente um ou alguns pap´eis que comp˜oem equipe, pois abrangem todo o ciclo de desenvolvimento ao tratarem de aspectos do ambiente integrado como um todo, afetando assim toda (ou quase toda) a equipe.

Os requisitos aqui apresentados n˜ao cobrem todos os aspectos inerentes `a integrac¸˜ao de ferramentas CASE. A maior parte dos requisitos foram extra´ıdos a partir das dimens˜oes de integrac¸˜ao apresentadas por Wasserman [Wasserman 1990] e aprofun-dadas por Thomas e Nejmeh [Thomas and Nejmeh 1992]. O cat´alogo apresentado n˜ao ´e uma referˆencia final sobre o assunto tratado, pondendo ser complementado por outros re-quisitos do dom´ınio pesquisado, assim como tamb´em ser revisado e modificado de acordo com as necessidades de cada ambiente e com as novas tecnologias vindouras.

Referˆencias

Biuk-Aghai, R. (1998). Customizable software engineering environments for flexible distributed software teams. In Software Engineering Conference, 1998. Proceedings. 1998 Asia Pacific, pages 228–235.

Bosua, R. and Brinkkemper, S. (1995). Realisation of an integrated software engineering environment through heterogeneous CASE-tool integration. In Proceedings of the Soft-ware Engineering Environments Conference, 1995, pages 152–159, Noordwijkerhout, Netherlands.

Brown, A. W. (1992). An annotated bibliography on integration in software engineering environments. Technical report, Software Engineering Institute - Carniege Mellon University, Pittsburgh, Pennsylvania.

Cook, C. and Churcher, N. (2003). An extensible framework for collaborative software engineering. In Proceedings of the Tenth Asia-Pacific on Software Engineering Confe-rence, 2003, pages 290–299.

Gautier, B., Loftus, C., Sherratt, E., and Thomas, L. (1995). Tool integration: experiences and directions. In ICSE ’95: Proceedings of the 17th international conference on Software engineering, pages 315–324, New York, NY, USA. ACM.

Hoffmann, M., Kuhn, N., Weber, M., and Bittner, M. (2004). Requirements for require-ments management tools. In Proceedings of the 12th IEEE International Requirerequire-ments Engineering Conference, 2004, pages 301–308.

Ossher, H., Harrison, W., and Tarr, P. (2000). Software engineering tools and environ-ments: a roadmap. In ICSE ’00: Proceedings of the Conference on The Future of Software Engineering, pages 261–277, New York, NY, USA. ACM.

Pohl, K. and Weidenhaupt, K. (1997). A contextual approach for process-integrated tools. In ESEC ’97/FSE-5: Proceedings of the 6th European conference held jointly with the 5th ACM SIGSOFT international symposium on Foundations of software engineering, pages 176–192, New York, NY, USA. Springer-Verlag New York, Inc.

Thomas, I. and Nejmeh, B. A. (1992). Definitions of tool integration for environments. IEEE Software, 9(2):29–35.

Wasserman, A. I. (1990). Tool integration in software engineering environments. In Proceedings of the international workshop on environments on Software engineering environments, pages 137–149, New York, NY, USA. Springer-Verlag New York, Inc. Wicks, M. (2004). Tool integration in software engineering: The state of the art in

2004. Technical report, Heriot-Watt Institute of Software Engineering. Dispon´ıvel em http://www.macs.hw.ac.uk:8080/techreps/.

Wicks, M. N. (2005). Tool integration in software engineering environ-ments. Technical report, Heriot-Watt University - School of Mathe-matical and Computer Sciences, Edinburgh, UK. Dispon´ıvel em www.macs.hw.ac.uk/ mnw1/pdf/esecfse2005/DocSymp.pdf.