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
desde a simples edição de textos até o gerenciamento de configurações, o teste de software e a verificação
formal de programas.
1

Computer Aided Software Engineering.

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].
 Ferramentas
Filtro
Fontes Dados Derivados
a)

Ferramentas
... com Dicionário de
Dados

b) Dicionário de Dados

Ferramentas
com Banco de Dados

c) Banco de Dados

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.
 Apresentação

Multimídia
Aparências
Operações
UIMS Comuns
Toolkit &
Guias de Estilo de
Window Manager Funcionalidades
Protocolos

Dados
Chamadas de procedimentos
Mensagens Dicionário
Sistema Base
Despachador de msgs de de de
arquivos Dados Objetos
Controle de processos

Controle Dados

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.
[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).

Tool A ... Tool Z Tool A Tool Z

Exportação de
Dados
Repositório de Dados Persistentes

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 Software

Esquemas relativamente estáticos que podem ser
determinados a priori.
Itens de dados de tamanho fixo.
Pequeno número de tipos de entidades com um grande
número de instâncias de cada tipo.
Itens de dados com valores únicos.
Esquemas dinâmicos e evolutivos, incluindo dados
sobre o sistema de integração.
Itens de dados de tamanho variável.
Grande número de tipos de entidades com poucas
instâncias destes.
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 Transações longas que exigem mecanismos mais
como base para controle de acessos concorrentes. 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.

Configurador

Editor Compilador

Código
Fonte
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.

UIC UIC
UIC

Software bus
SC SC

Figura 3.9. Ilustração da integração por controle através de software 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 ISO 6
(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.

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. É
2
PCTE: Portable Common Tool Environment
3
Public Tool Interface.
4
ESPRIT :European Strategic Programme on Research and development in Information
Technology
5
ECMA :European Computer Manufacturers Association
6
ISO :International Standard Organisation
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.

7
no estilo do sistema de gestão do UNIX
 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.

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

8
Figura adaptada de [Wak93]; Figure 3.4; pag 43
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.

Ferramentas Verticais:

Ferramenta de Ferramenta
Análise de Requisitos de Codificação

... Banco de Dados:

SQL Oracle QBE
Comunicação entre
ferramentas
e o PCTE

PCTE

SDSs todos os tipos

do repositório

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.

Usuário

Interface com o
Outras Ferramentas
Usuário

Interface
Comunicação

Interface Banco de
Dados

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 Exemplos
Ferramentas individuais 1950s Compiladores e ligadores.
Grupos de ferramentas 1975 UNIX Programmer’s Workbench
Primeiros ambientes integrados 1979 CADES
A influência de ADA 1980 Stoneman (APSE)
Ferramentas CASE 1980s RCS do Unix
Ambientes abertos e fechados 1984 Perspective
IPSEs 1985s ASPCTE, ECLIPSE e IPSE 2.5
Padrões para Public Tool Interface 1990s PCTE
PSEEs 1988s ARCADIA
Federação de CASE (CASE Environment) 1993s
Ferramentas de suporte ao processo de software 1993s Synervision e Process Weaver
Ambientes 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, projeto ou
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.

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.
9
Software Engineering Institute.
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.

Objetivos,
Necessidades do suposições,
usuário restrições

Ajuste
Critérios Lista de
critérios
Lista de ajustada
critérios

Avaliação
CASE
CASE
disponíveis

Resultados da Seleção
Avaliação CASE
Pode incluir
resultados existentes

Decisão
recomendada

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.

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.

Critérios

Confiabilidade Usabilidade Eficiência Manutenabilidade Portabilidade Geral

Funcionalidade

Ambiente de Funções Funções

Operação Verticais Horizontais

Ambiente de Modelagem Documentação

Projetos

Gerenciamento
Ambiente de Implementação de
HW/SW Configuração

Ambiente Gerenciamento
Teste de Projetos
Tecnológico

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
− 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.