A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Ferramentas CASE Sarajane Marques Peres. Motivação A complexidade dos requisitos dos softwares/sistemas exige um desenvolvimento sistemático apoiado por.

Apresentações semelhantes


Apresentação em tema: "Ferramentas CASE Sarajane Marques Peres. Motivação A complexidade dos requisitos dos softwares/sistemas exige um desenvolvimento sistemático apoiado por."— Transcrição da apresentação:

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 Dicionário de dados... Fontes Ferramentas Filtro Ferramentas com Dicionário de dados Ferramentas com Banco de dados Dados derivados Fontes Banco de dados 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 ferramenta que inteprete a base de dados 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) Dados Controle Operações comuns Guias de estilo de funcionalidade Sistema de arquivos Dicionário de dados Banco de dados Controle de processos Mensagens Chamada de procedimentos

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 Ferramenta A Ferramenta Z... Repositório de dados Ferramenta A Ferramenta B Exportação de 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 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 comerciaisBDs 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) Documento Id Documento Data Estado Pessoa Nome Departamento Versão Num. Versão Data Descrição Ferramenta Nome Fornecedor Data Responsável por Produz CriaPossui Modelo de objetos da Ferramenta de Gerenciamento de Versões

19 Exemplo de modelagem de objetos para integração de ferramentas (por dados) Projeto Nome Data Orçamento Gerente Nome Grau Produto Nome Estado Prazo Final Erros Pendentes Id Erro Estado Data Associado Possui Produz Modelo de objetos da Ferramenta de Gerenciamento de Projetos

20 Exemplo de modelagem de objetos para integração de ferramentas (por dados) Design Id Design Data Programa Id Programa Data Tamanho Construtor Nome Grau Módulo Nome Data Implementado_por Relatório Erros Data Estado Severidade Associado_aRelativo_a Composto_de Modelo de objetos do Avaliador de Erros de Programas

21 Exemplo de modelagem de objetos para integração de ferramentas (por dados) Ferramenta Nome Fornecedor Data Versão Num Versão Data Descrição Módulo Nome Data Produz Documento Id Documento Data Estado Pessoa Nome Departamento Grau Programa Id Programa Data Tamanho Design Id Design Data Projeto Nome Data Orçamento Erro Id Erro Estado Data Srveridade Produto Nome Estado Prazo Final Possui Responsável_por Composto_de Implementado_por Desenvolvido_por Produz Está_associado 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. Editor Configurador 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. UIC SC

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 Cliente Implementação do objeto IDL Stub IDL Skeleton Requisição Difusor da requisição

27 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

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 Eficiência Confiabilidade Manutenabilidade Portabilidade Geral Funcionalidade Ambiente de Operação Ambiente de Projetos Ambiente de HW/SW Ambiente Tecnológico Funções Verticais Modelagem Implementação Teste Funções Horizontais Documentação Gerenciamento de configuração Gerenciamento de projetos Usabilidade

36 Bibliografia GIMENES, I. M. S., Resenha: Ferramentas Case


Carregar ppt "Ferramentas CASE Sarajane Marques Peres. Motivação A complexidade dos requisitos dos softwares/sistemas exige um desenvolvimento sistemático apoiado por."

Apresentações semelhantes


Anúncios Google