Projeto: Desenvolvimento Fortemente Apoiado por Computador Arndt von Staa Departamento de...
Transcript of 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
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