A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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.

Apresentações semelhantes


Apresentação em tema: "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."— Transcrição da apresentação:

1 MSOO

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

3

4 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

5

6 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

7 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.

8 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

9 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

10 Complexidade de desenvolvimento

11 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.

12 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

13 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

14 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

15

16 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)

17 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

18 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

19

20

21 Open-source: Suporta XMI, OCL EJB, Hibernate, Spring, XML Schema, Java, Struts, OCL translations/queries

22 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)

23 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

24 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

25 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

26 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

27 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?


Carregar ppt "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."

Apresentações semelhantes


Anúncios Google