Desenvolvimento Orientado a Modelos

João Paulo A. Almeida (jpalmeida@ieee.org)

http://nemo.inf.ufes.br

Departamento de Informática /

Programa de Pós-Graduação em Informática

Universidade Federal do Espírito Santo

Informações gerais •  Página web: http://nemo.inf.ufes.br/jpalmeida •  Horário: sextas-feiras: 9:00-12:00 •  Local: CT-VII Aquário •  Twitter: @mdd_ufes

Objetivo •  Apresentar os conceitos básicos, aplicações e

pesquisa na área de Desenvolvimento Orientado a Modelos (Model-Driven Design).

•  Serão abordadas diversas linguagens de modelagem e vários domínios e aspectos de modelagem.

O que é um modelo?

O que é um modelo? •  Representação simbólica da “realidade” •  Resultado de um processo de abstração

– Remoção/omissão de detalhes irrelevantes –  Irrelevante obviamente depende do propósito da

abstração

•  Representação de algo a ser construído – Ex. plantas baixas de um prédio, plantas em

projeto de uma ponte •  Representação de algo a ser analisado

– Ex. modelo de avião para ensaio no túnel de vento

O que é um modelo? •  Representação precisa, sem ambiguidades •  Representação “formal”

O que é um modelo?

Qual é o objeto dos nossos modelos? •  Reformulando:

–  “O que estamos desenvolvendo?” •  Sistemas de Informação e aplicações em geral

– Pense em todos os aspectos do ciclo de vida: análise, projeto, codificação, ...

•  Organizações (nas quais os sistemas estão embutidos) – Organização – Processos de negócios – Papéis que os sistemas podem desempenhar – Requisitos impostos aos sistemas

•  Infraestruturas / frameworks de execução

Parte do problema...

http://www.robelle.com/library/smugbook/tree.gif

Parte do problema...

http://www.robelle.com/library/smugbook/tree.gif

Parte do problema...

http://www.robelle.com/library/smugbook/tree.gif

Parte do problema...

Parte do problema...

http://www.robelle.com/library/smugbook/tree.gif

Mais uma parte do problema...

Como o cliente foi cobrado

Partes do problema... Comunicação •  Problema de comunicação

– Expressar – Entender – Problema este que se relaciona tanto com os

conceitos (semântica) quanto com os aspectos sintáticos (ex. visuais)

– Se relaciona a todos os stakeholders •  Clientes • Gerentes, marketeiros, “analista de relacionamento” •  Projetistas, “designers”, analistas, arquitetos de TI, líder

de projeto •  Programadores •  Equipe de teste, equipe de manutenção, equipe de

instalação, etc.

Partes do problema... Solução •  Processos de desenvolvimento/modelagem

objetivam achar soluções para problemas •  Problemas potencialmente complexos

(intrinsicamente complexos) •  Modelagem como veículo de solução de

problemas •  Como expressar toda a complexidade do que

está nas nossas cabeças (das arquiteturas) nos modelos? – Domínio do problema – Domínio da solução

•  Sem impecilhos •  Sem complexidade acidental

Evolução / Manutenção

Evolução / Manutenção

Evolução / Manutenção

Relação entre modelos e sistema(s) •  Não somente da perspectiva manutenção /

evolução •  Se os modelos não são “conectados” ao(s)

sistema(s) eles se tornam irrelevantes durante o processo de desenvolvimento – Fidedignidade, veracidade (“truthfulness”)

•  Ou pior durante sua confecção (modelagem) – Quem vai levar a sério modelos que serão

esquecidos? •  Esses são os maiores problemas para o

descrédito do uso de modelos... “CASE” tradicional

Relação entre modelos e sistema(s) •  Objetivo final é “Extreme Non-Programming” •  Elevar o nível de abstração da atividade do

desenvolvedor •  Modelos “ricos” em expressividade, sem

detalhes acidentais de tecnologias

Pra que serve um modelo? •  Facilitar o projeto em todos os níveis

arquiteturais – Facilitar engenharia de requisitos, levantamentos – Facilitar achar soluções técnicas adequadas

•  Prescrever a construção –  Inclusive automática

•  Permitir a análise –  Incluindo validação, verificação

•  Facilitar a comunicação (com stakeholders) •  Guiar os testes •  Manter controle sobre evolução e manutenção

Tópicos a serem abordados •  Conceituação: fundamentos, abstração, modelos,

arquitetura, viewpoints, níveis de modelos •  Sintaxe e semântica •  Metamodelagem (MOF/EMF) e engenharia de

linguagem de modelagem •  Modelagem de Comportamento, Interação •  Modelagem Estrutural •  Modelagem de Organizações e Processos de Negócio •  Modelagem Específica de Domínio (Domain-Specific

Modelling) •  Padrões OMG: UML, OCL, MOF (e alternativas EMF) •  Transformações, sincronização, rastreabilidade de

modelos •  Teste orientado a modelos (Model-Driven Testing) /

validação e verificação de modelos •  Qualidade de linguagens gráficas e modelos gráficos

Avaliação •  2 trabalhos •  1 teórico

– Envolvendo conceituações básicas e a teoria de desenvolvimento orientado a modelos

•  1 prático – Envolvendo modelagem e geração de código – Definido individualmente para cada dupla (ou

aluno) visando abordar domínio relevante para a dissertação... (a combinar!)

Material didático •  Vários artigos e tutoriais online e trechos de livros •  Tese de Doutorado (páginas 9 a 18)

http://www.inf.ufes.br/~jpalmeida •  Oscar Pastor, Juan Molina, Model-Driven Architecture in Practice •  Harel, D. and Rumpe, B. 2000

Modeling Languages: Syntax, Semantics and all that Stuff, Part I: the Basic Stuff. Technical Report. UMI Order Number: MCS00-16., Weizmann Science Press of Israel

•  Vissers, C.A. and van Sinderen, M.J. and Ferreira Pires, L. (1993) What makes industries believe in formal methods. In: Protocol Specification, Testing and Verification XIII, Proceedings of the IFIP TC6/WG6.1 Thirteenth International Symposium on Protocol Specification, Testing and Verification, PSTV XIII, 25-28 May 1993, Liege, Belgium. pp. 3-26. IFIP Transactions C-16. North-Holland. ISBN 0-444-81648-8

•  João Paulo A. Almeida, Maria-Eugenia Iacob and Pascal van Eck, "Requirements Traceability in Model-Driven Development: Applying Model and Transformation Conformance", Information Systems Frontiers, Springer, 2007, ISSN 1387-3326 (print) 1572-9419 (online). [pdf, online]

Próxima Aula •  Discussão das seções “How this book is

organized” e “The purpose of this work” do livro “Model-Driven Architecture in Practice”

•  Buscar entender: – Críticas que o texto faz às práticas atuais de

desenvolvimento – Visão dos autores sobre o que é MDD

•  Faça uma leitura crítica do texto – O que os autores não mencionam mais deveriam

mencionar? – O que eles prometem? – Simplificam demais as coisas?