Ambientes, conceitos - inf.puc-rio.brinf2135/docs/INF2135-Modulo05-Ambientes... · sobre requisitos de ambientes de engenharia de software assistidos por computador • Justificativa

1

Ambientes, conceitos

Arndt von Staa

Departamento de Informática

PUC-Rio

Março 2014

Mar 2014 2Arndt von Staa © LES/DI/PUC-Rio

Especificação

• Objetivos

– Identificar necessidades dos desenvolvedores e mapeá-las sobre requisitos de ambientes de engenharia de software assistidos por computador

• Justificativa

– O desenvolvimento e a manutenção de software são processos realizados por um conjunto de desenvolvedores cooperantes

– Ambientes de engenharia de software são sistemas que devem apoiar de forma adequada essas equipes

– Ambientes dependem do domínio do problema a resolver e do domínio da solução utilizada

– É necessário identificar os requisitos básicos do serviço a ser prestado por ambientes de engenharia de software assistidos por computador

• devem ser fortemente voltados para manutenção

2


Aceite a realidade como ela é

e não como você gostaria que fosse

Corolário: Examine como pessoas desenvolvem e mantêm software e apoie esta forma, ao invés de

impor um modo de trabalho artificial.


O que é desenvolver software ?

• Software é conhecimento adquirido gradativamente

– desenvolvimento de software é um processo de aprendizado

• aprende-se sobre o problema a resolver

• aprende-se sobre a solução sendo dada

– o desenvolvimento termina quando se aprendeu o suficiente

– a manutenção continua “para sempre”

• sempre aprendendo algo novo

• Consequência

– ao aprender alguma coisa nova sobre algum aspecto (serviço ou engenharia) do sistema a resolver, conhecimento já registrado pode ser invalidado

– ocorrerão alterações sucessivas mesmo enquanto se está desenvolvendo a versão 1

• Boehm, B.W.; “The Changing Nature of Software Evolution”; IEEE Software 27(4; 2010; pags 26-28

• Beck, K.; “The Inevitability of Evolution”; IEEE Software 27(4); 2010; pags 28-29

3


O que é manutenção?

• Correção versus evolução - manutenibilidade

– Correção visa – corrigibilidade

• viabilizar a recuperação rápida do trabalho produtivo

• eliminar defeitos e vulnerabilidades– de forma rápida

– sem gerar novos problemas

– distribuindo rapidamente a versão corrigida e implantável aos interessados

– Evolução visa – evolutibilidade

• possibilitar o atendimento a novos desejos dos usuários

• dar vida longa aos artefatos, adaptar a novos contextos

• integrar com outros sistemas

• algumas ações– engenharia reversa

– reengenharia: arquitetura, projeto, tecnologia usada, interfaces, ...

– rejuvenescimento: transferir de plataforma obsoleta para moderna


O que é manutenção? Por que se preocupar?

• Causas para a manutenção– Melhoria (evolutiva)

• modifica a funcionalidade do artefato

• velho 50% Linux 12% novo 65%

– Adaptativa [Schach et al, 2003] [Nosek & Palvia, 1990]

• modifica o artefato sem afetar a sua funcionalidade


– Corretiva• remove defeitos


– Perfectiva / outros• remove deficiências

• velho 5% Linux 1% novo --

• Schach, S.; Jin, B.; Yu,L.; Heller, G.Z.; “Determining the Distribution of Maintenance Categories: Survey

versus Measurement”; Empirical Software Engineering 8; Kluwer; 2003; pp 351–365

• Nosek, J.T.; Palvia, P.; “Software Maintenance Management: changes in the last decade”; Software

Maintenance: Research and Practice 2(3); 1990; pp 157-174

4


O que é manutenção? Atividades

• Tarefas a serem realizadas durante o uso (e do teste):– detectar: identificar que ocorreu uma falha (observar um erro)

• durante a execução algum interessado pode observar

• pode ser observado por instrumentos adicionados ao código

– diagnosticar: identificar corretamente o defeito a partir da falha• procurar a causa da falha

• logs, análise cuidadosa do código, ...

– depurar: eliminar completamente o defeito• sem adicionar novos

– testar: verificar se a nova versão do artefato satisfaz a sua nova especificação e/ou sua correção• teste de regressão: verificar se tudo que não foi alterado continua

operando corretamente

– (re)disponibilizar: tornar a nova versão disponível para os interessados

– (re)instalar (implantar): por a nova versão em operação

Terminologia

• Técnica: maneira, jeito, arte (grego: téchne) ou habilidade especial de executar ou fazer algo

– exemplo: tabela de símbolos usando hashing

• Método: série de passos através dos quais se atinge um objetivo, usualmente acompanhado de recomendações para evitar erros

– exemplo: como utilizar formulários de casos de uso para produzir uma especificação de requisitos funcionais

• Metodologia: estudo de uma coletânea de métodos interdependentes utilizada em determinada disciplina ou processo

– exemplo: como desenvolver software (o processo) utilizando a UML (coletânea de métodos interdependentes)

adaptado de Wikipedia inglês e português, e do Aurélio Eletrônico

Fev 2014 8Arndt von Staa © LES/DI/PUC-Rio

5

Ambientes - domínios

• Domínio da aplicação (ou do problema)– determina a natureza do serviço a ser prestado pelo sistema

• Domínio do artefato– formado pelo conjunto dos artefatos que constituem determinado

sistema

• Domínio da tecnologia (ou do suporte ao uso)– formado pelo conjunto de itens tecnológicos (ex. ferramentas,

componentes, redes, servidores, sistemas operacionais) necessários para o sistema poder prestar o seu serviço e ser controlado em uso

• Domínio da solução (ou do ambiente)– formado pelo conjunto de itens tecnológicos (ex. ferramentas,

linguagens, processos) necessários para desenvolver e manter o sistema

• Domínio de comunicação– formado pelo conjunto de itens de comunicação humana (ex.

linguagens, representações, documentos) necessários para que os envolvidos possam interagir adequadamente



Ambientes – domínios, exemplos

• domínio da aplicação

– software embarcado

– sistemas de informação

– sistemas de comando e controle

– . . .

• domínio da solução

– orientação a objetos

– orientação a agentes

– baseado em UML

– uso de uma variedade de scripting languages

– sistema operacional

– sistema de gerência de bases de dados (sql, nosql, ... )

– . . .

6


Ambientes - domínios , exemplos

• domínio de artefatos

– versões de: código de produção, manuais, especificações de serviço, especificações de engenharia, diagramas, scripts de teste, módulos dublê, scripts de reconstrução, planos, simulações, panfletos, sub-sistema de manutenção...

• domínio de desenvolvimento

– versões de: IDE, controlador de versões, acompanhamento de pendências (issue tracking), linguagens, compiladores usados, bibliotecas, dicionários de dados, ...

• domínio de comunicação

– versões de: linguagens de representação, padrões de layout, estilos, ontologias, dicionários de termos, ...


Ambientes - domínios

• O conjunto de domínios não é ortogonal– alterar alguma coisa em um dos 5 domínios pode provocar mudanças

nos outros

7


Ambientes

• Ambientes de engenharia de software

– são formados por um conjunto harmonioso de:• plataformas: software, hardware, rede

• processos– metodologias

• papéis a serem desempenhados por pessoas

• pessoas com níveis de proficiência– nem sempre têm o nível desejável

• ferramentas

• linguagens de representação

• bases de software

• bases de dados estatísticos

• ...

– destinam-se ao desenvolvimento e à manutenção sistemáticos de software possuindo qualidade assegurada

• destinam-se, ainda, à pesquisa em desenvolvimento de software


Ambientes

• Ambientes de engenharia de software devem apoiar todas as atividades efetuadas ao desenvolver software, i.e. devem apoiar processos definidos– especificar

– produzir documentação para o usuário final (manuais, help)

– arquitetar

– produzir documentação técnica

– projetar

– implementar

– produzir instaladores

– gerenciar os diferentes processos ou sub-processos

– controlar a qualidade

– evoluir artefatos

– corrigir artefatos

– . . .

8

Ambientes

• Ambientes devem poder ser configurados de modo a apoiar adequadamente

– o desenvolvimento do sistema em questão

– a tecnologia utilizada para a solução

– a arquitetura do sistema

– a manutenção do sistema

– ...


Ambientes

• O conjunto de ferramentas que compõem um ambiente

– pode ser integrado ou não

– pode apoiar desde algumas poucas a virtualmente todas as atividades

– deve ajudar de fato os desenvolvedores a produzirem e manterem os artefatos desejados


9

Perguntas

• Ambientes devem ser configurados para os domínios e para o processo definido

– isso implica uma relação um para um entre artefato e ambiente?

– como aumentar a chance de reuso?

– como facilitar a sintonia fina do ambiente com os objetivos a atingir?



Conjunto de ferramentas

Nível mínimo:

• Ambiente de desenvolvimento integrado (IDE – Integrated

Development Environment)

– Eclipse, Visual Studio, ...

• Sistema de controle de versões

– SVC, Subversion, GIT, ...

• Sistema automatizado para a reconstrução de programas

– make, gmake, ant, maven, ...

• Sistema de acompanhamento de problemas

– Bugzilla, Jira, ...

• Repositório compartilhado de artefatos aceitos

• Repositório de padrões, diretrizes e convenções

– html, ... Huizinga, D.; Kolawa, A.; Automated Defect Prevention: Best Practices in

Software Management; Hoboken, New Jersey: John Wiley & Sons; 2007

10



Nível intermediário

• Todas as do nível mínimo

• Sistema de gerência de requisitos

– acompanha a alteração de requisitos

– permite determinar o impacto de alterações

– rastreia os requisitos nos artefatos desenvolvidos

• Sistema de teste automatizado básico

– realiza o teste de módulos e componentes

– realiza o teste de regressão



Nível avançado

• Todos do nível intermediário

• Transformadores

– geram esqueletos a partir de diagramas

– geram esboços de módulos de teste

– geram artefatos intermediários incompletos

• Geradores

– geram artefatos completos prontos para serem utilizados

– geram módulos de teste prontos

– geram suítes de teste úteis, prontos para o uso automatizado

• Analisadores e medidores estáticos

– verificam propriedades de artefatos segundo regras definidas

• Teste automatizado avançado

11


• Não existem outras?

– medições estáticas

– refactoring automatizado

– ...

• Tão relevantes quanto as anteriores?



Risco inerente a ferramentas

A Fool with a Tool is still a Fool

• Ferramentas esperam um certo nível de formação, treinamento e maturidade (proficiência) por parte dos seus usuários

• Ferramentas são amplificadores de talento.

– se o usuário tiver mais talento (proficiência) do que o esperado, a ferramenta ajuda

– se o usuário tiver menos, a ferramenta atrapalha

Parker, L.; A Fool with a Tool is still a Fool; HP Open View; 2001 Buscado em: 2/mai/2007; URL:

http://www.parallon.com/a_fool_with_a_tool_is_still_a_fool.pdf

12


Representações

• Metáfora:

– papel eletrônico

• vinculado às linguagens de representação

• simples de usar

• simples de alterar

• clemente– perdoa erros de uso

– perdoa erros de decisão

– facilita a alteração do conjunto de representações

– facilita a verificação e a transformação assegurando a consistência do todo

• admite fazer vários rascunhos em sucessivos graus de completeza e formalidade

– esboços

• admite criar alternativas– admite selecionar uma entre várias alternativas

– admite selecionar alternativas após a elaboração


Representações

• Tarefas do processo criativo de uma representação:

– gerar um ou mais esboços (outline)

• escolher o esboço considerado mais adequado

– detalhar o esboço escolhido

– se necessário, retratar da escolha ou do detalhamento

– adicionar formalidade

– verificar, validar e aprovar a representação intermediária

• produzir laudos

– arrumar o formato e a estrutura das representações

• refactoring de baixo nível de intensidade

– completar com informações que permitam a localização

• referências cruzadas

• palavras chave, domínios, name spaces

– dar o acabamento final – diagramação, ortografia, sintaxe

– verificar, validar e aprovar a representação final

13


Representações

• Tarefas do processo de manutenção de uma representação– refletir a partir de uma ou mais representações (eng. reversa)– gerar um ou mais esboços de reengenharia

• refactoring de elevado nível de intensidade• escolher o esboço considerado mais adequado• transferir para as representações correlatas as alterações de

engenharia

– detalhar o esboço escolhido– se necessário, retratar da escolha ou do detalhamento– rever ou adicionar formalidade– verificar, validar e aprovar a representação intermediária– arrumar o formato e a estrutura das representações– completar com informações que permitam a localização– dar o acabamento final – diagramação, ortografia, sintaxe– verificar, validar e aprovar a representação final


Formalidade vs. abstração

Pouco MuitoFormal

Mu

ito

Po

uco

Ab

str

ato

processo

real

Requisitos

Código

Processo ideal

14

Etapas do processo de desenvolvimento


Concepção

Análise do domínio

Análise do processo

Especificaçãode requisitos

Modelagemconceitual

Arquitetura

Codificação

Projetofísico

Projeto lógico

Auditoria física

Conversão

Auditoria funcional

Instalação

CQ do sistema

CQ de construtos

Integração

CQ dasunidades

Criação/manutenção Integração

Base desoftware

Especificação

Projeto

Implementação

Teste

Disponibi-lização

Evolução


Evolução da abstração, código

Sistema

Programa

Componente

Arquivos, bases de dados,mensagens, plataformaalto

Linha de código

Bloco

Função

Módulo

Classe

Módulos de definiçãoheader files

Módulos de definiçãoAPI - Aplication program

interface

Elementos públicos(e protected)

Parâmetrosgeneralizados

Escopo visível

Escopovisível

Níveis deabstração

concreto

baixo

Interface típica

15

Usuário

Gerente

Cadastro deusuários autorizados

SistemaSis

Dados de usuárioautorizado

Dados de usuárioautorizado

Direitos de uso deusuário identificado

Solicitação dedireitos de uso

Direitos de uso

Identificação,Senha e Ação

Obter direitos de usode determinado

usuário autorizadoComponente da aplicação

Manter o cadastro deusuários autorizados

Configurador externo

Tabela de direitos de usodisponíveis para Sis

Direitos de usoselecionáveis por Sis

componente

sistema de gerência de usuários

• Arquitetura do subsistema Controle de Acesso

Mar 2014

Exemplo: Componente Controle de Acesso

Entidadesexternas

Processo

Depósitode dados

Fluxos dedados

Sistema ou agente

responsável

Arndt von Staa © LES/DI/PUC-Rio 29

30 Arndt von Staa ©

Mar 2014

Componente Login, máquina de estados

Fornecerdados

Trocar a senha

Fornecer identi-ficação alternativa

{ "Cancelar" }

Não autoriza uso

{ "OK" }

{ "Mudarsenha"}

{ "Esqueci senha" }

Emite nova senha

Autorizauso

Dados ebotão Validar

dados

{Erro}{ "Cancelar" }

Cadastrode usuáriosautorizados

Usuário

Controlarerros

Cancelar

{Erros demais}

{Até 3 erros}

{Erro léxico}

"OK" ou"Cancelar"

16


Características do desenvolvimento

Rep 1

Rep 6

Rep 3

Rep 4

Rep 5

Rep 2

Um sistema é engenheirado usando um conjunto de representações



Rep 1

Rep 6

Rep 3

Rep 4

Rep 5

Rep 2

Existe precedência entre representações, mas estas não precisam

estar necessariamente completas e aprovadas antes de prosseguir

interdependência

17



Rep 1

Rep 6

Rep 3

Rep 4

Rep 5

Rep 2

Operações sobre representações - ideal

alteração

transformaçãoadição

extração

geração

geração é uma forma extrema de transformação



Rep 1

Rep 6

Rep 3

Rep 4

Rep 5

Rep 2

Operações sobre representações - real

alteração


extração

reflexão

adição

reflexão

18



Rep 1

Rep 6

Rep 3

Rep 4

Rep 5

Rep 2

Operações sobre representações ciclo completo

alteração


consolidação

reflexão

extração


Macro operações sobre representações

• Adição• Extração• Modificação• Propagação (para frente)• Propagação reversa (reflexão)• Consolidação• Pesquisa (procura)• Reuso

– verbatim, as is, assim como está; através de referências

• Composição• Decomposição• Verificação

– correto com relação à especificação e aos padrões

• Validação– correto com relação aos demais artefatos

• Aprovação– correto segundo os interesses do usuário e do cliente

19


Exemplo de decomposição

Folha Pai

Folha Filho

Instância deimagem de ligação

Instância deobjeto de ligação

Ligação imagem

DFD


Grafo de transformação de linguagens

20


Interdependência de representações

Verificarpré requisitos

Históricoescolar

disciplinascursadas

disciplina,matrículasolicitadas

disciplinasaceitas

disciplinas sempré requisito

Representação 1

Verificarpré requisitos

Obterhistóricoescolar

Validar todasdisciplinassolicitadas

Validardisciplina

Representação 2

Históricoescolar

Semestre

Disciplinamatriculada

código nome professor

Representação 3

0..n

0..n

Representação 4

pHistorico = ObterHistorico( idAluno ) ;if ( pHistorico != NULL ){ for ( inxDisc = 0 ; … { ...


Navegação entre representações

21


Mecânica do processo de navegação

Dictionary

Object A

Definition

Rules

Rep I

Object A

Rep J

Object A

Rep K

Object A

Rep L

Object A

Select targetrepresentation

With focus on source objectdisplay representation using rules


Visão abrangente das funcionalidades

• Meta-Ambiente de Engenharia de Software

– baseia-se em um dicionário de dados (Ontologia?)

– estou desenvolvendo...

Test caseselectioncriterion

Test log &findings

Interfacesketch

Generatetest cases

Specifier&

Reviewer

Externalspecification

Developcomponent

models

Performstatic

analysis

Designinterface

Interactwith other

components

Specificationmark up

Manualtest cases

Automatedtest scripts

toolData dictionary

/ onthology

SWB

Developcomponent

Testcomponent

Component

SWB

Other datadictionaries

22


Estado de progresso do processo proposto

Test toolspecification

Boundaryconditionscriterion

Test caseselectioncriterion

Test log &findings

Test scriptgenerator

Test casegenerator

Automatedtest scripts

Testcases

XML

Architect

Designer

Interfacedesigner

Developer

Marked upuse cases

Interfacesketch

Decisiontable

generator

Specifier&

Reviewer

Standard use cases

Decisiontables

XMLDecisiontableeditor

Typed deci-sion tables

XML

UserInterface

Statemachines

XMLStatemachine

editor

Designuser

interface

Mark upuse cases

Boundaryconditions

adder

XML

Performabletest cases

Manualtest cases

Format & print

tool

Datadictionary

SWB

Developartifact

Testartifact

Artifact

Modelo: máquinas de estado + tabelas de decisão;

derivadas de casos de uso por característica (feature)

Essential

problem


Características da solução proposta

Problemas observados

• Diversos trabalhos publicados envolvem a criação ou extensão de

– Linguagens de representação

• as existentes não se adéquam a necessidades específicas– dialetos (adaptações a algum domínio)

– linguagens totalmente novas

– Processos e metodologias

• Workflow

– Geradores de artefatos

– Transformadores

– Verificadores formais (ou quase :)

• analisadores estáticos

– Medidores

• estáticos: identificam “bad smells”

23



• Precisamos:

– Meta-editores para algumas poucas famílias de linguagens

• várias (muitas) instâncias de linguagem por família

• ambiente para a meta-programação

– Verificadores programáveis

• verificar modelos

• verificar representações

• analisadores estáticos

• medidores estáticos (“smell checkers”)

– Transformadores programáveis

• transformar de uma representação para outra

• Interfaces XMI, XML, MDL e outros

– Geradores

• geradores parciais de código ou documentação

• geradores de suítes de teste



• Precisamos ainda:– Fidedignidade

• da ferramenta em si

• do produto criado e mantido com o apoio da ferramenta

– Portatilidade• operar em diversas plataformas

– Distributividade• ferramenta operando em diversas máquinas e organizações ao

desenvolver/manter um mesmo sistema

– Desempenho que não incomode os desenvolvedores

– Baixo custo• o problema maior é a institucionalização da ferramenta

– Longevidade, manutenibilidade do produto• os sistemas desenvolvidos com a ferramenta serão mantidos com ela

• o custo de converter para outras ferramentas pode ser excessivamente alto

24


Requisitos pétreos ☺☺☺☺

• Hiper-documento

– distribuído

– distributível

– editável a partir de qualquer ponto

• Integração total entre as representações

• Transformação, no extremo: geração

– geração de esqueletos de representações

– propagação e reflexão de alterações

• Rastreabilidade

– controle de integridade intra e inter-representação

• Verificabilidade, validabilidade, aprovabilidade

– modelos formais ou quase (suficientemente?) formais

– geração quase automática de testes automatizados


Requisitos pétreos

• Apoiar a incorporação de domain specific languages (DSL)

• Apoiar a evolução dos sistemas objetivo

– desenvolvimento incremental

– desenvolvimento em qualquer ordem

• Suporte à engenharia reversa, à reengenharia e ao rejuvenescimento

– refactoring de alto nível de intensidade

– desenvolvimento em qualquer ordem

• Gerência de configuração embutida

– capaz de navegar entre versões

– capaz de observar ou transformar diferenças de versões

25


Requisitos pétreos

• Geração e manutenção de representações

– código em variadas linguagens

– diagramas

– textos

– textos compostos

• Criação e/ou adaptação das linguagens de representação

– ao domínio da aplicação – DSL

– à tecnologia usada, e.g. agentes, aspectos, OO puro, ...

– à cultura local

– às demais ferramentas do ambiente

• exportadores

• importadores

• XMI


Requisitos altamente desejáveis

• Integração com ferramentas de terceiros

– plug-ins ?

– sob eclipse, visual studio, QT creator, ...?

• Integração de componentes

– gerados por terceiros

• Distribuição de componentes

• Capacidade de estender frameworks

– identificar os hot-spots e associar regras e dicas a eles

• Capacidade de internalizar sistemas legados

– engenharia reversa

26


Esquema de geração a partir de modelos

• OMG propõe uma estrutura:

– PIM – modelo independente de plataforma

• nível de especificação em que se focaliza principalmente o negócio – o “o que” – a ser tratado

• modelo conceitual

– PSM – modelo dirigido para uma plataforma específica

• nível de especificação em que são representadas a forma específica de implementar

• arquitetura

• modelo físico

• seria interessante poder gerar pelo menos parcialmente esse nível

– Nível de implementação

• em que o código é adicionado ou completado


Estrutura meta – MOF/OMG

� OMG-Meta Object Facility, v1.4

27


Processo de desenvolvimento

• Assertion driven development adaptado

1. para todas as estruturas redigir um verificador estrutural (verificador de assertiva invariante) completo

• verificar a completeza do verificador ao testar: teste baseado em mutantes

• criar uma versão capaz de verificar somente o que está em memória: viabilizar a verificação "over the shoulder"

2. inserir assertivas de entrada

• parâmetros

• variáveis do objeto requeridas pelo método

3. se necessário inserir (marcar para ser gerado) trace seletivo e trace seletivo da pilha de execução (C++)

4. incorporar ao teste chamadas para o verificador estrutural

5. para estruturas extensas adicionar geração aleatória de dados


Algumas perguntas a responder

• Desenvolvimento dirigido por modelos

– traz vantagens?

• quais?

– pode-se desenvolver e depois manter / evoluir?

– é fácil / difícil de institucionalizar?

• por que?

– como é que ficam os sistemas legados?

• o sistema que você terminou de desenvolver hoje, amanhã já é um sistema legado �

• quanto custa internalizar um sistema legado?– uma grande parte dos sistemas em uso hoje são legados

– muitos ainda usam COBOL ou FORTRAN

• vale a pena reengenheirar sistemas legados?

28



• Ambientes integrados e baseados em modelos contribuem para a redução do custo do desenvolvimento e da manutenção?

– quanto?

• Ambientes integrados contribuem para o aumento da produtividade?

– quanto?

• Ambientes integrados contribuem para o reduzir o time to

market?

– quanto?

• Ambientes integrados adéquam-se a processos ágeis?

• Os custos de aquisição e de institucionalização são menores do que os benefícios (ganhos)?



• Por que é difícil encontrar meta-ambientes?

– só conheço um: meta-edit da MetaCase http://www.metacase.com• mesmo assim é pouco difundido

• Será por

– falta de domínio da tecnologia?

– custo para desenvolver?• software aberto (bazar) resolve ?

– tempo para desenvolver?

– complexidade?

– conflito com o publish or perish em voga nas universidades?

– custo de instanciação e de institucionalização?

– tamanho do mercado potencial?

– reduzida fatia do mercado que compraria?

– processo de comercialização?

– . . .

29



• Ao invés de ambientes que tal a solução tradicional?

– coletâneas de ferramentas

– padronização da interface entre ferramentas

• XML

• XMI

– ontologias (dicionários de dados)

• independentes

• interdependentes com as ferramentas

• bancos de dados orientados a objetos (noSQL) com interface padronizada

– para Java existe uma coletânea de ferramentas e de plugins para Eclipse

• esta solução é realmente boa?

• poderia ser transferida para outras linguagens de programação?



• Quadro branco mais máquina fotográfica digital seria uma boa alternativa para a documentação técnica?

– arquitetura

– design

• Quadro branco inteligente mais tablet computer seria melhor?

– vale a pena?

30


Bibliografia

• ter Hofstede, A.H.M.; Verhoef, T.F.; "Meta-CASE: Is the Game Worth the Candle?"; Information Systems Journal 6; Blackwell Science; 1996; pags 41-68

• Brown, A.W.; Earl, A.N.; McDermid, J.A.; Software Engineering Environments: Automated Support for Software Engineering; New York, NY: McGraw Hill; 1992

• Costagliola, G.; Deufemia, V.; Ferrucci, F.; Gravino, C.; “Constructing Meta-CASE Workbenches by Exploiting Visual Language Generators”; IEEE Transactions on Software Engineering 32(3); Los Alamitos, CA: IEEE Computer Society; 2006; pags 156-175

• Emmerich, W.; Schafer, W.; Welsh, J.; “Databases for Software Engineering Environments - The Goal has not yet been attained”; Proceedings of the 4th European Software Engineering Conference, Garmish-Partenkirchen, Germany; 1993; pags 145-162


Bibliografia

• Guedes, L.C.; Staa, A.v.; “Um processo de reengenharia econômico e eficaz”; 7o. SBES Simpósio Brasileiro de Engenharia de Software; Porto Alegre, RS: Sociedade Brasileira de Computação; 1993; pags 77-91

• Huizinga, D.; Kolawa, A.; Automated Defect Prevention: Best Practices in

Software Management; Hoboken, New Jersey: John Wiley & Sons; 2007

• MetaCase; MetaEdit+; Http://www.metacase.com ; Ylistönmäentie 31, FIN-40500 Jyväskylä, Finland

• MetaObjectFacility(MOF) Specification; OMG; 2002

• Staa, A.v.; Overview of the Talisman Version 5 Software Engineering Meta-

Environment; preliminary version

• Staa Informática; Ambiente de Engenharia de Software Assistido por

Computador - TALISMAN, Versão 4.3; Rio de Janeiro: Staa Informática Ltda, 1993. www.inf.puc-rio.br/~arndt aba projetos

Documents

Ambientes, conceitos - inf.puc-rio.brinf2135/docs/INF2135-Modulo05-Ambientes... · sobre requisitos de ambientes de engenharia de software assistidos por computador • Justificativa