Sistemas CASE Introdução DI-UFPE @1997, Alexandre Vasconcelos.

Sistemas CASE Introdução DI-UFPE @1997, Alexandre Vasconcelos

Conteúdo 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 DI-UFPE @1997, Alexandre Vasconcelos

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): editores de texto, compiladores, gerenciadores de versões, etc. DI-UFPE @1997, Alexandre Vasconcelos

O que é CASE? É o uso de suporte computacional no processo de desenvolvimento de software; DI-UFPE @1997, Alexandre Vasconcelos

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: grau de formalidade imposta; tipo de interface oferecida ao usuário; fase(s) do ciclo de vida coberta(s); profundidade do suporte oferecido, etc. DI-UFPE @1997, Alexandre Vasconcelos

Uma Classificação para Sistemas CASE - fases x profundidade
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. DI-UFPE @1997, Alexandre Vasconcelos

Uma Classificação para Sistemas CASE - fases x profundidade
DI-UFPE @1997, Alexandre Vasconcelos

Exemplos de Ferramentas CASE

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

Qualidade do Suporte CASE

Histórico 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; DI-UFPE @1997, Alexandre Vasconcelos

Histórico 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; DI-UFPE @1997, Alexandre Vasconcelos

Histórico 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. DI-UFPE @1997, Alexandre Vasconcelos

Vantagens dos Sistemas CASE
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; DI-UFPE @1997, Alexandre Vasconcelos

Vantagens dos Sistemas CASE
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. DI-UFPE @1997, Alexandre Vasconcelos

Problemas com os Sistemas CASE
O grau de melhoria da produtividade é menor do que o esperado, devido a: 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. DI-UFPE @1997, Alexandre Vasconcelos

CASE Workbenches 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; DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: especificação de requisitos
As principais características encontradas nestes sistemas são: 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.). DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: especificação de requisitos
Exemplos: DOORS (Dynamic OO Requirements System) - Quality Systems & Software (QSS); RTM (Requirements and Traceability Management); ProductTrack (Ferramenta para Captura, rastreamento e avaliação de requisitos). DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: especificação formal
As principais características encontradas nestes sistemas são: 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. Exemplos: CADiZ (Computer AIded Design in Z) - York Software Engineering; Z-eves - ORA Canada. DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: análise e projeto de sistemas
As principais características encontradas nestes sistemas são: 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. DI-UFPE @1997, Alexandre Vasconcelos

Exemplos: ObjectMaker - Catalyst Software Ltd. Teamwork - Cadre Technologies, Inc. Paradigm - Platinum Technology. DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: projeto e desenvolvimento de interfaces
As principais características encontradas nestes sistemas são: 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. Exemplos: Interviews; X-Designer - Imperial Software Technology, UK. DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: apoio à programação
As principais características encontradas nestes sistemas são: Edição, compilação, ligação e depuração de programas. Exemplos: Turbo C; Turbo Pascal; VisualC++; Delphi. DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: Dirigidos à Linguagem
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. DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: Dirigidos à Linguagem

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

Ferramentas e Workbenches: gerenciamento de projetos
Exemplos: Project - Microsoft; Time Line - Symantec. DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: gerenciamento de configurações
As principais características encontradas nestes sistemas são: 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. Exemplos: SCCS (Source Code Control System) e make no sistema Unix. DI-UFPE @1997, Alexandre Vasconcelos

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: 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?). DI-UFPE @1997, Alexandre Vasconcelos

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

Ferramentas e Workbenches: documentação
As principais características encontradas nestes sistemas são: 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. Exemplos: Interleaf; PageMaker - Aldus. DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: engenharia reversa
As principais características encontradas nestes sistemas são: 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. Exemplos: PathMap - Cadre. DI-UFPE @1997, Alexandre Vasconcelos

Meta-CASE Workbenches
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. DI-UFPE @1997, Alexandre Vasconcelos

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. DI-UFPE @1997, Alexandre Vasconcelos

Vantagens dos Workbenches
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. DI-UFPE @1997, Alexandre Vasconcelos

Desvantagens dos Workbenches
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. DI-UFPE @1997, Alexandre Vasconcelos

Ambientes de Propósito Geral
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. DI-UFPE @1997, Alexandre Vasconcelos

Ambientes de Propósito Geral: requisitos
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; DI-UFPE @1997, Alexandre Vasconcelos

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; DI-UFPE @1997, Alexandre Vasconcelos

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. DI-UFPE @1997, Alexandre Vasconcelos

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: 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; DI-UFPE @1997, Alexandre Vasconcelos

Ambientes de Propósito Geral: problemas
Inflexibilidade: 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). DI-UFPE @1997, Alexandre Vasconcelos

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: Escolha; Adaptação; Introdução; Uso; Evolução; Obsolescência. DI-UFPE @1997, Alexandre Vasconcelos

O Ciclo de Vida de um Sistema CASE
Escolha Adaptação Introdução Uso Evolução Obsolescência DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Escolha: definição
Envolve a escolha de um sistema CASE apropriada(o) para o tipo de software a ser desenvolvido na empresa. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Escolha: fatores
Os fatores a serem levados em conta na escolha de um sistema CASE são: 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). DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Adaptação: definição
Envolve a adaptação do sistema para as necessidades específicas da empresa. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Adaptação: principais atividades
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; DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Adaptação: principais atividades
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. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Introdução: definição
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. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Introdução: problemas
Resistência por parte dos usuários: crença de que os sistemas CASE são mais prescritivos e limitam a criatividade individual de cada pessoa. 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: medo de que a introdução de tecnologia desconhecida dificulte o processo de gerenciamento. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Introdução: respostas aos problemas
Resistência por parte dos usuários: 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. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Introdução: respostas aos problemas
Deficiência de treinamento: 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. Resistência por parte da gerência: 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. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio do Uso: definição
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. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Evolução: definição
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. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Evolução: problemas
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. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Obsolescência: definição
Este é o estágio no qual a ferramenta/ambiente se torna fora de uso: 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. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Obsolescência: problemas
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. DI-UFPE @1997, Alexandre Vasconcelos

Pontos-chave 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. DI-UFPE @1997, Alexandre Vasconcelos

Sistemas CASE Introdução DI-UFPE @1997, Alexandre Vasconcelos.

Apresentações semelhantes

Apresentação em tema: "Sistemas CASE Introdução DI-UFPE @1997, Alexandre Vasconcelos."— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Sistemas CASE Introdução DI-UFPE @1997, Alexandre Vasconcelos.

Apresentações semelhantes

Apresentação em tema: "Sistemas CASE Introdução DI-UFPE @1997, Alexandre Vasconcelos."— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback