ESCOLA DE ENGENHARIA DE SÃO CARLOS

Metodologia de Desenvolvimento de Sistemas Informatizados

Prof: Edson Walmir Cazarini

 

Ferramentas

CASE

 

 

 

Grupo 05:

Vivaldo Mason Filho

Wanderley Gazeta

Marcos Ant. Buda

 

INDICE

Capítulo 01 – Conceitos Teóricos *

1.1 O que é o CASE ? *

1.2 Blocos de Construção para o Case *

1.3 Ferramentas Case *

1.3.1 Ferramentas de Planejamento de Sistemas Comerciais *

1.3.2 Ferramentas de Gerenciamento de Projetos *

1.3.2.1 Ferramentas de Planejamento de Projetos *

1.3.2.3 Ferramentas de Métricas e Gerenciamento *

1.3.3 Ferramentas de Apoio *

1.3.3.1 Ferramentas de Documentação *

1.3.3.2 Ferramentas de Software Básico *

1.3.3.3 Ferramentas de Garantia de Qualidade *

1.3.3.4 Ferramentas de Banco de Dados e SCM *

1.3.4 Ferramentas de Análise e Projeto *

1.3.5 Ferramentas de Programação *

1.3.6 Ferramentas de Integração e Testes *

1.3.7 Ferramentas de Prototipação *

1.3.8 Ferramentas de Manutenção *

1.3.9 Ferramentas de Estrutura *

1.4 CASE e AI *

1.5.1 Definição de Requisitos de Integração *

1.5.2 Opções de Integração *

1.5.3 A Arquitetura de Integração *

1.5.4 O Repositório Case *

1.6 Conclusão *

Capítulo 02 - Por quE as Ferramentas CASE não são usadas ? *

Capítulo 03 - Ferramentas CASE: Por que Utilizar, Como Escolher? *

Capítulo 04 - Modelagem/Geração Automática de Sistemas Integrados *

Capítulo 05 - Ferramentas CASE: Solução ou Apoio aos Processos? *

Capítulo 06 - Ferramentas CASE (Exemplos) *

6.1 Dr. CASE 2.0 *

6.1.1 O Ambiente de Desenvolvimento *

6.1.2 Projeto Conceitual *

6.1.3 Projeto Lógico *

6.1.4 Implementação do Banco de Dados *

6.1.5 Integração com Sculptor *

6.1.6 Consistência dos Modelos *

6.1.7 Documentação e Help On-Line *

6.1.8 Conclusão *

6.1.9 Requisitos Mínimos do Sistema *

6.2 System Artchitect *

6.2.1 Aplicação dos produtos System Architect nas Fases de Desenvolvimetno de Sistemas *

6.3 ERWin / BPWin / Paradigm Plus / ModelMart *

6.3.1 Paradigm Plus *

6.3.2 ERwin/ERX *

6.3.3 ModelMart *

6.3.4 BPwin *

6.3.5 Cenário Análise Orientada a Objetos *

6.3.6 Cenário Análise Estruturada *

Bibliografia *

 

 

 

 

 

 

Capítulo 01 – Conceitos Teóricos

1.1 O que é o CASE ?

CASE (Computer Aided Software Engeneering ou Engenharia de Software Auxiliada por Computador), é uma das ferramentas do ambiente de suporte do engenheiro de software, permitindo-se automatizar atividades manuais e melhorando a qualidade antes mesmo do produto ser construído.

1.2 Blocos de Construção para o Case

Os blocos de construção criam o ambiente Case e podem ser ordenados da seguinte maneira:

Os três últimos níveis lançam as bases para o Case.

Na maioria dos casos, as ferramentas Case não possuem a construção de todos esses blocos e por isso não fazem parte de um ambiente Case integrado. O que acontece na maioria das vezes, é que um vendedor integra uma série de ferramentas e as vende como um pacote.

1.3 Ferramentas Case

A categorização das ferramentas Case pode gerar confusão entre as pessoas, pois elas tendem a ter visões diferentes e poderiam achar que uma ferramenta não pertence a uma certa categoria, e sim à outra.

Essas categorias podem ser classificadas por função, pelo uso, pela arquitetura do ambiente, etc.

A seguir, serão apresentadas algumas categorias de ferramentas Case com uma rápida explicação de cada uma delas. Para essa categorização será usada a função como critério primordial.

1.3.1 Ferramentas de Planejamento de Sistemas Comerciais

O objetivo primordial para as ferramentas dessa categoria é ajudar a melhorar a compreensão de como a informação flui entre as várias unidades organizacionais.

1.3.2 Ferramentas de Gerenciamento de Projetos

Essas ferramentas exercem um profundo impacto sobre a qualidade do gerenciamento de projetos para esforços de desenvolvimento de software, permitindo ao gerente gerar úteis estimativas de esforços, custo e duração de um projeto, definir a estrutura de divisão de trabalho, etc.

1.3.2.1 Ferramentas de Planejamento de Projetos

Concentram-se em duas áreas fundamentais: esforço e estimativa de custos (estima o tamanho e as características globais do projeto) e programação de projetos (define todas as tarefas do projeto).

1.3.2.2 Ferramentas de Rastreamento de Requisitos

O objetivos dessas ferramentas é oferecer uma abordagem sistemática ao isolamento dos requisitos, que se inicia com a especificação do cliente. Essas ferramentas tentam impedir que o sistema entregue não atenda plenamente aos requisitos especificados.

1.3.2.3 Ferramentas de Métricas e Gerenciamento

Ou ferramentas de medição, concentram-se nas características de processo e de produto. As ferramentas administrativas usam os requisitos e as prioridades dos clientes, as imposições sobre a organização de desenvolvimento e os riscos comerciais e técnicos para sugerirem uma ordem em que um projeto deva ser executado.

1.3.3 Ferramentas de Apoio

Essa categoria abrange ferramentas de aplicação e de sistemas que complementam o processo de engenharia de software, abrangendo também as atividades que são aplicáveis a esse processo, como será explicado a seguir.

1.3.3.1 Ferramentas de Documentação

Essas ferramentas dão apoio aos desenvolvedores no processo de documentação do sistema, que tende a ser bastante ineficiente.

1.3.3.2 Ferramentas de Software Básico

Elas proporcionam alta qualidade de rede, correio eletrônico, e outras capacidades de comunicação permitindo a migração para outros sistemas operacionais.

1.3.3.3 Ferramentas de Garantia de Qualidade

Essas ferramentas, na verdade, se baseiam em métricas para fazerem a auditoria do código-fonte, para determinar o cumprimento de padrões de linguagem.

1.3.3.4 Ferramentas de Banco de Dados e SCM

O gerenciamento de banco de dados serve de base para o estabelecimento de um repositório Case. As ferramentas Case também podem auxiliar cinco grandes tarefas de SCM: identificação, controle de versão, controle de mudanças, auditoria e relato de status.

1.3.4 Ferramentas de Análise e Projeto

Possibilitam que o engenheiro de software crie um modelo do sistema que será construído, contendo uma representação do fluxo de controle de dados, conteúdo de dados, representação de processo, especificação de controles e uma variedade de outras representações de modelagem, tentando eliminar os erros antes que eles se propaguem pelo projeto.

1.3.5 Ferramentas de Programação

Abrange compiladores, editores e depuradores para apoio às linguagens de programação, além dos ambientes de programação orientados a objetos, linguagens de quarta geração, os geradores de aplicações e as linguagens de consultas a banco de dados.

1.3.6 Ferramentas de Integração e Testes

As ferramentas de testes se dividem nas seguintes categorias:

1.3.7 Ferramentas de Prototipação

São ferramentas que auxiliam a criação de um protótipo durante qualquer ponto do espectro de implementação, utilizando uma base de conhecimentos que "entende" o domínio da aplicação.

 

1.3.8 Ferramentas de Manutenção

Podem ser subdivididas nas seguintes categorias:

Essas ferramentas, no futuro, farão um uso maior de técnicas de inteligência artificial, auxiliando na decomposição e reconstrução do sistema, mas ainda assim irão exigir a interação com um engenheiro de software.

1.3.9 Ferramentas de Estrutura

Oferecem gerenciamento do banco de dados, gerenciamento de configuração e capacidades de integração de ferramentas Case, exibindo componentes funcionais que suportam dados, interface e integração.

1.4 CASE e AI

Hoje as ferramentas Case fazem pouco uso das tecnologias de Inteligência Artificial, porém já estão sendo pesquisadas a criação de "agentes" de análise e projeto, que seriam ferramentas inteligentes que auxiliariam na análise, no projeto e na atividade de testes de sistemas computadorizados, ajudando na solução de problemas acessando uma base de conhecimentos sobre as características de uma classe limitada de aplicações.

1.5 Ambientes CASE Integrados

O verdadeiro poder do Case só pode ser obtido mediante integração que, entre seus benefícios, incluem-se:

Nos próximos itens, a questão da integração será descrita com mais detalhes.

 

1.5.1 Definição de Requisitos de Integração

O I-Case combina uma variedade de diferentes ferramentas de diferentes itens de informação, possibilitando a comunicação entre elas e com as pessoas durante o processo de engenharia de software. Um ambiente Case integrado deve:

1.5.2 Opções de Integração

Poucas ferramentas Case são usadas em total isolamento, podendo ser integradas de muitas maneiras diferentes. As seguintes opções de integração estão à disposição:

1.5.3 A Arquitetura de Integração

O modelo de arquitetura do framework de integração facilita a transferência de informações para dentro e para fora do "pool" de informações de engenharia de software que é criado. Para que isto seja possível, os seguinte componentes de arquitetura devem existir:

1.5.4 O Repositório Case

Repositório é um banco de dados que atua como o centro, tanto de acúmulo como de armazenagem das informações de engenharia de software, tendo o engenheiro o papel de interagir com o repositório através das ferramentas Case.

O repositório no ambiente I-Case é o conjunto de mecanismos e estruturas de dados que realizam a integração dados-ferramentas e dados-dados, realizando as seguintes funções: integridade de dados, compartilhamento de informações, integração dados-ferramentas, integração dados-dados, imposição metodológica e padronização de documentos.

Um repositório Case oferece dois tipos de serviços que se dividem entre aqueles esperados de qualquer sistema de gerenciamento de banco de dados sofisticado e aqueles específicos ao ambiente Case.

Entre as características padrões do repositório Case incluem-se:

Entre as características especiais do repositório Case incluem-se:

1.6 Conclusão

As ferramentas de engenharia de software auxiliadas por computador envolvem cada etapa do processo de engenharia e aquelas atividades de "guarda-chuva" que são aplicadas no decorrer de todo o processo. O Case compreende um conjunto de blocos de construção que só inicia em nível de hardware e de software de sistema operacional, e termina em ferramentas individuais.

Mas o real benefício das ferramentas não pode ser percebido até que elas sejam integradas - até que as informações produzidas com uma ferramenta possam ser facilmente usadas por outras ferramentas. O ambiente I-Case combina mecanismos de integração para dados, ferramentas e interação homem/máquina. Esta integração de ferramentas podem ser customizadas por vendedores que trabalhem juntos ou mediante software de gerenciamento oferecido como parte do repositório.

À medida que os anos passarem, o Case se tornará parte do tecido da engenharia de software. Exatamente como os engenheiros mecânicos e elétricos contam com o CAD/CAE/CIM para análise e projeto de produtos de alta tecnologia, os engenheiros de software confiarão no Case para a análise, projeto e testes de sistemas baseados em computador para o século XXI.

 

Capítulo 02 - Por que as Ferramentas CASE não são usadas ?

Em uma ampla pesquisa realizada em países europeus, descobriu-se que uma maioria esmagadora das organizações pesquisadas não utiliza nenhuma ferramenta Case, e algumas poucas utilizaram em apenas um ou dois projetos. Em muitos casos, os analistas dessas organizações desconheciam as ferramentas Case.

Alguns exemplos de projetos e projeções sobre os projetos existentes com o uso de Case, revelou um significativo aumento de produtividade da qualidade dos sistemas, da qualidade da documentação, além de uma padronização e redução da entrega do produto.

Mesmo com todos esses fatores positivos, a adoção do Case ainda é baixa. Algumas explicações para isto poderiam ser devido ao alto custo da ferramenta e do treinamento associado ao Case, ou por os benefícios não serem uniformes para todos os grupos afetados, gerando resistência por parte de alguns grupos.

Pesquisas anteriores sobre a adoção do Case eram falhas, pois não traziam nenhuma orientação teórica ou explicação dos fatores afetados pela adição. Novas pesquisas vêm colocando as ferramentas Case como sendo sistemas que suportam sistemas de informação e trabalhando junto com profissionais de software.

Quatro tendências foram levantadas como sendo o motivo para a adoção do Case:

São identificados três grupos de fatores que potencialmente afetam o uso do Case, sendo eles:

O resultado de uma análise de regressão realizada entre profissionais autônomos e companhias tendo como base para pesquisa os itens de participação, suporte ao gerenciamento, treinamento, complexidade, compatibilidade, vantagem relativa, voluntariedade e uso da ferramenta Case demonstrou que entre os diversos controles notou-se uma vantagem significativa dos efeitos da produtividade e qualidade, aumentando a velocidade, qualidade, facilidade e eficiência de tarefas respondidas no desenvolvimento de software.

Embora estes estudos não permitam definir conclusões de causalidade, uma notável interpretação das descobertas da presente pesquisa revelam que o alto uso do Case tende a aumentar a produtividade e qualidade dos sistemas de informação e desenvolvimento de software, e que a falta de voluntariedade tende a diminuir seu uso.

A interpretação desta pesquisa pode ser questionada, pois os dados foram coletados anonimamente em uma quantidade pequena de pessoas e companhias colaboradoras, podendo haver manipulação e exageros nesses dados, ou muita influência/pressão gerencial. Outro ponto que pode ser questionado é que a pesquisa foi realizada em um único país, a Finlândia, e diferentes culturas e países poderiam alterar os resultados obtidos.

 

Capítulo 03 - Ferramentas CASE: Por que Utilizar, Como Escolher?

Dentre as categorias de ferramentas de apoio ao desenvolvimento, destacam-se as ferramentas CASE. Após os compiladores e IDE’s, são provavelmente as ferramentas mais conhecidas(embora não mais utilizadas).

Historicamente, as primeiras ferramentas CASE voltavam-se principalmente para a geração de código CICS Command Level a partir de protótipos de telas liberando o programador da enfadonha tarefa de programar o mapsets (telas) do CICS na mão. No entanto, sua classificação como CASE é de certa forma pretensiosa, uma vez que CASE significa Computer Aided Software (ou systems auctores disputant) Engeneering, e as ferramentas citadas ajudavam apenas codificar. Foi a popularização do microcomputador que fez com que surgissem os CASE's tais como os conhecemos hoje, especialmente os Upper CASE, isto é aqueles destinados a ajudar na modelagem e documentação de sistemas.

É certo que o CASE ajuda o processo de modelagem, constituindo-se na principal ferramenta da "office automation" da área de sistemas. Mas , justificar a adoção de CASE por causa do aumento da produtividade de desenvolvimento é perder o ponto.

O fato é que o problema principal das empresas, ao menos em termos de esforço e alocação de recurso, não é desenvolvimento de novos sistemas. O grande "galho, todos sabem, é a Manutenção, que consome de 80 a 90% do esforço de "desenvolvimento". O pior é que se estima-se que 50% deste esforço (de manutenção) esteja alocado ao que se tem chamado information recovery", atividade vulgarmente conhecida como "leitura de programas" . Assim qualquer esforço de aumento de produtividade na manutenção tem impacto global muito maior do que os esforços destinados apenas para aumentar a produtividade de desenvolvimento. Esta é a razão pela qual, se defende que a principal vantagem da Orientação em Objeto, em ambiente Administrativo - comercial é o grau em que essa tecnologia facilita a manutenção, muito mais do que o aumento de produtividade em desenvolvimento via reutilização. De forma geral, o CASE, juntamente com as Metodologias de Desenvolvimento, causam aumento de produtividade facilitando a manutenção, na medida em que sistemas bem documentados dispensam boa parte da citada atividade de "recuperação de informação".

Modelar o sistema na mão ou usando Flow-Chart ou outras "criativas soluções" é um barato que sai caro. O resultado invariável é que na primeira manutenção a documentação fica desatualizada, e isto atrapalha.

A funcionalidade de facilmente registar e permitir a alteração dos modelos e outros documentos do projeto é muito mais importante em um CASE do que a facilidade de geração de códigos. Além disso, com a quantidade de linguagens de programação disponíveis e com a velocidade em que surgem novas sempre será difícil para os fornecedores de CASE manter-se em dia. Até porque muito do que os antigos geradores de códigos faziam foi incorporado pelas linguagens visuais de 4º geração (RAD). A única exceção, naturalmente, é a geração de DDL de Banco de Dados a partir de Modelos de Dados, já que o mapeamento é fácil e a tarefa meramente mecânica.

A adoção de CASE esta intimamente ligada à adoção de uma Metodologia de Desenvolvimento de Sistemas (MDS). Adotar CASE sem MDS é como comprar o Word sem saber escrever. Ao adotar uma ferramenta CASE, é fundamental implantar imediatamente uma MSD, ou ao menos treinar os usuários do CASE na técnicas de Engenharia de Software, que são usado como suporte pelo CASE.

Esta é a razão pela qual o mercado de CASE cresce tão lentamente. É também a razão do sucesso de ferramentas "CASE" que se limitam à Modelagem de Dados.

Como a maioria das empresas resiste `a adoção de MDS, a resistência do CASE é uma consistência natural. Como o DBA da empresa é freqüentemente o único a usar algum tipo de modelo formal DER este diagrama acaba sendo o único usado na empresa, justificando a compra de ferramentas específicas para este final.

Mas que as empresas não se enganem! Adiar sem a adoção de MDS e CASE é uma decisão de altíssimo risco. Os custos absurdos de manutenção de sistemas Mainframes, feitos sem MDS, CASE ou mesmo qualquer documentação, já nos deveriam ter ensinado que a economia no curto prazo pode ter conseqüências terríveis. O pior é que muita gente pensou que sistemas cliente servidor dispensam MDS (por causa do "RAD"...!), modelagem e documentação. Doce ilusão... Quem já teve de enfrentar a tarefa de manter sistemas cliente-servidor de "primeira geração" já deve ter descoberto que era feliz e não sabia.

Se era caro e difícil manter sistemas não documentados em Mainframes, manter sistemas cliente / servidor distribuídos, n - camadas, com interface na Internet etc. será não mais caro e difícil, mas impossível.

O que, portanto, é importante considerar ao escolher uma ferramenta CASE? Como qualquer software, questões como relação preço / desempenho, disponibilidade de suporte treinamento, confiabilidade do fornecedor etc. são sempre fundamentais. A porém, alguns fatores específicos para esse tipo de ferramenta.

Em primeiro lugar, o CASE deve ser escolhido de acordo com a metodologia e não o contrário. Parece óbvio mas é freqüente empresas comprarem CASE e depois adotarem a MDS imposta pela ferramenta.

Se o CASE escolhido não suporta alterações a MDS ficará congelada, ao menos em parte. Para evoluí-la, será necessário trocar o CASE.

O compromisso do fornecedor com a evolução da ferramenta é outro ponto fundamental. Se, o CASE for apenas mais um produto em um grande pacote para convencer o cliente a comprar (como um compilador ou um gerenciador de banco de dados), podem não existir garantias de evolução e nem mesmo de continuidade do produto. Um CASE que é vendido como instrumento para aumentar as vendas de um determinado sabor de metodologia corre o risco de não suportar metodologia concorrentes ou substitutivas.

Suporte aos modelos de orientação objetos, naturalmente é essencial.

Os suportes aos diversos modelos usados no desenvolvimento (tais como BFDs em MDSs estruturadas, DTEs e diagrama de fluxos de eventos na orientação objeto) é evidentemente necessário, ao menos para as empresas que pensam que o modelo de Dados é o único modelo que existe no desenvolvimento de sistemas.

A disponibilidade de treinamentos e consultorias nas técnicas usadas pelo CASE, é outro ponto fundamental.

Concluindo, a adoção da ferramenta CASE é um a tarefa complexa, com diversas interdependências (como a MDS da empresa, seu nível CMN de maturidade, as características dos sistemas gerados, a cultura da empresa etc.), não podendo ser tomada levianamente. Paralelamente, comprar e instalar ferramentas CASE é um processo que envolve simultaneamente capacitar seus usuários nas técnicas usadas pela ferramenta. A adoção simultânea do CASE com uma DMS adequada a empresa é, portanto, a decisão mais recomendada.

 

 

Capítulo 04 - Modelagem/Geração Automática de Sistemas Integrados

A utilização de ferramentas CASE é imprescindível quando se trata do desenvolvimento e administração de sistemas integrados. Na verdade, a codificação manual de programas deveria ser utilizada somente em situações muito específicas, quando por exemplo, os programas a serem desenvolvidos são simples e pertencem a sistemas departamentais que tem pouca integração com sistemas corporativos. Isto porque, na prática , temos visto que a codificação manual esta diretamente relacionada à diminuição de produtividade e qualidade dos programas.

Nas situações em que o gerenciamento e a criação de sistemas integrados são realizados por várias equipes de desenvolvedores simultaneamente, é muito importante ter uma ferramenta CASE que suporte as várias equipes , ao mesmo tempo e acompanhe todo o ciclo de desenvolvimento das aplicações.

Existem vários tipos de ferramentas CASE disponíveis no mercado. No entanto, a seleção de uma delas, pode ser determinada através da definição das características imprescindíveis que a ferramenta deve ter para atender às necessidades de casos específicos.

O conceito de repositório ou dicionário de dados único e compartilhado é muito importante para que a ferramenta CASE possa gerenciar todas as aplicações ao mesmo tempo e todas as fases de desenvolvimento. Esta é a única maneira de garantir a uniformidade e consistência de todas as partes do projeto.

As principais fases de desenvolvimento podem ser divididas da seguinte forma: modelagem dos processo de negócios, análise de dados e funções, projeto das bases de dados e sistemas, geração automática das bases de dados e aplicações , e após isso, a regressão e engenharia reversa para a manutenção dos sistemas.

A ferramenta deve contemplar todas essas fases e, mais do que isto, fornecer a integração automática e flexível entre todas estas etapas, seja da primeira para a última ou vice versa. Em algumas situações, o desenvolvimento pode ser feito da primeira etapa até a última, passando em cada uma das fases intermediárias. Mas em alguns momentos, pode ser necessário pular algumas fases e , posteriormente, fazer uma engenharia reversa para guardar todas as informações atualizadas no dicionário do CASE.

Além disso, um dicionário de dados completo pode fornecer a documentação de todas as etapas e facilitar o acompanhamento de todo o ciclo de desenvolvimento.

Na etapa de modelagem dos processos de negócios, é importante poder definir todos os processos referentes, sejam eles manuais ou informatizados, e seus detalhes, como descrição, duração, limites, associação de multimídia, fotos, filmes, entre outros. E através de todas estas definições, poder discutir melhoramentos, reengenharia de processos e fazer validações com os usuários e analistas de negócios.

Na fase de análise de dados definição de funções e fluxos da informação, são desenhados todos os diagramas conceituais dos sistemas e definidas todas as suas especificações , conforme as necessidades de negócios. Nesse momento, pode estar sendo definido sistemas relacionais através de diagramas de entidades e relacionamentos. Ou ainda, podem estar sendo definidos sistemas orientados a objetos. Nesses casos, é importante que a ferramenta suporte tanto a modelagem relacional, como a modelagem orienta a objetos e a integração entre elas. No caso de modelagem orientada a objetos é importante que a ferramenta suporte um padrão aberto definido como a UML (Unified Modelling Laguage).

Após a fase de análise a ferramenta CASE deve transformar, automaticamente, toda definição conceitual em projeto físico. Ou seja, todas as entidades, relacionamentos e suas especificações definidos anteriormente, se transformam em projetos de telas, relatórios, gráficos, menus, etc..

Nesse momento, será necessário detalhar os aspectos físicos antes da implementação aos dados, será detalhado em que banco de dados devem ser geradas, fisicamente, as tabelas ou classes de objetos, além da definição de volumes das informações dos sistemas, regras de usuário e seus acessos aos dados, entre outros. Em relação aos programas, podem ser definidos templates a serem utilizados, mensagens e padrões adotados na geração dos programas, tipos de aplicações geradas, entre outros.

Definido todo o projeto físico dos dados e aplicações, segue-se para a geração efetiva dos sistemas.

Através do projeto de dados será gerada, automaticamente, a criação de todas as bases de dados como tabelas, classes de objetos, índices, consistência de dados e regras de negócios nos bancos de dados. Evidentemente, esta geração das bases de dados deve suportar e ser aberta aos principais bancos do mercado.

Através do projeto de aplicações , todos os menus e programas serão gerados automaticamente. Isto vale tanto para relatórios quanto para telas ou gráficos.

É importante considerar ferramentas CASE que, além de acompanhar todo o ciclo de desenvolvimento de sistemas, tenham o conceito de projeto independente da implementação. Ou seja, a proposta é que a modelagem dos negócios seja efetuada uma única vez. E que a partir desta modelagem, e projeto únicos possa ser gerada a implementação dos sistemas de várias formas . Por exemplo, dependendo da necessidade, pode ser preciso gerar sistemas para o ambiente cliente/servidor, para a Web ou para ambos ao mesmo tempo, baseados no mesmo projeto já definido.

A idéia é que, se na fase de análise foi definido que um determinado atributo tem uma descrição e uma lista de valores específicos, isto seja levado, automaticamente, para o projeto de dados e para a criação dessa coluna no banco de dados, para todos os programas de manutenção deste campo, seja este programa executado através da Web ou em ambiente cliente/servidor.

Após a geração completa dos dados e aplicações, o que pode acontecer é a necessidade de alterações. A ferramenta deve oferecer recursos para análise de impacto e regeração automática das alterações. Por exemplo, pode ser necessário alterar o tamanho de uma campo específico que já esta sendo utilizado pelos sistemas. Devem ser oferecidos mecanismos para identificar todas as tabelas e programas em que este campo é referenciado, para que sejam feitas as regerações de dados e programas necessárias para efetivar esta alteração.

Em alguns casos, pode não haver tempo para que a alteração seja feita através da regeração da ferramenta CASE. Ou seja, a alteração é feita diretamente no programa fonte ou na tabela no ambiente de produção. Nesses casos, a ferramenta CASE deve suportar a engenharia reversa de dados e programas para que a alteração seja efetuada também no dicionário de dados e assim se mantenha a integridade e administração efetiva de todos os dados e aplicações. Para a ferramenta CASE suportar a engenharia reversa, é necessário que ela tenha uma integração completa com a ferramenta de desenvolvimento. Essa integração deve abranger não apenas os dados, de telas e suas respectivas consistência, mas também, todas as regras de negócios e definições pertencentes ao programa.

Relacionado a esta questão de engenharia reversa, um ponto importante a ser considerado é que, muitas vezes, quando se decide pela utilização de uma ferramenta CASE, todas as bases de dados e sistemas já estão criados e já estão sendo executados nos ambientes de produção. Nesses casos, será necessária a engenharia reversa completa de todos os dados e programas para levar todas estas informação para o dicionário de dados e, a partir deste ponto poder utilizar a ferramenta CASE para futuras alterações nos sistemas que foram levados ao dicionário, além de possibilitar a integração desses sistemas aos novos, que venham a ser desenvolvidos através do CASE.

Em certas situações, pode se tratar de sistemas legados que precisam ser convertidos para os novos modelos de computação. Nesses casos, poderia ser feita uma carga dos dados legados para bancos relacionais. A partir daí a engenharia reversa da ferramenta CASE levaria esses dados para o dicionário, onde poderiam ser feita a customização e regeração desses dados para um modelo de computação.

A conclusão final é que, para quem administra e desenvolve sistemas corporativos e integrados, cresce, cada vez mais, a necessidade de utilização da ferramenta CASE que tenham as funcionalidades descritas anteriormente. Estamos em um momento em que as mudanças tecnológicas estão afetando todos os aspectos envolvidos no desenvolvimento de aplicações. Hoje, nos deparamos com novas metodologias e modelagens de dados, novas linguagens de programação, novos modelos de distribuição de sistemas, novos padrões de comunicação.

Não basta apenas escolher uma ferramenta de desenvolvimento que tenha uma boa interface gráfica, baixo custo e seja de fácil utilização. Precisamos buscar uma solução completa de desenvolvimento que garanta a qualidade, a produtividade, e a integridade dos sistemas como um todo.

Por isso, uma ferramenta CASE completa e integrada às ferramentas de desenvolvimento que ofereça esta evolução para as novas tecnologias pode garantir a diminuição de custos e o aproveitamento de investimentos já realizados. Por exemplo, pode ser que todos os sistemas atuais estejam definidos no dicionário de dados do CASE com base em modelos relacionais, e os novos sistemas a serem desenvolvidos devam utilizar a modelagem orientada a objetos. A forma de integração destes ambientes, sem causar grande impacto, é através de ferramenta CASE que trabalhem com dicionário de dados unificado e assim suportem ambientes mistos para a modelagem e geração de dados.

Dessa forma, realmente haverá a integração dos sistemas já existentes aos novos sistemas e o gerenciamento completo de todas as aplicações.

 

 

Capítulo 05 - Ferramentas CASE: Solução ou Apoio aos Processos?

Quando a empresa busca no mercado uma ferramenta CASE, sua expectativa é acabar com os problemas tradicionais da área de desenvolvimento de sistemas, ou seja , reduzir o número de manutenções, aumentar a produtividade e a aderência às especificações requisitadas.

A maioria se esquece que a ferramenta CASE - Computer Aided Software Engeneering - é, por definição, uma ferramenta de apoio ao processo de desenvolvimento de software, não a solução mágica para os problemas da área.

A ferramenta CASE acelera e padroniza a documentação para a produção mágica para os problemas da área.

A ferramenta CASE acelera e padroniza a documentação para a produção de software, desde que seu usuário saiba "o que" documentar, caso contrário ocorre o tradicional : "garbage in, garbage out". Logo, não é incomum ouvirmos reclamações de que CASE não serve para nada e que só se perde tempo com a ferramenta; nesses ambientes, impera a opinião de que a melhor saída é desenvolver a moda antiga, ou seja, caoticamente e fortemente baseada em talentos individuais. O questionamento que surge é: se o uso correto da ferramenta me traz sensíveis ganhos de produtividade e qualidade, então como alcançá-los?

A ferramenta CASE deve ser definida após a definição das técnicas a serem usadas. É neste momento que cabe a escolha de uma ferramenta CASE capaz de suprir a necessidade tecnológica e, principalmente, uma ferramenta que permita acompanhar a evolução da maturidade da área de tecnologia de informação, ou seja, ela deve conter facilidades de ser meta CASE. Este termo refere-se a capacidade de customizar uma técnica padrão para as necessidades da empresa, minimizando a produtividade da área.

Concluindo, a ferramenta CASE é um instrumento muito poderoso para acelerar o processo, mas é de suma importância que a área de tecnologia de informação não as avalie pontualmente, e sim dentro de um contexto maior que o processo de Engenharia, seja ela de negócio, software ou ambas.

 

 

 

Capítulo 06 - Ferramentas CASE (Exemplos)

6.1 Dr. CASE 2.0

Nos últimos anos, o mercado de ferramentas CASE vem oferecendo um número cada vez maior de opções ao desenvolvedor que procura um mecanismo para otimizar o processo de desenvolvimento de sistemas, abrangendo as fases que vão da análise até a implementação. Durante a fase de escolha até sua implementação. Durante a fase de escolha da ferramenta, geralmente se analisa um conjunto de produtos dentre os disponíveis no mercado, portando - se normalmente pelo que apresenta a melhor relação custo/benefício e levando-se em conta o objetivo para o qual a ferramenta será destinada.

Nessa fase, as dúvidas as comuns no que diz respeito à escolha da ferramenta podem ser resumidas nas seguintes questões: Qual produto final produzido pela ferramenta CASE: o banco de dados, a aplicação de front-end ou ambos? É possível duas ou mais pessoas trabalharem simultaneamente no desenvolvimento de um sistema? Os analistas, envolvidos no projeto se sentirão à vontade com a metodologia empregada pela ferramenta durante a fase de modelagem de dados? Em que plataforma poderão ser implementados os sistemas desenvolvidos com o auxilio dessa ferramenta? Qual o grau de integração entre a ferramenta analisada e outras ferramentas existentes? Qual a flexibilidade oferecida pela documentação gerada pelo aplicativo? Que nível de segurança o produto oferece?

Pode se dizer que o Dr. CASE, uma ferramenta de desenvolvimento nacional da categoria Upper CASE (responsável pela análise, planejamento e implementação de banco de dados) desenvolvida e distribuída pela SQUADRA Tecnologia de Software.

Esta análise tem por objetivo relacionar as características da ferramenta às questões descritas anteriormente e a outras indagações que possam surgir durante a procura de uma solução ideal.

6.1.1 O Ambiente de Desenvolvimento

A nova versão do produto (2.0) tem uma interface gráfica simples e amigável, incluindo um navegador através do qual é possível visualizar ou alterar rapidamente qualquer elemento que faça parte do sistema em desenvolvimento.

Por ter sido desenvolvido com base na tecnologia cliente/ servidor, o Dr. CASE oferece a possibilidade de que o trabalho de desenvolvimento seja feito em equipe e, nesse caso, uma estação servidora fica responsável pela integridade dos dados referente ao sistema em desenvolvimento.

As definições de um ou mais sistemas são armazenados em um elemento denominado repositório, que nada mais é do que um diretório do disco rígido, o que permite que o controle de segurança seja feito através do próprio sistema operacional.

O grupo de tipos de dados a ser utilizados durante todo o processo de desenvolvimento do sistema pode ser aquele com o qual o desenvolvedor se sente mais à vontade independente do SGBD a ser utilizado na implementação final do sistema. Entre as opções de grupos disponíveis estão o do Paradox, do Access Acc e Ss, do interbase e muito outros.

6.1.2 Projeto Conceitual

O Modelo Conceitual de Dados (MCD) é elaborado no Dr. CASE, utilizando - se a abordagem Entidade - Relacionamento E-R desenvolvida por Peter Chen, incluindo extensões com generalização, especialização e agregação. Essa abordagem disponibiliza ao desenvolvedor um conjunto de opções que permite sua total abstração de quaisquer limites tecnológicos impostos pelo projeto lógico ou pelo SGBD a ser utilizado posteriormente.

O Dr. CASE permite que um sistema seja desenvolvido não tenha um MCD, porém essa forma de utilização da ferramenta caracteriza o desperdício da abstração alcançada pelo modelo conceitual, devido a própria facilidade encontrada pela maioria dos desenvolvedores na utilização do modelo E-R.

6.1.3 Projeto Lógico

O modelo lógico de dados (MLD), utilizado pelo Dr. CASE tem com referência o modelo relacional, usado em larga escala nos SGBDs comercializados atualmente. A derivação do MLD é feita pelo Dr. CASE, seguindo as regras de transposição pré definidas pela ferramenta, as quais que podem ser ajustadas pelo usuário.

O processo de transposição do projeto conceitual para o projeto lógico abrange desde mapeamento simples, como a geração de uma tabela à partir de um relacionamento com cardinalidade N:N, até outros mais complexos, como regras da integridade referencial geradas à partir de relacionamentos envolvendo entidades fortes e fracas. Todas as definições referentes a tabelas e campos gerados à partir da transposição do projeto conceitual para o projeto lógico podem ser alteradas durante esta última fase.

O projeto lógico permite a inclusão de estruturas físicas de banco de dados como consultas, índices checks, triggers e stored procedures (neste caso, deve se levar em conta que a maioria dessas estruturas só podem ser implementadas em SGBDs que utilizam a tecnologia cliente-servidor.

6.1.4 Implementação do Banco de Dados

Ao final do projeto lógico, o MLD está pronto para ser implementado em uma plataforma compatível com o modelo relacional. A implementação poderá ser feita mediante a utilização de um Script SQL ou através da geração física dos arquivos que irão compor o banco de dados. Esta última opção é normalmente utilizada em banco de dados Desktop, como Paradox e DBASE, enquanto a implementação via a Script SQL (que consiste em um arquivo texto com os comandos em SQL responsáveis pela definição do banco de dados) é utilizada em SGBDs de maior porte, como o interbase, SQL Server , Oracle e outros. Caso a plataforma a ser utilizada não esteja incluída nessa relação, pode-se ainda utilizar um Script genérico de acordo com o padrão ANSI SQL. Durante a geração do Script, o usuário terá à disposição de uma série de opções de "incrementação" do código (como, por exemplo, a inclusão de comentários gerados automaticamente pelo Dr. CASE).

6.1.5 Integração com Sculptor

O Sculptor é um gerador de código Delphi, desenvolvido também pela esquadra. Embora os dois produtos possam trabalhar de forma independente, há ainda a possibilidade de se desenvolver um sistema completo utilizando-se as duas ferramentas.

Neste caso, o Dr. CASE é responsável pela análise e projeto do sistema, exportando as definições do modelo de dados para o dicionário de dados do Sculptor, que, por sua vez, gera o código fonte da aplicação que, por fim irá acessar uma base de dados projetado pelo Dr. CASE.

6.1.6 Consistência dos Modelos

Durante a transposição do modelo conceitual para o modelo lógico e deste para a implementação, o Dr. CASE verifica a consistência do modelo já produzido antes de passar para a fase seguinte. Na etapa de transposição do projeto conceitual para o modelo lógico um dos erros a serem verificados é a ocorrência de atributos multivalorados , definidos por chave primária de uma entidade. Na transposição do projeto lógico para a implementação do banco de dados, verifica-se, entre outras condições, a existência de uma tabela referenciada por uma chave estrangeira.

6.1.7 Documentação e Help On-Line

O Dr. CASE permite a geração de vários tipos de relatórios referente aos elementos do sistema (desde os mais simples até os mais complexos).

Uma inovação da versão 2.0 é Dr. CASE DFD, um aplicativo instalado junto com o Dr. CASE, e que tem como objetivo a documentação de modelos funcionais baseados no Diagrama de Fluxos de Dados (DFD).

O sistema de Help On-Line fornecido pelo Dr. CASE tem uma interface consideravelmente intuitiva e conteúdo equivalente ao manual do usuário, oferecendo também um acesso rápido e direto.

6.1.8 Conclusão

Com o lançamento da versão 2.0, o Dr. CASE reforça a sua posição entre as ferramentas CASE disponíveis no mercado. Num universo de produtos extremamente caros e de difícil utilização requerendo longos e custosos treinamentos, além de consultoria permanente o Dr. CASE se destaca como uma ferramenta única pela sua facilidade de utilização e excelente relação custo / benefício, o que pode ser decisivo na hora da compra.

6.1.9 Requisitos Mínimos do Sistema

6.2 System Artchitect

A ferramenta CASE System Archtect é hoje um produto de primeira necessidade em empresa que possui desenvolvimento de software, ou utilizam pacotes que precisam integrar-se com outros sistemas. Uma ferramenta CASE deve, antes de mais nada, retratar as metodologias diversas, tanto as tradicionais, baseadas em análise estruturadas, quanto as mais recentes como OOA&D, permitindo ao usuário migrar de para outra conforme o projeto e a concepção.

Assim como um arquiteto necessita fazer desenhos para um projeto de um edifício, o analista de sistemas tem na sua prancheta uma ferramenta CASE. Só o CASE pode retratar um projeto de um sistema, suas conexões, seus fluxos, suas interface, sua dimensão , sua complexidade, suas etapas sua reutilização, etc.

A atuação nos projetos desde sua concepção até a execução final, faz da ferramenta CASE um produto básico para desenhar, planejar, executar, implantar, testar e controlar sistemas.

A grande versatilidade do System Archtect se deve a utilização de variadas técnicas como as de Chris Gane, DeMarco, Booch, Rumbaugh, UML, Ivar Jacobson, Yourdon e James Martin. Essas técnicas podem ser totalmente integradas na ferramenta através de customizações para que o System Architect se adapte a metodologia de desenvolvimento de sistemas de cada organização. Sendo uma ferramenta meta-case, o System Architect se adapta totalmente ao ambiente de desenvolvimento, não engessando o processo de análise e projeto de software.

O System Architect tem a vantagem de ser uma ferramenta flexível para a empresa que trabalha com a Análise Estruturada de Sistemas .

A utilização do System Architect em uma empresa dá a organização necessária para que ela possa racionalizar o desenvolvimento de sistemas.

Os sistemas são planejados e entregues nos prazos especificados. Com o SA , é possível documentar os requisitos e objetivos do sistema, ou seja, fazer um estudo preliminar do software a ser desenvolvido. Depois desse estudo, as informações definidas permitirão definir corretamente os prazos de entrega do produto e efetivamente cumpri-los.

O uso do System Architect diminui a manutenção dos sistemas e padroniza seu desenvolvimento. A implantação de uma metodologia apoiada na ferramenta faz com que a análise seja consistente, confiável e prática. O resultado disso são sistemas que atendem a sua especificação e , como conseqüência, há uma diminuição na manutenção.

O System Architect tem ainda como característica importante o fato de ser uma ferramenta workgrup, ou seja, é impossível compartilhar um mesmo projeto entre diversos analistas de desenvolvimento. Num único repositório são colocadas todas as informações do projeto. Essas informações podem ser disponibilizadas através dos relatórios padrão do AS, por meio de macros via Microsoft Word, e também disponibilização dos projetos em HTML, permitindo, através de uma intranet, acesso aos modelos e a sua documentação.

Os projetos podem ser agrupados por sistemas e subsistemas; existe uma enciclopédia do SA correspondente a cada um deles. Essas enciclopédias ficam armazenadas na rede de acordo com as áreas de trabalho dos analistas.

Todos os procedimentos para a criação de um novo projeto, troca de informações entre os projetos e padrões de procedimento de trabalho devem ser especificados antes da implantação e divulgação do SA .

O SA torna-se então uma ferramenta "facilitadora" e "automatizadora" do cumprimento de tarefas de cada analista.

O SA pode ainda gerar produtos para outras ferramentas no ambiente de desenvolvimento através de links.

Na fase de projeto o SA possibilita integrações com banco de dados através de engenharia direta ou reversa dos dados.

A partir do modelo entidade - relacionamento, o SA gera scripts (.SQL) para a maioria dos bancos de dados relacionais do mercado do mercado, de modo que o SGBD cria as tabelas a partir deste script ou via ODBC, onde o SA cria as tabelas físicas diretamente no banco de dados.

Mas se a necessidade fora documentação de modelos já existentes no banco, o SA faz a engenharia reversa dos dados, de modo a gerar o modelo lógico e alimentar seu repositório a partir de um script, ou conectando - se ao banco de dados via ODBC e importando diretamente o modelo físico. Outros links são disponibilizados pelo System Architect, como geração básica de código para ferramentas de programação.

A partir do modelo entidade - relacionamento, é possível gerar forms com operações de inserção , deleção , alteração, e consulta , para Visual Basic, Dephi e Power Builder.

A partir do modelo de classes, geram - se estruturas básicas para criação de classes e métodos nas seguintes linguagens: C++, Java, Delphi, VB, e padrão CORBA.

6.2.1 Aplicação dos produtos System Architect nas Fases de Desenvolvimetno de Sistemas

1 - Levantamento do processo (ante - projeto)

Nesta fase utilizam-se técnicas para modelar os processos de negócio. Essas técnicas são baseadas no padrão IDEF, como IDEF0 e IDEF3. Tais técnicas são disponibilizadas pela ferramenta System Architect - BPR, que armazenará toda a informação levantada nessa fase em um repositório.

Esse repositório pode ser compartilhado com a ferramenta System Architect, fazendo com que as fases seguintes de desenvolvimento estejam integradas e de acordo com essa primeira e fundamental etapa.

Com o SA - BPR, pode-se modelar os processos do negócio, abordando suas entradas, saídas , recursos(físicos) e restrições, tempo e custo de cada atividade (ABC Cost).

2 - Estudo de viabilidade econômica / planejamento

A partir das informações levantadas na primeira etapa , relatórios de referencia cruzada podem ser gerados, extraindo todas as definições do repositório.

3 - Análise

Várias informações que foram definidas na fase de levantamento são reutilizadas na fase de análise, permitindo total integração entre modelagem de processos de negócios e modelagem funcional e de dados.

4 - Projeto

Esta fase aborda o modo de implementação mo ambiente da empresa (linguagens, banco de dados).

O System Architect disponibiliza várias técnicas para modelar a distribuição dos componentes do sistema a ser desenvolvido.

5 - Implementação/Testes/Homologação

A partir dos produtos gerados na fase anterior, o SA gera os scripts para o banco de dados e os forms para as linguagens de quarta geração.

6.3 ERWin / BPWin / Paradigm Plus / ModelMart

Atualmente, quando se pensa em desenvolvimento de sistemas em plataforma cliente/servidor, duas são as principais linhas a serem seguidas: Análise Estruturada/Essencial ou Análise Orientada a Objetos.

Há ainda os que preferem abstrair-se da fase convencional da análise e, a partir da definição do modelo de dados (Entidade/Relacionamento), iniciar o desenvolvimento da aplicação com alguma ferramenta de mercado (VB, PowerBuilder, Centura/SQLWindows, Delphi, C++, Java, etc.) embutindo, de alguma forma, a análise nesta fase.

O objetivo dessas ferramentas é que possam agregar produtividade na fase inicial do projeto preparando-o, de forma adequada, para a fase de programação da aplicação com o front-end de mercado da preferência do desenvolvedor.

Desta forma, pode-se oferecer as seguintes ferramentas CASE:

Se o caminho for análise estruturada a composição será: BPwin, ERwin, ModelMart.

Ao contrário, se o caminho for análise orientada a objetos a composição será: Paradigm Plus, ERwin, ModelMart.

6.3.1 Paradigm Plus

O Paradigm Plus, ferramenta CASE que possibilita que a OOA seja feita com base nas principais metodologias de mercado tais como: UML, OMT, Fusion, Booch, OOCL, Martin/Odell, Shlaer/Mellor, Coad/Yourdon, entre outras, estendendo cada método para suportar o Use Cases do Jacobson. O trabalho é desenvolvido através de modelagem visual podendo gerar arquitetura de código para os principais front-end's de mercado tais como: Delphi, Java, Microsoft Visual Basic, Microsoft Visual C++, Microsoft Visual J++, PowerBuilder, entre outros; DDL básica para os principais RDBMS de mercado tais como: Oracle, Microsoft SQLServer, Sybase, entre outros.

6.3.2 ERwin/ERX

Ferramenta de modelagem de dados com capacidade de gerar DDL para os principais RDBMS de mercado podendo incorporar triggers, stored procedures, regras de validação, domínios, templates, etc. Uma de suas características mais avançadas é a capacidade de fazer engenharia reversa através de scripts ou direto do dicionário de dados do banco podendo, através da função "COMPLETE COMPARE" oferecer um relatório detalhado das eventuais discrepâncias entre o modelo e a base ou script podendo inclusive promover a sincronização entre ambos.

6.3.3 ModelMart

Ambiente multiusuário para desenvolvimento e gerenciamento de modelos. Possibilita que diversos desenvolvedores possam trabalhar simultaneamente num mesmo modelo oferecendo um sofisticado controle através da definição de privilégios de uso através dos perfis estabelecidos para cada projetista. Controla todas as alterações simultâneas e os eventuais conflitos que possam existir.

6.3.4 BPwin

Ferramenta para modelagem de processos que permite definir e otimizar qualquer processo de negócio (business process). Provendo uma interface intuitiva do tipo point-and-click que permite a criação de modelos em minutos, o BPwin oferece mais capacidades analíticas que as ferramentas CASE tradicionais. Através da automação da metodologias IDEF0, IDEF3 e DFD o BPwin provê o rigor lógico necessário para garantir resultados corretos e consistentes. Utilizando um ambiente gráfico o BPwin permite a construção rápida de diagramas de processos SADT, DFD ou Workflow o qual mostram claramente o resultado das atividades, os recursos necessários para executá-las e seus relacionamentos. Além disso, o BPwin mantém a integridade referencial do diagrama, prevenindo conexões incorretas de linhas, garantindo consistência das atividades em todo o modelo.

6.3.5 Cenário Análise Orientada a Objetos

O Paradigm Plus, a partir da modelagem visual, pode gerar arquitetura de código e ddl com as seguintes vantagens:

6.3.6 Cenário Análise Estruturada

O BPwin, a partir da modelagem visual, pode ser usado para a definição e documentação dos processos conforme segue:

Para melhor ilustrar o que foi falado segue um modelo visual da integração das ferramentas.

 

 

Bibliografia

Developer’s Magazine – junho/1998 – Axcel Books do Brasil Editora Ltda. – R.J.

Iivari, Juhani – Communication of the ACM – "Why are CASE tools not used ? " – outubro/1996

PressMan, Roger S. – Engenharia de Software – São Paulo: Makron Books, 1995

PressMan, Roger S. – Software Engeneering