Ferramentas CASE

1
Ferramentas CASE

• Sarajane Marques Peres

2
Motivação

• A complexidade dos requisitos dos
  softwares/sistemas exige um desenvolvimento
  sistemático apoiado por técnicas eficazes que
  possibilitem mensurar os riscos de uso e provar
  para a comunidade que o uso do software é seguro.
• Conseqüentemente exige-se a melhora da qualidade
  dos produtos e para alcançar isso
• Necessita-se de um processo de software bem
  definido, assistido e monitorado.
• Necessita-se de métodos estruturados e formais
  para apoio ao desenvolvimento de software.
• Necessita-se de apoio às atividades do processo
  de software.
• Para que se consiga monitorar/assistir um
  processo, é necessário que ele seja bem definido.
• Os métodos de estruturação (independente de
  paradigma) utilizados no desenvolvimento de
  software oferecem procedimentos e notações
  diagramáticas que especificam a função do
  software em diferentes níveis de abstração, e
  permitem a construção do mesmo.
• A sofisticação dos métodos leva a uma
  complexidade maior no gerenciamento do processo
  de desenvolvimento de software. As ferramentas
  entram neste processo como agentes que pretendem
  simplificar as ações envolvidas no processo.

3
Introdução

• Ferramenta CASE
• CASE Computer Aided Software Engeneering.
• Ferramenta que oferece um conjunto de serviços,
  fortemente relacionados, para apoiar uma ou mais
  atividades do processo de desenvolvimento de
  software.
• Serviços ação efetuada pelo computador que é de
  interesse do desenvolvedor
• Simples edições de texto
• Gerenciamento de configurações
• Teste de software
• Verificações formais
• Estudar ferramentas CASE é estudar
• Como construir definição de requisitos e
  arquitetura
• Como usar processo de adoção, avaliação e
  seleção.

4
Conceitos básicos

• As ferramentas CASE podem ser
• Horizontais oferecem serviços utilizados durante
  todo o processo de software
• Verticais utilizadas em fases específicas do
  processo de software
• Também podem ser classificadas de acordo com os
  serviços que oferecem, dentre as quais, cita-se.
• Documentação
• Planejamento e gerenciamento de projetos
• Especificações formais
• Comunicação
• Análise e projeto de software
• Projeto e desenvolvimento de interfaces
• Programação
• Gerenciamento de Configuração
• Controle de Qualidade

5
Como construir?

• Sua construção também demanda a utilização das
  técnicas de desenvolvimento de software afinal
  ela é um software.
• Cada ferramenta tem propósitos diferentes,
  fornece serviços diferentes, mas possuem algumas
  características em comum.
• Do processo de desenvolvimento de software comum,
  destacam-se duas atividades que apresentam
  peculiaridades quando envolvidas no processo de
  desenvolvimento de uma ferramenta CASE
• Levantamento de requisitos
• Projeto de arquitetura

6
Requisitos de Ferramentas CASE

• A captura dos requisitos do sistema junto ao
  usuário é um pouco diferenciada porque
• Os usuários de ferramentas CASE não são tão bem
  definidos quanto os usuários de um aplicação
  comum.
• São desenvolvedores
• Membros de equipes de marketing também auxiliam
  no processo
• Trata-se de um produto dirigido a mercado
• O processo desta fase se dá basicamente por meio
  de atividades macro
• Análise do mercado
• Análise de documentação de ferramentas similares
  existentes
• Testes sobre as ferramentas similares existentes
• Elaboração e aplicação de questionários (na forma
  de ciclo de questões) que deverão ser respondidos
  pelos desenvolvedores e pessoal de marketing

7
Arquitetura de Ferramentas CASE

• A definição da arquitetura está intimamente
  relacionada ao contexto no qual a ferramenta
  atuará. Os principais aspectos a serem analisados
  são
• As atividades do ciclo de vida que a ferramenta
  vai abranger
• O repositório de dados que será utilizado
• O estilo de interface que será adotado
• Os serviços disponíveis em outras ferramentas que
  serão reutilizados
• Quais as ferramentas existentes no mercado com as
  quais esta ferramenta deveria cooperar
• Quais mecanismos de comunicação com outras
  ferramentas, serão utilizados
• Quais filtros de dados serão utilizados
• Para quais plataformas a ferramenta será
  desenvolvida.

8
Arquitetura de Ferramentas CASE

• Uma ferramenta CASE deve ser flexível, com
  arquitetura modular para facilitar sua
  configuração para diferentes propósitos. A
  arquitetura deve ser baseada em
• Componentes que representam os subsistemas
  principais e objetos da ferramenta
• Mecanismos de interação (tecnologia de
  integração) que representam a forma como os
  componentes interagem, trocam informações e
  afetam uns aos outros

9
Exemplos de arquiteturas
Testes de codificação
Dicionário de dados
Engenharia reversa
Qualquer ferramenta que inteprete a base de dados
Principal diferença entre elas a abertura para
o compartilhamento de dados com outras
ferramentas. A melhor forma é a da terceira
arquitetura.
XML ?
10
O problema de integração das ferramentas

• Cada ferramenta pode ser vista como um módulo que
  provê um serviço específico.
• A combinação destes módulos pode oferecer novas
  funcionalidades.
• Exercício Liste os dados que ferramentas de
  propósito diferentes podem gerar e discuta o
  problema de integração/interpretação destes
  dados. Utilize o slide 4 para definição dos
  propósitos.
• Problemas
• Como cada ferramenta trata os dados
• Sobreposição de serviços
• Gerenciamento de versões
• Geração de códigos
• A resolução deste problema está baseada num
  modelo de integração que representa os aspectos
  básicos que devem ser tratados.

11
O modelo de integração de três dimensões
Apresentação (similaridades de estilo e
interface)
Operações comuns
Guias de estilo de funcionalidade
Dados
Chamada de procedimentos
Sistema de arquivos
Dicionário de dados
Banco de dados
Mensagens
Controle de processos
Controle
12
Integração por interface

• As ferramentas devem ser construídas de forma que
  a interface esteja independente da codificação de
  funções.
• O objetivo é deixar que a interface da ferramenta
  seja configurada/alterada facilmente, buscando
  padronização e concentração de investimentos de
  evolução.

13
Integração por Dados

• Promove formas de compartilhar os dados entre
  diferentes ferramentas.
• Utilizando um repositório de dados comum (um
  SGBD, por exemplo) é possível promover a
  integração usando dados persistentes.
• A importação e a exportação de dados também pode
  ser utilizada e, neste caso, as ferramentas
  possuem estruturas de armazenamento de dados
  internas e realizam traduções para o formato de
  outras ferramentas.
• A combinação destas duas formas de integração por
  dados pode ser combinada na prática.

14
Abordagens para compartilhamento de dados
Requer convenções de conversões. Dificulta o
gerencia- mento dos dados.
Requer convenções para armazenamento. Se
beneficia das vantagens de um SGBD.
Como convenções genéricas, aceita por todos os
fabricantes, é difícil de se conseguir, o que
acontece é o estabelecimento de convenções entre
ferramen- tas que são mais utilizadas, na forma
combinada, pelo mercado.
15
Integração por dados

• Encontrar um esquema comum de dados implica em
  estabelecer um conjunto de tipos de objetos e
  relacionamentos comuns, ou seja, um modelo comum.
• Uma vez conseguido isso, esquemas de
  gerenciamento devem ser empregados, gerenciando
  acessos e alterações, principalmente advindas da
  inserção de novas ferramentas ao conjunto.
• Tecnologias que provessem suporte a esse tipo de
  integração seriam úteis, uma vez que as
  ferramentas poderiam ser implementadas sem a
  preocupação do gerenciamento de repositórios.

16
Características dos BDs
BDs para aplicações comerciais BDs para suportar a integração de ferramentas CASE
Esquemas relativamente estáticos que podem ser determinados a priori. Esquemas dinâmicos e evolutivos, incluindo dados sobre o sistema de integração
Ítens de dados de tamanho fixo. Ítens de dados de tamanho variável.
Pequeno número de tipos de entidades com um grande número de instâncias de cada tipo. Grande número de tipos de entidades com poucas instâncias destes.
Itens de dados com valores únicos. Versões múltiplas dos itens de dados com controle de dependências e relacionamentos entre versões.
Muitas transações curtas que podem ser utilizadas como base para controle de acessos concorrentes. Transações longas que exigem mecanismos mais sofisticados de controle de concorrência.


17
Integração por dados

• Existem alguns padrões definidos para integração
  de ferramentas (os discutiremos mais tarde).
• Entretanto, apesar de relativamente maduros, não
  são totalmente aceitos no mercado relacionado.
• A integração por dados envolve uma especificação
  semântica dos dados. Esta parece ser uma das
  maiores dificuldades da área. Encontrar uma
  modelagem, em uma granulosidade ideal para o
  armazenamento dos dados e de seus significados.

18
Exemplo de modelagem de objetos para integração
de ferramentas (por dados)
Modelo de objetos da Ferramenta de
Gerenciamento de Versões
19
Exemplo de modelagem de objetos para integração
de ferramentas (por dados)
Modelo de objetos da Ferramenta de
Gerenciamento de Projetos
20
Exemplo de modelagem de objetos para integração
de ferramentas (por dados)
Modelo de objetos do Avaliador de Erros de
Programas
21
Exemplo de modelagem de objetos para integração
de ferramentas (por dados)
Ferramenta
Versão
Documento
Pessoa
Possui
Responsável_por
Nome Fornecedor Data
Produz
Num Versão Data Descrição
Id Documento Data Estado
Nome Departamento Grau
Módulo
Programa
Design
Projeto
Composto_de
Nome Data
Id Programa Data Tamanho
Id Design Data
Nome Data Orçamento
Está_associado
Produz
Implementado_por
Desenvolvido_por
Produto
Erro
Nome Estado Prazo Final
Id Erro Estado Data Srveridade
Associado_a
22
Integração por Dados

• De acordo com o modelo apresentado, qualquer
  operação realizada em qualquer uma das três
  ferramentas, individualmente, pode ser realizada
  por meio dos objetos apresentados no modelo
  final.
• Observe que o modelo integrado sintetiza o que é
  um documento e o que é uma pessoa.
• Um relacionamento de especialização foi inserido.
• Alguns caminhos (envolvendo relacionamentos) se
  tornam mais curtos enquanto outros se tornam mais
  longos.

23
Integração por Controle

• Provê mecanismos de comunicação entre ferramentas
  independentemente do compartilhamento de dados.
• As ações executadas pelas ferramentas são
  comunicadas às outras por meio de sinais de
  controle.
• A integração se dá sem sacrificar a independência
  das ferramentas. Cada uma trata os dados como
  melhor lhe convém.

Configurador
Editor
Compilador
Código Fonte
Comunicação ponto a ponto
24
Integração por Controle

• Chamada remota de procedimentos, é uma forma de
  integração por controle. Mais adequada a produtos
  de um mesmo fabricante.
• Software bus e Broadcast Message Server são
  mecanismos que permitem a comunicação entre
  produtos construídos por fabricantes diferentes,
  requerendo o mínimo de alteração possível na
  estrutura interna dos produtos.
• Exemplos HP Softbench, Tooltalk, CORBA, COSE,
  OLE, OpenDoc e, atualmente, WebServices tem
  atuado na integração por controle.

25
Software Bus

• As interfaces procedimentais estão localizadas em
  módulos chamados Software Components. Estes não
  interagem em nenhum momento com os usuários
  (outras ferramentas).
• Todas as ações de interface com os usuários (as
  ferramentas) devem ser implementadas nos User
  Interface Component, responsáveis por chamar os
  Software Components para executar as ações.
• São processos distintos.

26
Broadcast Message Server

• Responsável pela distribuição de mensagens dos
  tipos requisição, respostas ou notificação.
• As mensagens contém indicações sobre as
  ferramentas destino e especificações sobre o
  escopo para o qual a mensagem se aplica.
• A sintaxe e semântica das mensagens são definidas
  por protocolos.

IDL Interface Definition Language
27
Composição básica de uma ferramenta CASE
28
Adoção de Ferramentas CASE

• O processo de adoção de ferramentas CASE é um
  processo crítico dentro de uma empresa. Existe um
  contraste neste processo um aumento da oferta de
  ferramentas CASE no mercado contra a dificuldade
  das empresas em obter aumentos significativos de
  produtividade.
• O IEEE P1348 Recommended Pratice for the
  Adoption of CASE Tools tenta fornecer um conjunto
  de questões que devem ser analisadas quando da
  adoção de uma ferramenta CASE, para aumentar as
  chances de sucesso em seu uso.

29
O processo de adoção

• O que se espera da adoção
• Prover um nível apropriado de suporte tecnológico
  para os processos de desenvolvimento e manutenção
  de software
• Impactar positivamente sobre produtividade,
  qualidade, padronização, documentação
• Induzir o uso geral e contínuo de ferramentas na
  organização e seus grupos.
• Passos
• Definição da necessidade
• Avaliação e seleção de ferramentas
• Condução de um esforço piloto
• Tornar rotineiro o uso das ferramentas

30
O processo de adoção

• Não se deve esperar que a adoção de uma
  ferramenta CASE solucione problemas no processo
  de desenvolvimento de software.
• O processo deve estar maduro para que a adoção da
  ferramenta tenha sucesso. O modelo CMM
  (Capability Maturity Model) e os padrões
  relacionados a ISO 9000, oferecem meios de
  avaliar o nível em que se encontra o processo de
  desenvolvimento de software em uma empresa.
• Dependendo do nível em que uma empresa se
  encontra, determinadas ferramentas já poderiam
  ser adotadas, enquanto outras ainda demandariam
  uma melhora na maturidade do processo dentro da
  empresa.
• O processo de adoção de uma ferramenta deve ser
  avaliado a partir de critérios mensuráveis para
  se saber se o sucesso foi alcançado ou não.
• Medidas de produtividade do processo de software
• Percentual de projetos que utilizam a ferramenta
• Tempo de treinamento necessário
• Precisão das estimativas de custo do processo de
  software
• Aderência a padrões.

31
O processo de adoção

• O projeto piloto
• Deve ser conhecido, permitir comparações e
  passível de ser desenvolvido no tempo previsto
  para o projeto piloto
• Plano de migração (para uso geral e contínuo)
• Informações sobre os objetivos, critérios de
  avaliação, cronogramas e riscos da migração
• Informações sobre aquisição, instalação e
  adequação da ferramenta ao ambiente
• Necessidades e recursos requeridos para
  treinamento durante e após a migração
• Definição de procedimentos padrões para o uso de
  ferramentas.

32
O processo de adoção

• O passo de aquisição de ferramentas deve se
  preocupar com o tratamento de algumas
  informações
• Os pacotes de componentes de software,
  documentação e treinamento a serem adquiridos
  para cada plataforma
• Os mecanismos para aquisição de upgrades
• As 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 de conversão de dados provenientes de
  ferramentas antigas.

33
Avaliação de Ferramentas CASE

• Processo no qual vários aspectos de uma
  ferramenta CASE são medidos, considerando-se
  critérios definidos. Os resultados são
  armazenados para uso posterior.
• Passos
• Definir a tarefa de avaliação
• Identificar e selecionar critérios de avaliação
• Identificar CASE candidatas
• Avaliar CASE candidatas
• Emitir relatório contendo resultados

34
Seleção de Ferramentas CASE

• 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.
• Passos
• Definir o propósito da seleção
• Definir o escopo da seleção
• Identificar suposições e restrições
• Definir as atividades de seleção
• Identificar e ponderar os critérios de seleção
• Identificar as ferramentas candidatas (quando não
  identificadas em um processo de avaliação
  prévio)
• Acessar os resultados da avaliação (quando
  realizada)
• Aplicar os critérios considerados aos resultados
  da avaliação.

35
Critérios
Critérios
Eficiência
Confiabilidade
Manutenabilidade
Portabilidade
Geral
Usabilidade
Funcionalidade
Ambiente de Operação
Funções Verticais
Funções Horizontais
Ambiente de Projetos
Modelagem
Documentação
Ambiente de HW/SW
Implementação
Gerenciamento de configuração
Ambiente Tecnológico
Teste
Gerenciamento de projetos
36
Bibliografia

• GIMENES, I. M. S., Resenha Ferramentas Case
  -1995.