Apresentação

As ferramentas CASE têm assumido papel importante no desenvolvimento de software de qualidade. Este trabalho traz uma resenha sobre o que tem sido desenvolvido na área nos últimos anos. O objetivo é mostrar os problemas atuais e indicar como construir ferramentas CASE para beneficiar os usuários. Os processos de adoção e seleção de ferramentas CASE também são abordados através de um resumo dos padrões IEEE P1348 e P1209. Os aspectos de integração de ferramentas CASE abordados tiveram como referência principal os estudos feitos pelo CASE Environment Group do SEI.

Esta monografia foi desenvolvida baseada na experiência com a disciplina Ambientes de Desenvolvimento de Software do Curso de Ciência da Computação e de projetos de pesquisa do Grupo de Engenharia de Software do Departamento de Informática da Universidade Estadual de Maringá. Partes do conteúdo que aparece aqui foram elaboradas por alunos de iniciação científica sob minha orientação, em especial por Edicezar Leandro Nanni, Selma Bássiga Sabião e Luciana Martimiano.

1. Introdução

Os produtos de software são amplamente utilizados pela comunidade nos mais diversos setores, que envolvem desde aplicações triviais até sistemas críticos, tais como sistemas de segurança militar, sistemas de controle aéreo (fly by wire aircraft) e sistemas de controle financeiro. Isto implica que a qualidade de um produto de software é uma questão fundamental, não apenas nos aspectos tecnológicos, mas também nos efeitos sociais resultantes do uso destes produtos pela comunidade. A complexidade dos requisitos impostos aos produtos de software atualmente demanda um desenvolvimento sistemático apoiado por técnicas e mecanismos eficazes que possam ser mensurados e provados para a comunidade que o uso de um produto software não implicará em riscos.

Podemos abordar as soluções disponíveis na engenharia de software para melhorar a qualidade dos produtos de software em três aspectos básicos, como segue:

estabelecimento de um processo de software bem definido, assistido e monitorado; métodos estruturados e formais para apoiar o desenvolvimento de software; ferramentas de apoio às atividades do processo de software.

Entenda-se por processo de software, o conjunto de todas as atividades relacionadas ao desenvolvimento, controle, validação e manutenção de um software operacional. A disciplina que estuda o processo de software tem como objetivo: consolidar o entendimento deste processo, desenvolver modelos e formalismos adequados para representá-lo, bem como produzir estratégias, metodologias e ferramentas para suportar a execução e manutenção deste processo [Gim94]. Existe um crescente interesse nesta disciplina, devido ao fato de que um processo de software bem definido permite um efetivo monitoramento e controle do desenvolvimento do software e, dessa forma, leva à redução dos custos de produção, bem como à melhoria da qualidade e integridade do software.

Os métodos estruturados vêm sendo amplamente estudados na engenharia de software desde seus primórdios. Estes métodos oferecem procedimentos e notações diagramáticas através dos quais os requisitos de software são elicitados, transformados e documentados para produção de um código operacional. Exemplos destes métodos são JSD, SD e SSADM. Podemos incluir também os recentes métodos baseados no paradigma de orientação a objetos, tais como OMT, BOOCH e Fusion. Nas últimas décadas temos assistido a uma grande ênfase na produção de métodos formais para apoiar o desenvolvimento de software. Estes métodos baseiam-se em formalismos com base matemática visando representar os requisitos de software de forma consistente e não ambígua, bem como oferecendo técnicas de transformação das representações do software que permitem uma verificação formal destas. Exemplos de métodos e notações utilizadas nesta área são VDM, Z e Lotus.

À medida em que os métodos de desenvolvimento se tornam mais sofisticados, a complexidade da administração do processo de software cresce. As limitações do ser humano diante do controle do grande volume de informações e passos sistemáticos envolvidos na aplicação dos métodos demandam ferramentas de apoio automatizadas.

Atualmente tem surgido um grande número de ferramentas de apoio ao processo de software, conhecidas tradicionalmente como ferramentas CASE1. Uma ferramenta CASE oferece um conjunto de serviços fortemente relacionados para apoiar uma ou mais atividades do processo de software. Considere-se serviço como sendo uma ação efetuada pelo computador que é de interesse do desenvolvedor. Estes serviços vão

1

? Computer Aided Software Engineering.

desde a simples edição de textos até o gerenciamento de configurações, o teste de software e a verificação formal de programas.

O estudo de ferramentas CASE envolvem dois aspectos principais: como construir e como usar ferramentas CASE. O primeiro aspecto refere-se a: como definir os requisitos e a arquitetura das ferramentas. O segundo envolve o estudo do processo de adoção, avaliação e seleção de ferramentas CASE, a análise de benchmarks e definições que dizem respeito a como configurar licenças e escolher plataformas para ferramentas CASE. As duas abordagens envolvem uma análise das políticas de mercado. Esta monografia apresenta: os conceitos básicos e a arquitetura de ferramentas CASE; o processo de adoção, avaliação e seleção de ferramentas CASE; e as questões relacionadas à integração de ferramentas CASE no processo de software. Concluimos com uma análise geral da atual situação do mercado de ferramentas CASE.

2. Conceitos Básicos de Ferramentas CASE

Uma ferramenta CASE é um produto computacional que suporta uma ou mais das atividades do processo de software. A introdução dessas ferramentas visa melhorar a qualidade do software e aumentar a produtividade do seu processo de produção. As ferramentas CASE podem ser :

horizontais - oferecem serviços utilizados durante todo o processo de software, tais como suporte à documentação e gerenciamento de versões e configurações;

verticais - são utilizadas em fases específicas do processo de software, tais como análise de requisitos e teste de software.

As ferramentas CASE também podem ser classificadas conforme o conjunto de serviços principais que estas oferecem. Um serviço é uma ação efetuada pelo computador que é de interesse do desenvolvedor [Sch93]. Uma proposta de classificação é apresentada na tabela 2.1 [Pre92]. Através desta tabela podemos observar o amplo espectro de ferramentas CASE existentes, apesar de ser comum a referência a ferramentas CASE como ferramentas específicas para análise e projeto de software.

Atividades Exemplos de Ferramentas

Planejamento de Sistemas Gerenciais Foundation, Interactive Engineering

Workbench, Information Engineering Facility;

Gerenciamento de Projetos SuperProject, Microsoft Project, MacProject II,

ESTIMATES;

Especificação de Requisitos CORE, RMS/PC, R-Trace;

Especificação Formal de Sistemas CADIZ, OBJ;

Documentação Interleaf, Page Maker (Aldus);

Comunicação Utilitários do Unix, Microsoft mail;

Controle de Qualidade Q/Auditor, Auditor;

Gerenciamento de Versões e Configurações SCCS do Unix, PVCS ;

Análise e Projeto de Software JSD, SADT, HOOD, PC Case, OMT;

Projeto e Desenvolvimento de Interfaces Interviews, Lucas Film;

Programação Turbo X’s, Anna.

Tabela 2.1. Classificação de ferramentas CASE.

3. Construção de Ferramentas CASE

A construção de ferramentas CASE é como a construção de um software para domínio específico. Apesar dos possíveis serviços oferecidos por essas ferramentas serem muitos, existem características comuns. Esta seção analisa os requisitos e a arquitetura de ferramentas CASE.

3.1 Requisitos de Ferramentas CASE

A análise de requisitos para o desenvolvimento de ferramentas CASE difere-se da análise de uma aplicação comum, especialmente no que diz respeito à captura dos requisitos junto aos usuários. Os usuários de ferramentas CASE não são tão bem definidos quanto os de uma aplicação comum. Neste caso, são os desenvolvedores, auxiliados pelo pessoal de marketing que devem produzir a especificação da ferramenta.

Uma das formas de se definir os requisitos de ferramentas CASE é através do modelo de ciclo de questões. Segundo Potts et. al.[Pot94] a ênfase em questionários é apropriada para projetos contratuais e produtos dirigidos para o mercado. O modelo de ciclo de questões envolve as seguintes atividades: documentação, discussão e evolução dos requisitos.

Assim, primeiramente, deve-se analisar toda a documentação das ferramentas similares existentes. Esta documentação inclui: manuais, livros, artigos publicados e as próprias ferramentas. Uma análise do mercado deve auxiliar o processo de definição dos requisitos, levantando as características e necessidades do público alvo, que incluem: desenvolvedores comerciais, desenvolvedores científicos e acadêmicos.

Após a fase de pesquisa, deve-se elaborar questões relacionadas à ferramenta. A cada requisito estabelecido podem estar associadas várias questões. Estas questões são respondidas pelos desenvolvedores, eventualmente, auxiliados pelo pessoal de marketing. Como resultado das discussões os requisitos são aprimorados, repetindo-se o ciclo de questões até se considerar que o conjunto de requisitos é satisfatório.

3.2 Arquitetura de Ferramentas CASE

O projeto de ferramentas CASE envolve uma análise sobre o contexto no qual esta vai operar. Os aspectos principais a serem analisados incluem:

quais as atividades do ciclo de vida que esta vai abranger; qual o repositório de dados a ser utililizado; qual o estilo de interface a ser adotado; quais os serviços disponíveis em outras ferramentas que podem ser reutilizados; com quais ferramentas existentes no mercado vale a pena cooperar; que mecanismos de comunicação com outras ferramentas devem ser utilizados; quais os formatos de dados, para os quais, filtros devem ser colocados disponíveis; quais as plataformas, para as quais a ferramenta vai ser desenvolvida.

Esses aspectos irão orientar o projeto da aquitetura da ferramenta de modo a obter uma configuração flexível. É desejável que a arquitetuta dessas ferramentas seja o mais modular possível de modo a facilitar a configuração destas para diferentes propósitos. A arquitetura da ferramenta envolverá componentes, que representam os subsistemas principais e objetos da ferramenta. Estes componentes são conectados através de um mecanismo de interação, que representa a forma como os componentes interagem, trocam informações e afetam uns aos outros. Esses estudos estão relacionados à tecnologia de integração que visa identificar e desenvolver princípios de arquitetura com o objetivo de manisfestá-los em componentes executáveis de software [Sch93].

As ferramentas CASE encontradas no mercado hoje geralmente funcionam de forma isolada. Estas utilizam formatos de dados proprietários, o que impede que ferramentas façam uso dos dados produzidos uma das outras. Exemplos dos tipos de arquitetura existentes são mostrados na figura 3.1 [Bro93].

Figura 3.1. Exemplos de Arquitetura de Ferramentas CASE.

A ilustração 3.1.a. mostra uma ferramenta filtro que recebe arquivo de dados como entrada e transforma em aquivos de saída. Os arquivos trazem dentro de si o formato de dados da ferramenta, que geralmente é de complexa compreensão. No caso de arquivos Unix, pode-se entender os dados a nível de bytes, porém, interpretação da sintaxe e semântica dos dados fica a cargo de cada ferramenta. A integração pode ser obtida, neste nível, utilizando-se o mecanismo de piping. A figura 3.1.b. mostra uma ferramenta que utiliza um dicionário de dados para catalogar suas informações. Finalmente, a figura 3.1.c. ilustra uma ferramenta que utiliza um gerenciador de banco de dados para armazenamento de suas informações.

Dado que as ferramentas CASE, em geral, apoiam atividades específicas, um projeto necessita de um grande número destas para conseguir cobrir todo o processo de software. Cada ferramenta pode ser vista como um módulo que provê um conjunto de serviços. Estes módulos podem ser combinados para oferecer novas funcionalidades. Assim, além do problema de compartilhamento de dados, o uso de várias ferramentas isoladas pode trazer problemas de sobreposição de funcionalidades. Por exemplo, várias ferramentas podem embutir serviços de gerenciamento de versões ou serviços de geração de código.

Muito tem sido estudado sobre integração de ferramentas CASE. A partir destes estudos, modelos de integração que representam os aspectos básicos a serem tratados têm sido produzidos. Um dos mais conhecidos é o modelo de três dimensões [Sch89, Was90] apresentado na figura 3.2.

Banco de Dados

Ferramentas com Banco de Dados

Ferramentas Filtro

Fontes Dados Derivados

Ferramentas com Dicionário de

Dados

Dicionário de Dados

...

a)

b)

c)

Figura 3.2. Modelo de três dimensões de integração de ferramentas CASE.

Neste modelo, os aspetos básicos de integração são vistos em três dimensões: apresentação, dados e controle. A dimensão de apresentação representa a similaridade do estilo e comportamento da interface das ferramenta. Isto envolve, uso uniforme de menus, push-bottons e janelas, bem como mesma reação a eventos semelhantes. As ferramentas CASE atuais, usualmente, seguem padrões de facto, como o Microsoft Windows e o X Windows.Um dos princípios básicos do projeto de ferramentas é a separação da interface do código da aplicação[Sch93]. Isto permite o desenvolvimento da interface independente do código da aplicação, facilitando alterações na interface sem influenciar no código, padronização e concentração de investimentos. Os trabalhos nessa área têm sido intensificados no contexto de trabalho cooperativo para facilitar a comunicação à distância entre usuários.

Nas seções seguintes trataremos a integração por dados e integração por controle.

3.2.1 Integração por Dados

A integração por dados visa prover formas de compartilhar os dados manipulados pelas ferramentas, evitando-se a multiplicação e diversidade, de estruturas e serviços. Esta tem sido uma das formas mais estudadas de integração de ferramentas.

O compartilhamento pode se dar através de dados persistentes. Pode-se utilizar um repositório de dados comum, por exemplo, um gerenciador de banco de dados comercial, como o Oracle ou Sybase, onde todas as ferramentas armazenam seus dados. Outra alternativa é a importação e exportação de dados. Neste caso, cada ferramenta tem sua forma de armazenamento de dados interna e, traduções são realizadas para exportação de dados para outras ferramentas. Estas abordagens estão ilustradas na figura 3.3. Brown et. al.

DadosControle

Multimídia

Aparências

UIMS

Toolkit &

Window Manager

Protocolos

Chamadas de procedimentos

Mensagens

Despachador de msgs

Controle de processos

Sistemade arquivos

Dicionário deDados

Base de Objetos

Apresentação

OperaçõesComuns

Guias de Estilo de Funcionalidades

Dados

[Bro94] aponta que, apesar da clara diferença entre estas abordagens, na prática, é comum se encontrar a combinação dessas.

Ambas as abordagens acima requerem convenções para conversões ou armazenamento dos dados manipulados pelas ferramentas. Uma convenção genérica, de amplo espectro e aceita por todos os fabricantes é difícil de se encontrar e estabelecer. Um exemplo de convenção para importação e exportação de dados é o padrão CDIF [Bre95]. Na prática, temos encontrado ferramentas que exportam seus dados para o formato de outras ferramentas que são amplamente utilizadas. Um exemplo disto é uma ferramenta de análise e projeto orientado a objetos que gera código para banco de dados comerciais amplamente utilizados (ex. Objectstore, Objectivity e ONTOS).

Figura 3.3. Abordagens para compartilhamento de dados persistentes.

O compartilhamento de dados em termos de importação e exportação dificulta a administração dos dados em alguns aspectos, tais como segurança, concorrência e controle de versão e configuração, pois o controle dos dados fica sob responsabilidade de cada ferramenta. Outras formas de compartilhamento de dados exigem um conhecimento da semântica dos dados manipulados pelas ferramentas. Isto pode se dar através de formato de dados comuns ou esquemas de dados comuns. O formato de dados comum representa um acordo para armazemento dos dados em um formato especificado. Este formato pode ser, por exemplo, uma estrutura de dados (ex. árvore sintática) que traz dentro de si informações semânticas.

Esquemas de dados comuns podem ser obtidos utilizando-se, por exemplo, modelos ERA ou orientado a objetos. Isto implica em encontrar um conjunto de tipos de objetos e relacionamentos comuns a todas as ferramentas. Além disso, são necessários serviços de administração desses esquemas, pois novas ferramentas podem ser integradas adicionando-se novos tipos e relacionamentos ou reutilizando-se os existentes. A necessidade desse tipo de integração gerou vários estudos pois foi inicialmente vista como ideal, uma vez que as ferramentas não mais precisariam investir no repositório e serviços de administração de dados. Os primeiros candidatos a prover este tipo de integração foram os gerenciadores de banco de dados relacionais, porém, estudos iniciais sobre o tipo e comportamento dos dados manipulados nas atividades de engenharia de software indicaram que novas características seriam necessárias [Ber87]. Um resumo destas características, apresentado por Brown et. al. [Bro94] é reproduzido na tabela 3.1.

Banco de Dados Comerciais Banco de Dados Para Engenharia de SoftwareEsquemas relativamente estáticos que podem ser determinados a priori.

Esquemas dinâmicos e evolutivos, incluindo dados sobre o sistema de integração.

Itens de dados de tamanho fixo. Itens de dados de tamanho variável.

Repositório de Dados Persistentes

Tool A Tool Z

. . . Tool A Tool Z

Exportação de Dados

Pequeno número de tipos de entidades com um grande número de instâncias de cada tipo.

Grande número de tipos de entidades com poucas instâncias destes.

Itens de dados com valores únicos. Versões múltiplas dos itens de dados com controle de dependências e relacionamentos entre versões.

Muitas transações curtas que podem ser utilizadas como base para controle de acessos concorrentes.

Transações longas que exigem mecanismos mais sofisticados de controle de concorrência.

Tabela 3.1. Características de Banco de Dados Comerciais versus Banco de Dados para Engenharia de Software.

Extensões de modelos relacionais, bem como o uso de banco de dados orientado a objetos foram propostos para servir como base para integração de ferramentas CASE, em particular no contexto de ambientes de desenvolvimento de software. Na tentativa de oferecer um conjunto de serviços comuns para integração de ferramentas CASE, surgiram os padrões CAIS e PCTE.PCTE é o mais bem sucedido destes padrões. Este surgiu inicialmente como um padrão Europeu [ECM90] e se tornou um padrão internacional ISO/IEC 13719, para o qual existem atualmente duas implementações comerciais[Tra95,EDS95]. O pagrão PCTE é descrito na seção 3.2.3.O desenvolvimento de esquemas de dados comuns é reconhecidamente difícil pelos fabricantes de ferramentas, pois implica em um esforço de desenvolvimento extra para um mercado onde os padrões como PCTE ainda não estão estabelecidos. Para se obter uma boa integração de dados é necessário compatibilizar os tipos manipulados pelas ferramentas, definindo-se a granulosidade dos dados e os relacionamentos apropriados. Se a granulosidade dos dados for muito fina torna-se difícil encontrar uma semântica de dados comum. Por outro lado, se a granulosidade dos dados for muito grossa, por exemplo a nível de arquivos, tira-se pouco proveito da integração. Esquemas compartilháveis podem ser grandes e complexos, o que implica que tempo e esforço devem ser dedicados à sua manutenção. Na seção 3.2.1.1 apresentamos um exemplo de modelagem de dados para ferramentas.

3.2.1.1 Exemplo de Modelagem de Objetos para Integração de Ferramentas

Para tornar as dicussões acima mais concretas, apresentamos um exemplo de integração de ferramentas derivado de Brown et. al. [Bro94] e adaptado para o modelo de objetos OMT [Sab95].

O exemplo é composto de três ferramentas CASE, que são: gerenciamento de versão; gerenciamento de projetos; traçador de erros de programas.

O exemplo apresentado nas figuras de 3.4 a 3.7, mostra o modelo de objetos para estas ferramentas, mais o modelo de integração. Este exemplo é uma evolução do modelo apresentado em Brown et. al. [Bro94] como um modelo de entidade e relacionamento. O objetivo é mostrar um modelo de integração dessas três ferramentas, que reflita os dados em comum entre elas.

Pelo exemplo acima, verificamos que o modelo de integração (figura 3.7) abrange as três ferramentas, ou seja, qualquer operação realizada em qualquer ferramenta individualmente pode ser realizada através dos objetos representados neste modelo.

No modelo integrado (figura 3.7) foi acrescentada a generalização de documento, que pode ser um projeto, design, programa ou módulo. Isto foi necessário para que pudéssemos sintetizar no modelo integrado, o que é um documento. O objeto pessoa, no modelo integrado, representa os objetos pessoa, gerente e construtor, dos modelos individuais, tendo reunido todos os atributos existentes nos três objetos. Esta decisão foi tomada pelo fato de que as características dos três objetos são equivalentes.

Podemos visualizar no modelo integrado (figura 3.7) os objetos: pessoa, documento, versão e ferramenta com seus relacionamentos e atributos, representando o gerenciamento de versão (figura 3.4). Assim, é possível no modelo integrado seguir os seguintes relacionamentos: uma pessoa é responsável por vários

documentos que possuem várias versões as quais são produzidas por uma determinada ferramenta. Este relacionamento corresponde ao relacionamento completo da figura 3.4.

Figura 3.4: Modelo de objetos da Ferramenta de Gerenciamento de Versão.

Figura 3.5. Modelo de objetos da Ferramenta de Gerenciamento de Projeto.

Figura 3.6. Modelo de objetos do Traçador de Erros de Programas.

Figura 3.7. Modelo de objetos para integração das três ferramentas.

Para obter uma equivalência do gerenciamento de projeto (figura 3.5), especializamos o objeto documento como um projeto e seguimos o seguinte relacionamento do modelo integrado: uma pessoa é responsável por vários projetos que produz vários produtos. Para obter o relacionamento possui entre produto e erros pendentes (figura 3.5), temos que seguir um caminho mais longo, pois a ferramenta de gerenciamento de projeto está interessada no produto e seus respectivos erros como um todo e, o traçador de erros de programas, em encontrar os erros para cada módulo do programa. Com isso, podemos verificar que o total de erros encontrados em todos os módulos, corresponde aos erros pendentes no gerenciamento de projeto.

Para obtermos as atividades do traçador de erros de programas (figura 3.6), usamos o seguinte caminho: um projeto é desenvolvido por um design que é implementado por vários programas que são compostos de vários módulos os quais estão associados a vários erros, sendo esses erros responsabilidade de uma pessoa.

3.2.2 Integração por Controle

A integração por controle provê mecanismos de comunicação entre ferramentas independente do compartilhamento de dados, conforme ilustrado na figura 3.8. Neste contexto, as ações executadas pelas ferramentas são comunicadas às outras através de sinais de controle. A intenção desse mecanismo é ser mais flexível, obtendo integração sem sacrificar a independência das ferramentas.

Figura 3.8. Comunicação entre ferramentas através de integração por controle. A figura 3.8 ilustra uma comunicação ponto a ponto entre ferramentas, onde um Editor, após fazer uma alteração do código fonte, informa ao Configurador. Este, por sua vez, chama o Compilador. No exemplo não nos referimos a forma especial alguma de armazenamento do código fonte, apenas todas as ferramentas têm acesso a este, o que é ilustrado através das linhas pontilhadas

A forma mais primitiva de integração por controle é a chamada de procedimentos, porém esta só é adequada na construção de produtos auto-contidos. No caso das ferramentas CASE, são necessários mecanismos que permitam comunicação entre produtos construídos por fabricantes diferentes, requerendo o mínimo de alteração possível na estrutura interna dos produtos. Podemos destacar dois desses mecanismos: software bus e broadcast message server [Sch93].

Software bus foi utilizado no projeto Eureka Software Factory (ESF). A arquitetura da ESF, ilustrada na figura 3.9, considera que:

as interfaces procedimentais estão localizadas em módulos chamados Software Components (SCs), e não devem iniciar ação alguma de interface com o usuário;

todas as ações de interface com o usuário devem ser implementadas nos User Interface Components (UICs), responsáveis por chamar os SCs para executar as ações. Os UICs e SCs devem ser executados através de processos diferentes.

Figura 3.9. Ilustração da integração por controle através de software bus.

Configurador

Editor Compilador

Código Fonte

UIC UIC UIC

SC SCSoftware bus

Podemos observar através da figura 3.9 que o software bus é um processo que representa os mecanismos para implementação de chamadas dos SCs a partir dos UICs.

Na abordagem de integração por controle através de passagem de mensagens, as ferramentas se comunicam através de um broadcast message server que é responsável pela distribuição das mensagens. As mensagens podem ser dos tipos: requisição, resposta ou notificação. As mensagens podem conter indicações sobre as ferramentas destino, bem como especificações sobre o escopo para o qual a mensagem se aplica. Protocolos devem ser definidos para estabelecer a sintaxe e a semântica das mensagens. Analogamente ao compartilhamento de dados, o grau de integração pode ser avaliado de acordo com a semântica das mensagens. Conforme Brown et. al. [Bro94], os acordos semânticos podem variar desde eventos simples, tais como start e stop, até eventos mais complexos que envolvem vários eventos de granulosidade fina.

Exemplos de mecanismos de integração por controle, baseados em broadcast message server são: HP Softbench, Tooltalk e CORBA. Tooltalk tem sido muito utilizado, devido ao grande número de plataformas SunOS. CORBA tem sido referido como um dos padrões mais atrativos atualmente. Outros esforços que podem influenciar na integração por controle são COSE, OLE e OpenDoc.

3.2.3 PCTE

O PCTE2 é um PTI3para a integração de dados, controle de processos e comunicação entre ferramentas, ou seja, ele define “normas de comportamento” entre as ferramentas, indispensáveis para a integração destas dentro de um ambiente de engenharia de software (SEE) [Nan95].

Em 1983, dentro do projeto ESPRIT4, iniciaram-se os trabalhos do projeto PCTE, que tinha como objetivo inicial, definir as especificações de uma interface essencial para o usuário e implementar as facilidades básicas para um protótipo de um ambiente de ferramentas comuns portáteis [Wak93].

Com a evolução do projeto, a idéia inicial de especificar a interface do usuário foi abandonada, em favor de padrões emergentes baseados no padrão X11, como OSF/Motif.

O PCTE tornou-se um padrão europeu em dezembro de 1990, com a aprovação da sua especificação abstrata, como o Standard ECMA5-149 [ECM90]. Em meados de 1994, tendo como base o padrão europeu, a ISO6 (ISO/IEC 13719) aceitou o PCTE como um padrão mundial para integração de ferramentas em SEEs.

Entre as facilidades oferecidas pelos SEEs, podemos destacar o repositório aberto, que é uma base de dados onde são guardadas todas as informações relativas a um projeto de desenvolvimento de software, e também uma base para a comunicação entre as ferramentas.

O padrão PCTE também inclui um repositório para SEEs abertos, o qual utiliza conceitos de bancos de dados , controle de processos, de concorrência e distribuição. Uma característica importante de um SEE aberto é que as ferramentas podem ser adicionadas e retiradas conforme se tenha necessidade e, além disso, uma ferramenta pode ser utilizada em vários ambientes diferentes, desde que estes utilizem o mesmo tipo de repositório. Em SEEs abertos que utilizam PCTE, esta flexibilidade é dada exatamente pelo PCTE, que fornece uma série de facilidades para que as ferramentas, desde que sigam um modelo de construção comum, se comuniquem e trabalhem conjuntamente e de maneira simplificada, da forma mais transparente possível para os seus usuários.

2PCTE: Portable Common Tool Environment3 Public Tool Interface.4ESPRIT :European Strategic Programme on Research and development in Information Technology5ECMA :European Computer Manufacturers Association6ISO :International Standard Organisation

A característica principal e maior motivação para o desenvolvimento e utilização do PCTE é o seu uso como um repositório aberto para SEEs. Isto permite que os dados relativos a um projeto estejam todos agrupados em um único local (pelo menos em nível lógico, já que o PCTE suporta a distribuição de dados por vários volumes separados e em máquinas distintas), o que facilita a comunicação das ferramentas.

A utilização de um modelo geral de dados dentro do SEE facilita a integração das ferramentas, pois exige que todas elas conheçam e utilizem o mesmo padrão para a manipulação de dados, ficando muito mais simples para a ferramenta utilizar-se dos dados gerados por outra.

O repositório aberto concentra toda a informação utilizada em um processo de software, tais como: os dados comumente gerados pelas ferramentas, ex: texto, código-fonte e estruturas de dados; dispositivos para comunicação entre as ferramentas, ex: pipes e filas de mensagens; informações utilizadas para controle, ex: lista de estações de trabalho ligadas ao sistema e

informações sobre processo em execução.Além dessas, temos informações sobre a estrutura dos dados armazenados na base e seus relacionamentos (chamados de esquemas) e do próprio código executável, tanto dos programas que fazem parte do projeto-alvo, como das ferramentas e dos processos do PCTE.

O mecanismo do PCTE responsável pela manipulação dos dados é chamado Sistema de Gestão de Objetos ou simplesmente SGO, que é um sistema capaz de guardar tanto os dados - numa parte chamada base de dados - quanto a informação sobre a estrutura destes dados - em outra parte chamada metabase. É importante entender que a base de dados e a metabase não estão separadas fisicamente, ficando armazenadas conjuntamente no repositório de dados.

O PCTE não estabelece uma modelagem de dados no sentido de definir bibliotecas de tipos de dados gerais para serem utilizados nos processos de software, não determinando como a informação deve ser organizada para que se possa trabalhar eficientemente no desenvolvimento de um software. Não há na especificação do PCTE nenhuma referência a tipos predefinidos específicos para este fim (como por exemplo a estrutura de um arquivo fonte, uma árvore sintática gerada por um “parser” e gráficos de Gantt). Estas decisões são deixadas a cargo dos projetistas das ferramentas ou do gerente de processo, que devem definir o conjunto de tipos que são utilizados no SEE.

Nas seções seguintes mostraremos a estrutura do repositório do PCTE e seus mecanismos para gerenciar esquemas compartilháveis.

3.2.3.1 - Estrutura do repositório

Para manipular dados tão variados e com relacionamentos tão complexos como os existentes no processo de software, o PCTE conta com uma estrutura especial na sua base de dados, inspirada no modelo de Entidade-Relacionamento-Atributo, mas com extensões e modificações para suportar as peculiaridades exigidas pelos SEEs.

Na figura 3.10 é mostrado um diagrama com os elementos que podem ser encontrados na base de objetos. Este tipo de diagrama é amplamente utilizado nos documentos referentes ao PCTE (embora o diagrama não seja um padrão oficial) e permite um melhor entendimento do modelo de dados. Ele é chamado de diagrama de instâncias, pois descreve uma parte da base de objetos em um dado momento, mostrando as instâncias dos objetos, links e atributos, que são os elementos que formam esta base, e adicionando informações importantes e necessárias para um melhor entendimento da situação. O modo como cada elemento é representado no diagrama será explicado, conforme necessário, juntamente com a explicação do próprio elemento, nos parágrafos que se seguem. É importante esclarecer que nem todas as informações possíveis de serem representadas nestes diagramas são necessárias para todas as situações, ficando a cargo de quem elabora o diagrama, apresentar apenas as informações desejadas e omitir as redundâncias ou informações desnecessárias. Por isso, em algumas entidades que aparecem em um diagrama de instâncias,

podem faltar indicativos de nome, valor, tipo ou alguma outra informação que se julgou irrelevante para uma situação.

Figura 3.10 - representação das entidades no diagrama de instâncias.

As entidades na base do PCTE são tratadas como objetos. Os objetos guardam informações que possuam algum significado para as ferramentas ou para o usuário e também informações necessárias ao sistema (ex. data de criação e proprietário do objeto) para que este possa manipular os objetos de forma consistente. No diagrama, os objetos são representados como círculos sombreados, como é o caso, na figura 3.10, da palavra autor, representando uma pessoa que escreveu algum texto ou obra. Para referenciar um certo objeto, utiliza-se no diagrama, um pseudônimo (ou rótulo), representado por um retângulo branco que leva dentro de si um pequeno nome (geralmente uma letra maiúscula apenas). Este nome tem sentido apenas para referenciar, por algum motivo, um objeto dentro do diagrama, como por exemplo, o objeto que possui um retângulo com a letra A na figura 3.10.

Os objetos interagem com os outros objetos para modelar os relacionamentos que estes possuem no mundo real, como por exemplo, um objeto documento poderia se relacionar com um objeto autor pelo relacionamento escrito_por ou escreveu, conforme se considere a origem e o destino do relacionamento (claro, no primeiro caso, o objeto documento é a origem do relacionamento e no segundo, objeto autor é a origem). No nosso exemplo, apenas o nome escreveu é aceito, pois o relacionamento é unidirecional, com origem no objeto autor.Os relacionamentos são representados dentro da base por meio de uma ligação (link), que liga dois (e sempre dois) objetos, um chamado origem (do qual o link parte) e outro destino (ao qual o link chega). Um único link pode ligar os dois objetos em um relacionamento unidirecional, ou então um par de links de direções opostas (chamados links reversos) podem ser usados para determinar um relacionamento bidirecional. No diagrama, um único link é representado por uma flecha comum, enquanto que os links duplos são representados por duas flechas paralelas e de sentidos contrários. As flechas dos links duplos têm, cada uma, apenas metade da ponta, o que aumenta a idéia de dependência entre eles.

Na figura 3.10, existe apenas um relacionamento unidirecional, entre o objeto autor e o objeto documento. O relacionamento leva o nome de escreveu e sua direção é o objeto do tipo autor para o objeto do tipo documento. Os outros relacionamentos que existem na figura são bidirecionais, representados por flechas duplas. A escolha entre um relacionamento unidirecional ou bidirecional depende exclusivamente da necessidade do usuário ou da ferramenta que vai utilizá-lo.

Vários links podem partir ou chegar a um objeto. Estes links podem ser de diversos tipos, dependendo do que foi definido no tipo do objeto em questão. O mecanismo de definição de tipos é a base para a abstração de dados do PCTE, e será estudado em mais detalhes na seções seguintes. No diagrama, o tipo de um objeto

é indicado por um nome colocado sobre o círculo que o representa, como é o caso do objeto com a palavra autor sobre ele, indicando que este é um objeto do tipo autor. Já o tipo dos links é indicado por um retângulo que possui uma ponta direcionada para o link. Dependendo da cardinalidade do relacionamento que o link representa, seu tipo pode ser precedido por uma chave, como é o caso do link indicado por 1.seção, onde o número 1 é a chave e seção é o tipo do link.

A cardinalidade de um relacionamento determina quantos links poderão chegar ou partir de um objeto. Por exemplo, uma cardinalidade um-para-muitos determina que, do objeto origem poderá partir vários links, mas no objeto destino poderá chegar apenas um link. Um exemplo disto é o relacionamento existente no diagrama entre o objeto do tipo documento e os objetos do tipo texto. O tipo do link que liga os objetos é seção, o que representa que um objeto do tipo texto faz o papel de uma seção (como um índice ou um capítulo) dentro de um documento. A cardinalidade do relacionamento é um-para-muitos (se olhado do objeto documento para o objeto texto), por isso, vários links podem sair do documento, mas apenas um link deste relacionamento pode chegar a cada um dos objetos texto. O fato do relacionamento ser um-para-muitos também impede que um objeto texto faça parte de mais de um documento. Mas isto é determinado somente pelo projetista da ferramenta que utiliza estes dados (neste caso, poderia ser um editor de textos), sendo que o PCTE suportaria também um relacionamento muitos-para-muitos, se fosse necessário.

Um objeto pode participar de quantos relacionamentos necessitar, o que pode confundir um pouco a noção do número de links partindo e chegando a um objeto como foi exposto acima. No caso dos objetos do tipo texto da figura 3.10, o relacionamento com o objeto documento determina que apenas um link do tipo seção pode chegar a eles. Porém, isto não impede que outros links de outros tipos possam chegar até eles. Poderiam existir outros objetos que se relacionassem com estes textos, ou o próprio objeto documento poderia participar de outro relacionamento com eles (como um relacionamento que indicasse a ordem em que devem ser apresentados estes textos dentro do documento).

O PCTE não determina de quantos relacionamentos um objeto participa, mas exige que o tipo dos links e a quantidade de cada tipo que pode partir ou chegar ao objeto sejam especificados. Esta especificação é feita através do limite inferior e limite superior do intervalo de cardinalidade, o qual especifica, respectivamente, o mínimo e o máximo número de links do mesmo tipo que podem sair do mesmo objeto origem. Se a variação, em parte ou todo não é definida, o valor default do limite inferior é zero e o do limite superior é um número arbitrário alto.

Tanto objetos quanto links podem ter associados a eles um certo número de atributos. Os atributos guardam partes das informações dos objetos e links. Essas informações são necessárias aos usuários (ex. o nome de um capítulo, o título de um figura e o estado em que se encontra um programa), às ferramentas (ex. o número páginas de um documento postscript e a identificação de seu criador) ou ao SGO (ex. a hora de criação do objeto e a identificação de seu criador) e, são derivadas dos sete tipos básicos predefinidos do PCTE (boolean, natural, enumeration, time, float, integer e string). Atributos sempre são encontrados na base, associados a um objeto ou a um link, nunca separadamente, e seus nomes devem ser únicos dentro de um objeto ou link. As operações permitidas sobre os atributos, além de sua associação a um objeto ou link, são a leitura e a escrita, ficando a cargo de cada ferramenta qualquer outro processamento sobre eles.

No diagrama de instâncias, um atributo de um objeto é representado como um retângulo pontilhado (ou tracejado) colocado sobre o círculo que identifica o objeto ao qual ele pertence. Dentro do retângulo pode ser colocado apenas o valor do atributo (como em Capítulo 1, na figura 3.10) ou seu nome, seguido de um sinal de igual e o seu valor (no mesmo exemplo, poderíamos ter identificação = “Capítulo 1”). Não é permitido colocar apenas o nome do atributo, pois este é um diagrama de instâncias. Caso mais de um atributo do objeto necessite ser mostrado no diagrama, estes devem ser “empilhados” uns sobre os outros dentro de retângulos individuais. Os atributos de um link são mostrados por meio de retângulos com bordas completas (não tracejadas), encostados acima ou abaixo do tipo do link. Também deve ser empilhados quando houver mais de um.

O atributo tipo enumeração (enumeration) é parecido com os tipos enumeração das linguagens de programação (ex. C, Ada e Pascal) e determinam um conjunto de valores que um certo atributo pode conter. Por exemplo, um atributo que determine o direito de acesso de uma ferramenta sobre um objeto

poderia ser um atributo enumeração com itens-enumeração: nenhum, leitura, modificação e destruição. Cada item-enumeração do conjunto também é um tipo especial do PCTE e está ligado ao tipo enumeração por links de composição.

A imagem de cada item-enumeração (o valor que denota cada item para o sistema) é uma string contendo um valor qualquer, dado pela ferramenta ou pelo usuário. Como exemplo, podemos ter o item-enumeração nenhum com uma imagem “Sem direitos” e o item destruição a imagem “Todos os direitos”.

Um atributo especial para objetos é o conteúdo (contents) que pode ser comparado a um arquivo de um sistema de gerenciamento de arquivos7, pois é um fluxo de bytes não estruturado ao qual são aplicadas operações simples de abertura, fechamento, posicionamento (seek) do ponteiro, leitura e escrita (de quantidades variáveis de caracteres). Nem todo objeto possui contents e, quando ele está presente, armazena informações com volume de dados consideravelmente maior que um atributo simples (como um número ou uma string). Exemplos típicos são texto, (seja de um editor ou um gerador de aplicativos), código executável, figuras, código binário e qualquer bloco de informação que necessite ser manipulado como se fosse um arquivo. O conteúdo é um atributo sem nome e é herdado dos tipos ancestrais do objeto, não podendo ser associado a um objeto como os outros atributos.

Os objetos e links estão organizados na base, formando um grafo direcionado, sendo que os objetos são os vértices e os links são os arcos do grafo. A figura 3.11 mostra uma pequena parte deste grafo (e é mais um exemplo do diagrama de instâncias), representando alguns relacionamentos entre programadores, módulos fonte e programas.

Figura 3.11 - uma parte do grafo formado na base de objetos

Todos os relacionamentos mostrados na figura 3.11 são bidirecionais, como é o caso de escrito_por que liga objetos com os rótulos C e 1.

Existe um relacionamento especial mostrado na figura 3.11, situado entre programas e módulos (o relacionamento possui faz_parte), que estabelece uma relação de composição entre os objetos - um programa é composto de vários módulos. Determinar objetos compostos é uma função especial dos links.

7no estilo do sistema de gestão do UNIX

Uma característica interessante do exemplo da figura 3.11 é que entre objetos dos tipos programador e módulo, existem duas espécies de relacionamentos, um chamado escreveu e outro chamado revisou. Isto acontece porque no mundo real (de onde foram retirados estes relacionamentos) devem ser relevantes as diferenças existentes entre as duas atividades (escrever e revisar) efetuadas sobre os módulos. Mais uma vez, isto é uma decisão do gerente de processo ou dos projetistas das ferramentas.

Nos links que saem do objeto 1 em direção aos objetos A e B, existe um número seguido de um ponto, antes do seu tipo (como em 1.possui). Este número é chamado de chave do link e é necessário para diferenciar dois links de um mesmo tipo que partem de um objeto. As chaves são um tipo especial de atributo para links e podem ser numéricas (números naturais), ou alfanuméricas, utilizadas quando se deseja dar maior significado e complementar o nome de um link. Sempre que um objeto possui mais de um link de um mesmo tipo saindo dele, estes links devem receber chaves para diferenciá-los, pois tanto os objetos quanto os links da base são designados pelos caminhos formados pelos link. A designação de objetos e links dentro da base é o assunto da próxima seção.

3.2.3.2 - Navegando pelo repositório

O repositório do PCTE reflete todas as atividades produzidas no processo de software, por isso, é uma base extremamente mutável. Cada processo invocado dentro do SEE causa uma atualização na base, por menor que seja (o sistema cria um objeto representando o contexto dinâmico de cada processo que entra em execução). Geralmente, as modificações são mais profundas e a pesquisa aos dados da base é bastante elevada. A forma como estão organizados os dados requer um mecanismo especial para poder-se designar cada objeto ou link dentro da base de dados. O grafo gerado pelos objetos e pelos links pode conter até centenas de milhares de elementos, dependendo do número de projetos sendo desenvolvidos e do número de usuários da instalação, mas dezenas de milhares é um número razoável para qualquer base, o que já exige um sistema ágil o bastante para que o desempenho geral da instalação não fique prejudicado.

Para poder chegar a cada objeto dentro da base, o PCTE utiliza um sistema de navegação por entre os links, designando sequências de links a partir de um objeto de posição determinada até chegar ao objeto que se quer encontrar. Estas sequências são denominadas caminhos (paths) e são possíveis pois, cada link que parte de um objeto, possui um nome exclusivo em relação aos outros links daquele objeto. Quando entra em execução, uma ferramenta determina certos objetos dentro da base, denominados objetos referenciados, que serão o início dos caminhos para chegar a um objeto qualquer. Na figura 3.11, por exemplo, o objeto X (do tipo programa) poderia ser referenciado. Então, o objeto 2 (do tipo programador) poderia ser designado por:

$X/1.possui/escrito_por

ou então por um caminho alternativo:

$X/2.possui/escrito_por

Podemos notar que os dois caminhos são válidos e designam exatamente o mesmo objeto. Isto é comum, devido aos objetos participarem de vários relacionamentos ao mesmo tempo. Também é bom lembrar que os links escrito_por que aparecem nos exemplos acima não são os mesmos, e isto não causa ambiguidade para o PCTE, pois cada um deles só pode ser acessado por caminhos diferentes, ou seja, o conjunto de links e objetos anteriores a eles, (no caso $X/1.possui e $X/2.possui) são diferentes ou a ordem de aparição dos links e objetos destes conjuntos é diferente. Aliás, este também é o modo de designar links dentro da base. Por isso, os exemplos anteriores também designam os links escrito_por mas, ao contrário do objeto 2 (que era único em ambos os casos), cada caminho designa um link diferente (veja a figura para comprovar isto).

Note também a semelhança entre a forma de navegação do PCTE e a navegação (e indicação) dos diretórios do sistema UNIX. Isto não é coincidência, pois as primeiras idéias dos projetos que deram origem ao PCTE atual eram bastante ligadas ao UNIX, sendo que as primeiras implementações foram feitas neste sistema.

Para designar-se um atributo, primeiro encontramos o objeto ou link ao qual ele está associado, (pois estão sempre associados a um objeto ou a um link) da mesma forma explicada acima e então indicamos o nome do atributo.

3.2.3.3 - Mecanismo de tipos e esquemas

As seções seguintes descrevem os mecanismos de tipos e esquemas do PCTE que são utilizados para representar os dados manipulados pelas ferramentas e pelo processo de software.

Tipos

Vamos considerar a situação de criação de um objeto para guardar um capítulo de um livro, dentro do repositório de dados do PCTE. Este objeto pode trazer informações sobre o título deste capítulo (para que ele seja facilmente encontrado por uma ferramenta de busca), a data de sua criação, o número de páginas que possui, além do próprio texto que forma este capítulo. Essas informações podem ser colocadas, em um único objeto, cuja ferramenta associada (ex. um browser) determina que espécie de estrutura guardaria naquele objeto. Entretanto, se houvesse em algum lugar separado, informações sobre a estrutura interna do objeto, tanto um editor quanto o browser poderiam trabalhar conjuntamente utilizando as mesmas estruturas de dados.

O modelo de dados do PCTE permite a integração de ferramentas exatamente porque a definição de tipos não é particular a cada ferramenta. Eles podem ser acessados por muitas ferramentas distintas, desde que estas possuam a capacidade de entender o modelo de definição de tipos do PCTE. Quando uma ferramenta descreve um novo tipo, ele passa a estar disponível para qualquer outra ferramenta que queira utilizá-lo, por meio de um mecanismo de importação de tipos.

As entidades básicas do modelo de dados do PCTE são objetos, links e atributos, e são essas as formas de tipos que existem. Os objetos são os únicos que possuem herança de tipos, ou seja, são os únicos que podem receber as informações já definidas em outros tipos ditos ancestrais (parents), e também servirem como ancestrais de outros tipos.

O sistema necessita guardar informações sobre os tipos, para poder manipulá-los (criar objetos de um certo tipo, testar o tipo de uma entidade). Ele guarda estas informações em objetos chamados objetos tipo, que são armazenados na base de objetos juntamente com os outros objetos. Estes dados sobre a própria estrutura do repositório são chamados de metadados e são tratados igualmente a qualquer outra entidade.

Apenas algumas características de um objeto, link ou atributo são definidas na especificação de seu tipo, já, outras informações não são suportadas por um tipo, pois elas variam com a situação de uso da entidade, como os tipos e o número de links que partem e chegam a um determinado objeto e os atributos que ele possui. As informações que mudam, conforme o uso de um tipo, são definidas dentro de uma coleção de tipos relacionados, chamada de SDS (Schema Definition Set).

Esquemas de trabalho e conjuntos de definições de esquemas

A existência de um grande número de tipos (entre centenas e milhares) dentro da base de dados é comum em instalações do PCTE. Para uma ferramenta, pode ser muito difícil (e nada eficiente) lidar com todos os tipos que venham a aparecer no repositório. Também não é necessário que a ferramenta saiba todos os relacionamentos dos quais os objetos que manipula fazem parte. Como exemplo, uma ferramenta destinada a controlar acesso de usuários a projetos, tem que conhecer, a priori, apenas os objetos do tipo usuário, os objetos do tipo projeto e os links entre estes objetos, que poderiam ser do tipo permissão e que teriam como atributos uma senha, um período de validade e um período de renovação obrigatório da senha. Mesmo que o objeto projeto tenha outros relacionamentos (ex. listas de atividades, arquivos texto, especificações e ferramentas utilizadas), para a ferramenta de permissão de acesso, estes relacionamentos não são relevantes,

e não precisam ser conhecidos. Para resolver este problema, cada ferramenta possui um esquema de trabalho (working schema), que determina quais entidades serão vistas pela ferramenta dentro da base.

Um esquema de trabalho é um conjunto de SDSs, que determina todos os tipos de relacionamentos necessários a um processo em um dado momento. O esquema de trabalho filtra toda a informação que existe na base de objetos, permitindo que a ferramenta visualize apenas os dados que lhe interessa e impedindo que esta manipule dados que não lhe dizem respeito, ou os quais não conhece a estrutura. A figura 3.12 dá uma idéia de como isto ocorre.O esquema de trabalho de uma ferramenta pode ser alterado em tempo de execução, caso isto seja necessário.

Cada SDS guarda uma coleção de tipos objeto, tipos link, tipos atributo e tipos itens_enumeração, que estão relacionados de algum modo. Por exemplo, é no SDS que se determina quais os links que partem e chegam a um objeto, os seus atributos associados, o modo de uso e várias outras informações.

Figura 3.12 - o esquema de trabalho como um filtro8

Os objetos que compõem o SDS são chamados de tipos-no-SDS. Existem quatro espécies de tipos-no-SDS: tipos-no-SDS de objetos, tipos-no-SDS de links, tipos-no-SDS de atributos e tipos-no-SDS de itens-enumeração. Cada um deles guarda informações específicas para cada entidade que representa. Existem propriedades gerais para todos os tipos-no-SDS, tais como o modo de uso do tipo, nome local ao SDS, hora de criação ou importação, que são guardadas em todos os tipos-no-SDS.

Os tipos, que cada tipo-no-SDS referencia, podem ser importados de outro SDS ou podem ser criados pela ferramenta. Uma ferramenta pode ainda criar SDSs, ou utilizar-se de vários SDSs diferentes e já existentes na base.

Os SDSs provêm a separação do modelo de dados de uma ferramenta de seu código. Esta separação facilita extremamente a integração das ferramentas. Tal estrutura é ilustrada na figura 3.12.

8Figura adaptada de [Wak93]; Figure 3.4; pag 43

Ferramentas Verticais:

Ferramenta deAnálise de Requisitos

Ferramentade Codificação

. . .

Comunicação entre ferramentas

e o PCTE

Banco de Dados:

SQL Oracle QBE

SDSs todos os tiposdo repositório

PCTE

Figura 3.13 - comunicação das ferramentas com o PCTE.

Em um ambiente baseado em PCTE existem quatro SDSs, que representam os tipos predefinidos do PCTE, necessários para suportar suas operações. Esses SDSs são:

system: contém todos os tipos necessários para distribuição, execução, comunicação interprocessos e mecanismos de controle de concorrência/integridade no PCTE. É nesse SDS que o tipo principal de objeto (object) e seus atributos são definidos;

metasds: contém todos os tipos de meta-esquema necessários para operações na base de objeto; security: contém todos os tipos necessários pelos mecanismos de segurança; accounting: contém todos os tipos necessários para os mecanismos de contabilização.

No PCTE, cada processo tem um esquema de trabalho associado, tornando possível que tipos visíveis de um esquema de trabalho e suas instâncias possam ser acessados pelos respectivos processos, e, portanto, fazendo com que ferramentas executáveis possam conhecer os esquemas que representam seus modelos de dados.

Um esquema de trabalho é definido por uma sequência de SDSs, sendo a ordem dos mesmos significativa na decisão dos nomes dos tipos, como descrito abaixo. Um esquema de trabalho é uma união bem formada de tipos de uma sequência de SDSs, formando um conjunto de tipos-no-esquema-de-trabalho. Um tipo-no-esquema-de-trabalho representa a união das seguintes propriedades:

um objeto tipo, cujo tipo está no tipo-no-esquema-de-trabalho; cada tipo-no-SDS que está associado ao objeto tipo, cujo SDS está incluído no esquema de

trabalho. Um tipo que é compartilhado entre SDSs pode, portanto, ter propriedades no esquema de trabalho que tenham sido derivadas de mais de um SDS;

algumas propriedades herdadas dos tipos pais (somente para o tipo objeto). Isso significa que uma instância de um tipo objeto pode ser tratada como uma instância de um de seus tipos ancestrais que está no esquema de trabalho, ou seja, uma instância de um tipo não incluído no esquema de trabalho será acessível se um tipo ancestral está no esquema de trabalho. Por exemplo, considere um SDS para um desenvolvimento de programa que define source-code como tipo filho de file. Se o SDS file está no esquema de trabalho, então as instâncias de source-code podem ser acessadas com todas as propriedades envolvidas pelos tipos do SDS. Se esse SDS é excluído do esquema de trabalho e system é incluído, então as mesmas instâncias serão acessadas como instâncias de system-file, com as propriedades daquele tipo ao invés desse.

Um tipo-no-esquema-de-trabalho pode ter vários nomes diferentes, derivados do nome de cada associação com o tipo-no-SDS. Se dois tipos-no-esquema-de-trabalho diferentes possuirem o mesmo nome local, este é

associado ao tipo do primeiro SDS da sequência. Isto é o único significado prático de ordem dos SDSs que definem um esquema de trabalho.

Nas operações dos processos do PCTE, somente os tipos-no-esquema-de-trabalho são avaliados. Portanto, são eles que determinam as propriedades das instâncias que serão vistas.

Esquemas de trabalho diferentes podem fornecer diferentes visões de uma base de objetos; por exemplo: os tipos de link que são visíveis em um esquema de trabalho, podem ser invisíveis ou ter nomes diferentes em outro. Desse modo, visões apropriadas para diferentes tarefas podem ser providas, ou banco de dados logicamente separados podem ser definidos.

Tipos Importados em um SDS

Cada SDS (exceto system, o qual define o object) deve importar pelo menos um tipo objeto como base para os tipos filhos que serão definidos, e/ou aplicações no tipo de link ou atributo que serão feitas. Importar tipos é o mecanismo para uma nova ferramenta registrar seus esquemas no esquema global do ambiente, fazendo a associação entre os tipos já existentes e os novos tipos.

Quando um tipo é importado, um novo tipo-no-SDS é criado, com algumas das propriedades do original. As propriedades que não acompanham o novo SDS são as que seriam modificadas ou ignoradas no novo SDS, para propósitos de modelagem de dados.

Quando um tipo é importado, ele pode receber um nome local diferente, e novas aplicações dos tipos no novo SDS podem ser feitas. Se o nome local não é especificado explicitamente, o nome local do SDS original é assumido.Quando um tipo é importado em um SDS, nem todas as propriedades do tipo-no-SDS original são assumidas, conforme descrito abaixo:

na importação de um tipo objeto, todos os seus tipos ancestrais são implicitamente importados se eles já não estão no SDS, mas eles não têm nome local no SDS importador. Se o tipo-no-SDS original era associado aos tipos de link e atributos, esses não são importados implicitamente. Suas aplicações não são importadas até mesmo se tipos associados são explicitamente importados;

em um tipo link, seus tipos de atributos chaves (se existirem) são importados implicitamente, do mesmo modo que o tipo reverso e os tipos de atributos chaves (se existirem), mas nenhum desses tipos importados implicitamente tem nome local no SDS importado. Nem os tipos de atributos não-chaves, nem suas aplicações, são importados. Quando um tipo link é importado, ele não está associado a quaisquer tipos objeto. Portanto, um tipo de link recentemente importado tem que ser associado com a origem e destino dos tipos de objetos, antes que as instâncias do tipo possam ser usadas;

quando se importa um tipo atributo, ele não está associado com quaisquer outros tipos. Portanto, um tipo atributo recentemente importado, tem que ser associado com tipos de objetos ou links, antes de ser usado. Já num tipo atributo de enumeração, seus tipos de ítens de enumeração são implicitamente importados, mas eles não têm nome local no SDS importado. Um tipo de ítem de enumeração não pode ser explicitamente importado em um SDS.

3.2.4 Considerações Finais

Com base nas discussões acima, podemos resumir que a arquitetura de uma ferramenta CASE deve conter os módulos necessários, para permitir a sua comunicação com o mundo externo, através de mecanismos de compartilhamento de dados, controle e apresentação, conforme ilustrado na figura 3.14.

Figura 3.14. Composição de uma ferramenta CASE.

As facilidades ou dificuldades de inserção de uma ferramenta CASE em um conjunto integrado, depende essencialmente das três dimensões referidas acima. No caso da integração por dados é necessário analisar os modelos de dados e processos internos da ferramenta a ser inserida, e compatibilizá-los com os modelos das ferramentas existentes. Isto requer atividades específicas, diferentes do projeto de esquema para repositórios tradicionais. A exemplo, Brémeau [Bre93, Bre95], apresenta um método para definição de esquemas para PCTE, onde as características especiais deste repositório são consideradas.

A inserção de uma ferramenta em uma aqruitetura de passagem de mensagens envolve conversão de suas entradas e saídas, nos tipos de mensagens existentes nos mecanismos de suporte, tais como requisição, resposta ou notificação.

Até o momento, falamos de ferramentas CASE e seus mecanismos de integração, nos referindo ao mínimo à ambientes de engenharia de software. Historicamente, as ferramentas CASE, também conhecidas como COTS (Commercial of the Shelf Tool) se desenvolveram paralelamente aos estudos de ambientes integrados, o que culminou no estabelecimento de duas culturas CASE que agora tendem a convergir.

A tabela 3.2 mostra uma evolução de ambientes e ferramentas mais alguns exemplos destes. A cultura de ambientes integrados (IPSE e SEE) [Bro92] voltou-se para pesquisas sobre a arquitetura das ferramentas e definição de um framework que fornecesse os serviços necessários para integração a nível de dados, controle e apresentação. Os ambientes foram concebidos para apoiar todo ciclo de vida de software. Seriam ambientes completos, conforme ilustrado na figura 3.15, onde ferramentas poderiam ser facilmente integradas (plug-and-play). Esta cultura foi desenvolvida a nível acadêmico na busca de soluções eminentemente técnicas e cooperativas.

Eventos Ano ExemplosFerramentas individuais 1950s Compiladores e ligadores.Grupos de ferramentas 1975 UNIX Programmer’s WorkbenchPrimeiros ambientes integrados 1979 CADES

Usuário

Outras FerramentasInterface com o

Usuário

Interface Banco de Dados

Interface Comunicação

A influência de ADA 1980 Stoneman (APSE)Ferramentas CASE 1980s RCS do UnixAmbientes abertos e fechados 1984 PerspectiveIPSEs 1985s ASPCTE, ECLIPSE e IPSE 2.5Padrões para Public Tool Interface 1990s PCTEPSEEs 1988s ARCADIAFederação de CASE (CASE Environment) 1993sFerramentas de suporte ao processo de software 1993s Synervision e Process WeaverAmbientes de engenharia de software comerciais 1995 DBENCH Tabela 3.2 - Evolução histórica dos ambientes de engenharia de software e ferramentas CASE.

Por outro lado, a cultura CASE desenvolveu-se com escopo localizado (ex. especificação, projetoou gerenciamento de configuração). A ênfase foi na produção de ferramentas isoladas. Esta cultura

desenvolveu-se no âmbito comercial. Os problemas apontados neste capítulo, no entato, fizeram com que os fabricantes de ferramentas procurassem soluções a nível de integração.

A fusão dessas culturas tem sido referida como Federação de CASEs ou CASE Environment [Bro94].

Uma dimensão que também pode ser considerada nos modelos de integração [Tho92] é a de processo. Os conceitos básicos desta dimensão são apresentados em Gimenes [Gim94]. Brown et. al. [Bro94] propõe um modelo de integração de três níveis, no qual a dimensão de processo é vista como primordial para análise da integração de ferramentas. Finkelstein [Fin94] apresenta os principais projetos europeus nesta área. Christie [Chr95] traz uma descrição dos conceitos básicos de processo de software mais uma comparação de duas ferramentas de suporte ao processo de software.

Finalmente, o projeto da arquitetura de uma ferramenta CASE deve observar o nível de integração desejado (coesão e acoplamento). Deve ser analisado o quanto vale a pena integrar ou prover integração para outras ferramentas, devido à complexidade técnica que ainda persiste na área. Deve ser analisado, basicamente, independência versus forte cooperação.

Figura 3.15 - Arquitetura de um SEE.

4. Adoção de Ferramentas CASE

Visto como um meio de melhorar a qualidade e a produtividade da produção de software, o

processo de adoção de ferramentas CASE tem assumido papel significativo na indústria de software, pois, em contraste ao aumento do número de ferramentas CASE disponíveis no mercado, muitas organizações não têm obtido aumentos significativos de produtividade. É possível que grande parte das ferramentas CASE caiam em desuso. Isto deve-se às

inadequadas práticas na adoção dessas ferramentas. O IEEE P1348 - Recommended Pratice For the Adoption of CASE Tools [IEEa], apresenta um conjunto de questões importantes para aumentar as probabilidades de sucesso na adoção de ferramentas, as quais são resumidas nesta seção.

Considera-se que a adoção bem sucedida de uma ferramenta CASE, deve, pelo menos: prover um nível apropriado de suporte tecnológico para os processos de

desenvolvimento e manutenção de software; ter um impacto positivo sobre: produtividade, qualidade do produto, aderência a

padrões, documentação e aquisição de medidas quantitativas;

induzir o uso geral e contínuo de ferramentas na organização e seus grupos.

Os passos significativos para adoção de uma ferramenta CASE incluem: definição das necessidades de CASE; avaliar e selecionar ferramentas CASE; conduzir um esforço piloto; migrar as ferramentas para uso rotineiro.

A definição das necessidades de CASE abrange a aquisição de conhecimento sobre o que existe disponível no mercado, bem como a avaliação da qualidade destes produtos. Isto pode se dar através das documentações e seminários oferecidos pelos fornecedores. É importante também que se obtenham informações sobre a aplicação das ferramentas a partir de usuários experientes.

Ao mesmo tempo, deve-se fazer uma avaliação das capacidades da organização interessada

na adoção, em termos do seu processo de produção de software, das tecnologias utilizadas e do pessoal envolvido. Abordagens formais para esta avaliação incluem: o modelo Capability Maturity Model (CMM) do SEI9 [Pau93] e os padrões relacionados a ISO 9000. Este é um aspecto fundamental, uma ferramenta CASE não irá solucionar os problemas de organização de uma companhia. Humphrey [Hum89] sugere que ferramentas CASE não sejam utilizadas antes de se obter um processo bem definido (nível 3). Brown et. al. [Bro94] aponta que benefícios podem ser obtidos já no nível 2, através de algumas ferramentas, uma vez que este inclui: gerenciamento de configurações, garantia de qualidade, gerenciamento de projetos e gerenciamento de requisitos. Já existem boas ferramentas em alguns desses casos, como por exemplo gerenciamento de projetos.

9 Software Engineering Institute.

As necessidades da organização são derivadas dos problemas que estão sendo enfrentados no

desenvolvimento de software, que podem estar relacionados a: gerenciamento, processo, produto, fatores econômicos, pessoal e fatores tecnológicos.

Devem ser também definidos critérios mensuráveis para possibilitar a avaliação do sucesso alcançado na introdução da ferramenta. Alguns desses critérios incluem: medidas de produtividade do processo de software, percentual de projetos utilizando a ferramenta, tempo de treinamento necessário, nível alcançado pelo pessoal que utiliza a ferramenta, precisão das estimativas de custo do processo de software e aderência a padrões.

A avaliação e seleção de ferramentas identifica critérios de seleção, ferramentas candidatas e emite uma recomendação para seleção de uma ou mais ferramentas. Este passo será descrito com mais detalhe no capítulo 5.

Após selecionadas as ferramentas, deve-se conduzir um ou mais projetos pilotos para verificar os passos anteriores e preparar para a introdução da ferramenta em larga escala. O projeto piloto deve ser de preferência um projeto conhecido, para permitir comparações, e ,

que possa ser desenvolvido no tempo previsto para o projeto piloto. Ao final deste passo deve-se confirmar a adoção da ferramenta ou abandonar o esforço de adoção.

Para efetivar a migração da ferramenta, para uso geral e contínuo, é necessário preparar um plano de migração que dever conter:

informações sobre os objetivos, critérios de avaliação, cronogramas e riscos da migração;

informações sobre a aquisição, instalação e adequação da ferramenta ao ambiente;

necessidades e recursos para treinamento durante e após a migração; definição de procedimentos padrões para uso da ferramenta.

Um dos passos que normalmente é subestimado é a aquisição da ferramenta . Esta pode ser lenta e muitos parâmetros precisam ser definidos. Entre as informações que precisam ser tratadas estão:

os pacotes de componentes de software, documentação e treinamento a serem adquiridos para cada plataforma;

os mecanismos para aquisição de upgrades; ferramentas com as quais a nova ferramenta pode ser integrada; a adequação necessária para a ferramenta de modo a satisfazer as convenções e

procedimentos da organização; as responsabilidades pela instalação, integração, adequação e manutenção da

ferramenta; um plano para conversão de dados provenientes de ferramentas velhas.

Finalmente, deve-se monitorar o uso da ferramenta, oferecendo suporte para manutenção e upgrading.

5. Avaliação e Seleção de Ferramentas CASE

A avaliação de ferramentas CASE, é um processo no qual vários aspectos de uma ferramenta CASE são medidos, considerando-se critérios definidos e os resultados são armazenados para uso posterior. A seleção de ferramentas CASE é o processo no qual os dados de uma ou mais avaliações de ferramentas são ponderados e comparados, considerando-se critérios definidos, para determinar se uma ou mais ferramentas podem ser recomendadas para adoção. O padrão IEEE 1209-1992 - Recommended Pratice for the Evaluation and Selection of Case Tools [IEEb]. Nesta seção apresentamos um sumário das questões mais importantes tratadas neste padrão.

O processo geral de avaliação e seleção de ferramentas é mostrado na figura 5.1.

Figura 5.1 Processo geral de avaliação e seleção de ferramentas.

Este processo pode servir a vários propósitos, como: avaliação de várias ferramentas CASE e seleção de uma ou mais; avaliação de uma ou mais ferramentas CASE com os resultados mantidos para futura

referência; seleção de uma ou mais ferramentas CASE usando dados de avaliações prévias.

Objetivos, suposições, restrições

Ajuste Critérios

Avaliação CASE

SeleçãoCASE

Resultados da Avaliação

Necessidades do usuário

Lista de critérios

Lista de critérios ajustada

Decisão recomendada

CASE disponíveis

Pode incluir resultados existentes

As linhas da figura 5.1 ilustram o fluxo de informações nos processos. Os elementos que fazem parte do processo incluem:

objetivos, suposições e restrições; necessidades dos usuários: requisitos quantitativos e qualitativos; critérios: parâmentros para avaliação e decisão; resultados da avaliação; decisão recomendada.

Os cargos/funções envolvidos no processo são, em geral: usuários, fornecedores, avaliadores e selecionadores.

5.1 O Processo de Avaliação

Os passos definidos para a avaliação de ferramentas são descritos como segue: Definir a tarefa de avaliação:

especificar o propósito da avaliação; definir o escopo da avaliação; identificar suposições e restrições; definir as atividades de avaliação.

Identificar e selecionar critérios de avaliação.

Identificar CASE candidatas: avaliadores independentes, fornecedores do CASE, demonstrações e

informações de usuários atuais. Avaliar CASE candidatas:

exame da documentação do fornecedor; entrevista com usuários atuais do software; exame de documentações de projetos que utilizam o software; avaliação de demonstrações; aplicação das ferramentas em projetos pilotos; exame dos resultados de avaliações prévias.

Emitir relatório contendo resultados: sumário executivo; background da avaliação; abordagem da avaliação; informações sobre as ferramentas: nome da ferramenta, versão da

ferramenta, fornecedor, ponto de contato, configuração hospedeira, background e descrição da ferramenta.

Na descrição geral da ferramenta deve-se observar: processo de engenharia de software para o qual a ferramenta se aplica; ambiente de funcionamento da ferramenta (ex. liguagens de programação

suportadas, sistema operacional e compatibilidade com bancos de dados.); serviços relevantes providos pela ferramenta; estrutura de entrada/saída (estilo de interface); domínio de aplicação.

Ao final do processo da avaliação os resultados devem ser armazenados para posterior utilização em processo de seleção.

5.2 O Processo de Seleção

O processo de seleção de ferramentas pode embutir ou não um processo de avaliação. Em alguns casos podem ser usados dados disponíveis de uma avaliação independente. Nesses casos, deve-se compatibilizar os critérios de avaliação e seleção.

Figura 5.2 Critérios de seleção de ferramentas CASE.

Os passos envolvidos na seleção incluem: definir o propósito da seleção; definir o escopo da seleção

recursos, cronograma e resultados esperados; identificar suposições e restrições

Confiabilidade Usabilidade Eficiência Manutenabilidade Portabilidade Geral

Critérios

Funcionalidade

Ambiente de Operação

Funções Verticais

Funções Horizontais

Ambiente de Projetos

Ambiente de HW/SW

Ambiente Tecnológico

Modelagem

Implementação

Teste

Documentação

Gerenciamento de

Configuração

Gerenciamento de Projetos

escolher a ferramenta de mais baixo custo, finalizar a seleção em dois meses, pessoal disponível 50% do tempo para avaliação;

definir as atividades de seleção; identificar e ponderar os critérios de seleção; identificar as ferramentas candidatas (quando não identificadas em processo de

avaliação prévio); acessar os resultados da avaliação; aplicar os critérios considerados, aos resultados da avaliação.

Um dos pontos mais importantes no processo de avaliação e seleção é a definição de critérios. Os tipos de critérios podem ser valores exatos, como capacidade de memória requerida; escala de valores, como facilidade de aprendizagem (1..5); valores lógicos (y/n), como capacidade de gerar postscript ou medidas que tomam um ou mais valores, como plataformas de implementação.

Os critérios adotados no padrão IEEE 1209-1992 estão organizados de acordo com o padrão ISO/IEC 9126 - Information Technology - Software product evaluation - Quality characteristics and guidelines for their use.

A hierarquia destes critérios é ilustrada na figura 5.2. Relacionamos abaixo os pontos principais de cada um desses critérios:

Ambiente Operacional ambiente de projeto: aspectos relacionados ao projeto técnico, como apoio às

atividades do processo de software, domínio de aplicação, tamanho da aplicação suportada.

requisitos de hardware e software; ambiente tecnológico: obidiência a padrões, compatibilidade com outras

ferramentas, métodos e linguagens suportadas.

Funções Verticais Modelagem:

diagramação: bloco, Chen, fluxo de controle, DFD, ERA, Jackson, métodos orientados a objetos e redes de Petri;

análise gráfica: capacidade de analisar figuras gráficas das ferramentas para extração de informações para derivação de requisitos do projeto;

elicitação e especificação de requisitos; linguagens de especificação de projetos; modelagem de dados; modelagem de processos; simulação; prototipação; geração de telas; rastreamento; verificação de consistência e completude; projeto de relatórios

Implementação edição dirigida a sintaxe; geração de código; geração de esquemas de banco de dados; compilação; conversão de código fonte; análise de confiabilidade; engenharia reversa; reestruturação de código; análise de código fonte; depuração.

Teste definição do teste; execução automática de teste; análise dos resultados de teste; análise de cobertura de teste; análise de performance; capacidades de simulação.

Funções Comuns repositório de dados documentação

edição de texto, edição gráfica, edição baseada em formulários, hipertexto, obidiência a padrões, extração automática de dados e geração de documentos;

gerenciamento de configurações; gerenciamento de projetos; confiabilidade

integridade de dados, backup, segurança, manipulação de erros, manipulações de situações perigosas;

Usabilidade consistência da interface com o usuário; internacionalização; facilidade de aprendizagem e operação; facilidade de adaptação; qualidade da documentação; disponibilidade e qualidade de treinamento; conhecimento prévio requerido; uniformidade da interface com o usuário; help on-line; clareza de diagnósticos; tempo de respostas; facilidade de instalação.

Eficiência

requisitos de armazenamento; requisitos de memória; requisitos de processador; workload; performance.

Manutenabilidade atendimento a solicitações; fornecimento de atualizações; atualização das questões de compatibilidade.

Portabilidade compatibilidade com versões do sistema operacional; habilidade de mover entre diferentes versões da ferramenta; obidiência a padrões.

Critérios Gerais custo de implementação: compra, manutenção e treinamento; influência na organização; restrições de desenvolvimento/entrega; reputação do fornecedor; certificação do fornecedor; políticas de licenças; restrições de exportação; reputação da ferramenta; suporte do fornecedor; disponibilidade e qualidade de treinamento; ambiente de trabalho exigido para instalação da ferramenta.

Dados os passos e critérios acima, espera-se que a probabilidade de sucesso na adoção, avaliação e seleção de ferramentas CASE aumente. Pode-se notar que a análise detalhada do processo de software no qual a ferramenta será aplicada é fator decisivo nestes processos.

Referências

[Ber87] P. A. Bernstein, “Database System Support for Software Engineering”, Proceedings of the 9th International Conference on Software Engineering, pp 166-179, (Mar. 1987).

[Bre93] C. Brémeau and I. Thomas, “A Schema Design Method For PCTE”, Proceedings of the PCTE’93 Conference, 1993.

[Bre95] C. Brémeau and I. Thomas, Designing Schemas for Object Bases, Stanford Management Group, 1995 (draft version).

[Bro92] A. W. Brown, A. N. Earl, J. A. McDermid, Software Engineering Environments , Addison-Wesley Publishing Company (1992).

[Bro93] A. W. Brown, K. L. Wallnau e P. H. Feiler, “Understanding Integration in a Software Development Environment: Issues and Illustrations”, Jounal of Systems Integration, 3, pp. 303-329 (1993).

[Bro94] A. W. Brown, D. J. Carney, E. J. Morris, D. B. Smith e P. F. Zarrella, Principles of CASE Tool Integration, Oxford University Press, New York, (1994).

[Chr95] A. M. Christie, Software Process Automation: The Technology and Its Adoption, Springer-Verlag, Alemanha, 1995.

[EDS95] EDS, PORTOS - Technical Overview, 1995.

[Gim94] I. M. S. Gimenes, Uma Introdução ao Processo de Engenharia de Software, XIII Jornada de Atualização em Informática, Caxambu, Brasil (Ago. 1994).

[Hum89] W. S. Humphrey, Managing the Software Process, Addison-Wesley Publishing Company (1989).

[IEEa] IEEE Recommended Practice for the Evaluation and Selection of CASE Tools, IEEE Computer Society, (Dez. 1992).

[IEEb] IEEE P1348 Recommended Practice For the Adoption of CASE Tools, Draft 6.0, (Set. 1994).

[Nan95] E. C. L. Nanni, PCTE: Um padrão para Integração em Ambientes de Engenharia de Software, Relatório de Iniciação Científica, Departamento de Informática, Universidade Estadual e Maringá, (Ago. 1995).

[Pau93] M. C. Paulk, M. B. Chriss e C. V. Weber, Capability Maturity Model for Software, Version 1.1, Software Engineering Institute Technical Report CMU/SEI-93-TR-94, Carnigie Mellon University, Pittsburgh, P.A., (Fev. 1993).

[Pot94] C. Potts, K. Takahashi e A. I. Anton, “Inquiry-Based Requirements Analysis”, IEEE Software, Março, 1994.

[Pre92] R. S. Pressman, Software Engineering: A Parctioner’s Approach, 3a. Edição, McGraw-Hill, 1992.

[Sab95] S. B. Sabião, Método para Construção de Esquemas Compartilhados em PCTE , Relatório de Iniciação Científica, Departamento de Informática, Universidade Estadual e Maringá, (Ago. 1995).

[Sch93] D. Schefström e G. van den Broek, Tool Integration: Environments and Frameworks, John Wiley & Sons Ltd., Inglaterra (1993).

[Sch89] D. Schefström, “Building a Highly Integrated Development Environment Using Preexisting Parts”, IFIP’89 San Francisco, CA, USA, North Holland, (Set.89).

[Tho92] I. Thomas e B. Nejmeh, “Definitions of Tool Integration for Environments”, IEEE Software 9(3), pp 29-35, (Mar. 1992).

[Tra95] Transtar, Profile of Tools, 1995.

[Wak93] L. Wakeman e J. Jowett, PCTE: The Standard for Open repositories, Simon & Schuster International Group, Inglaterra, 1993.