1/26/2009. Baseadas em Experiência pessoal/profissional/acadêmica

Transcrição

1 Baseadas em Experiência pessoal/profissional/acadêmica 1

2 Metamodelo UML Meu Metamodelo Meu processo de negócios Meu processo de negócios Stereotypes Perfis Controle sobre os elementos Modelo mais conciso / enxuto Facilita as transformações / geração de código Modelo mais legível Sistemas automotivos Controladores de motor Sistemas embarcados Diesel Gas 2

3 Metamodelo da UML é COMPLICADO! Vários elementos / pacotes Vários níveis de herança Confusão de nomes Difícil escrever transformações Ele é o artefato central Ele define a semântica do seu domínio e das linguagens É a linguagem comum dentro da organização/projeto/grupo Utilize meios robustos e escaláveis para defini-lo e mantê-lo DSL textual ou ferramenta UML Editor em árvore EMF não é escalável Nem o editor GMF... 3

4 É importante Capacidade de dividir o metamodelo em vários módulos Definição deve ser incremental! Baseada na experiência Conhecimento dos especialistas Boa idéia Começar com o domínio da plataforma destino MDD centrado na arquitetura Exercite o metamodelo Melhore e valide continuamente Especialistas do domínio e equipe de desenvolvimento Discuta opções Crie modelos e sentenças para exercitá-lo Ao descobrir que é impossível expressar uma sentença ou modelo Este pode estar errado ou necessita reformulação Ou o metamodelo precisa ser alterado!! 4

5 Um modelo onde as restrições não são satisfeitas não pode ser utilizado como entrada para um gerador/transformador Verifique estas restrições! Não inclua as verificações na transformação! Torna as mesmas mais complexas Caso existam duas transformações para um mesmo modelo, estas precisam ser duplicadas em cada transformação. As verificações devem estar separadas, e acontecer cedo no processo de modelagem Ao desenvolver uma transformação Assuma que o modelo está correto e é válido Liste possíveis problemas com a validade Crie verificações externas, a serem executadas antes da transformação Durante digitação Utilizando mensagens de erro Etc. Cuidado com alterações de versões Possíveis conflitos / inconsistências Afinal, no MDD, são sujeitos ao controle de versão: Metamodelos Definições das DSLs (sintaxes) Transformações Templates Arquivos auxiliares 5

6 Mantenha código gerado e manual em arquivos separados Apesar de existirem tecnologias como Jmerge! Nunca modifique código gerado! Projete uma arquitetura que defina quais artefatos são gerados, e quais não são! Utilize abordagens de projeto apropriadas para unir código gerado e não-gerado Interfaces Padrões de projeto (Factory, Strategy, Bridge, Template Method) Código gerado pode chamar código não-gerado Código gerado Código nãogerado 6

7 Um framework não-gerado pode chamar partes que são geradas Código não-gerado Código gerado Fábricas podem ser utilizadas para plugar componentes gerados Código nãogerado Fábrica Código gerado Classes geradas podem ser subclasses de classes não geradas Classe nãogerada Classe gerada 7

8 A classe-base pode ter chamadas para métodos abstratos a serem implementados pela classe gerada (template method) Classe nãogerada Classe gerada Produza código bem estruturado e bonito sempre que possível! Tenha em mente o desenvolvedor que Irá verificar o código gerado Irá testar e depurar o código gerado Em geral, este padrão facilita a aceitação pela geração de código Exemplos: Comentários Prettyprinters / formatadores automáticos String de localização ( Gerado a partir do modelo xyz ) Acredite que é possível regenerar tudo! Não tenha medo de apagar o que foi gerado! Transformações/gerações Fato: caso seja necessário um único passo manual (uma linha que precise ser modificada, um arquivo que precise ser renomeado, etc) O gerador será descartado! 8

9 Isto não significa Gerar tudo o que for possível! Mas sim Utilize uma plataforma de domínio rica! Possivelmente construída, comprada, ou open source! Aproveite ao máximo os modelos! Evite duplicação e minimize tarefas manuais Aproveite para gerar também: Guias de usuário Textos de ajuda Dados de testes Scripts de compilação Conteúdos diversos Etc Encontre um meio-termo entre O esforço para automatizar tarefas manuais O esforço para realizar manualmente tarefas repetitivas Caso seja mais fácil fazer manualmente, FAÇA! 9

10 Os melhores desenvolvedores são até 10 vezes melhores que desenvolvedores medianos! Você é este desenvolvedor! Coloque seu conhecimento no gerador/transformador/plataforma Leve os demais desenvolvedores a seguir o mesmo caminho! Dê aos desenvolvedores uma liberdade limitada para que os mesmos implementem os aspectos não-gerados do software. Isto leva a Sistemas bem-estruturados Mantém a promessa feita pelos modelos Desafio: como combinar código gerado e código manual de forma controlada? Bloquear código / regiões protegidas! Padrões / framework de receitas (Ex: oaw) 10

11 Sistemas complexos tipicamente consistem de vários aspectos, preocupações ou pontos de vista Frequentemente estes são descritos por pessoas diferentes, em ocasiões diferentes Na maioria dos casos, diferentes formas de sintaxe concreta são necessárias Desta forma, utilize modelos separados para estes pontos de vista Estruture seu sistema em diferentes subdomínios técnicos (persistência, GUI, etc) Cada subdomínio terá seu próprio metamodelo e DSL Defina metaclasses especiais para servirem de ponte entre diferentes metamodelos Irão ajudar na junção dos aspectos Em casos mais simples, pode-se considerar nomes de elementos como a informação unificadora Às vezes, um ponto de vista é todo um aspecto! Preocupação ortogonal (persistência, segurança, etc) Entrecorta todo o sistema O gerador pode atuar como um aspect weaver Combinando os aspectos no código gerado 11

12 Defina uma plataforma de aplicações rica, específica de domínio: Bibliotecas Aplicações geradas Frameworks Classes-base -Classes do domínio Plataforma -Regras de negócio -Serviços Interpretadores de domínio -... etc Plataforma técnica/ middleware -Persistência -Transações -Distribuição -Escalonamento -Acesso a hardware -... Linguagem de programação Sistema Operacional Ao invés de gerar código para a API da linguagem As transformações irão gerar código para esta plataforma Por isso, ficam mais simples DSLs e frameworks são dois lados da mesma moeda Um framework é uma DSL? 12

13 Usuário Usuário Aplicação Gerada Aplicação Gerada Plataforma técnica / middleware Linguagem de programação (API) Sistema Operacional Plataforma técnica / middleware Plataforma Linguagem Específica de programação de (API) Domínio Sistema Operacional Não é preciso gerar 100% da aplicação Pode-se gerar uma parte E reutilizar outra A razão geração/plataforma varia De sistema para sistema Em um mesmo sistema, de momento para momento Regras simples: Se a plataforma estiver muito complicada, gere mais código Se o gerador estiver muito complicado, ou gerando muito código duplicado, mova-o para a plataforma Código gerado é frequentemente código para completar framework DSLs facilitam o uso de frameworks! 13

14 Um sistema bem-sucedido é construído sobre uma arquitetura bem definida Planeje as transformações de acordo com os elementos desta arquitetura Em uma arquitetura em camadas Utilize transformações modelo-para-modelo (m2m) para implementar as camadas superiores com base nas abstrações providas pelas camadas inferiores Camada 3 Modelos M2T Camada 2 Camada 1 Plataforma M2M M2T Modelo Modelo M2M M2M M2M M2T Modelo Modelo Modelo Modelos M2M M2T Modelo Camada 3 Camada 2 Camada 1 Plataforma 14

15 Por exemplo, assuma que precisa gerar código Java. Você precisa de: Nome do pacote para a classe gerada Caminho do projeto onde o código será gerado Etc Colocar estas informações no metamodelo do domínio irá causar poluição É ainda pior quando um mesmo modelo é usado para diferentes plataformas Permita que as metaclasses sejam anotadas com informações externas! 15

16 Ambos Podem ser construídos sobre um mesmo metamodelo Podem verificar restrições em tempo real Irão funcionar com modelos EMF básicos Editores gráficos Melhores para relações estruturais Editores textuais Melhores para aspectos algorítmicos Integram melhor com CVS (diff, merge, etc) Alguns casos requerem uma modularização da transformação Exemplo: máquina de estados / estado de emergência Problema: adicionar um estado ligado a todos os outros Transformações modelo-para-modelo podem realizar esta tarefa Nunca modifique modelos intermediários!! 16

17 Exemplo Ordenação de tabelas Tabela: name=id (Campo)*; Campo:... Ordenacao: Coluna 1 Coluna 2 Coluna 3 Nenhuma ; Ordenacao: Coluna 1 Exemplo Ordenação de tabelas Tabela: name=id (Campo)*; Campo:... Ordenacao: (ordem=int Expressao ( ASC DESC ) ; )+; Expressao: Termo (Sinal Termo)?; Termo: [Campo] Numero Expressao; Sinal: + - * / ; Ordenacao: 1 nome ASC; 2 idade*2/altura DESC;... 17

18 Ordenacao: Coluna 1 Mais simples Ordenacao: 1 nome ASC; 2 idade*2/altura DESC;... Configuração de rotina Eficiência, direção DSLs Composição criativa Flexibilidade, complexidade if(ordenação == Nenhuma ) return; else { campo = pegacampo(ordenacao); ordena(campo); } List<Ordenacao> ordenacoes =...; ordena(ordenacoes); for(ordenacao o: ordenacoes) { int valor =... // avaliar expressao ordena(o.campo, valor);... } 18

19 Configuração de rotina Composição criativa DSLs Eficiência, direção Flexibilidade, complexidade Vá tentando da esquerda para a direita! A maneira mais fácil de descrever comportamento é reduzi-lo para tags simples! Ex: Comunicação entre componentes Alternativas! Síncrona, assíncrona, etc Apenas é necessário marcar a opção desejada! A transformação ou o gerador implementa o comportamento escolhido Pode ser simples verdadeiro/falso Uma matriz de decisões Ou uma árvore de configuração mais complexa! 19

20 Próxima opção: formalismo conhecido! Máquina de estados Lógica de predicados Mecanismos de regras de negócio Vantagens: A semântica fica clara Existem editores e ferramentas É fácil implementar mecanismos para estes formalismos Esta abordagem já é considerada composição criativa! Caso não exista um formalismo adequado Invente o seu! Semântica própria Crie linguagens para descrevê-lo Desvantagem: Você precisa implementar tudo Pode não ser trivial! Último recurso: Linguagem Turingcompleta 3GL UML action semantics Qualquer comportamento Porém, não será específica para o domínio 20

21 Pressuposto: é impossível verificar a corretude do software (maioria dos casos) Solução: testes intensivos Diferentes tipos: O software faz o que o desenvolvedor queria? O que foi desenvolvido é realmente o que o sistema deveria fazer? O sistema executa e escala adequadamente? Propriedades não-funcionais funcionam conforme especificado (segurança, transações, etc)? As ferramentas e tecnologias utilizadas funcionam bem juntos? O código faz o que o desenvolvedor pretendia? Existem frameworks (JUnit) Escritos pelo desenvolvedor Tipicamente testam funcionalidades No MDD, os testes podem ser gerados a partir dos modelos 21

22 Propriedades estáticas Para comportamento, deve haver um modelo adicional! Testes adicionais podem ser gerados a partir de invariantes (OCL) Pode-se também embutir código de avaliação das restrições (OCL) no código gerado, e testar durante a execução Veículo Veículo.setMotorista(p) pre: p.idade > 18 setmotorista(pessoa p) class Veiculo {... public void setmotorista(pessoa p) { if(! (p.idade > 18) ) throw new ViolacaoDeRestricao(); } } Pode-se gerar automaticamente casos de teste para os valores -3, -1, 0, 1, 10, 17, 18, 19, E verificar se o sistema responde de acordo com o modelo previsto O sistema faz o que o cliente (ou os requisitos) diz? Mesma abordagem técnica, porém escritos pelo especialista do domínio. Talvez utilizando uma linguagem específica para isso Caso existam restrições OCL, as mesmas podem ser usadas para gerar casos de teste Pois são semanticamente mais ricas do que os requisitos típicos 22

23 Basicamente Simulam um certo número de clientes Medem tempo de resposta Utilização dos recursos Normalmente exigem Configuração do ambiente de testes Os clientes simulados podem ser gerados Quais operações chamar Sequência Intervalos Quantos processos paralelos Como e quando armazenar os resultados medidos Verificação de modelos Detecção de erros de projeto Extremo: interpretar e simular todo o modelo Existem UML Virtual Machines Mais fácil Verificar restrições antes da transformação/geração O gerador também é um artefato No início Precisa ser testado! Conceito de 2 canais Gerador 1 Código de implementação Modelo Gerador 2 Código de teste 23

24 24