Parte 1 CONCEITOS MDD

Transcrição

1 Parte 1 CONCEITOS MDD 1

2 Desenvolvimento de software Como éfeito Análise de um problema/processo/sistema Desenvolvimento de uma solução Software + não-software Testes/validação Uma série de problemas!! 2

3 Como deveria ser Problema Solução 3

4 A realidade Problema Solução Implementação 4

5 A realidade Modelagem é algo positivo... Arquitetos (algumas vezes) usam UML para criar modelos de alto nível São usados em um primeiro momento Discussões, idéias, etc (análise) Porém logo são inúteis Programadores criam código manualmente Manutenção é feita diretamente no código Modelos perdem a consistência Mesmo com engenharia reversa, ainda é um artefato desnecessário 5

6 Problemas a serem resolvidos Reduzir o fardo da modelagem Dificuldades da linguagem (UML) Inconsistências entre modelo-código Necessidade de ferramentas caras Modelo é algo desnecessário 6

7 Reutilização Conhecimento fica criptografado no código public static void main(string args[]) { if(args.length > 0) imprimemensagem(args[0]); else imprimemensagem( Alô mundo! ); } public static void imprimemensagem(string mensagem) { } System.out.println(mensagem); 7

8 Reutilização de conhecimento public void abriu() { estado = ABERTO; timer = new Timer(10000); } public void fechou() { if(estado == ABERTO) { estado = FECHADO; timer = null; } } public void fimtimer() { if(estado == ABERTO) { estado = DISPARANDO; tocaalarme(); timer = new Timer(20000); } else { estado = ABERTO; desligaalarme(); timer = new Timer(10000); } } 8

9 Reutilização de conhecimento Inicial Fechado Abriu porta Fechou porta Disparando alarme Aberto 10 segundos 20 segundos 9

10 Reutilização de conhecimento Java ASM C# Lisp Prolog 10

11 Problemas a serem resolvidos Reduzir o fardo da modelagem Facilitar o reuso do conhecimento Formas mais eficientes para representar o conhecimento Menos dependentes do código final Mais próximas do domínio do problema Diferente da documentação 11

12 Produtividade Um elemento conceitual corresponde a vários elementos do código Diferença no nível de abstração Mapeamento problema / solução 12

13 Produtividade Abriu porta Fechou porta Inicial Fechado Aberto Disparando alarme 10 segundos 20 segundos public void abriu() { estado = ABERTO; timer = new Timer(10000); } public void fechou() { if(estado == ABERTO) { estado = FECHADO; timer = null; } } public void fimtimer() { if(estado == ABERTO) { estado = DISPARANDO; tocaalarme(); timer = new Timer(20000); } else { estado = ABERTO; desligaalarme(); timer = new Timer(10000); } } 13

14 Produtividade Abriu porta Fechou porta Inicial Fechado Aberto Disparando alarme 10 segundos 20 segundos public void abriu() { estado = ABERTO; timer = new Timer(10000); } public void fechou() { if(estado == ABERTO) { estado = FECHADO; timer = null; } } public void fimtimer() { if(estado == ABERTO) { estado = DISPARANDO; tocaalarme(); timer = new Timer(20000); } else { estado = ABERTO; desligaalarme(); timer = new Timer(10000); } } 14

15 Produtividade Abriu porta Fechou porta Inicial Fechado Aberto Disparando alarme 10 segundos 20 segundos public void abriu() { estado = ABERTO; timer = new Timer(10000); } public void fechou() { if(estado == ABERTO) { estado = FECHADO; timer = null; } } public void fimtimer() { if(estado == ABERTO) { estado = DISPARANDO; tocaalarme(); timer = new Timer(20000); } else { estado = ABERTO; desligaalarme(); timer = new Timer(10000); } } 15

16 Produtividade 16

17 Produtividade Muitas tarefas de implementação são repetitivas e exaustivas EJB 2.0 CORBA Struts Hibernate Perde-se tempo precioso em trabalho braçal Poderia ser usado em tarefas mais conceituais 17

18 Problemas a serem resolvidos Reduzir o fardo da modelagem Facilitar o reuso do conhecimento Aproveitar o trabalho de forma mais produtiva Foco em tarefas conceituais Evitar tarefas repetitivas 18

19 Manutenibilidade Correções Erros Melhorias Evolução Novas funcionalidades Exigem nova análise, projeto, implementação, testes, etc... Normalmente o tempo é curto 19

20 Manutenção a realidade Problema Solução 20

21 Manutenibilidade Abriu porta Fechou porta Inicial Fechado Aberto Disparando alarme 10 segundos 20 segundos public void abriu() { estado = ABERTO; timer = new Timer(10000); } public void fechou() { if(estado == ABERTO) { estado = FECHADO; timer = null; } } public void fimtimer() { if(estado == ABERTO) { estado = DISPARANDO; tocaalarme(); timer = new Timer(20000); } else { estado = ABERTO; desligaalarme(); timer = new Timer(10000); } } 21

22 Manutenibilidade 22

23 Exemplo de manutenção Modificar um campode um registro em uma aplicação baseada em Struts Tabela, índices, visões, consultas, etc. (SQL) Ação (classe Java) Mapeamento (XML) Formulário (XML) Bean de dados (Java/XML) DAO -Data Access Objects (Java) Página (HTML) Regras de validação (Javascript) Arquivo de mensagens (.properties) etc. 23

24 Manutenibilidade Trabalho braçal para construir Re-trabalho braçal para modificar Rastreabilidade Um elemento conceitual Diversos artefatos de implementação Consistência das mudanças Entre os diversos artefatos 24

25 Manutenibilidade Erros de programaçãopodem ser facilmente encontrados Compilador / IDE Checagens simples (método privado nunca é chamado, etc.) Erros conceituais Difíceis de identificar no código Conhecimento está criptografado 25

26 Manutenibilidade public void abriu() { estado = ABERTO; timer = new Timer(10000); } public void fechou() { if(estado == ABERTO) { estado = FECHADO; timer = null; } } public void fimtimer() { if(estado == ABERTO) { estado = DISPARANDO; tocaalarme(); timer = new Timer(20000); } else { estado = ABERTO; desligaalarme(); timer = new Timer(10000); } } 26

27 Manutenibilidade Inicial Fechado Abriu porta Fechou porta Disparando alarme Aberto 10 segundos 20 segundos 27

28 Manutenibilidade Inicial Abriu porta Fechou porta Fechado Fechou porta Disparando alarme Aberto 10 segundos 20 segundos 28

29 Manutenibilidade Uma vez realizada a alteração Atualizar os modelos (Quase) nunca acontece Uma vez que os desenvolvedores tenham um modelo mental começam a descartar o modelo físico (documentação) Resultado = modelos desatualizados Faz parte do fardo da modelagem 29

30 Problemas a serem resolvidos Reduzir o fardo da modelagem Facilitar o reuso do conhecimento Aproveitar o trabalho de forma mais produtiva Facilitar a manutenção Aproveitar o re-trabalho de forma mais produtiva Possibilitar que mudanças sejam realizadas no nível conceitual Facilitar a localização de erros e falhas Manter a consistência entre modelo e código 30

31 Validação Verificações automáticasde restrições de alto nível Difíceis de se realizar diretamente no código Exemplos (máquina de estados): Estados inalcançáveis Transições infinitas Estados mortos Facilita manutenção Evitando introdução de erros 31

32 Validação Estado morto Estado inalcançavel Transição infinita 32

33 Otimização Nível de código Pré-calcular expressões Utilização de macros Remoção de expressões redundantes Em nível mais alto não é possível sem a existência de um modelo Remover estados redundantes Normalizar base de dados Indexar tabelas de acordo com as consultas existentes 33

34 Problemas a serem resolvidos Reduzir o fardo da modelagem Facilitar o reuso do conhecimento Aproveitar o trabalho de forma mais produtiva Facilitar a manutenção Validação / otimização Fazer uso de checagem automática Utilizar o conhecimento de especialistas do domínio 34

35 Portabilidade Acompanhar a evolução das plataformas de hardware/software Novas tecnologias surgem Aumenta a pressão para a migração Custo do porte: Esforço gasto em tarefas específicas da plataforma 35

36 Portabilidade Software independente da plataforma Software dependente da plataforma Requisitos Modelos Regras de negócio Otimizações Código Arquivos de configuração Scripts (sql, make, etc) Código específico da plataforma Bibliotecas da plataforma 36

37 Portabilidade Software independente da plataforma Requisitos Modelos Regras de negócio Otimizações 1 mês Software dependente da plataforma Código Arquivos de configuração Scripts (sql, make, etc) Código específico da plataforma Bibliotecas da plataforma 6 meses 37

38 Portabilidade Software independente da plataforma Software dependente da plataforma Requisitos Modelos Regras de negócio Otimizações Código Arquivos de configuração Scripts (sql, make, etc) Código específico da plataforma Bibliotecas da plataforma 38

39 Portabilidade Software independente da plataforma Requisitos Modelos Regras de negócio Otimizações 3 meses Software dependente da plataforma Código Arquivos de configuração Scripts (sql, make, etc) Código específico da plataforma Bibliotecas da plataforma 3 meses 39

40 Problemas a serem resolvidos Reduzir o fardo da modelagem Facilitar o reuso do conhecimento Aproveitar o trabalho de forma mais produtiva Facilitar a manutenção Validação / otimização Portabilidade Reduzir o esforço específico de plataforma Concentrar no trabalho conceitual 40

41 Alta complexidade do software atualmente Exemplo: LBS Location-Based Systems GIS Geographical Information Systems Múltiplas plataformas Múltiplas interfaces Diversas fontes de dados Interoperabilidade Usuário final leigo 41

42 Rastreamento (rádio-frequecia, GPRS) Visualização(Java SWING, Web, JME, Palm) Localização Roteamento Telemetria Acionamento remoto 42

43 Tecnologias envolvidas Hardware dedicado (veículos) GPS, sensores, atuadores Software embarcado (C) Geoposicionamento Leitura/escrita sinais Protocolo de comunicação Transmissão Criptografia Central (C++) Armazenamento dos dados Autenticação 43

44 Tecnologias envolvidas Monitoramento/rotas (Java/SWING) Visualização dos veículos Sobreposição no mapa Cálculo de rotas Servidor de mapas (Java) Visualização em camadas Caching Base de dados PostgreSQL + PostGIS Funções de consulta / geometria Diferentes fornecedores de mapas 44

45 Tecnologias envolvidas Dispositivos móveis Celular (JME) PND Personal Navigation Device (C# /.NET) Visualização Web Portal de mapas (Javascript) Edição de mapas (Java/SWING) Nomes de ruas Sentido/mão de direção 45

46 Resultado Complexidade exige Diversos profissionais Diversos especialistas Comunicação é crítica Especialistas em TI x Especialistas no domínio Cada um em seu território! Porém, com a alta complexidade Torna-se uma tarefa difícil Além disso Constantes mudançasnas plataformas/requisitos/tecnologias disponíveis 46

47 Rastreamento (rádio-frequecia, GPRS) Visualização(Java SWING, Web, JME, Palm) Localização Roteamento Telemetria Acionamento remoto 47

48 Problemas a serem resolvidos Reduzir o fardo da modelagem Facilitar o reuso do conhecimento Aproveitar o trabalho de forma mais produtiva Facilitar a manutenção Validação / otimização Portabilidade Lidar com a alta complexidade do software atual Diferentes especialistas (TI vs domínio) Necessidade de integração / interoperabilidade 48

49 Solução Modelagem Reutilização Produtividade Manutenibilidade Validação / otimização Portabilidade Alta complexidade Desenvolvimento Orientado a Modelos (MDD) Model-Driven Development (MDSD) Model-Driven Software Development (MDE) Model-Driven Engineering 49

50 O que é? DESENVOLVIMENTO ORIENTADO A MODELOS 50

51 Desenvolvimento convencional import java.util.*; Economia public synchronized replicatedata() {... } Finanças Alimentos Jogos <%@ page language="java > <%@taglibprefix="c uri="jsp/jstl/core %> <html> <head>... <struts-config> <form-bean>... <action>... CREATE TABLE </struts-config> Map( id INTEGER PK... ) #include "demoextension.h" intaeeclscreateinstance(void**ppobj) { *ppobj = NULL; if( ClsId == AEECLSID)... jnzrx00# addb, 0F# addc, 0E# mova, 00# 51

52 Desenvolvimento convencional com atividade de modelagem import java.util.*; Economia public synchronized replicatedata() {... } Finanças Alimentos Jogos <%@ page language="java > <%@taglibprefix="c uri="jsp/jstl/core %> <html> <head>... <struts-config> <form-bean>... <action>... CREATE TABLE </struts-config> Map( id INTEGER PK... ) #include "demoextension.h" intaeeclscreateinstance(void**ppobj) { *ppobj = NULL; if( ClsId == AEECLSID)... jnzrx00# addb, 0F# addc, 0E# mova, 00# 52

53 Desenvolvimento orientado a modelos Modelos fazem parte do software import java.util.*; Economia public synchronized replicatedata() {... } Finanças Alimentos Jogos <%@ page language="java > <%@taglibprefix="c uri="jsp/jstl/core %> <html> <head>... <struts-config> <form-bean>... <action>... CREATE TABLE </struts-config> Map( id INTEGER PK... ) #include "demoextension.h" intaeeclscreateinstance(void**ppobj) { *ppobj = NULL; if( ClsId == AEECLSID)... jnzrx00# addb, 0F# addc, 0E# mova, 00# 53

54 Desenvolvimento orientado a modelos Os modelos não são somente papel São entradas para transformadores e geradores Desenvolvedor é protegido das complexidades Inerente e acidental Em alguns casos, o desenvolvedor nem precisa visualizar código! 54

55 public int soma (int a, int b) { int resultado = a + b; return resultado; } 55

56 public int soma (int a, int b) { } int resultado = a + b; return resultado; public int soma (int a, int b) { int resultado = a + b; return resultado; }.java PUSH AX MOV AL, char MOV AH, 0Eh INT 10h POP AX.asm bin 56

57 PUSH AX MOV AL, char MOV AH, 0Eh INTpublic int soma 53 (int 10h a, int b) { POP int resultado 92 = AXa + b; ADD return resultado; AX,BX INT} 10h POP AX JNZ R1, 1Eh

58 53 Domínio 92problema math public int soma (int a, int b) { int resultado = a + b; return resultado; }.java PUSH AX MOV AL, char MOV AH, 0Eh Domínio TI INT 10h POP AX.asm (solução) bin 58

59 Microsoft Access 59

60 60

61 Netbeans Mobility Pack 61

62 Elementos 62

63 Elementos Exemplo do Netbeans Não é possível alterar a ferramenta de modelagem Não é possível alterar a transformação Tecnologias atuais MDD Permitem a construção/edição destes artefatos 63

64 Vantagens e desvantagens DESENVOLVIMENTO ORIENTADO A MODELOS 64

65 Vantagens Venda Compra Aluguel Contrato Fiador Cotação Classe Objeto Métodos Atributos Padrões Especialista do domínio Especialista em TI 65

66 Vantagens Um único modelo pode dar origem a diferentes implementações, linguagens ou plataformas Permite capturaro conhecimento do domínio de forma clara Ficando disponível para os desenvolvedores Escondedetalhes de implementação durante o desenvolvimento de soluções Um único modelo pode gerar uma grande quantidade e diversidade de código 66

67 Vantagens Especialistas do domínio têm um papel mais ativo no processo Maior eficiência no desenvolvimento Maior qualidade no produto/processo Geradores não produzem erros acidentais Modelos estão sempre atualizados 67

68 Desvantagens Maior rigidez no software produzido Alta complexidadedos artefatos necessários (transformadores, etc) Questão do desempenho Otimização automática vs código escrito manualmente Exige habilidades específicas e pessoas altamente especializadas em MDD 68

69 Comparação com desenvolvimento tradicional 69

70 MDD estágio

71 MDD estágio

72 Alguns números Nokia reporta que consegue desenvolver novos celulares até 10 vezes mais rápido Lucent relata ganhos de produtividade de 3 a 10 vezes, dependendo do produto Redução de 50 para 1em termos de linha de especificação/código Juha-PekkaTolvanen. Making model-based code generation work. Embedded Systems Europe, 8(60):3638, Aug/Sept David Wile. Lessons learned from real dsl experiments. Sci. Comput. Program., 51(3): ,

73 ABORDAGENS PARA MDD 73

74 Abordagens MDD MDD são os princípios Desenvolvimento orientado a modelos Elevação da importância do modelo no processo Existem diversas frentes Cada uma baseada em padrões, ferramentas e processos específicos 74

75 Abordagens para MDD OMG MDA (Model-Driven Architecture) VanderbiltUniversity MIC (Model Integrated Computing) Microsoft Software Factories Eclipse Modeling 75

76 OMG - MDA Model-Driven Architecture Surgiu em 2001 Baseada em padrões (standards) Objetivo Especificarum sistema de forma independente de plataforma Especificar plataformas Escolher uma plataforma para o sistema Transformara especificação genérica em uma especificação específica de plataforma 76

77 MDA Visão Geral 77

78 MDA Principais elementos CIM Computation Independent Model PIM Platform Independent Model PSM Platform Specific Model Modelo de plataforma Transformação de modelos 78

79 Ciclo de vida MDA 79

80 Transformações MDA 80

81 Padrões MDA UML Unified Modeling Language MOF Meta-Object Facility CWM Common Warehouse Metamodel XMI XML Metadata Interchange QVT Query / Views / Transformations 81

82 Padrões MDA MOF Formato XML XMI UML CWM Outros metamodelos Modelos UML Modelos de dados Outros modelos Modelo UML1.xmi Modelo UML2.xmi Modelo Dados1.xmi Modelo Qualquer1.xmi Modelo Qualquer2.xmi 82

83 Padrões MDA MOF Metamodelo A Metamodelo B Modelos A QVT Modelos B Consultas Transformações 83

84 MDA Uma série de especificações Foco em portabilidade, independência de plataforma Voltadas à implementaçãoe padronização é uma referência Fabricantes podem optar por aderir aos padrões Não define uma metodologia Não define ferramentas Porém foi uma das iniciativas fundamentais para o surgimento do paradigma 84

85 MIC Model Integrated Computing Pesquisa da Vanderbilt University Três elementos principais Tecnologia para modelagem específica de domínio Conjunto de ferramentas para modelagem Frameworkpara análise formal, verificação e transformação de modelos GME Generic Modeling Environment 85

86 Software factories Jack Greenfield, Keith Short, Steve Cook, and Stuart Kent. Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools. Wiley, Abordagem para desenvolvimento de software Reutilização sistemática MDD tem um papelimportante 86

87 Software factories Pense em uma fábrica tradicional Estrutura projetadapara produzir uma determinada família ou linha de produtos Trêselementos Esquemada fábrica de software: descreve o que é necessário para construir os produtos da fábrica Template da fábrica: é uma instância do esquema Ambienteextensível: ferramentas utilizadas para a produção, configuradas através do template 87

88 MDD e software factories Modelos são usados para Capturar especificações em alto nível (intenção) Transformações são usadas para Gerar implementação automaticamente Outras checagens realizadas em modelos Diferentemente da MDA Menos interesse em portabilidade e independência de plataforma Maior foco em produtividade e reutilização 88

89 Software factories - tecnologias Microsoft Visual Studio DSL Tools Ferramenta para definição de linguagens específicas de domínio Geração de código Outras funções 89

90 Eclipse modeling Série de ferramentas e protótipos Origem e influência do MOF Linha própria INRIA Institut National de Recherche en Informatique et en Automatique França Universidade de Nantes França Borland IBM 90

91 Projetos Eclipse Modeling Eclipse Modeling Framework Graphical Modeling Framework Textual Modeling Framework Xtext TCS UML2Tools 91

92 Projetos Eclipse Modeling Model to Model Transformation Atlas Transformation Language Xtend Model to Text Transformation Java Emitter Templates Xpand Generative Modeling Technologies Incubadora de projetos inovadoresrelacionados a modelagem AM3, AMW, MOFScript, etc. 92

93 RECAPITULANDO 93

94 Problema Solução Solução Implementação 94

95 Ferramenta de modelagem Transformações Produto Desenvolvedor Compiladores Benefícios 95

96 DSL UML MIC Software factories TMF MDA Eclipse 96

97 Fim da parte 1 Perguntas? Sugestões: Qual a relação MDD / métodos ágeis? E quanto à gerência de configuração? Como são realizados os testes no MDD? Quanto tempo ainda vai demorar? Vai ter coffee break? O que vai cair na prova? Quem ganhou a corrida de F1? O que pesa mais? 1 Kg de penas ou 1 Kg de chumbo? 97