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


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


Características do desenvolvimento

Rep 1Rep 6

Rep 3

Rep 4

Rep 5

Rep 2

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


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


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


Evolução da abstração




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


Uma possível arquitetura

alguma forma de

especificarfoco em automação dos testes


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


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 ; … { ...


Linguagens de representação


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?


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}


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


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>.


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


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


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


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


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é


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


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>



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


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


Distribuição de bases de software

D eveloper 1 D eveloper 3D eveloper 2

In terconnection linkUsage link

O rganization A O rganization B


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


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

[email protected]


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


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


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


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


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


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


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?



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



• 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

• . . .



• 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

• . . .



• 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



• 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?



• 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

[email protected]


PUC-Rio

Abril 2010

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

Documents

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