Projeto: Desenvolvimento Fortemente
Apoiado por Computador
Arndt von Staa
Departamento de Informática
PUC-Rio
Abril 2010
Especificação do seminá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
Mar 2010
Arndt von Staa © LES/DI/PUC-Rio
2
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
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
Arndt von Staa © LES/DI/PUC-Rio
4
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
Arndt von Staa © LES/DI/PUC-Rio
5
Características do desenvolvimento
Um sistema é engenheirado usando um conjunto de representações
Rep 2
Rep 4
Rep 6
Rep 1
Rep 3
Mar 2010
Rep 5
Arndt von Staa © LES/DI/PUC-Rio
6
Representações formam um sistema
Representações formam um sistema, operações sobre representações
alteração
adição
transformação
Rep 2
reflexão
Rep 4
consolidação
Rep 6
Rep 1
Rep 3
Rep 5
extrair
adicionar
operações
precedência
“natural”
extração
i-1
refletir
i
elaborar
i+1
modificar
Mar 2010
Arndt von Staa © LES/DI/PUC-Rio
7
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
Arndt von Staa © LES/DI/PUC-Rio
8
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
Arndt von Staa © LES/DI/PUC-Rio
9
Etapas do processo de desenvolvimento
Evolução
Operação
Base de
software
Concepção
Auditoria física
Análise do processo
Especificação
Conversão
Análise do domínio
Auditoria funcional
Especificação
de requisitos
Disponibilização
Instalação
Modelagem
conceitual
CQ do sistema
Arquitetura
CQ de construtos
Projeto
Integração
Projeto lógico
Projeto
físico
Teste
Controle da qualidade
das unidades
Programação
Codificação
Criação/manutenção
Integração
Staa, A.v.; Programação Modular; Rio de Janeiro: Campus; 2000; capítulos 2 e 10
Mar 2010
Arndt von Staa © LES/DI/PUC-Rio
10
Evolução da abstração
SISTEMA
PROGRAMA
MÓDULO
Especificação
de requisitos
Especificação
de requisitos
Especificação
de requisitos
Modelagem
conceitual
Modelagem
conceitual
Modelagem
conceitual
Arquitetura
do sistema
Arquitetura
do programa
Arquitetura
do módulo
Projeto
Implementaçã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.
Mar 2010
Arndt von Staa © LES/DI/PUC-Rio
11
Uma possível arquitetura
Specifier
&
Reviewer
alguma
forma de
especificar
Standard
use cases
Interface
sketch
Interface
designer
Design
user
interface
User
Interface
Architect
foco em automação dos testes
Mark up
use cases
Marked up
use cases
SWB
Data
dictionary
Test case
generator
State
machine
editor
Designer
XML
Typed decision tables
Decision
table
generator
Test case
selection
criterion
XML
Decision
table
editor
Decision
tables
Develop
artifact
Artifact
Developer
XML
Test
cases
Test
artifact
Boundary
conditions
adder
XML
Performable
test cases
Test script
generator
Format & print
Boundary
conditions
criterion
Mar 2010
XML
State
machines
Manual
test cases
tool
Automated
test scripts
Test log &
findings
Test tool
specification
Arndt von Staa © LES/DI/PUC-Rio
12
Representações: navegação entre elas
Definition
Representações não existem, existem
regras para renderizar viewports delas,
as regras podem variar (quase)
dinamicamente
Rules
Select target
representation
With focus on source object
display representation using rules
Rep I
Rep J
Rep K
Rep L
Object A
Object A
Object A
Object A
Dictionary
Object A
Mar 2010
Arndt von Staa © LES/DI/PUC-Rio
13
Interdependência de representações
Representação 1
disciplina,
matrícula
solicitadas
disciplinas
aceitas
Verificar
pré requisitos
disciplinas
cursadas
Representação 2
disciplinas sem
pré requisito
Verificar
pré requisitos
Obter
histórico
escolar
Histórico
escolar
Validar todas
disciplinas
solicitadas
Validar
disciplina
Representação 3
Histórico
escolar
Representação 4
0..n
Semestre
0..n
Disciplina
matriculada
pHistorico = ObterHistorico( idAluno ) ;
if ( pHistorico != NULL )
{
for ( inxDisc = 0 ; …
{
...
código nome professor
Mar 2010
Arndt von Staa © LES/DI/PUC-Rio
14
Linguagens de representação
Mar 2010
Arndt von Staa © LES/DI/PUC-Rio
15
Exemplo: Componente Controle de Acesso
Falta alguma coisa?
• Fluxo de dados do componente
Dados de usuário
autorizado
Manter o cadastro de
usuários autorizados
Configurador externo
Gerente
Dados de usuário
autorizado
Cadastro de
usuários autorizados
Sistema
Sis
Mar 2010
Solicitação de
direitos de uso
Direitos de uso de
usuário identificado
Obter direitos de uso
Identificação,
de determinado
Senha e Ação
usuário autorizado
Direitos de uso Componente da aplicação
Arndt von Staa © LES/DI/PUC-Rio
Usuário
16
Componente Login, máquina de estados
Cadastro
de usuários
autorizados
{ "OK" }
Sistema
Sis
Dados e
botão
Fornecer
dados
{erro}
{ "Cancelar" }
{1o. a 3o.
erro}
{ Quarto ou
mais erro }
{ "Cancelar" }
Validar
dados
{ "Mudar
senha"}
Autoriza
uso
Trocar a senha
{erro} { "Esqueci
senha” }
Controlar
erros
Fornecer identificação alternativa
Usuário
Emite nova senha
Não autoriza uso
Mar 2010
Arndt von Staa © LES/DI/PUC-Rio
17
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 Login
O 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 controle
3. Quando o usuário teclar “OK” então
3.1 O componente Login ativa o estado “Confirmar usuário”
Fim quando
4. Quando o usuário teclar “Mudar senha” então
4.1 O componente Login ativa o estado “Trocar a senha”
Fim quando
Mar 2010
Arndt von Staa © LES/DI/PUC-Rio
18
Exemplo: Conversão para texto mark-up
Texto inicial
1. O usuário digita a sua identificação lexicamente correta
Texto mark-up
1. 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ário
Pessoa: 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 exibido
1. O <#idUs> <#idED> a sua <#idIdU> <#idSinxIdU>.
Mar 2010
Arndt von Staa © LES/DI/PUC-Rio
19
Arquitetura abrangente
DFB
PRB
Meta definition
base
Parameter
base
SWB
Environment
builder role
Environment
base
Meta
environment
MTB
Feedback
Global metrics
base
Project
manager
Instance
builder
DFB
PRB
DFB
PRB
Definition
base
Parameter
base
Definition
base
Parameter
base
User
role
User
role
Meta
environment
Mar 2010
Meta
environment

SWB
MTB
SWB
MTB
Software
base
Local metrics
base
Software
base
Local metrics
base
Arndt von Staa © LES/DI/PUC-Rio
20
Arquitetura: conjunto de meta-editores
Representation
language
definition
Dictionary
editor
Thing
dictionaries
Dialog definition
Diagram definition
Dialog
Elements
Diagram
editor
Diagrams
DFB
Definition
base
BSW
Structure definition
Text definition
Tool definition
Structure
editor
Structural
relations
Text
editor
Things
Elements
Relations
Internal
tools
Things
Elements
Relations
Repository
Foreign
tools
Mar 2010
Arndt von Staa © LES/DI/PUC-Rio
21
Componentes de um meta-editor
Processing
layer
Interaction layer
Formatting
rules
Workspace
schema
Format
Assembly
rules
Assemble
Concrete
representation
Mar 2010
Persistence layer
Retrieve
Repository
schema
Edit / browse
Validate
Disassemble
Editing
rules
Validation
rules
Disassembly
rules
Arndt von Staa © LES/DI/PUC-Rio
Store
22
Arquitetura de um meta-editor
Componente interpretador
Efetuar
ação 1
Efetuar
ação 2
Determinar
ação
Efetuar
ação n
Módulo cliente
I
n
t
e
r
f
a
c
e
Função cliente
( IdServico ,
RefCallBack )
Funções Call back
Interface
call back
Tabela
interpretável
+
Strategy
Tabela
fonte
Mar 2010
Serviço 1( ... )
Serviço 2( ... )
...
Serviço k( ... )
Tradutor
Arndt von Staa © LES/DI/PUC-Rio
23
Meta-editor diagramas
Base de definição
Base de software
Carimbo de: processo
Processo: 123
Moldura:
Nome: "Obter dados"
Aliás 3: 2.1
Relação Agentes:
João
Maria
José
Campo 1: Aliás 3
moldura _________
Campo 2: Nome
Campo 3: Relação Agentes
moldura _________
Diagrama Fluxo de Dados
Nome: xxx
Instância de: processo
Processo: 123
Posição: 30 100
Dimensões: 12 x 8
Vídeo (Folha)
100
30
2.1
Obter dados
área ocupada
João
Mar 2010
Arndt von Staa © LES/DI/PUC-Rio
24
Meta-especificação em 3 níveis
Software base schema
Label
Parameter base
schema
Software base
static schema
Definition base
static schema
Instance
belongs to
2
Adornment
n
n
1
1
n
Link
obeys
Definition base schema
Label
classes
Adornment
classes
label rules
Instance
classes
Mar 2010
link
rules
Arndt von Staa © LES/DI/PUC-Rio
ornament rules
Link
classes
25
Especificação da linguagem “modular C++”
Programa
Utiliza
Utilizado por
Cliente
Módulo
Servidor
Módulo
Função Dado
Tipo
referencia
Herda de
Classe
Módulo Módulo Módulo Herdada por
referenciada
Função Tipo
Dado
Projeto
Sobre-carrega
Redefine
Tipo
Função
Sobre-carregado Redefinido
Compõe
Implementação
Função Chama
Compõe
Bloco
Decompõe
Mar 2010
Bloco Chamada
Dado
Usado
Tipo
Usa
Dado
Decompõe
Arndt von Staa © LES/DI/PUC-Rio
26
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
Arndt von Staa © LES/DI/PUC-Rio
27
Repositório lógico elementar
1
n
Dictionary
Object
n
Property
n
Relation
types
Other
types
n
Name
entre classes definidas
Binary
relation
Bounded
string
entre classes definidas
Ternary
relation
Unbounded
string
entre classes quaisquer
Mapping
Simple
text
Link
Markup
text
Relational
text
Table
gráfico
texto contendo referências
Abstract
syntax
graph
User
defined 1
Mar 2010
User
defined 2
Arndt von Staa © LES/DI/PUC-Rio
User
defined n
28
Repositório físico persistente
Página
origem
Página
Base de persistência é um simulador
de memória virtual segmentada
NumBtrees
Pai
Ant
Página
lista
Referência
a BTREE
Prox
Página
raiz
Página lista
de listas
Elemento
estrutural
Filho
0..MaxListas
Referência
a lista
Página
livre
0..MaxChaves
Prox
MaxChaves/2
.. MaxChaves
Página
estrutural
Página
de dados
1..MaxDados
Elemento
de dados
âncora
Colaboração, visão simplificada
SWB
Environment
server
Shared
databases
Database
integrator
Network
Environment
instance
Environment
instance
SWB
SWB
SWB
SWB
Local
databases
Differential
databases
Local
databases
Differential
databases
Workstation
Mar 2010
Workstation
Arndt von Staa © LES/DI/PUC-Rio
30
Distribuição de bases de software
Developer 1
Interconnection link
Usage link
Mar 2010
Developer 2
Organization A
Arndt von Staa © LES/DI/PUC-Rio
Developer 3
Organization B
31
Processo de teste
Application
Java or C++
OR
Console
driver C++
(main)
Test
script
Component
API
Closed C++
component
Generic
tester
Specific
tester
Test
support
Leakage
control
Counter
Command
reader
Already developed
and accepted
application modules
Utilities
and run
time
support
Module
under test
Module
under test
Mar 2010
Arndt von Staa © LES/DI/PUC-Rio
32
Processo de teste
Definition
module
Generate
test module
skeleton
Define test
command
syntax
Implement
test command
interpreters
Write script
Generate
command table
and documentation
Perform
test
Test is complete
and accepted
while more to be tested
Implement
functions to be
tested
Mar 2010
Arndt von Staa © LES/DI/PUC-Rio
33
Perguntas?
Arndt von Staa
[email protected]
Departamento de Informática
PUC-Rio
Abril 2010
Anexo: Requisitos básicos
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
Arndt von Staa © LES/DI/PUC-Rio
36
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
Arndt von Staa © LES/DI/PUC-Rio
37
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
Arndt von Staa © LES/DI/PUC-Rio
38
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
Arndt von Staa © LES/DI/PUC-Rio
39
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
Arndt von Staa © LES/DI/PUC-Rio
40
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
Mar 2010
Arndt von Staa © LES/DI/PUC-Rio
41
Anexo: Perguntas de pesquisa
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
Arndt von Staa © LES/DI/PUC-Rio
43
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
Arndt von Staa © LES/DI/PUC-Rio
44
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
Arndt von Staa © LES/DI/PUC-Rio
45
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
Arndt von Staa © LES/DI/PUC-Rio
46
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
Arndt von Staa © LES/DI/PUC-Rio
47
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
Arndt von Staa © LES/DI/PUC-Rio
48
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
Mar 2010
Arndt von Staa © LES/DI/PUC-Rio
49
Perguntas?
Arndt von Staa
[email protected]
Departamento de Informática
PUC-Rio
Abril 2010