MSOO 2008.2

Flexibilidade:◦ Regras de Negócios Dinâmicas◦ Customização de Aplicações pelos Usuários Finais

Agilidade:◦ As soluções devem atender a prazos cada vez mais agressivos com

redução do ciclo de desenvolvimento e aumento de produtividade. Interoperabilidade:

◦ Intergração de Sistemas Distribuídos e Heterogêneos◦ Evolução Rápida da Tecnologia da Computação

Qualidade:◦ As soluções devem possuir um nível de qualidade cada vezmais elevado

para atender as expectativas Redução de Custos

Como nós podemos construir e integrar aplicações de modo eficiente?

Chave para gerenciar a complexidade das aplicação atuais:◦ Padrões de Projeto◦ Frameworks (Infraestruturas)◦ Desenvolvimento Baseado em Componentes (DBC)◦ MDA

Pontos Chave:◦ Reutilização de artefatos de software◦ Facilitar a manutenção e evolução◦ Integração◦ Qualidade

O simples uso da OO não garante que obtenhamos sistemas confiáveis, robustos, extensíveis e reutilizáveis.

O foco das metodologias de desenvolvimento está na solução em si (o que e como) e não em suas justificativas (porque).

É difícil compartilhar a experiência entre experts e novatos.

Aumentar o nível de reutilização

Padrões capturam soluções recorrentes e as nomeiam o Projeto e comunicação em um nível alto de abstração

Permitem compartilhar experiências bem sucedidas na resolução de problemas recorrentes;

Compõem um vocabulário de alto nível para discussão de questões relativas ao projeto de sistemas de software;

Permitem que os desenvolvedores concentrem seus esforços nos aspectos relacionados ao negócio.

Sub-sistema semi-acabado feitos para serem estendidos◦ Voltados para domínios particulares em termos de

conceitos específicos ‘Projeto’ + ‘Código’

◦ Projeto Pelo congelamento de certas decisões de projeto

◦ Código Pelo conjunto de classes abstratas e suas implementações

padrão

Significante acréscimo de produtividade para aplicações específicas◦ Reutilização

Otimização de utilização de recursos◦ Programadores experientes

Desenvolvimento de frameworks◦ Programadores novatos

Fazem aplicativos a partir dos frameworks Impõe um processo de desenvolvimento

◦ Decisões de projeto embutidas nos frameworks

Complexidade de desenvolvimento

Infraestrutura para desenvolvimento de software definido pela OMG

Diferencial está no fato do desenvolvimento ser baseadonas atividades de modelagem

Forma de desvincular a arquitetura do sistema da sua implementação.

Separação entre a especificação das operações do sistema e os detalhes das funcionalidades de uma plataforma específica.

No ciclo de desenvolvimento tradicional há, de maneira geral, as fases:◦ Levantamento de requisitos, análise, design, codificação, testes e

implementação Geralmente, no final de um projeto, a aplicação desenvolvida nem

sempre reflete as definições da fase de análise e design◦ Existem alterações que são feitas apenas na codificação◦ Isto se deve ao fato de muitas vezes não haver uma ferramenta

automatizada e integrada para acompanhar todo o ciclo e facilitar a análise de impacto de uma alteração

Em cada fase são produzidos textos e documentos estáticos◦ Não possuem nenhum recurso de atualização de modo automático das

alterações ou melhorias realizadas nas fases anteriores A produtividade cai durante o ciclo de desenvolvimento,

principalmente no momento da manutenção da aplicação

As fase não diferem muito A grande diferença está nos

artefatos/documentos gerados durante o processo de desenvolvimento

Esses documentos são modelos que podem ser "entendidos pelos computadores"

Estas informações não são estáticas e possuem uma ligação com a sua fonte◦ Se uma alteração for definida em uma etapa, as demais

etapas automaticamente receberão a referida alteração

CIM (Modelo Independente de Computação) PIM (Modelo Independente de Plataforma)

◦ Representa a futura aplicação independentemente da implementação tecnológica Não há a preucupação se o código gerado será Java ou C++, se a

base de dados será Oracle ou DB2

◦ Modelagem do negócio PSM (Modelo Específico de Plataforma)

◦ Modelo voltado para a tecnologia que será utilizada para gerar o sistema

◦ O PIM é transformado em um ou mais PSM´s Código (Modelo de Código)

◦ Passo final no desenvolvimento que envolve a transformação de cada PSM em código

Produtividade◦ Maior prioridade ao PIM◦ Maior produtivade pois o desenvolvedor não precisará se preocupar com detalhes

da implementação◦ Maior atenção aos problemas de negócio que a aplicação precisa resolver

Portabilidade◦ O PIM pode ser gerado para vários PSM´s

Interoperabilidade◦ Os PSM´s devem se comunicar

Manutenção e Documentação◦ Do custo total de uma aplicação, 20% está relacionado ao desenvolvimento e 80%

a manutenção Não adianta gerar código, a ferramenta deve ajudar quando houver a necessidade de

mudança "Andar sobre a água e desenvolver software a partir de uma especificação são fáceis se

ambos estão congelados!"

◦ Uma boa ferramenta deve manter a sincronia entre os modelos Alto nível de abstração (Revolução MDA)

Stereótipos◦ Representados com << > >

Exemplo◦ Book é uma classe

stereótipo herda de classe UML

◦ Book é uma entidade Possui uma representação no banco de dados

◦ Entity é um novo construtor Herda de classe UML

◦ Objetos livres podem ser persistidos Exemplo: tabela livro

Stereótipos/Tagged Values◦ Interpretados por geradores de código

Exemplo◦ Gerador de modelo para EJB◦ Stereótipo entity

objetos persistentes ~ Entity Beans◦ Stereótipo PK

Marca atributos como Primary Key

Open-source: http://team.andromda.org

Suporta XMI, OCL

EJB, Hibernate, Spring, XML Schema, Java, Struts, OCL translations/queries

Em junho de 2003, EDS publicou um estudo de caso com o título "Driving business agility with Model Driven Architecture"

O objetivo era avaliar de que forma a MDA pode acelar o desenvolvimento

O estudo utilizou a aplicação "Pet Store" desenvolvida pela Sun utilizada para demonstrar padrões de projeto

A Pet Store é uma típica aplicação de e-commerce Vários fornecedores de servidores de aplicação a utilizam

para ilustrar a compatibilidade de seus produtos com a arquitetura J2EE

O estudo foi realizado comparando:◦ Aplicação gerada manualmente (J2EE Pet Store)◦ Versão da Microsoft com a mesma funcionalidade (.Net Pet

Shop)◦ Versão gerada com MDA (J2EE Pet Store utilizando OptimalJ)

O gráfico mostra que MDA permite desenvolver aplicações complexas com um esforço manual muito menor

Para cada 200 linhas de código JAVA geradas automaticamente foram escritas de 1 a 4 linhas de código manualmente

Quanto maior e mais complexo o projeto, mais evidentes ficam os ganhos na aplicação do MDA

A experiência com modelagem UML é fundamental

MDA deve ser adotado desde o início do projeto

Toda quebra de paradigma causa polêmica Toda evolução vem acompanhada de ceticismo Ao mesmo tempo, esse processo exige uma reavaliação se o que

fizemos e como fazemos pode ser melhorado Quando olhamos por esse ângulo, vemos que estamos evoluindo As empresas querem se concentrar no seu negócio e querem que a

tecnologia seja uma ferramenta Nós queremos fazer as melhores aplicações e da melhor forma O código é importante, mas ele é o resultado de uma

transformação◦ O código é uma tradução de negócio para determinado ambiente

computacional◦ Toda inteligência está no PIM◦ No futuro, não teremos que nos preocupar com a codificação de uma

aplicação◦ Teremos ferramentas capazes de gerar o código quase na sua totalidade

Linha de Produtos de Software Variabilidade Desenvolvimento Baseado em Componentes Programação Orientada a Aspectos Fábricas de Software Linguagem Específica de Domínio Programa Generativo Web Semântica Ontologias etc

Modelo não serve somente para documentação, mas têm papel fundamental na implementação.

Integração e Interoperabilidade como palavras chave da MDA. Redução de prazo e custos no desenvolvimento de novas aplicações Necessidade de codificação manual reduzida MDA acelera o ciclo de desenvolvimento de aplicações e padroniza o

processo de desenvolvimento MDA também aumenta o nível de reuso nos projetos de desenvolvimento.

Ela permite que a solução evolua independentemente das tecnologias envolvidas na implementação

Com o MDA, a documentação do projeto, ou seja, os modelos UML têm maior valor, porque agora o modelo não serve apenas para documentar, e sim para a geração do próprio sistema

As ferramentas não estão totalmente maduras, porém já podem ser utilizadas. Com a evolução das ferramentas, a tendência é que no futuro MDA seja altamente utilizado no desenvolvimento de sistemas de informação

MDA ou XP? A convivência entre os dois é possível?