Ferramentas CASE
Sarajane Marques Peres
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.
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.
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
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
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
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.
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;
Exemplos de arquiteturas
Dicionário de dados
...
Fontes
FerramentasFiltro
Ferramentas comDicionário de dados
Ferramentas comBanco de dados
Dados derivados
Fontes
Banco de dados
Arquivos Arquivos
Principal diferença entre elas: a abertura para o compartilhamento de dados com outras ferramentas. A melhor forma é a da terceira arquitetura.
Testes de codificação
Engenharia reversa
Qualquer ferramentaque inteprete a basede dados
XML
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.
O modelo de integração de três dimensões
Apresentação (similaridades de estilo e interface)
Dados
Controle
Operações comuns
Guias de estilo de funcionalidade
Sistema dearquivos
Dicionário dedados
Banco dedados
Controle deprocessos
Mensagens
Chamada deprocedimentos
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.
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.
Abordagens para compartilhamento de dados
FerramentaA
FerramentaZ
...
Repositóriode dados
FerramentaA
FerramentaB
Exportaçãode dados
Requer convenções para armazenamento. Se beneficia das vantagens de um SGBD.
Requer convenções de conversões. Dificulta o gerencia-mento dos dados.
Como convenções genéricas, aceita por todos os fabricantes, é difícil de seconseguir, o que acontece é o estabelecimento de convenções entre ferramen-tas que são mais utilizadas, na forma combinada, pelo mercado.
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.
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.
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.
Exemplo de modelagem de objetos para integração de ferramentas (por dados)
Documento
Id DocumentoDataEstado
Pessoa
NomeDepartamento
Versão
Num. VersãoDataDescrição
Ferramenta
NomeFornecedorData
Responsável por
Produz
CriaPossui
Modelo de objetos da Ferramenta de Gerenciamentode Versões
Exemplo de modelagem de objetos para integração de ferramentas (por dados)
Projeto
NomeDataOrçamento
Gerente
NomeGrau
Produto
NomeEstadoPrazo Final
Erros Pendentes
Id ErroEstadoData
Associado
Possui
Produz
Modelo de objetos da Ferramenta de Gerenciamentode Projetos
Exemplo de modelagem de objetos para integração de ferramentas (por dados)
Design
Id DesignData
Programa
Id ProgramaDataTamanho
Construtor
NomeGrau
Módulo
NomeData
Implementado_por
Relatório Erros
DataEstadoSeveridade
Associado_a Relativo_a
Composto_de
Modelo de objetos do Avaliador de Errosde Programas
Exemplo de modelagem de objetos para integração de ferramentas (por dados)
FerramentaNomeFornecedorData
Versão
Num VersãoDataDescrição
Módulo
NomeData
Produz
Documento
Id DocumentoDataEstado
Pessoa
NomeDepartamentoGrau
Programa
Id ProgramaDataTamanho
Design
Id DesignData
Projeto
NomeDataOrçamento
ErroId ErroEstadoDataSrveridade
Produto
NomeEstadoPrazo Final
Possui Responsável_por
Composto_de
Implementado_porDesenvolvido_porProduz Está_associado
Associado_a
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.
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.
Editor
Configurador
Compilador
CódigoFonte
Comunicação ponto a ponto
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.
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.
UIC UIC UIC
SC SC
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= InterfaceDefinition Language
Cliente Implementação
do objeto
IDLStub
IDLSkeleton
RequisiçãoDifusor da requisição
Composição básica de uma ferramenta CASE
Interface com o usuário.
Interface de comunicação.
Interface com o SGBD.
Usuário
Outras ferramentas
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.
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
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.
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.
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.
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;
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.
CritériosCritérios
EficiênciaConfiabilidade Manutenabilidade Portabilidade Geral
Funcionalidade
Ambiente deOperação
Ambiente deProjetos
Ambiente deHW/SW
AmbienteTecnológico
FunçõesVerticais
Modelagem
Implementação
Teste
Funções Horizontais
Documentação
Gerenciamentode configuração
Gerenciamentode projetos
Usabilidade
Bibliografia
• GIMENES, I. M. S., Resenha: Ferramentas Case -1995.