Projeto: Desenvolvimento Fortemente Apoiado por Computador Arndt von Staa Departamento de...

Projeto: Desenvolvimento Fortemente Apoiado por Computador

Arndt von Staa

Departamento de Informática

PUC-Rio

Abril 2010

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

• Objetivos

– Desenvolver um meta-ambiente de engenharia de software assistido por computador

•Área: Model driven development

• Justificativa

– O desenvolvimento e a manutenção de software são parte de um único processo realizado por equipes, possivelmente distribuídas, de desenvolvedores que também evoluem no tempo

– 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 i.e. a tecnologia utilizada na solução

Arndt von Staa © LES/DI/PUC-Rio

Especificação do seminário

Objetivo principal de ambientes de ES

• Ambientes de engenharia de software assistidos por computador devem apoiar efetiva e eficazmente

– os diferentes papéis ao

• desenvolver

• manter

• co-evoluir

– variados domínios de problema

– variados domínios de solução

– a criação, a evolução e o uso dos diferentes artefatos que compõem sistemas intensivos em software

• possibilitando a adaptação e o uso das tecnologias que melhor se adéquam ao problema a resolver

Mar 2010 4 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Ambientes

• Ambientes de engenharia de software

– são formados por um conjunto harmonioso de:

• processos => organização do trabalho

• papéis a serem desempenhados por pessoas

• pessoas com níveis de proficiência adequados aos seus papéis

– nem sempre possuem a proficiência desejável

• ferramentas de diversas procedências => apoiam as práticas

• metodologias => variedade de métodos formando um todo coerente

• linguagens de representação => apoiam métodos

• plataformas: software, hardware, rede

• bases de dados estatísticos

• bases de software

• . . .

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

Mar 2010 5 Arndt von Staa © LES/DI/PUC-Rio

Parêntesis

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

– Correção e perfecção visa – corrigibilidade

• viabilizar a recuperação rápida para retornar ao trabalho produtivo

• eliminar defeitos, vulnerabilidades e insuficiências de desempenho

– de forma rápida

– sem gerar novos problemas

– distribuindo e implantando rapidamente a versão corrigida aos interessados

– Evolução e adaptação visa – evolutibilidade

• dar vida longa aos artefatos

• possibilitar o atendimento a novos desejos dos usuários

• integrar com outros sistemas imprevistos e possivelmente externos

• exemplos de ações

– engenharia reversa

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

– rejuvenescimento: transferir de plataforma obsoleta para moderna

Mar 2010 6 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Características do desenvolvimento

Rep 1Rep 6

Rep 3

Rep 4

Rep 5

Rep 2

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

Mar 2010 7 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Representações formam um sistema

Rep 1Rep 6

Rep 3

Rep 4

Rep 5

Rep 2

Representações formam um sistema, operações sobre representações

alteração

transformaçãoadição

consolidação

reflexão

extraçãooperações

precedência“natural”

refle tir e laborar

m odificar

adicionar extra ir

i-1 i i+1

Mar 2010 8 Arndt von Staa © LES/DI/PUC-Rio 8 Arndt von Staa © LES/DI/PUC-Rio

Representações - criação

• Tarefas do processo criativo de uma representação

– entender o problema e 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 aceitar a representação, intermediário

• 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

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

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

Mar 2010 9 Arndt von Staa © LES/DI/PUC-Rio 9 Arndt von Staa © LES/DI/PUC-Rio

Representações, manutenção

• Tarefas do processo de manutenção de uma representação– engenharia reversa: gerar reflexões a partir de uma ou mais

representações subsequentes – gerar um ou mais esboços da 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 aceitar a representação, intermediário– arrumar a estrutura e o formato das representações– completar com informações que agilizem a localização– dar o acabamento final – diagramação, ortografia, sintaxe– verificar, validar e aprovar a representação, final

Mar 2010 10 Arndt von Staa © LES/DI/PUC-Rio

Etapas do processo de desenvolvimento

C oncepção

Análise do dom ínio

Análise do processo

Especificaçãode requisitos

M odelagemconceitua l

A rquite tura

C odificação

Projetofís ico

Projeto lóg ico

Auditoria fís ica

C onversão

Auditoria funcional

Insta lação

C Q do sistem a

C Q de constru tos

Integração

C ontro le da qualidadedas unidades

C riação/m anutenção Integração

Base desoftw are

Staa, A.v.; Programação Modular; Rio de Janeiro: Campus; 2000; capítulos 2 e 10

Especificação

Projeto

Programação

Teste

Disponi-bilização

EvoluçãoOperação

Mar 2010 11 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Evolução da abstração

Especificaçãode requisitos

Especificaçãode requisitos

Especificaçãode requisitos

M odelagemconceitual

M odelagemconceitual

M odelagemconceitual

A rquiteturado sistem a

Arquiteturado program a

Arquiteturado m ódulo

S ISTEM A PRO G RAM A M Ó DU LO

Projeto

Im plem entação

Corolário: representações são transformadas para nível de abstração mais baixo. Neste novo nível são necessariamente adicionados detalhes.

Test toolspecification

Boundaryconditions

criterion

Test caseselectioncriterion

Test log &find ings

Test scrip tgenerator

Test casegenerator

Autom atedtest scripts

Testcases

XM L

Architect

D esigner

Interfacedesigner

D eveloper

M arked upuse cases

Interfacesketch

D ecis iontable

generator

Specifier&

R eview er

Standard use cases

D ecis iontables

XM LD ecisiontableeditor

Typed deci-s ion tables

XM L

U serInterface

Statem achines

XM LStatem achine

editor

D esignuser

interface

M ark upuse cases

Boundaryconditions

adder

XM LPerform able

test cases

M anualtest cases

Form at & prin t

too l

D atadictionary

SW B

D evelopartifact

Testartifact

A rtifact

Mar 2010 12 Arndt von Staa © LES/DI/PUC-Rio

Uma possível arquitetura

alguma forma de

especificarfoco em automação dos testes

Mar 2010 13 Arndt von Staa © LES/DI/PUC-Rio

Representações: navegação entre elas

D ictionary

O bject A

D efin ition

R ules

R ep I

O bject A

R ep J

O bject A

R ep K

O bject A

R ep L

O bject A

Select targetrepresentation

W ith focus on source objectd isp lay representation using ru les

Representações não existem, existem regras para renderizar viewports delas,as regras podem variar (quase) dinamicamente

Mar 2010 14 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Interdependência de representações

Verificarpré requis itos

H istóricoescolar

d iscip linascursadas

discip lina,m atrícu la

solic itadas

discip linasaceitas

discip linas sempré requis ito

R epresentação 1

Verificarpré requis itos

O bterh istóricoescolar

Validar todasdiscip linassolic itadas

Validard iscip lina

R epresentação 2

H istóricoescolar

Sem estre

D iscip linam atriculada

código nom e professor

R epresentação 3

0..n

0..n

R epresentação 4

pH istorico = O bterH istorico( idA luno ) ;if ( pH istorico != N U LL ){ for ( inxD isc = 0 ; … { ...

Mar 2010 15 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Linguagens de representação

Mar 2010 16 Arndt von Staa © LES/DI/PUC-Rio

U suário

G erente

C adastro deusuários autorizados

S istem aSis

D ados de usuárioautorizado

D ados de usuárioautorizado

D ire itos de uso deusuário identificado

Solic itação dedire itos de uso

D ire itos de uso

Identificação,Senha e Ação

O bter d ire itos de usode determ inado

usuário autorizadoC om ponente da aplicação

M anter o cadastro deusuários autorizados

C onfigurador externo

Exemplo: Componente Controle de Acesso

• Fluxo de dados do componenteFalta alguma coisa?

Mar 2010 17 Arndt von Staa © LES/DI/PUC-Rio

Componente Login, máquina de estados

Fornecerdados

Trocar a senha

Fornecer identi-ficação a lternativa

{ "C ancelar" }

N ão autoriza uso

{ "O K" }

{ "M udarsenha"}

{ "Esquecisenha” }

Em ite nova senha

Autorizauso

Dados ebotão Validar

dados

C ontro larerros

{ Q uarto oum ais erro }

{ "C ancelar" }

C adastrode usuáriosautorizados

U suário

S istem aSis

{erro}{1o. a 3o.erro}

{erro}

Mar 2010 18 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Componente login: caso de uso parcial

Caso de uso Efetuar login – estado fornecer dados

Resumo O usuário fornece os dados de identificação para usar o sistema XXX segundo um dos modos de usar registrados

Ator principal Sistema XXX

Pré condição O sistema XXX ativou o componente LoginO cadastro de usuários autorizados está atualizado, disponível e criptografado segundo chave interna ao sistema XXX

Descrição 1. O usuário digita a identificação e senha lexicamente corretas 2. O usuário digita corretamente os caracteres de controle3. Quando o usuário teclar “OK” então 3.1 O componente Login ativa o estado “Confirmar usuário” Fim quando4. Quando o usuário teclar “Mudar senha” então 4.1 O componente Login ativa o estado “Trocar a senha”Fim quando

Mar 2010 19 Arndt von Staa © LES/DI/PUC-Rio

Exemplo: Conversão para texto mark-up

Texto inicial1. O usuário digita a sua identificação lexicamente correta

Texto mark-up1. O <usuário @ Pessoa : Usuario> <digita @ Ação :

EntrarDados( Usuario, idUsuario)> a sua <identificação @ Attributo : IdUsuario> <lexicamente correta @ Regra : SintaxeIdUsu, Define( SintaxeIdUsu, idUsuario)>

Conteúdo resultante no dicionárioPessoa: idUs( string:“usuário” , Rel:idED<-idIdU , Rel:idAt<-idIdU)Atributo:idIdU( string:“identificação” , Rel:idSintx<-idSinxIdU ,

Rel:idUsus<-idUs)Ação: idED( string: “digita” , Rel: idAtor<-idUs , Rel: idAt<-idIdU)Regra: idSinxIdU( string: “lexicamente correta” , Rel: idAt<-idIdU)

Texto armazenado a ser renderizado sempre que for exibido1. O <#idUs> <#idED> a sua <#idIdU> <#idSinxIdU>.

Mar 2010 20 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Arquitetura abrangente

Instancebuilder

M etaenvironm ent

M etaenvironm ent

M etaenvironm ent

Environm entbuilder ro le

Pro jectm anager

U serro le

U serro le

Feedback

M eta defin itionbase

D FB

D efin itionbase

D FB

D efin itionbase

D FB

Environm entbase

SW B

SW B SW B

PR B

Param eterbase

PR B

Param eterbase

PR B

Param eterbase

M TB

G lobal m etricsbase

M TB

Local m etricsbase

M TB

Local m etricsbase

Softw arebase

Softw arebase

Mar 2010 21 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Arquitetura: conjunto de meta-editores

Fore igntools

D iagrameditor

D ia log

Texteditor

Internaltoo ls

Structureeditor

D ictionaryeditor

R epresentationlanguagedefin ition

D iagram s

E lem ents

Thingdictionaries

D iagram defin ition

D ia log defin ition

Text defin ition

Structure defin ition Structura lre lations

ThingsE lem entsR elations

ThingsE lem entsR elations

Tool defin ition

D FB

D efin itionbase

BSW

R epository

Mar 2010 22 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Componentes de um meta-editor

R epositoryschem a

Form attingru les

Assem blyru les

Form at Assem ble R etrieve

Editingru les

Validationru les

D isassem blyru les

Edit / brow se Validate D isassem ble Store

W orkspaceschem a

In teraction layerP rocessing

layer Persistence layer

C oncreterepresentation

Mar 2010 23 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Arquitetura de um meta-editor

Determ inaração

Efetuaração 1

E fetuaração 2

E fetuaração n

Com ponente in terpretador M ódulo cliente

Função cliente

Funções Call back

Serviço 1( ... )Serviço 2( ... )

...Serviço k( ... )

In terfacecall back

Interface

Tabelainterpretável

( IdServico ,RefC allBack )

+Strategy

TradutorTabelafonte

Mar 2010 24 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Meta-editor diagramas

O bter dados

2.1

João

área ocupada

100

30

Vídeo (Folha)

Base de defin ição

Carim bo de: processo

M oldura:

Cam po 1: A liás 3 m oldura _________Cam po 2: Nom eCam po 3: Relação Agentes m oldura _________

D im ensões: 12 x 8

D iagram a F luxo de Dados Nom e: xxx

Instância de: processo P rocesso: 123 Posição: 30 100

Base de softw are

Processo: 123

Nom e: "O bter dados" A liás 3: 2 .1 Relação Agentes: João M aria José

Mar 2010 25 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Meta-especificação em 3 níveis

Param eter baseschem a

Software base schem a

Defin ition base schem a

Label

Link

Adornm ent

Instance 2 n

n

1

n

1

Labelclasses

Linkclasses

Adornm entclasses

Instanceclasses

linkrules

label ru les ornam ent ru les

belongs to obeys

Software basestatic schem a

Defin ition basestatic schem a

Mar 2010 26 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Especificação da linguagem “modular C++”

M ódulo

Função

BlocoD ecom põe

C om põe

D adoD ecom põe

C om põe

C lasseH erdada por

H erda de

M ódulo

TipoFunção

Função

B loco

C ham a

C ham ada

Tipo

D ado

D ado

U sado

U sa

Tipo

M ódulo

TipoD ado

M ódulo

Program a

Sobre-carrega

Sobre-carregado

R edefine

R edefin ido

U tiliza

U tilizado por

M ódulo

Função

C liente

Servidor

Projeto

Im plem entação

referencia

referenciada

Hiper-objeto

• idHiperObjeto

– Descritor hiper-objeto: idClasse

– Nome principal: string

– Nome código Java: string

– Descrição: texto

– Instanciado: <idObj1.diag , idInst><idObj2.diag , idInst>...

– Relação a : idObj3 , idObj4 ...

– Relação b : <idObj5 , idInst1><idObj6 , idInst2> ...

– Especificação formal: texto

– ...

• Estrutura da chave dos objetos de programação

– <idHiperObjeto, idInstancia , idTipo , idAtributo , idVersão>

Mar 2010 27 Arndt von Staa © LES/DI/PUC-Rio

Mar 2010 28 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Repositório lógico elementar

R elationtypes

N am e

D ictionary

n

O bjectn

Boundedstring

U nboundedstring

Sim pletext

M arkuptext

B inaryre lation

Ternaryre lation

M apping

Link

O thertypes

Property

1

n

Abstractsyntaxgraph

R elationaltext

U serdefined 1

U serdefined n

U serdefined 2

Table

n

entre classes definidas

entre classes quaisquer

gráfico

texto contendo referências

entre classes definidas

Repositório físico persistente

Elem entode dados

E lem entoestrutura l

Páginara iz

Páginalivre

Páginalista

Página

Páginade dados

Páginaestrutura l

F ilho

Ant

Prox

Prox

Pai

M axChaves/2.. M axC haves

0..M axChaves

R eferênciaa lista

Página listade listas

0..M axListas

R eferênciaa BTR EE

Páginaorigem

N um Btrees

1..M axDados

Base de persistência é um simulador de memória virtual segmentada

âncora

Mar 2010 30 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Colaboração, visão simplificada

N etw ork

Shareddatabases

SW B

SW BSW BSW BSW B

Localdatabases

Localdatabases

D ifferentia ldatabases

D ifferentia ldatabases

Environm entinstance

Environm entinstance

D atabaseintegrator

Environm entserver

W orkstation W orkstation

Mar 2010 31 Arndt von Staa © LES/DI/PUC-Rio

Distribuição de bases de software

D eveloper 1 D eveloper 3D eveloper 2

In terconnection linkUsage link

O rganization A O rganization B

Mar 2010 32 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Processo de teste

M odule under test

M odule under test

Already developedand accepted

application m odules

Consoledriver C++

(m ain)

G enerictester

Specifictester

Testscrip t

ApplicationJava or C++

Com ponentAPI

Leakagecontro l

Counter

Testsupport

Com m andreader

C losed C++com ponent

O R

Utilitiesand run

tim esupport

Mar 2010 33 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Processo de teste

D efine test com m and

syntax

Im plem enttest com m and

interpretersW rite scrip t Perform

test

G eneratecom m and table

and docum entation

w hile m ore to be tested

Test is com pleteand accepted

D efin itionm odule

Im plem entfunctions to be

tested

G eneratetest m odule

skeleton

Perguntas?

Arndt von Staa

arndt@inf.puc-rio.br

Departamento de Informática

PUC-Rio

Abril 2010

Anexo: Requisitos básicos

Mar 2010 36 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Requisitos pétreos

• Precisamos de, entre outras, as funcionalidades:

– Meta-editores para algumas famílias de linguagens

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

• ambiente para a meta-programação

– Verificadores programáveis

• verificar representações e modelos

• validar conjuntos de representações

• analisadores estáticos

• medidores (“smell checkers”)

– Transformadores programáveis (bi-direcionais)

• transformar de uma representação para outra

• Interfaces XMI, XML, MDL e outros

– Geradores

• geradores (compositores) de código ou documentação

• geradores de suítes de teste

Mar 2010 37 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Requisitos pétreos

• Precisamos ainda:– Fidedignidade

• da ferramenta em si

• do produto criado e mantido com o apoio da ferramenta

– Portatilidade• a ferramenta deve poder operar em diversas plataformas

– Distributividade• desenvolvimento colaborativo em diversas máquinas e organizações

– 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

Mar 2010 38 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Requisitos pétreos

• Hiper-documento

– distribuído

– distributível

– edição em qualquer representação é visível nas outras

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

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

– criação e manutençã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

– modelos formais ou quase (suficientemente?) formais

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

Mar 2010 39 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Requisitos pétreos

• 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

• de baixo nível de intensidade

• Gerência de configuração embutida

– capaz de navegar entre versões

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

Mar 2010 40 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Requisitos pétreos

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

– código interdependente em variadas linguagens

– diagramas

– textos compostos

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

– ao domínio da aplicação

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

– à cultura local

– às demais ferramentas do ambiente

• exportadores

• importadores

• XMI

Mar 2010 41 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Requisitos altamente desejáveis

• Integração com ferramentas de terceiros

– plug-ins ?

– sob eclipse?

• 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

Anexo: Perguntas de pesquisa

Mar 2010 43 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

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 ao ambiente de desenvolvimento?

• vale a pena?

Mar 2010 44 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Algumas perguntas a responder

• Ambientes integrados 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)?

Mar 2010 45 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Algumas perguntas a responder

• Ambientes instanciados apóiam eficazmente

– o desenvolvimento incremental?

– engenharia reversa e reengenharia (refactoring) em larga escala?

– processos de desenvolvimento de software específicos?

• CMMI

• SPICE

• MPS.br

• Métodos ágeis

• . . .

Mar 2010 46 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Algumas perguntas a responder

• Pode-se instanciar ambientes para

– aproveitar frameworks existentes?

– gerar código completo compilável?

– reutilizar quaisquer artefatos, ou parte deles?

• especificação

• arquitetura

• frameworks

• design patterns

• componentes

• projetos

• código

• teste

• documentação para o usuário

• . . .

Mar 2010 47 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Algumas perguntas a responder

• Ao invés de ambientes integrados que tal:

– coletâneas de ferramentas

– padronização da interface entre ferramentas

• XML

• XMI

• outros

– ontologias (dicionários de dados)

• independentes

• interdependentes com as ferramentas

• bancos de dados orientados a objetos com interface padronizada

Mar 2010 48 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Algumas perguntas a responder

• Quadro branco mais máquina fotográfica digital seria uma boa alternativa?

• Quadro branco inteligente mais tablet computer seria melhor?

• “Manuscrito para string e para diagrama” seria ainda melhor?

– vale a pena?

Mar 2010 49 Arndt von Staa © LES/DI/PUC-Rio Arndt von Staa © LES/DI/PUC-Rio

Algumas perguntas a responder

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

– se o usuário tiver mais, a ferramenta ajuda

– se o usuário tiver menos a ferramenta atrapalha

• Como promover a formação e o treinamento necessários?

• Como reduzir o risco de estar desenvolvendo shelfware?

• Ferramentas são amplificadores de talento.

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

Perguntas?

Arndt von Staa

arndt@inf.puc-rio.br

Departamento de Informática

PUC-Rio

Abril 2010