Sistemas CASE
Introdução
DI-UFPE
@1997, Alexandre Vasconcelos
1
Conteúdo








DI-UFPE
Motivação
O que é CASE?
Uma Classificação para Sistemas CASE
Histórico;
Vantagens dos Sistemas CASE
Problemas com os Sistemas CASE
Ferramentas, Workbenches e Ambientes CASE
O Ciclo de Vida de um Sistema CASE
@1997, Alexandre Vasconcelos
2
Motivação



A Engenharia de Software envolve trabalho técnico,
administrativo e de controle;
Algumas tarefas são criativas e outras não;
Tarefas não-criativas podem ser automatizadas com
o uso de CASE (Computer Aided Software
Engineering):




DI-UFPE
editores de texto,
compiladores,
gerenciadores de versões,
etc.
@1997, Alexandre Vasconcelos
3
O que é CASE?

DI-UFPE
É o uso de suporte computacional no processo de
desenvolvimento de software;
@1997, Alexandre Vasconcelos
4
Uma Classificação para Sistemas CASE



Classificação permite que sistemas CASE possam
ser comparados;
Não existe uma classificação padrão;
Sistemas CASE podem ser classificados de acordo
com várias dimensões:




DI-UFPE
grau de formalidade imposta;
tipo de interface oferecida ao usuário;
fase(s) do ciclo de vida coberta(s);
profundidade do suporte oferecido, etc.
@1997, Alexandre Vasconcelos
5
Uma Classificação para Sistemas CASE fases x profundidade




DI-UFPE
Ferramenta - é um produto de software que auxilia em uma
ou mais tarefas específicas de uma ou mais fases do
processo (ciclo de vida) de desenvolvimento de software (ex:
compilação, checagem de consistência de um projeto,
edição de texto, etc.);
Workbench - conjunto de ferramentas integradas que
suporta uma ou mais fases do processo de desenvolvimento
de software (ex: especificação, projeto, implementação, etc.).
Ambiente - suporta todo ou uma grande parte do processo
de desenvolvimento de software. Geralmente é um conjunto
de workbenches integrados.
Na prática estes limites não são bem definidos.
@1997, Alexandre Vasconcelos
6
Uma Classificação para Sistemas CASE fases x profundidade
CASE
technology
Tools
Editors
Workbenches
Compilers
File
comparators
Analysis and
design
Multi-method
workbenches
DI-UFPE
Environments
Integrated
environments
Programming
Single-method
workbenches
Testing
General-purpose
workbenches
@1997, Alexandre Vasconcelos
Process-centred
environments
Language-specific
workbenches
7
Exemplos de Ferramentas CASE
Too l type
Managemen t to ol s
Edi ti ng t oo ls
Exa mples
P ERT t oo l s, Es ti mati o n t o ol s
Text ed ito rs, di ag ram edi to rs , wo rd
p ro cess o rs
Con fi gu rat io n man ag ement to o ls Versi on manag emen t s ys tems , Ch ang e
man agemen t s y st ems
P ro to ty p in g to ol s
Very hi gh -lev el l an g uages ,
u ser i nt erface g en erat ors
Meth od -s u pp o rt to ol s
Des ig n edi to rs ,d at a d icti o nari es , cod e
g en erat ors
Lan g uag e-proces si ng t oo l s
Comp il ers, in terp reters
P ro g ram an al ys is t oo ls
Cro ss reference gen erato rs, st ati c
analy sers , d y namic an aly sers
Tes ti ng t oo ls
Tes t d ata g en erat ors, fil e co mparato rs
Deb u gg i ng t oo ls
In teract iv e deb ug g in g sy st ems
Do cu men tati on t oo ls
P ag e layo u t p rog rams, imag e ed i to rs
Re-en g in eeri ng t oo ls
Cro ss -referen ce s ys tems, prog ram res tru ctu rin g s ys tems
DI-UFPE
@1997, Alexandre Vasconcelos
8
Um Ambiente CASE Típico
Desenvolvedores e
Gerentes
Farermenta A
Fearrmenta B
Ferramenta X
Integrador
Plataforma de Hardware e Software
Adm. Sist.
DI-UFPE
@1997, Alexandre Vasconcelos
9
Qualidade do Suporte CASE
Quality of tool support
Excellent
Good
Moderate
Poor
Req uir
emen ts
Fo rmal
d efin ition sp ecifica
tion
Fun ction o rien ted
d esign
Data
mod elling
Object-orien tedProg rammin g
d esign
Tes tin g
Main tenance Man ag emen t
Activity
DI-UFPE
@1997, Alexandre Vasconcelos
10
Histórico





DI-UFPE
Surgimento de Ferramentas CASE específicas;
Primeiras ferramentas voltadas ao desenvolvimento
de programas (ex: compiladores);
Desenvolvimento de ferramentas incompatíveis;
Necessidade de desenvolver ferramentas que
pudessem ser integradas;
Surgimento de workbenches de programação;
@1997, Alexandre Vasconcelos
11
Histórico




DI-UFPE
Surgimento de métodos de projeto de software (ex:
Jackson, Yourdon, etc.);
Adequação destes métodos a CASE (diagramas,
anotações e documentos);
Surgimento de ferramentas de suporte a estes
métodos;
Surgimento de workbenches de suporte a outras
fases do ciclo de vida de software;
@1997, Alexandre Vasconcelos
12
Histórico



DI-UFPE
Automação de fases isoladas não foi satisfatória;
Surgimento do APSE (Ada Programming Support
Environment) na década de 1980;
Surgimento de ambientes CASE integrados (IPSEs,
ICASE’s, SDE’s ou SEE’s), suportando todo o ciclo
de vida de software.
@1997, Alexandre Vasconcelos
13
Vantagens dos Sistemas CASE






DI-UFPE
Automatiza o trabalho manual (não-criativo);
Torna o desenvolvimento menos tedioso;
Impõe padrões de notações e métodos entre os
usuários;
Facilita a verificação de consistência e completude
do projeto, documentação e código dos sistemas;
Aumenta a produtividade e reduz os custos de
desenvolvimento;
Ajuda a melhorar a qualidade (ex: confiabilidade,
reusabilidade, etc.) do software;
@1997, Alexandre Vasconcelos
14
Vantagens dos Sistemas CASE



DI-UFPE
Ajuda a melhorar a documentação e manutenção;
Possibilita que problemas no desenvolvimento sejam
descobertos mais cedo, evitando a propagação entre
as diversas fase;
Enfim, ameniza a crise de software.
@1997, Alexandre Vasconcelos
15
Problemas com os Sistemas CASE

O grau de melhoria da produtividade é menor do que
o esperado, devido a:



DI-UFPE
Alguns problemas de desenvolvimento de software não são
completamente automatizáveis (ex: problemas de
gerenciamento);
Problemas de integração;
As pessoas que adotam estes sistemas não dão a devida
atenção aos processos de treinamento e adaptação.
@1997, Alexandre Vasconcelos
16
CASE Workbenches




DI-UFPE
São sistemas especializados, desenvolvidos a partir de
ferramentas e tecnologias particulares e que tiveram sua
aplicabilidade estendida para cobrir uma ou mais fases do
ciclo de vida do desenvolvimento de software;
Geralmente são fechados, ou seja, só podem ser
estendidos a partir da modificação de sua
arquitetura/código-fonte;
Existem alguns poucos workbenches abertos, onde novas
ferramentas podem ser adicionadas incrementalmente;
Existe um grande número de workbenches especializados
disponíveis e em uso, oferecendo excelente
funcionalidade e ganhos em produtividade;
@1997, Alexandre Vasconcelos
17
Ferramentas e Workbenches:
especificação de requisitos

As principais características encontradas nestes
sistemas são:






DI-UFPE
Captura de requisitos;
Alocação de requisitos a sub-sistemas (de forma gráfica ou
textual);
Estabelecimento de ligações entre requisitos
dependentes/derivados;
Rastreamento de requisitos (quem os forneceu?, por que?,
evolução, etc.);
Gerenciamento de versões dos requisitos;
Gerenciamento do trabalho cooperativo (acessos
concorrentes, níveis de acesso, etc.).
@1997, Alexandre Vasconcelos
18
Ferramentas e Workbenches:
especificação de requisitos

Exemplos:



DI-UFPE
DOORS (Dynamic OO Requirements System) - Quality
Systems & Software (QSS);
RTM (Requirements and Traceability Management);
ProductTrack (Ferramenta para Captura, rastreamento e
avaliação de requisitos).
@1997, Alexandre Vasconcelos
19
Ferramentas e Workbenches:
especificação formal

As principais características encontradas nestes
sistemas são:





Exemplos:


DI-UFPE
Ambiente para edição;
Verificação léxica, sintática e de tipos;
Geração de mensagens de erro com informações
suficientes para o usuário localizar e reconhecer o erro;
Auxílio à prova formal das especificações.
CADiZ (Computer AIded Design in Z) - York Software
Engineering;
Z-eves - ORA Canada.
@1997, Alexandre Vasconcelos
20
Ferramentas e Workbenches:
análise e projeto de sistemas

As principais características encontradas nestes
sistemas são:




DI-UFPE
Facilidades para representação gráfica do fluxo de controle
e dos dados correspondentes;
Facilidades para criação de um modelo do sistema e análise
da consistência do mesmo;
Suporte a métodos de análise e projeto estruturados (ex:
SA/SD, SADT, JSD) e/ou técnicas de modelagem orientadas
a objetos (ex: OMT, Booch, UML, etc.);
Pode incluir geradores de código a partir do modelo
especificado.
@1997, Alexandre Vasconcelos
21
Ferramentas e Workbenches:
análise e projeto de sistemas
Data
dictionary
Structured
diagramming
tools
Report
generation
facilities
Code
generator
Central
information
repository
Query
language
facilities
Forms
creation
tools
Design, analysis
and checking
tools
Import/export
facilities
DI-UFPE
@1997, Alexandre Vasconcelos
22
Ferramentas e Workbenches:
análise e projeto de sistemas

Exemplos:



DI-UFPE
ObjectMaker - Catalyst Software Ltd.
Teamwork - Cadre Technologies, Inc.
Paradigm - Platinum Technology.
@1997, Alexandre Vasconcelos
23
Ferramentas e Workbenches:
projeto e desenvolvimento de interfaces

As principais características encontradas nestes
sistemas são:



Exemplos:


DI-UFPE
Facilidades para edição gráfica da interface;
Geração do código correspondente a partir do protótipo da
interface construída por meio de manipulação direta.
Interviews;
X-Designer - Imperial Software Technology, UK.
@1997, Alexandre Vasconcelos
24
Ferramentas e Workbenches:
apoio à programação

As principais características encontradas nestes
sistemas são:


Exemplos:




DI-UFPE
Edição, compilação, ligação e depuração de programas.
Turbo C;
Turbo Pascal;
VisualC++;
Delphi.
@1997, Alexandre Vasconcelos
25
Ferramentas e Workbenches:
Dirigidos à Linguagem



DI-UFPE
Ferramentas compartilham uma representação
comum dos programas (ex: árvore sintática);
O editor de texto tem conhecimento da sintaxe da
linguagem e pode editar a representação abstrata ao
invés do código fonte;
Permite que múltiplas visões do programa sejam
geradas.
@1997, Alexandre Vasconcelos
26
Ferramentas e Workbenches:
Dirigidos à Linguagem
Graphical
progr am view
Text
view
Procedure
heading view
Abstract syntax
tree
DI-UFPE
@1997, Alexandre Vasconcelos
27
Ferramentas e Workbenches:
gerenciamento de projetos

As principais características encontradas nestes
sistemas são:




Facilidades para representação de fluxo de documentos;
Geração de métricas de produtividade;
Estimativas de esforço e custos;
Facilidades para gerenciamento de tarefas:
Quais as tarefas a serem executadas e por quem?
Qual o cronograma de execução das tarefas?
Quais os pré-requisitos para execução das tarefas?
Quais os recursos disponíveis para a execução das tarefas?
Quais os custos para a execução das tarefas?
DI-UFPE
@1997, Alexandre Vasconcelos
28
Ferramentas e Workbenches:
gerenciamento de projetos

Exemplos:


DI-UFPE
Project - Microsoft;
Time Line - Symantec.
@1997, Alexandre Vasconcelos
29
Ferramentas e Workbenches:
gerenciamento de configurações

As principais características encontradas nestes
sistemas são:




Exemplos:

DI-UFPE
Controle de acesso às bibliotecas de componentes (ex:
duas pessoas não podem fazer modificações de um mesmo
componente ao mesmo tempo);
Controle de versões;
Controle de dependências para a reconstrução do sistema.
SCCS (Source Code Control System) e make no sistema
Unix.
@1997, Alexandre Vasconcelos
30
Ferramentas e Workbenches:
teste de software


Tentam propiciar uma redução do tempo e do custo do esforço
de teste;
As principais características encontradas nestes sistemas são:





DI-UFPE
Documentação de testes:
Definição do teste, armazenamento e recuperação.
Suporte à geração de casos de teste;
Suporte à avaliação dinâmica da atividade de teste:
Métricas (ex: número de comandos executados pelo teste);
Percentagem de caminhos cobertos pelo teste, etc.;
Suporte à avaliação estática (ex: análise da complexidade do
software com respeito à facilidade de manutenção);
Análise de abrangência (os testes foram exaustivos?).
@1997, Alexandre Vasconcelos
31
Ferramentas e Workbenches:
teste de software

Exemplos:


+1Test - +1 Software Engineering;
Ferramentas da Eastern Systems Inc.:
TestPlan (gerenciamento de testes);
TestBed (ferramenta de análise estática/dinâmica de testes);
TestDesigner (ferramenta de testes).
DI-UFPE
@1997, Alexandre Vasconcelos
32
Ferramentas e Workbenches:
documentação

As principais características encontradas nestes
sistemas são:




Exemplos:


DI-UFPE
Extração automática de informações de outras ferramentas
usadas no desenvolvimento;
Extração automática de informações do código fonte;
Geração de documentos de acordo com determinados
padrões.
Interleaf;
PageMaker - Aldus.
@1997, Alexandre Vasconcelos
33
Ferramentas e Workbenches:
engenharia reversa

As principais características encontradas nestes
sistemas são:



Exemplos:

DI-UFPE
Extração de informações sobre a arquitetura do sistema,
estrutura de controle, fluxo lógico, estrutura de dados e fluxo
de dados, a partir da análise do código fonte;
Construção do modelo comportamental do sistema a partir
da análise dinâmica do sistema. Essa característica é
bastante rara.
PathMap - Cadre.
@1997, Alexandre Vasconcelos
34
Meta-CASE Workbenches


DI-UFPE
Alguns workbenches são conceitualmente similares.
Ex: em workbenches de projeto e análise, as
diferenças podem ser o tipo de diagrama suportado e
as regras utilizadas; em workbenches de
programação, as ferramentas compartilham uma
representação sintática dos programas, a qual pode
ser definida separadamente;
Meta-CASE Workbenches são sistemas que dão
apoio ao processo de criação de outros
workbenches.
@1997, Alexandre Vasconcelos
35
Meta-CASE Workbenches


DI-UFPE
Os primeiros sistemas deste tipo foram criados na
década de 1980 (Mentor, Synthesizer Generator,
Gandalf);
Nestes sistemas, a sintaxe e a semântica da
linguagem alvo são definidas e usadas para adaptar
ferramentas genéricas de processamento de
linguagens.
@1997, Alexandre Vasconcelos
36
Meta-CASE Workbenches
Language
syntax
definition
Semantic
information
DI-UFPE
Environment
generator
Languageoriented
environment
@1997, Alexandre Vasconcelos
Language
tables
Generic
environment
37
Vantagens dos Workbenches



DI-UFPE
Geralmente estão disponíveis para uso em
computadores pessoais de baixo custos;
Facilitam a padronização da documentação de
sistemas de software;
Estima-se ganhos de produtividade em torno de 40%
nos projetos, os quais são produzidos com menos
defeitos.
@1997, Alexandre Vasconcelos
38
Desvantagens dos Workbenches




DI-UFPE
São sistemas geralmente fechados. Dificilmente podem
ser integrados com outros sistemas;
Facilidades de importação e exportação de documentos
são limitadas (geralmente ASCII e diagramas Postscript);
É difícil e muitas vezes impossível adaptá-los às
necessidades específicas das organizações;
Deficiências no gerenciamento de configurações,
principalmente devido à impossibilidade de relacionar
documentos produzidos no workbench com documentos
produzidos externamente.
@1997, Alexandre Vasconcelos
39
Ambientes de Propósito Geral




DI-UFPE
São ambientes que já foram concebidos como
plataformas capazes de incorporar uma vasta gama
de ferramentas;
Destinam-se ao suporte de sistemas de software de
grande escala;
São denominados IPSE’s;
Existem poucos ambientes comerciais de propósito
geral e mesmo os que existem oferecem
funcionalidade limitada.
@1997, Alexandre Vasconcelos
40
Ambientes de Propósito Geral: requisitos






DI-UFPE
Suportar o desenvolvimento de software de grande porte;
Suportar todo o ciclo de vida de software;
Suportar e integrar os diversos métodos usados nas
diversas fases;
Estabelecer um guia automático para elaboração de um
projeto, passando por todas as fases do ciclo de vida de
software, integrando as ferramentas e dados;
Permitir acesso direto a qualquer ferramenta, obedecendo
a certos pre-requisitos;
Oferecer uma interface com o usuário consistente e
uniforme em todas as ferramentas;
@1997, Alexandre Vasconcelos
41
Ambientes de Propósito Geral: requisitos





DI-UFPE
Prover mecanismos para compartilhar informações
entre as ferramentas;
Permitir propagação de atualização por todas as
ferramentas, se houver alteração da base de dados
em uma delas;
Prover controle de versão e gerenciamento de
configuração sobre todas as informações;
Permitir trabalho cooperativo;
Ser configurável de acordo com as necessidades dos
projetos e usuários;
@1997, Alexandre Vasconcelos
42
Ambientes de Propósito Geral: requisitos




DI-UFPE
Permitir a reusabilidade de componentes de
software;
Ser extensível (aberto), isto é, permitir que novas
ferramentas sejam incorporadas;
Suportar a comunicação entre as equipes de
desenvolvimento;
Coletar dados para medição de produtividade do
processo de desenvolvimento de software.
@1997, Alexandre Vasconcelos
43
Ambientes de Propósito Geral: problemas


Pouca evidência prática das vantagens teóricas
destes ambientes em termos do custo-benefício;
Tamanho e complexidade dos ambientes, levando a:




DI-UFPE
Custos elevados para aquisição, treinamento, manutenção e
uso;
Muitos sistemas não têm uma boa performance;
Necessidade de pessoal de suporte para instalação,
monitoração e ajustes;
Decréscimo da produtividade no período de implantação,
devido à falta de familiaridade e à mudança da sistemática
de trabalho;
@1997, Alexandre Vasconcelos
44
Ambientes de Propósito Geral: problemas

Inflexibilidade:




DI-UFPE
Idealmente ambientes deveriam ser customizáveis para
cada usuário;
Na prática, a maioria dos ambientes disponibiliza um certo
número de ferramentas e o melhor que pode ser feito é a
incorporação de novas ferramentas;
Poucos são os sistemas que permitem a flexibilização do
processo de desenvolvimento.
A tecnologia ainda é instável (falta ou excesso de
padrões).
@1997, Alexandre Vasconcelos
45
O Ciclo de Vida um Sistema CASE


O ciclo de vida de um sistema CASE é comparável
ao ciclo de vida de um software desenvolvido usando
tal sistema;
Existem vários estágios que podem ser identificados
no uso de um sistema CASE:






DI-UFPE
Escolha;
Adaptação;
Introdução;
Uso;
Evolução;
Obsolescência.
@1997, Alexandre Vasconcelos
46
O Ciclo de Vida de um Sistema CASE
DI-UFPE
Escolha
Adaptação
Uso
Evolução
@1997, Alexandre Vasconcelos
Introdução
Obsolescência
47
O Estágio da Escolha:
definição

DI-UFPE
Envolve a escolha de um sistema CASE
apropriada(o) para o tipo de software a ser
desenvolvido na empresa.
@1997, Alexandre Vasconcelos
48
O Estágio da Escolha:
fatores

Os fatores a serem levados em conta na escolha de
um sistema CASE são:





DI-UFPE
Padrões e métodos adotados na empresa devem ser
suportados;
O hardware existente e os futuros desenvolvimentos do
hardware;
As classes de aplicações a serem desenvolvidas;
Segurança de acesso;
Preço (aquisição, manutenção e evolução).
@1997, Alexandre Vasconcelos
49
O Estágio da Adaptação:
definição

DI-UFPE
Envolve a adaptação do sistema para as
necessidades específicas da empresa.
@1997, Alexandre Vasconcelos
50
O Estágio da Adaptação:
principais atividades


DI-UFPE
Instalação e teste;
Definição do modelo de processo de software mesmo que não seja possível embutir este modelo
(ex: cascata, espiral, etc.) no sistema, esta atividade
é necessária para que o gerente visualize onde o
sistema CASE pode ser usado e que interfaces com
outras ferramentas precisam ser construídas;
@1997, Alexandre Vasconcelos
51
O Estágio da Adaptação:
principais atividades


DI-UFPE
Integração - envolve a integração do sistema CASE com
outros sistemas CASE.
 Se o novo sistema baseia-se num Sistema de
Gerenciamento de Objetos (OMS) compartilhado, o
esquema deve ser definido e validado. Isto envolve
identificar todas as entidades e relacionamentos que são
importantes para o processo de desenvolvimento de
software da organização;
 Se o novo sistema é baseado em arquivos, um formato
comum de arquivos deve ser adotado, ou quando não,
programas filtros devem ser construídos.
Documentação - todo o processo de instalação e adaptação
deve ser documentado.
@1997, Alexandre Vasconcelos
52
O Estágio da Introdução:
definição

DI-UFPE
Envolve a introdução do sistema CASE na empresa.
Para isto, é necessário que o engenheiro de software
seja adequadamente treinado para o seu uso.
@1997, Alexandre Vasconcelos
53
O Estágio da Introdução:
problemas

Resistência por parte dos usuários:


Deficiência de treinamento:



usuários são relutantes em aprender novas tecnologias;
dificuldades em entender características/facilidades dos
novos sistemas.
Resistência por parte da gerência:

DI-UFPE
crença de que os sistemas CASE são mais prescritivos e
limitam a criatividade individual de cada pessoa.
medo de que a introdução de tecnologia desconhecida
dificulte o processo de gerenciamento.
@1997, Alexandre Vasconcelos
54
O Estágio da Introdução:
respostas aos problemas

Resistência por parte dos usuários:



DI-UFPE
o sistema CASE dará assistência às tarefas maçantes do
desenvolvimento de software (ex: redesenhar diagramas de
projeto, encontrar o código associado à documentação e
vice-versa, etc.);
os engenheiros de software terão mais tempo para as
tarefas criativas e gratificantes do seu trabalho;
não é pretensão dos sistemas CASE desestimular a
habilidade de criar dos engenheiros de software.
@1997, Alexandre Vasconcelos
55
O Estágio da Introdução:
respostas aos problemas

Deficiência de treinamento:




Resistência por parte da gerência:


DI-UFPE
o treinamento deve ser de boa qualidade;
o orçamento dedicado ao treinamento deve ser adequado;
a migração para a nova tecnologia deve ser gradativa.
os custos de introdução da tecnologia em novos projetos
devem ser cuidadosamente medidos e comparados com os
custos anteriores;
estas medidas podem ser usadas para convencer os
gerentes das vantagens da introdução de novas
ferramentas/ambientes.
@1997, Alexandre Vasconcelos
56
O Estágio do Uso:
definição



DI-UFPE
Envolve o uso da ferramenta/ambiente no
desenvolvimento de software do dia-a-dia.
Após a introdução da ferramenta/ambiente em
projetos pilotos, tal tecnologia pode se tornar
disponível para todos os projetos;
Inicialmente o uso deve ser incentivado, mas com o
ganho de experiência este uso pode se tornar
obrigatório.
@1997, Alexandre Vasconcelos
57
O Estágio da Evolução:
definição


DI-UFPE
Na realidade não é um estágio isolado, pois é uma
atividade contínua durante todo o ciclo de vida da
ferramenta/ambiente;
Envolve a modificação da ferramenta/ambiente para
adaptá-la a novos requisitos ou a novas plataformas
de hardware ou software.
@1997, Alexandre Vasconcelos
58
O Estágio da Evolução:
problemas


DI-UFPE
As versões nova e velha da ferramenta/ambiente
podem não ser compatíveis devido a mudanças no
hardware/software;
Se esta incompatibilidade existir e forem necessárias
ambas as versões da ferramenta/ambiente na
empresa, então a infra-estrutura antiga de
hardware/software terá que ser mantida na empresa,
juntamente com a nova infra-estrutura.
@1997, Alexandre Vasconcelos
59
O Estágio da Obsolescência:
definição

Este é o estágio no qual a ferramenta/ambiente se
torna fora de uso:



DI-UFPE
devido a deficiência de suporte por parte do
fabricante/vendedor;
devido a mudanças na plataforma de hardware e/ou
software da empresa;
devido à substituição por outra ferramenta/ambiente mais
adequado para a empresa.
@1997, Alexandre Vasconcelos
60
O Estágio da Obsolescência:
problemas



DI-UFPE
Garantir que o software desenvolvido usando a
ferramenta/ambiente ainda pode ser suportado pela
empresa;
Um período de transição/migração para uma nova
tecnologia deve ser cuidadosamente planejado;
Este período é mais tranqüilo se o software
desenvolvido usando a ferramenta/ambiente já se
tornou obsoleto.
@1997, Alexandre Vasconcelos
61
Pontos-chave



DI-UFPE
CASE envolve o suporte automatizado ao processo
de desenvolvimento de software;
A tecnologia CASE pode ser classificada de acordo
com diversas características (ex: funcionalidade,
fases do desenvolvimento suportadas, etc.);
Ferramentas dão suporte a atividades individuais,
workbenches dão suporte a conjuntos de atividades
e ambientes dão suporte a todo o processo.
@1997, Alexandre Vasconcelos
62