Engenharia de software auxiliada por computador - Computer-aided software engineering

Exemplo de ferramenta CASE.

A engenharia de software auxiliada por computador ( CASE ) é o domínio das ferramentas de software usadas para projetar e implementar aplicativos. As ferramentas CASE são semelhantes e parcialmente inspiradas por ferramentas de design auxiliado por computador (CAD) usadas para projetar produtos de hardware. As ferramentas CASE são usadas para desenvolver software de alta qualidade, livre de defeitos e de fácil manutenção. O software CASE é freqüentemente associado a métodos para o desenvolvimento de sistemas de informação junto com ferramentas automatizadas que podem ser usadas no processo de desenvolvimento de software .

História

O projeto Sistema de Otimização e Design de Sistemas de Informação (ISDOS), iniciado em 1968 na Universidade de Michigan , deu início a um grande interesse em todo o conceito de uso de sistemas computacionais para auxiliar analistas no difícil processo de análise de requisitos e desenvolvimento de sistemas. Vários artigos de Daniel Teichroew despertaram toda uma geração de entusiastas com o potencial do desenvolvimento de sistemas automatizados. Sua ferramenta Problem Statement Language / Problem Statement Analyzer (PSL / PSA) era uma ferramenta CASE, embora fosse anterior ao termo.

Outro segmento importante surgiu como uma extensão lógica para o dicionário de dados de um banco de dados . Ao estender o intervalo de metadados mantidos, os atributos de um aplicativo podem ser mantidos em um dicionário e usados em tempo de execução. Este "dicionário ativo" tornou-se o precursor da capacidade de engenharia orientada a modelos mais moderna . No entanto, o dicionário ativo não forneceu uma representação gráfica de nenhum dos metadados. Foi a vinculação do conceito de dicionário contendo metadados de analistas, derivado do uso de um conjunto integrado de técnicas, com a representação gráfica desses dados que deu origem às versões anteriores do CASE.

O próximo participante no mercado foi o Excelerator da Index Technology em Cambridge, Massachusetts. Enquanto o DesignAid funcionava com a Convergent Technologies e mais tarde Burroughs Ngen em microcomputadores em rede, a Index lançou o Excelerator na plataforma IBM PC / AT . Embora, na época do lançamento, e por vários anos, a plataforma IBM não suportasse rede ou um banco de dados centralizado como as máquinas Convergent Technologies ou Burroughs, o fascínio da IBM era forte e o Excelerator ganhou destaque. Logo após a Excelerator estava uma onda de ofertas de empresas como a Knowledgeware (James Martin, Fran Tarkenton e Don Addington), a CA Gen da Texas Instrument e o conjunto de ferramentas FOUNDATION da Andersen Consulting (DESIGN / 1, INSTALL / 1, FCP).

As ferramentas CASE estavam em seu pico no início dos anos 1990. De acordo com a PC Magazine de janeiro de 1990, mais de 100 empresas estavam oferecendo cerca de 200 ferramentas CASE diferentes. Na época, a IBM havia proposto AD / Cycle, que era uma aliança de fornecedores de software centrada no repositório de software da IBM usando IBM DB2 em mainframe e OS / 2 :

As ferramentas de desenvolvimento de aplicativos podem ser de várias fontes: da IBM, de fornecedores e dos próprios clientes. A IBM entrou em relacionamentos com a Bachman Information Systems, Index Technology Corporation e Knowledgeware, em que produtos selecionados desses fornecedores serão comercializados por meio de um programa de marketing complementar da IBM para fornecer ofertas que ajudarão a atingir uma cobertura completa do ciclo de vida .

Com o declínio do mainframe, as ferramentas AD / Cycle e Big CASE morreram, abrindo o mercado para as ferramentas CASE convencionais de hoje. Muitos dos líderes do mercado CASE no início dos anos 1990 acabaram sendo comprados pela Computer Associates , incluindo IEW, IEF, ADW, Cayenne e Learmonth & Burchett Management Systems (LBMS). A outra tendência que levou à evolução das ferramentas CASE foi o surgimento de métodos e ferramentas orientados a objetos. A maioria dos vários fornecedores de ferramentas adicionou algum suporte para métodos e ferramentas orientados a objetos. Além disso, surgiram novos produtos projetados de baixo para cima para dar suporte à abordagem orientada a objetos. A Andersen desenvolveu seu projeto Eagle como alternativa à Fundação. Vários dos líderes de pensamento no desenvolvimento orientado a objetos desenvolveram sua própria metodologia e conjunto de ferramentas CASE: Jacobsen, Rumbaugh, Booch , etc. Eventualmente, esses diversos conjuntos de ferramentas e métodos foram consolidados por meio de padrões liderados pelo Object Management Group (OMG). A Unified Modeling Language (UML) da OMG é atualmente amplamente aceita como o padrão da indústria para modelagem orientada a objetos.

Software CASE

A. Fuggetta classificou o software CASE diferente em 3 categorias:

As ferramentas oferecem suporte a tarefas específicas no ciclo de vida do software .
Workbenches combinam duas ou mais ferramentas focadas em uma parte específica do ciclo de vida do software.
Os ambientes combinam duas ou mais ferramentas ou workbenches e dão suporte ao ciclo de vida completo do software.

Ferramentas

As ferramentas CASE suportam tarefas específicas no ciclo de vida de desenvolvimento de software. Eles podem ser divididos nas seguintes categorias:

Modelagem de negócios e análise. Ferramentas de modelagem gráfica. Por exemplo, modelagem E / R, modelagem de objetos, etc.
Desenvolvimento. Fases de projeto e construção do ciclo de vida. Ambientes de depuração. Por exemplo, IISE LKO .
Verificação e validação . Analise o código e as especificações quanto à correção , desempenho, etc.
Gerenciamento de configurações. Controle o check-in e check-out de objetos e arquivos do repositório. Por exemplo, SCCS , IISE.
Métricas e medição. Analise o código quanto à complexidade, modularidade (por exemplo, sem "ir para"), desempenho, etc.
Gerenciamento de Projetos. Gerenciar planos de projeto, atribuições de tarefas, agendamento.

Outra maneira comum de distinguir ferramentas CASE é a distinção entre CASE superior e CASE inferior. As ferramentas Upper CASE oferecem suporte à modelagem de negócios e análise. Eles suportam linguagens diagramáticas tradicionais, como diagramas ER , diagrama de fluxo de dados , gráficos de estrutura , árvores de decisão , tabelas de decisão , etc. Ferramentas CASE inferiores oferecem suporte a atividades de desenvolvimento, como design físico, depuração, construção, teste, integração de componentes, manutenção e reverso Engenharia. Todas as outras atividades abrangem todo o ciclo de vida e se aplicam igualmente ao CASE superior e inferior.

Bancadas de trabalho

Os workbenches integram duas ou mais ferramentas CASE e oferecem suporte a atividades de processo de software específicas. Portanto, eles alcançam:

uma interface homogênea e consistente (integração de apresentação).
Integração perfeita de ferramentas e conjuntos de ferramentas (controle e integração de dados).

Um exemplo de ambiente de trabalho é o ambiente de programação Visual Basic da Microsoft . Ele incorpora várias ferramentas de desenvolvimento: um construtor de GUI, um editor de código inteligente, depurador, etc. A maioria dos produtos CASE comerciais tendiam a ser bancadas de trabalho que integravam perfeitamente duas ou mais ferramentas. As bancadas também podem ser classificadas da mesma maneira que as ferramentas; como foco em Análise, Desenvolvimento, Verificação, etc., bem como em letras maiúsculas, minúsculas ou processos, como gerenciamento de configuração, que abrangem o ciclo de vida completo.

Ambientes

Um ambiente é uma coleção de ferramentas CASE ou workbenches que tenta oferecer suporte ao processo de software completo. Isso contrasta com as ferramentas que se concentram em uma tarefa específica ou uma parte específica do ciclo de vida. Os ambientes CASE são classificados pela Fuggetta da seguinte forma:

Kits de ferramentas. Coleções de ferramentas fracamente acopladas. Eles normalmente se baseiam em workbenches de sistema operacional, como o Unix Programmer's Workbench ou o conjunto VMS VAX. Eles normalmente realizam integração por meio de tubulação ou algum outro mecanismo básico para compartilhar dados e passar o controle. A força da fácil integração também é uma das desvantagens. A simples passagem de parâmetros por meio de tecnologias como script de shell não pode fornecer o tipo de integração sofisticada que um banco de dados de repositório comum pode.
Quarta geração. Esses ambientes também são conhecidos como 4GL, que significa ambientes de linguagem de quarta geração, devido ao fato de que os primeiros ambientes foram projetados em torno de linguagens específicas, como Visual Basic. Eles foram os primeiros ambientes a fornecer integração profunda de várias ferramentas. Normalmente, esses ambientes eram focados em tipos específicos de aplicativos. Por exemplo, aplicativos orientados à interface do usuário que faziam transações atômicas padrão para um banco de dados relacional. Os exemplos são Informix 4GL e Focus.
Centrado na linguagem. Ambientes baseados em uma única linguagem frequentemente orientada a objetos, como o ambiente Symbolics Lisp Genera ou VisualWorks Smalltalk do Parcplace. Nesses ambientes, todos os recursos do sistema operacional eram objetos na linguagem orientada a objetos. Isso fornece uma depuração poderosa e oportunidades gráficas, mas o código desenvolvido é limitado principalmente à linguagem específica. Por esse motivo, esses ambientes eram principalmente um nicho dentro do CASE. Seu uso era principalmente para prototipagem e projetos de P&D. Uma ideia central comum para esses ambientes era a interface de usuário modelo-visão-controlador que facilitou a manutenção de várias apresentações do mesmo projeto consistentes com o modelo subjacente. A arquitetura MVC foi adotada por outros tipos de ambientes CASE, bem como por muitos dos aplicativos que foram construídos com eles.
Integrado. Esses ambientes são um exemplo do que a maioria do pessoal de TI tende a pensar primeiro quando pensa em CASE. Ambientes como AD / Cycle da IBM, FOUNDATION da Andersen Consulting, o sistema CADES ICL e DEC Cohesion. Esses ambientes tentam cobrir o ciclo de vida completo da análise à manutenção e fornecer um repositório de banco de dados integrado para armazenar todos os artefatos do processo de software. O repositório de software integrado foi o recurso definidor para esses tipos de ferramentas. Eles forneceram vários modelos de design diferentes, bem como suporte para código em linguagens heterogêneas. Um dos principais objetivos para esses tipos de ambiente era a "engenharia de ida e volta": ser capaz de fazer alterações no nível de design e fazer com que elas se refletissem automaticamente no código e vice-versa. Esses ambientes também eram normalmente associados a uma metodologia específica para desenvolvimento de software. Por exemplo, a suíte FOUNDATION CASE da Andersen estava intimamente ligada à metodologia Andersen Method / 1.
Centrado no processo. Este é o tipo de integração mais ambicioso. Esses ambientes tentam não apenas especificar formalmente os objetos de análise e design do processo de software, mas o próprio processo em si e usar esse processo formal para controlar e orientar os projetos de software. Os exemplos são East, Enterprise II, Process Wise, Process Weaver e Arcádia. Esses ambientes foram, por definição, vinculados a alguma metodologia, uma vez que o próprio processo de software é parte do ambiente e pode controlar muitos aspectos da chamada da ferramenta.

Na prática, a distinção entre bancadas de trabalho e ambientes era flexível. Visual Basic, por exemplo, era um workbench de programação, mas também era considerado um ambiente 4GL por muitos. Os recursos que distinguiam workbenches de ambientes eram a integração profunda por meio de um repositório compartilhado ou linguagem comum e algum tipo de metodologia (ambientes integrados e centrados no processo) ou especificidade de domínio (4GL).

Fatores de risco CASE principais

Alguns dos fatores de risco mais significativos para organizações que adotam a tecnologia CASE incluem:

Padronização inadequada. As organizações geralmente precisam adaptar e adotar metodologias e ferramentas para seus requisitos específicos. Fazer isso pode exigir um esforço significativo para integrar tecnologias divergentes, bem como métodos divergentes. Por exemplo, antes da adoção do padrão UML, as convenções e métodos de diagramas para projetar modelos orientados a objetos eram muito diferentes entre os seguidores de Jacobsen, Booch e Rumbaugh.
Expectativas irrealistas. Os proponentes da tecnologia CASE - especialmente os fornecedores que comercializam conjuntos de ferramentas caros - muitas vezes exageram na expectativa de que a nova abordagem será uma solução milagrosa que resolverá todos os problemas. Na realidade, essa tecnologia não pode fazer isso e se as organizações abordarem o CASE com expectativas irrealistas, inevitavelmente ficarão desapontadas.
Treinamento inadequado. Como acontece com qualquer nova tecnologia, o CASE requer tempo para treinar as pessoas no uso das ferramentas e para se familiarizar com elas. Os projetos CASE podem falhar se os profissionais não tiverem tempo adequado para treinamento ou se o primeiro projeto tentado com a nova tecnologia for altamente crítico para a missão e repleto de riscos.
Controle de processo inadequado. O CASE fornece novos recursos significativos para utilizar novos tipos de ferramentas de maneiras inovadoras. Sem a orientação e os controles adequados do processo, esses novos recursos também podem causar novos problemas significativos.

Languages

In other projects