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?