evolução no desenvolvimento de software com a utilização ... · 3.2.4.1 pim – modelo ......
TRANSCRIPT
Universidade Federal de Santa Catarina
Anna Carla Verner
Helder dos Santos Puia
Evolução no desenvolvimento de software com a utilização do MDA
Florianópolis, 13 de Outubro de 2004.
2
1. Introdução......................................................................................................................... 4 2. Problemas atuais da Engenharia de Software ........................................................... 5
2.1 PRODUTIVIDADE X QUALIDADE ......................................................................... 5 2.2 PORTABILIDADE ...................................................................................................... 7 2.3 INTEROPERABILIDADE ......................................................................................... 9 2.4 MANUTENÇÃO........................................................................................................ 10 2.5 DOCUMENTAÇÃO .................................................................................................. 12
3. Model Driven Architecture............................................................................................ 14 3.1 OBJECT MANAGEMENT GROUP ......................................................................... 14 3.2 MDA........................................................................................................................... 14
3.2.1 O QUE É MDA? ................................................................................................. 14 3.2.2 Arquitetura........................................................................................................... 15
3.2.2.1 O Núcleo .................................................................................................... 16 3.2.2.2 Camada Intermediária ............................................................................. 20 3.2.2.3 Pervasive Services................................................................................... 20
3.2.3 Ciclo de Vida ....................................................................................................... 21 3.2.4 Funcionamento .................................................................................................... 22
3.2.4.1 PIM – Modelo independente de plataforma ......................................... 23 3.2.4.2 PSM – Modelo específico para plataforma .......................................... 23 3.2.4.3 Transformação .......................................................................................... 25
4. Como MDA pode ajudar na solução dos problemas atuais.................................... 29 4.1 Produtividade.............................................................................................................. 29 4.2 Portabilidade............................................................................................................... 30 4.3 Interoperabilidade....................................................................................................... 30 4.4 Manutenção e Documentação..................................................................................... 32
5. Ferramentas MDA ......................................................................................................... 33 5.1 Compuware OptimalJ ................................................................................................. 33 5.2 Rational XDE ............................................................................................................. 35 5.3 AndroMDA................................................................................................................. 37
6. MDA na Prática.............................................................................................................. 39 6.1 Aplicação de Controle de Compra e Venda de Mercadorias...................................... 39 6.2 Arquitetura da aplicação............................................................................................. 40 6.3 Aplicando o MDA ...................................................................................................... 40
6.3.1 PIM e PSM .......................................................................................................... 41 6.3.2 Transformações PIM para PSM .......................................................................... 42 6.3.3 Transformação de PSM para modelo de código.................................................. 42 6.3.4 Três Níveis de Abstração..................................................................................... 43 6.3.5 Transformação PIM para Relacional................................................................... 44
6.4 PIM ............................................................................................................................. 44 6.5 Modelo Relacional...................................................................................................... 45 6.6 Modelo de Componentes EJB .................................................................................... 46 6.7 Modelo Web ............................................................................................................... 48 6.8 Última Transformação – PSM para código ................................................................ 49
6.8.1 Modelo Relacional para Código SQL ................................................................. 49 6.8.2 Modelo EBJ para código Java ............................................................................. 50
6.8.2.1 Entity Bean ................................................................................................ 50
3
6.8.2.2 Session Bean ............................................................................................ 52 6.8.2.3 Session Façade ........................................................................................ 53
6.8.3 Transformação do Modelo WEB para Código .................................................... 54 6.8.3.1 JSP ............................................................................................................. 55 6.8.3.2 Struts .......................................................................................................... 56
6.9 Resultado .................................................................................................................... 57 7. Conclusão....................................................................................................................... 60 8. Referência Bibliográfica ............................................................................................... 62 9. Apêndices ....................................................................................................................... 64
9.1 Planilha de Use Case Points ....................................................................................... 64 9.2 Scripts ......................................................................................................................... 66
9.2.1 Script de criação .................................................................................................. 66 9.2.2 Script de Remoção............................................................................................... 68
9.3 Códigos....................................................................................................................... 69
4
1. Introdução
Uma das principais propriedades que um software deve apresentar é
capacidade a mudanças e adaptabilidade tanto a requisitos quanto ao ambiente
computacional no qual está inserido. Sabe-se que não é nada trivial atingir essa
capacidade, principalmente mantendo produtividade.
O MDA, Model Driven Architecture, é um framework que promove o uso de
desnvolvimento de modelos independentes dos detalhes da implementação dando
ao sistema uma flexibilidade maior. A maior parte do processo é automatizada
não só mantendo como aumentando a produtividade e qualidade do sistema.
O nosso objetivo neste trabalho é relatar o uso desse framework em uma
abordagem que pretende apresentar soluções para os principais problemas de
engenharia de software atualmente: Produtividade, portabilidade,
interoperabilidade, manutenção e documentação.
5
2. Problemas atuais da Engenharia de Software
Atualmente, no desenvolvimento de software, nos deparamos com uma
série de dificuldades que até pouco tempo atrás não estavam presentes.
Antigamente os sistemas eram mais simples, não precisavam ser integrados a
outros sistemas e em sua maioria eram sistemas batch, que não tinha interface
com o usuário.
Nesta seção apresentaremos algumas das dificuldades encontrada no
desenvolvimento de software atualmente.
2.1 PRODUTIVIDADE X QUALIDADE
Uma das preocupações da indústria de software é a necessidade de criar
software e sistemas corporativos muito mais rapidamente e a um custo mais
baixo. Para fazer bom uso da crescente potência dos computadores, precisamos
de um software de maior complexidade. Ainda que mais complexo esse software
também precisa ser mais confiável. A alta qualidade é fundamental no
desenvolvimento de software[MAR95].
Existem vários fatores que devem ser avaliados quando falamos em
qualidade de software. Mas o que é exatamente qualidade em software?
Existem várias definições para qualidade em software, uma das mais aceita
é a seguinte.
“Conformidade com requisitos funcionais e de desempenho explicitamente
declarados, padrões de desenvolvimento explicitamente documentados e
características implícitas, que são esperadas em todo software desenvolvido
profissionalmente”.
De forma geral, este conceito explica qualidade em software, mas que
características um software deve possuir para que possamos avaliar a qualidade
do mesmo?
6
Devemos levar em consideração ao avaliar qualidade em software fatores
internos e externos.
Alguns aspectos como rapidez, facilidade de uso, que estão presentes ou
não em um software, podem ser detectadas pelos usuários finais. Estes aspectos
são chamados fatores externos de qualidade. Outros aspectos como
modularidade, facilidade de leitura, são fatores internos, perceptíveis apenas a
profissionais de computação que tem acesso ao código fonte do sistema[MEY97].
Alguns dos mais importantes fatores de qualidade estão listados abaixo:
1. Corretude: é a habilidade do software de executar suas tarefas de
forma exata, como definido na especificação.
2. Robustez: é a habilidade do software de reagir de forma apropriada
sob condições anormais.
3. Extendibilidade: é a facilidade de adaptação do software a
mudanças de especificação.
4. Reusabilidade: é a habilidade dos componentes de software a
servirem para construção de muitas outras diferentes aplicações.
5. Compatilidade: é a facilidade de combinação de componentes de
software a outros.
6. Eficiência: é a habilidade do software de usar menos recursos de
hardware que for possível, como tempo de processador, espaço
ocupado em memória e disco, largura de banda usada no serviço de
comunicação.
7. Portabilidade: é a facilidade de transferir um software a vários tipos
de hardware e sistemas operacionais.
8. Facilidade de uso: é a facilidade com que pessoas de diversas
qualificações podem aprender a usar o software e ajuda-los a
resolver problemas. Isso inclui a facilidade de instalação, operação e
monitoramento.
Existem ainda diversos outros fatores que influenciam na qualidade do
software e existem também diversos normas e padrões muito aceitos e utilizados
7
como as normas ISO de qualidade e CMM, mas que não são objetivos deste
estudo.
Aí esta um grande dilema, como garantir os vários aspectos de qualidade e
ao mesmo tempo manter uma boa produtividade sem comprometer custos e
prazos.
O principal objetivo da engenharia de software é aumentar a produtividade
na construção de aplicações computacionais. Ela pode atingir esse objetivo de
várias maneiras. Duas das mais importantes são o uso de ferramentas
automatizadas e a identificação dos dados e processos comuns, de modo que
tenham que ser projetados uma vez apenas, e não separadamente para diversas
aplicações[MAR89].
A maneira mais conveniente de se conseguir produzir software com
qualidade sem comprometer custo e prazos, é com um bom planejamento, com
auxílio de ferramentas de apoio ao processo de desenvolvimento e uma equipe
capacitada para tal, apenas assim será possível atingir as metas estabelecidas no
início do projeto.
2.2 PORTABILIDADE
A indústria de software tem uma especial característica que a diferencia da
maioria das outras indústrias. A cada ano, e cada vez mais rápido, novas
tecnologias estão sendo inventadas e se tornando populares (por exemplo, Java,
Linux, XML, HTML, SOAP, UML, J2EE, .NET, ASP, Flash, Web Services, e assim
por diante). Muitas companhias precisam seguir estas novas tecnologias por boas
razões:
• A tecnologia é definida pelo cliente;
• Resolver alguns problemas reais;
• Ferramentas deixam de dar suporte a velhas tecnologias e passam a
focar nas novas[KLE03].
Portabilidade é reconhecidamente um atributo desejado para a maioria dos
softwares.
8
“Um software é portável sobre dois ambientes distintos se o custo de
transportar e adaptar este software para o novo ambiente é menor que o custo de
desenvolve-lo novamente”.
Existem vários fatores que afetam a portabilidade, dentre eles estão:
• Diferenças entre sistemas operacionais;
• Diferenças entre linguagens de programação;
• Diferenças entre arquiteturas de máquinas.
Podemos relacionar ainda a portabilidade, algumas sub-categorias:
• Adaptabilidade: atributos do software que evidenciam sua
capacidade de ser adaptado a ambientes diferentes, sem a necessidade
de aplicação de outras ações além daquelas fornecidas para esta
finalidade.
• Capacidade para ser instalado: atributos do software que evidenciam
o esforço necessário para sua instalação num ambiente especificado.
• Conformidade: atributos do software que o tornam consonantes com
padrões ou convenções relacionadas à portabilidade.
• Capacidade para substituir: atributos do software que evidenciam sua
capacidade e esforço necessário para substituir um outro software, no
ambiente estabelecido para esse outro software.
As novas tecnologias oferecem benefícios que não podem ser deixados de
lado. Por isso as pessoas vêm mudando de tecnologia constantemente. Como
conseqüência, os investimentos nas tecnologias perdem valor e se tornam
obsoletos.
A situação é ainda mais complexa porque as tecnologias evoluem também.
Elas vêm em diferentes versões, sem a garantia de que serão compatíveis com as
anteriores. As ferramentas geralmente suportam apenas duas ou três das mais
recentes versões.
9
Como conseqüência, os softwares existentes são sempre portados para as
novas tecnologias, ou para novas versões da tecnologia existente, ou então
passam a operar com as tecnologias antigas, como sistemas legados.
2.3 INTEROPERABILIDADE
Softwares raramente vivem sozinhos. Muitos sistemas precisam se
comunicar com outros, muitas vezes com sistemas já existentes.
“Interoperabilidade refere-se à habilidade de dois ou mais sistemas
(computadores, recursos, redes, software, e outros componentes de tecnologia da
informação) de interagir com o outro e trocar dados de acordo com um método
prescrito a fim de atingir resultados esperados [ISO ITC-215]”.
Alguns benefícios da interoperabilidade são:
• Os clientes podem escolher a tecnologia mais adequada para as
suas necessidades.
• Aumento da competição, levando a um aumento da qualidade e
diminuição dos preços.
• Redução do uso de tecnologia obsoleta.
Pode-se ter muitos ganhos com a interoperabilidade, mas ela não vem de
graça, exige muito trabalho adicional, e existem várias barreiras a serem
quebradas, dentre as dificuldades encontradas para se atingir a interoperabilidade
estão o tamanho e complexidade dos dados, performance, heterogeneidade, taxa
de mudança e diferença entre domínios de aplicação. Estes itens estão
detalhados abaixo.
• Tamanho/complexidade dos dados: quando o conjunto de dados é
relativamente pequeno ou simples, a interoperabilidade pode ser
atingida convertendo os dados de saída de um componente
conforme entrada do outro. Mas se o conjunto de dados é muito
10
grande, a memória utilizada e a performance associada a esta
conversão pode ser inaceitável.
• Performance: A interoperabilidade exige uma alta performance, pois
para atingi-la é necessário a implementação de várias camadas de
interfaces virtuais, o overhead gerado por estas camadas podem
atingir níveis inaceitáveis.
• Heterogeneidade: Nós enfrentamos freqüentemente uma
diversidade grande de sistemas computacionais, de origens dos
dados e de formatos, de usuários, de línguas, e de modelos de
programação. Esta heterogeneidade ao mesmo tempo em que
estimula, também dificulta a interoperabilidade.
• Taxa de mudança: Tecnologia computacional (hardware e
software), estão sempre mudando. Quando uma nova tecnologia se
torna disponível uma enorme pressão para os usuários passaram a
utiliza-la passa a existir. Esta volatilidade geralmente faz com que a
interoperabilidade tenha uma baixa posição na lista de prioridades.
• Diferenças entre domínio de aplicação: Inevitavelmente,
diferentes aplicações têm diferentes requisitos. Assim como a
heterogeneidade, esta diferenças aumentam a complexidade quando
vamos gerar uma ferramenta para garantir a interoperabilidade. Uma
das dificuldades é a necessidade de adaptar a ferramenta, para
acomodar a terminologia e a semântica associadas com o domínio
particular da aplicação.
2.4 MANUTENÇÃO
A manutenção faz parte da vida do software, pois de maneira geral, todo
software sofre modificações. Essas modificações normalmente são devidas a
mudanças de legislação, inclusão ou alteração de funcionalidades e correções de
erros. Um software pode apresentar os seguintes tipos de manutenções:
11
• Corretiva – Quando o sistema não foi corretamente desenvolvido,
sendo que na manutenção devemos diagnosticar e corrigir esses
problemas de desenvolvimento.
• Adaptativa – Realizada pra acompanhar mudanças e evoluções de
hardware.
• Perfectiva – Realização de melhorias que surgiram com a utilização o
software. Como por exemplo, a alteração de uma funcionalidade ou a
inclusão de uma nova.
• Preventiva ou Preditiva – Realizada para aumentar a confiabilidade
ou a manutenibilidade futura do sistema ou software.
A manutenção consome em média 70% de todo o esforço despendido com
a produção do software, mantendo o mesmo em looping e aumentando seu tempo
de vida, claro que não passamos 70% do tempo corrigindo erros, apenas cerca de
20% deste tempo é desprendido em correção, os 80% restante são gastos
adaptando sistemas a modificações no seu ambiente externo, fazendo melhorias
solicitadas pelo usuário e submetendo a reengenharia, para uso futuro.
A manutenção é caracterizada como um iceberg, esperamos que apenas a
parte visível esteja carente de manutenção, porém, normalmente uma massa
enorme de problemas e custos esconde-se sob a superfície. No início dos anos
70, o iceberg de manutenção era suficientemente grande para afundar um porta-
aviões. Hoje, poderia facilmente afundar toda a marinha[PRE01].
Uma vez sendo inevitável ter mudanças quando se constroem sistemas
baseados em computador e para pessoas, devemos desenvolver mecanismos e
processos para avaliar, controlar e fazer modificações, visando facilitar as
mudanças e reduzir a quantidade de esforços despendidos em manutenção. Um
mecanismo que contribui para uma melhor manutenibilidade do sistema é a
documentação do sistema.
A manutenção torna-se mais difícil devido ao uso de documentação
inadequada. Quando se realizam alterações, quase sempre se esquece de fazer
as atualizações correspondentes na documentação. Essa então não mais reflete o
sistema.
12
2.5 DOCUMENTAÇÃO
A documentação nos conta toda a história de um sistema, desde sua
concepção, passando pelo seu desenvolvimento e acompanhando sua
manutenção, mostrando-nos o que fazem, como fazem e para quem fazem. Ela
inicia no momento da elaboração e segue por todas as etapas do projeto. A
documentação mais do que qualquer coisa faz com que o sistema independam
das pessoas que irão manipula-lo.
A documentação deve ser vista como uma ferramenta de auxílio, pois será
utilizada nos momentos de necessidade por todas as pessoas envolvidas no
sistema. Para cumprir tal papel, deve ser elaborada no final de cada fase
determinada pela metodologia adotada bem como necessita ser atualizada
sempre que houver uma modificação.
Os documentos devem conter informações necessárias que possibilitam
concluir sobre a finalidade, como foram feitos e o que é necessário para colocar o
sistema em funcionamento.
Os principais objetivos de documentar são:
• Divulgar e deixar claro o que faz o sistema, como utiliza-lo, as suas
vantagens, operação e requisitos para funcionamento;
• Mostrar quais as técnicas ou ferramentas utilizadas para o
desenvolvimento, tempo, custos, equipe, cronogramas, metodologia,
integração, etc.;
• Orientar e treinar o usuário na operação do sistema;
• Possibilitar a garantia para a empresa da continuidade do
funcionamento do sistema.
A documentação está inserida num contexto de produção de variada gama
de informações por pertencer ao processo de desenvolvimento de software, onde
a qualidade e disponibilidade de informação sobre diferentes tipos de serviços
influenciam diretamente a qualidade e agilidade do processo e do produto,
acumulando grande quantidade de documentos.
13
Existem algumas diretrizes de qualidade que uma boa documentação deve
apresentar. Tais diretrizes estão calçadas em três pilares:
• Completa: Não deve faltar nenhuma informação para facilitar a
compreensão do usuário, lembrando sempre que nem tudo que é
irrelevante para um é para outro. Podemos eliminar diversas falhas
apenas adotando alguma padronização;
• Precisão: Os documentos devem ser revisados por duas pessoas
com visões diferentes e devem estar em conformidade com as
especificações do sistema;
• Clareza: Devem ser de fácil identificação, localização e organização.
Dados estatísticos demonstram que de 47% a 62% do tempo gasto em
manutenção de sistemas é despendido na tentativa de entender o programa, e
que ler o código fonte custa 3,5 vezes mais do que ler a documentação. Além
disso, 53% dos defeitos são descobertos em trechos tidos como corretos e 10%
são introduzidos durante as alterações. Outros 64% dos defeitos são de lógica,
enquanto 79% são causados por entendimento incorreto do problema. [KET99].
14
3. Model Driven Architecture
A Object Management Group é a entidade idealizadora do MDA e nesta
etapa iniciaremos com uma visão geral sobre a OMG, continuaremos com uma
abordagem sobre o MDA, o que é, como está estruturado e como funciona.
3.1 OBJECT MANAGEMENT GROUP A OMG foi fundada em abril de 1989 inicialmente por 11 companhias
realizando operações independentes sem fins lucrativos. Com o objetivo de
desenvolver excelência tecnológica, comercialmente viável e independente de
especificações proprietárias para a indústria de software. O novo consórcio inclui
aproximadamente 800 membros.
Foi formada para ajudar a reduzir a complexidade, baixar os custos e
acelerar a introdução de novas aplicações padronizadas. A OMG pretende atingir
essa meta através da introdução do MDA.
A OMG é responsável pelo aparecimento de tecnologias como CORBA,
XML, XMI, UML, MOF, CWM, entre outras. A organização é respeitada
mundialmente e as tecnologias criadas pelo grupo são sempre inovadoras e
tendem a se tornar padrões de desenvolvimentos.
3.2 MDA
3.2.1 O QUE É MDA?
O MDA é um framework para desenvolvimento de software. A chave do
MDA é a importância dos modelos no processo de desenvolvimento. Com MDA o
processo de desenvolvimento de software é dirigido pela modelagem do sistema.
MDA define uma abordagem à especificação de sistemas de informação
que separa a especificação das funcionalidades do sistema, da especificação da
implementação dessa funcionalidade numa plataforma específica, abstraindo a
maneira como o mesmo usará as potencialidades de sua plataforma.
15
O objetivo é automatizar algumas das etapas do processo de
desenvolvimento de software incluindo a geração de código para a plataforma
escolhida.
As três principais metas do MDA são a portabilidade, interoperabilidade e
usabilidade baseada na separação de interesses.
Para entender o impacto que o MDA trará para a engenharia de software é
só analisarmos a atuação da OMG e sua influência na indústria de software. A
OMG sempre buscou a definição de normas que facilitassem e padronizassem o
desenvolvimento de sistemas buscando a tão sonhada interoperabilidade.
3.2.2 Arquitetura
O coração da arquitetura está no centro da Figura 1, é baseado nos
padrões de modelagem da OMG: UML, MOF e CWM.
Outras duas camadas completam a arquitetura. A primeira representa as
plataforma que são alvo do framework atualmente e a segunda representa os
serviços que devem existir independente da plataforma adotada.
Figura 1 - Arquitetura MDA
16
3.2.2.1 O Núcleo
O núcleo do MDA compreende um conjunto de UML profiles, desenvolvidos
pela OMG, cada um abrangendo determinada área do processo de
desenvolvimento. Esses profiles representam as características comuns de todos
os ambientes middleware apropriados, porém será independente de qualquer
plataforma específica.
MOF – Meta-Object Facility
O MOF é uma ampla especificação. O principal foco é o gerenciamento de
meta-dados, fornecendo um framework que suporta qualquer tipo de meta-dados
e permita que novos tipos sejam adicionados se necessário.
O que permite isso é sua arquitetura baseada na arquitetura tradicional de
meta-modelos, de quatro camadas que são padronizados por órgão como ISO e
CDIF. Estas camadas estão descritas abaixo:
• Informação: É a camada usada pelos Objetos, e compreendem as
informações que desejamos descrever. Estas informações são
tipicamente referenciadas como “dados”;
• Modelo: Esta camada engloba as informações descritas pelos meta-
dados. Os meta-dados são informalmente agregados como modelos.
• Meta-modelo: Compreende as descrições que definem a estrutura e
semântica dos meta-dados. Meta-meta-dados são informalmente
agregados como meta-modelos. Um meta-modelo pode ser pensado
como sendo uma “linguagem” para descrever diferentes tipos de
dados.
• Meta-meta-modelo: Compreende as descrições que definem a
estrutura e semântica dos meta-meta-dados, em outras palavras, é a
“linguagem” para definição de diferentes tipos de meta-dados.
17
A figura 2 mostra a arquitetura MOF englobando modelos e meta-modelos
para UML e OMG IDL.
Figura 2 - Arquitetura MOF
A arquitetura dos meta-dados de MOF tem algumas características
importantes que a distinguem de outras arquiteturas:
• MOF é orientado a objetos e suporta meta-modelos alinhados com
os modelos de objetos de UML;
• O modelo de MOF é auto descritivo, ou seja, o modelo de MOF é
formalmente definido com seus próprios modelos.
O fato do MOF se autodefinir ajuda a validar seus meta-modelos. Desde
que ele possa se auto descrever, ele deve ser adequado para descrever outros
meta-modelos de mesma complexidade.
UML – Unified Model Language
UML é um sistema de notação, incluindo a semântica, dirigida à
modelagem de sistemas, usando conceitos orientados a objetos. UML é um
padrão aceito pela indústria para a modelagem orientada a objetos.
Ela começou como um esforço conjunto de Grady Booch e Jim Rumbaugh
em 1994, para combinar seus dois métodos populares – os métodos Booch e
18
OMT(Object Modeling Techinque). Mais tarde, Ivar Jacobson se juntou a eles (o
criador do método OOSE, Object Oriented Software Engineering). Em resposta a
uma solicitação da OMG para definir uma linguagem e notação de modelagem
padronizada, UML foi submetida como candidata em 1997.
A OMG aceitou UML, a qual também recebeu a aprovação de fato pela
indústria, uma vez que seus criadores representam métodos de análise e/ou
projeto de primeira geração muito populares.
UML ajuda você a especificar, visualizar e documentar modelos de
software, incluindo sua estrutura e designer, de modo que englobe todos os
requisitos. Você pode utiliza-lo para modelar negócio e também outros sistemas
que não sejam software.
Com UML pode ser modelado qualquer tipo de aplicação, rodando com
qualquer combinação de hardware, sistema operacional, linguagem de
programação e rede. É flexível possibilitando a modelagem de aplicações
distribuídas utilizando qualquer middleware disponível no mercado. UML é
construído baseado em MOF o qual define classe, operações e conceitos
fundamentais que são ajustados naturalmente a linguagens e ambientes
orientados a objetos.
UML forma a fundação do MDA, pois com ele pode-se especificar sistema
independente de plataforma ou especificar para uma plataforma específica e MDA
utiliza essas duas formas.
UML não é uma metodologia, mas sim uma linguagem de modelagem. As
metodologias definem métodos e processos de desenvolvimento para a criação
efetiva de sistemas de software, no entanto, agora, podem faze-lo usando uma
linguagem comum.
CWM – Common Warehouse Model
19
CWM fornece um framework para representar os meta-dados sobre a
origem dos dados, dados alvos, transformação e análises, e o processo e
operação que criam e gerenciam data warehouse e provê informações sobre seu
uso.
O meta-modelo CWM consiste em um conjunto de sub-meta-modelo que
representam os meta-dados comum do warehouse. Os sub-meta-modelos são:
• Data Source: Incluem meta-modelos que representam orientação a
objetos, registros, relacionamentos, multidimensionalidade e XML;
• Data Analysis: Incluem meta-modelos que representam as
transformações de dados, OLAP, Data Mining, informações visuais e
nomenclatura de negócio.
• Warehouse Management: Incluem meta-modelos que representam
processos e resultados de operações warehouse.
Figura 3 - Meta-modelo CWM
Em resumo o CWM é um padrão de meta-dados específico para a
integração de Data Warehouses, e-business e sistemas de negócio inteligentes
em ambientes heterogêneos e distribuídos, através de uma representação e de
um formato de troca de meta-dados. É uma iniciativa do grupo, com o objetivo de
prover um framework orientado a objetos e padronizado para aplicações
20
distribuídas, visando dar suporte a reusabilidade, portabilidade e
interoperabilidade entre componentes de DW.
Utiliza a UML como linguagem de modelagem padrão, organizando os tipos
de meta-dados por assunto segundo categorias e funções num DW.
3.2.2.2 Camada Intermediária
Essa camada compreende os ambientes middleware que são alvo do MDA
atualmente: O ambiente web-service, CORBA principalmente CORBA Component
Model ou CCM, Java incluindo EJB, C#, .NET, XML/SOAP. Se sua plataforma
favorita não estiver nessa lista ou se novas plataformas surgirem os membros da
OMG irão adiciona-las o mais breve possível.
3.2.2.3 Pervasive Services
Todas as aplicações, independente do contexto, dependem de um conjunto
de serviços essências. Esses serviços variam de acordo com a origem do sistema,
mas normalmente incluem serviços de diretórios, segurança, manipulação de
eventos, persistência e transações. Esses serviços estão representados na
arquitetura no anel mais externo.
Ainda que com mesmos objetivos, em termos de implementação esses
serviços quando definidos e construídos em plataformas específicas possuem
características que os restringem das demais plataformas.
No framework MDA os pervasive services são representados no mais alto
nível de abstração. A este nível de abstração, a maneira com que esses serviços
serão implementados na plataforma específica ficará a cargo do framework
deixando transparente o funcionamento para o desenvolvedor.
21
3.2.3 Ciclo de Vida
Historicamente sistemas têm sido desenvolvidos, gerenciados e integrados
usando um grande número de tecnologias, ferramentas e middleware. O que
temos visto ultimamente é uma movimentação gradual para modelos semânticos
mais completos, bem como padrões de representação de comunicação de dados.
Neste aspecto a OMG contribui com as tecnologias já citadas UML, CWM, MOF,
entre outras. Essas tecnologias podem ser usadas para melhor integrar as fases
do ciclo de vida do sistema
O ciclo de vida do MDA não difere muito dos ciclos de vida dos modelos
tradicionais. As mesmas fases podem ser identificadas. Uma das maiores
diferenças está na natureza dos artefatos que são criados durante o processo de
desenvolvimento. Os artefatos são modelos formais que podem ser entendidos
pelo computador.
Na Figura 4 – ciclo de vida do MDA, cada uma das esferas representa uma
das etapas do processo de desenvolvimento, que é bastante similar às demais
metodologias. A primeira etapa é o levantamento de requisitos, em seguida as
etapas de análise, design, codificação, teste e implantação. O que difere são as
saídas das etapas, que são representadas pelos quadrados, onde surgem novos
conceitos e modelos, que serão vistos em mais detalhes a seguir.
22
.
Figura 4 – Ciclo de vida do MDA
3.2.4 Funcionamento
Para entendermos o funcionamento do MDA devemos conhecer os
modelos definidos pela sua arquitetura. Esses modelos são à base do
funcionamento do framework, o que torna possível o alcance dos objetivos
proposto.
Requisitos
Analise
Design
Codificação
Teste
Implantação
Fonte
PIM
PSM
Fonte
Processo
MDA
Especificação De Requisitos
23
3.2.4.1 PIM – Modelo independente de plataforma
Todo projeto em MDA começa com a criação do modelo independente de
plataforma. O objetivo do PIM é expressar apenas as funcionalidades de negócio
e comportamento, devendo ser construído por analista de negócio e de modelo,
sendo o mais preciso possível.
O PIM pode ser refinado tornando-se ainda mais precisos. Para isso
podemos incorporar ao PIM alguns aspectos de tecnologia sempre abstraindo
detalhes de alguma plataforma específica. Por exemplo, todos os ambientes
permitem especificar padrões, alguns dos padrões de modelagem que são
incorporados a todas as tecnologias foram também incorporados ao UML,
tornando fácil à adoção de algum padrão de desenvolvimento, apenas
identificando alguns estereótipos nos modelos.
Além dos padrões de desenvolvimento, neste nível também podem ser
incorporados aos modelos, os pervasive services. Como vimos anteriormente, os
pervasive services são modelados em MDA no mais alto nível de abstração,
sendo este mais alto nível representado pelo PIM.
O PIM pode ser refinado tantas vezes quanto necessário até que se atinja o
nível de precisão desejado. O PIM produzido especifica a funcionalidade e
comportamento do sistema e os links aos pervasive services, finalizada esta etapa
esses modelos serão transformados em outros modelos que levam em
consideração todas as características específicas da plataforma escolhida(PSM).
3.2.4.2 PSM – Modelo específico para plataforma
O PSM é uma visão do sistema do ponto de vista específico da plataforma.
Um PSM combina as especificações no PIM com os detalhes que especificam
como esse sistema usa um tipo particular de plataforma.
Uma vez que a primeira interação do PIM esteja completa o mesmo é
armazenado em MOF e serve como entrada para a produção do modelo
24
específico para a plataforma, como mostrado na Figura 5. Especificações e
extensões UML dão o poder de representar tanto PIM quanto PSM.
Figura 5 - Processo com MDA
Para produzir o PSM é necessário escolher a plataforma alvo ou
plataformas para os modelos da aplicação. Caso a ferramenta de desenvolvimento
utilizada não saiba qual a plataforma e quais pervasive services serão utilizados,
essas informações deverão ser fornecidas.
25
Durante o mapeamento as características de tempo real e informações de
configuração que projetamos de uma maneira geral são convertidas para
formulários específico requeridos pela plataforma alvo. Através de um
mapeamento padrão, as ferramentas automatizam as conversões possíveis
deixando os pontos ambíguos para serem implementados a mão. As versões mais
antigas do MDA podem requerer ajustes consideráveis, sendo que a quantidade
diminuirá com os profiles e o amadurecimento dos mapeamentos.
3.2.4.3 Transformação
O processo MDA se parece muito com o processo de desenvolvimento
tradicional, a grande diferença e vantagem do processo MDA está na
transformação de PIM para PSM, sendo que este processo pode e deve ser
automatizado para que se obtenha todos os benefícios que o framework oferece.
Ocorrem duas transformações essências no processo, a primeira é a
transformação do PIM para PSM e a segunda de PSM para código. A
transformação de PSM para código não é nenhuma novidade, uma vez que este
modelo é muito próximo ao código. Essas transformações são baseadas em
mapeamento que consistem em um conjunto de regras de transformação que são
especificações não ambíguas de modo que o modelo possa ser usado para criar
outro modelo.
A figura 6 mostra a descrição do metamodelo MDA. PIM, PSM e técnicas
de mapeamento são baseadas em metamodelos expressados preferencialmente
por tecnologias OMG (MOF, UML ou CWM).
26
Figura 6 – Metamodelo MDA
Em MDA, uma das características chave é a noção de mapeamento.
Mapeamento é um conjunto de regras e técnicas usadas para modificar um
modelo a fim de gerar outro. Os mapeamentos são usados para transformar:
• PIM para PIM – Esta transformação é usada quando os modelos são
refinados, filtrados ou especializados durante o ciclo de vida do
desenvolvimento sem necessitar nenhuma informação que dependa
da plataforma. O mapeamento mais óbvio é o da análise para o
projeto. Mapeamentos PIM para PIM são usados geralmente para o
refinamento do modelo.
• PIM para PSM – Esta transformação é usada quando o PIM está
refinado o suficiente para ser projetado para a infraestrutura
específica. A projeção é baseada nas características da plataforma.
A descrição destas características deve ser feita usando uma
descrição UML e eventualmente um profile para descrever conceitos
comuns da plataforma. Ir de um modelo de componente lógico a um
27
modelo de componente comercial existente, como EJB para a
plataforma J2EE ou CCM para a plataforma CORBA, é um tipo de
mapeamento PIM para PSM.
• PSM para PSM – Esta transformação é necessária para a
concretização e a extensão dos componentes. Por exemplo,
empacotamento dos componentes é realizado através da seleção
dos serviços e sua configuração. Uma vez empacotados, a entrega
dos componentes pode ser feita pela especificando inicial dos dados,
máquinas alvo, geração e configuração do container, etc.
Mapeamentos PSM para PSM são usados geralmente para refinar o
modelo dependente da plataforma.
• PSM para PIM – Esta transformação é requerida para a abstração
de modelos implementados em uma plataforma específica em um
modelo de plataforma independente. Este procedimento assemelha-
se freqüentemente a um processo de "mineração" que é difícil ser
automatizado inteiramente. Porém pode ser suportado por
ferramentas. Idealmente, o resultado deste mapeamento resultará
no PIM correspondente ao mapeamento PSM.
UML Profiles tem um papel importante dentro de MDA, visto que MDA os
usa para realizar os mapeamentos entre modelos. Para implementar
mapeamentos é necessário conhecer os metamodelos de entrada e os modelos
de saídas bem como suas regras de mapeamentos.
Há múltiplos caminhos para transformar um PIM expressado em UML para
um PSM correspondente também expressado em UML:
• Alguém pode estudar o modelo independente de plataforma e
construir a mão o modelo específico para plataforma.
• Alguém pode estudar o modelo independente de plataforma e utilizar
modelos de padrões de refinados conhecidos para reduzir a
dificuldade na construção do PSM e a relação de refinamento entre
os dois.
28
• Um algoritmo pode ser aplicado ao modelo independente de
plataforma e criar um esqueleto do modelo específico para
plataforma e ser refinado manualmente, talvez usando alguns dos
mesmos padrões de refinamento do segundo item.
• Um algoritmo pode criar um modelo específico para plataforma
completo de um modelo independente de plataforma completo,
explicitamente ou implicitamente gravando a relação de refinamento
para o uso de outras ferramentas automatizadas.
As transformações inteiramente automatizadas são praticáveis em
ambientes restritos. O grau de transformações automatizadas pode ser
aumentado consideravelmente quando as seguintes circunstâncias são obtidas:
• Não existe relação com sistemas legados.
• O modelo de entrada para a transformação é semanticamente rico.
• O algoritmo de transformação ser de alta qualidade.
29
4. Como MDA pode ajudar na solução dos problemas atuais
Nas seções anteriores vimos alguns dos principais problemas encontrados
no desenvolvimento de software atualmente, o que é MDA e como o mesmo
funciona. Nesta seção veremos como ele pode ajudar realmente na solução dos
problemas apresentados.
4.1 Produtividade
Em MDA o foco maior do desenvolvedor está no desenvolvimento do PIM.
Desde que o desenvolvedor possa trabalhar independentemente de detalhes
específicos da plataforma alvo, há muitos detalhes técnicos que eles não precisam
se incomodar. Esses detalhes técnicos são automaticamente adicionados na
transformação de PIM para PSM. Isto pode melhorar a produtividade de duas
formas.
Em primeiro lugar o desenvolvedor tem menos trabalho porque os detalhes
específicos da plataforma não precisam ser projetados e escritos. Estes detalhes
estão definidos no mapeamento das transformações. Em nível de PSM a muito
menos código a ser escrito, porque a maior parte do código já é gerada a partir do
PIM.
O segundo melhoramento é conseqüência do desenvolvedor estar mais
focado na produção do PIM, prestando mais atenção do negócio, na arquitetura e
no modelo de objetos por traz do sistema. Engenharia de Software tem provado
que projetar o sistema primeiro irá reduzir as possibilidades de erros arquiteturais
do sistema. Como resultado temos um sistema que se ajusta melhor as
necessidades dos usuários finais, sendo que esses usuários podem obter essas
melhores funcionalidades em menos tempo.
Todo esse ganho de produtividade pode ser atingido apenas com o uso de
ferramentas que automatizam a geração do PSM a partir do PIM. Note que isso
implica em muitas informações estarem incorporadas ao PIM e/ou a ferramenta de
geração.
30
Outro fator importante para o ganho da produtividade é a geração de
código. Gerando código automaticamente podemos economizar o trabalho que é
requerido para escrever os mesmos arquivos sempre. Por exemplo, na plataforma
J2EE às vezes precisamos escrever seis ou mais arquivos para criar apenas um
componente EJB. A maioria disso poderia ser automatizada com uma ferramenta
de geração.
4.2 Portabilidade
Com MDA a portabilidade é alcançada pelo foco do desenvolvimento nos
PIM’s, que são definidos independente de plataforma. O mesmo PIM pode ser ao
mesmo tempo transformado em diversos PSM para diferentes plataformas. Tudo o
que se especifica em nível de PIM deve ser completamente portável.
A portabilidade está limitada as ferramentas de geração automática que
estão disponíveis. Para as plataformas mais populares um grande número de
ferramentas estão sendo disponibilizadas, para as menos populares deve-se ter
uma ferramenta que suporte um plugin para definição de transformações e essas
definições devem ser descritas manualmente. Para novas tecnologias e
plataformas que irão chegar no futuro a industria de software precisa disponibilizar
os mapeamentos de transformações a tempo. Isso nos permite rapidamente
desenvolver novos sistemas com novas tecnologias baseadas nos modelos de
PIMs já existentes.
4.3 Interoperabilidade
A figura 7 mostra vários PSM gerados a partir de um PIM e podem ter
relações. Em MDA essas relações são chamadas de bridges(pontes). Quando os
PSMs são alvos para diferentes plataformas eles não podem conversar
diretamente um com outro, de uma forma ou de outra nós precisamos transformar
os conceitos de uma plataforma em conceitos usados para a outra plataforma.
31
MDA resolve esse problema gerando não apenas PSM mas também as pontes
necessárias entre eles.
Figura 7 – Interoperabilidade MDA com o uso de bridges
Sendo capaz de transformar um PIM em dois PSM’s alvos de duas
plataformas, todas as informações que são necessárias para a construção das
pontes entre os dois PSM’s estão disponíveis. Para cada elemento de um PSM é
conhecido o elemento no PIM que o originou. A partir do elemento PIM sabe-se
qual é o elemento correspondente no segundo PSM. Pode-se então deduzir como
os elementos de um PSM se relacionam com elementos de um segundo PSM.
Desde que também se conheça todos os aspectos e detalhes técnicos de todos os
PSM’s, se tem todas as informações necessárias para gerar a bridge entre os dois
PSM’s.
Tomando como exemplo, um PSM podia ser o modelo Java e o outro PSM
poderia ser um modelo relacional. Para um elemento Cliente no PIM sabe se quais
classes Java ele se transformou. Também são conhecidas as tabelas que esse
elemento foi transformado. Construir uma bridge entre o objeto Java no PSM-Java
e uma tabela no PSM-Relacional é fácil. Para buscar um objeto na base de dados
deve-se selecionar os dados das tabelas do cliente e incializar as classes do outro
PIM
PSM
Code Code
PSM PSM Bridge
Code Bridge
Primeira Transformação
Primeira Transformação
Segunda Transformação
Segunda Transformação
32
PSM com esses dados. O armazenamento é realizado obtendo os dados a partir
de um objeto Java e persistindo nas tabelas do cliente.
A interoperabilidade entre plataformas pode ser realizada por ferramentas
que não geram apenas PSM, mas também as bridges entre eles, e possivelmente
a outras plataformas também.
4.4 Manutenção e Documentação
O PIM é usado para gerar PSM e o PSM é usado para gerar código. O
modelo é a exata representação do código. O PIM tem a função de documentar o
mais alto nível de abstração que é necessário para qualquer sistema. A grande
diferença é o que PIM não é abandonado depois de construído, mudanças
realizadas no sistema são realizadas por mudança no PIM e feita uma nova
geração de PSM e código.
Boas ferramentas entre tanto mantém esses elementos sincronizados, ou
seja, qualquer alteração em qualquer um destes elementos refletira em alterações
correspondentes nos demais.
Em MDA a documentação de mais alto nível estará naturalmente refletindo
a exata implementação do sistema, tornando assim a manutenção do sistema e da
própria documentação menos custosa.
33
5. Ferramentas MDA
Como vimos anteriormente, MDA pode nos ajudar em vários aspectos no
processo de desenvolvimento. Mas todo o ganho que MDA pode oferecer, está
totalmente vinculado as ferramentas que dão suporte a esta abordagem. Nesta
seção abordaremos algumas das ferramentas que implementam este conceito,
algumas delas de forma completa (modelagem, transformações entre modelos e
geração de código), porém a grande maioria das ferramentas existentes dão
suporte apenas parte dos conceitos que o framework adota.
5.1 Compuware OptimalJ
OptimalJ tem a sua base nos padrões da indústria, definidos pela OMG,
como MDA que gera aplicações J2EE diretamente de modelos visuais deixando
por conta dos patterns as melhores práticas na geração dos códigos e com um
alto nível de abstração. Tudo isso com foco na funcionalidade da aplicação e não
na sua implementação.
Fornece um simples e fácil, porém poderoso modo de desenvolver
aplicações Java distribuídas, sem envolver os desenvolvedores na complexidade
da arquitetura J2EE. Desenvolvedores com pouca experiência podem facilmente
construir ou modificar aplicações, enquanto desenvolvedores experientes podem
se voltar para construção e refinamentos da arquitetura. Isto significa que podem
focar no que você esta construindo, e não como está construindo.
34
Figura 8 - Interface OptimalJ
Usando OptimalJ, os desenvolvedores interagem com um modelo visual da
aplicação e geram automaticamente a maior parte do código necessário para
executar uma aplicação multicamada completa. Usando este paradigma visual, os
desenvolvedores podem abstrair a complexidade do desenvolvimento distribuído
em J2EE.
Além do ambiente visual, o ambiente integrado de desenvolvimento fornece
um editor de fonte, um navegador de classes, um editor de formulário e um
debugger para permitir aos desenvolvedores ver, modificar e customizar a
aplicação gerada. As classes existentes não geradas por OptimalJ podem ser
importadas e chamadas pela aplicação.
OptimalJ utiliza padrões para gerar todo código necessário. Padrões
encapsulam as melhores práticas para codificação J2EE. Com OptmalJ, pode-se
rapidamente criar aplicações usando um conjunto completo de componentes
35
J2EE, incluindo Enterprise Java Beans(EJB), Java Server Page(JSP), entre
outros.
Esta ferramenta mantém sincronizados o código fonte e os modelos, de
forma que qualquer um que seja alterado implique na alteração nos demais, além
de permitir a integração com outras ferramentas. Ele permite a importação de
diversos modelos já existentes, o que inclui diagramas UML no formato XML
(Extensible Markup Language) que podem ser gerados por produtos como o
Rational Rose, da IBM, arquivos IDL do CORBA e JCA do Cobol, além de web
services na extensão WSDL e arquivos .JAR já existentes.
Como prega o MDA, o foco do desenvolvimento com OptmalJ está nos
modelos, a partir dele a aplicação é gerada, tendo um ganho de produtividade
significativo, além de manter sincronizados os modelos e código fonte, mantendo
uma documentação do sistema sempre atualizadas.
A restrição quanto à ferramenta está no fato desta gerar aplicações
exclusivamente para plataforma J2EE, deixando a empresa que adota esta
ferramenta, engessada nesta arquitetura.
5.2 Rational XDE
IBM Rational Rose XDE oferece aos analistas e desenvolvedores a
possibilidade de desenvolvimento dirigido a modelo em um ambiente para
construção que permite desenvolver software com rapidez e qualidade. Oferece
um ambiente visual e de desenvolvimento completo que visa suprir as
necessidades das organizações que utilizam J2EE, C++ e .NET. Permite aos
usuários trabalhar dentro de IDE´s, incluindo Eclipse, ou pode ser instalado dento
do WebSphere Studio e Microsoft Visual Studio .NET.
36
Figura 9 - Interface Rational XDE
O Rational Rose XDE fornece todos os elementos essenciais de UML em
um único produto. Pode ser aplicado na análise, arquitetura, projeto e
implementação. Fornece ferramentas comuns para criação e manutenção de
modelos UML, suporta engenharia reversa do código e geração automática de
código e permite o controle de quando e como os modelos serão sincronizados ao
código.
XDE possui templates de código que aumenta o poder desta ferramenta
com relação à geração de código. Esses templates geram muito mais do que o
esqueleto do código. Em poucas palavras, os templates de código contem parte
de código escritos na plataforma alvo, como Java, e scripts como JavaScripts que
podem ser executados dinamicamente quando o template de código for aplicado a
um elemento do modelo.
37
O Rational XDE possui padrões baseados em UML, ou em relacionamentos
estruturados e comportamentos que podem ser aplicados em situações gerais no
desenvolvimento de software. Os padrões fornecem um refinamento de modelo
para modelo enquanto que os templates de código fornecem um refinamento de
modelo para código.
O Rational XDE é uma das ferramentas mais completas atualmente, pois
implementa a grande maioria dos conceitos MDA. Com essa ferramenta
conseguimos a automatização não apenas para uma plataforma. Para grandes
empresas, é um investimento justificável, pois pode se ter o retorno rapidamente,
mas para pequenas empresas o investimento feito em uma ferramenta como essa
pode ser inviável.
5.3 AndroMDA
AndroMDA é um framework de geração de código, que pega modelos UML
gerados por alguma ferramenta de modelagem no formato XMI e gera
componentes customizados. Vem com um conjunto de templates de geração
baseados em tags XDoclet.
A figura 8, mostra o funcionamento da ferramenta. A partir de modelos XMI
gerados por alguma ferramenta de modelagem, o AndroMDA gera os
componentes JAVA usando o template adequado para cada elemento do modelo.
Este templete é baseado em tags XDoclet.
38
Figura 10 - AndroMDA Funcionamento
XDoclet é uma ferramenta para gerar texto e código através do
processamento de templates. É uma extensão da API Javadoc Doclet, da Sun,
aplicação mais popular é gerar artefatos EJB. A partir de templates para esta e
muitas outras tecnologias, é possível automatizar a codificação de sistemas.
XDoclet é o coração do AndroMDA, pois esta vem com um grande conjunto
de templates permitindo a geração automática de vários componentes. AndroMDA
permite também que você crie seus próprios templates e os adicione ao conjunto
de templates do AndroMDA.
A grande vantagem do AndroMDA é ser uma ferramenta open source, de
geração de código para plataforma JAVA a partir dos modelos, ou seja, as
atenções do desenvolvedor está voltada para o negócio do sistema.
A restrição está no fato de não implementar todos os conceitos de MDA.
Como o AndroMDA não é uma ferramenta de modelagem, não é possível
sincronizar código fonte e modelo, e em alguns casos existe algumas
incompatibilidades com algumas ferramentas de modelagem, e ser exclusivo para
plataforma JAVA, contudo é uma solução barata para aumento da produtividade.
39
6. MDA na Prática
Neste capítulo iremos apresentar uma análise prática do processo MDA
utilizando a ferramenta OptimalJ. A escolha dessa ferramenta se deve ao fato de
ser, entre as ferramentas pesquisadas, a que mais se adequou a tal paradigma.
Para tanto desenvolvemos uma aplicação de controle de compra e venda
de mercadorias de uma loja fictícia. A aplicação é relativamente simples e foi
desenvolvida sem nenhuma pretensão comercial, visando apenas à ilustração do
paradigma.
6.1 Aplicação de Controle de Compra e Venda de Mercadorias
O exemplo que será explorado neste trabalho consiste em uma aplicação
de controle de compra e venda de mercadorias que pode ser utilizado para
qualquer estabelecimento com tal necessidade, é uma aplicação relativamente
simples visto que o objetivo não é um software comercial, mas sim a ilustração do
processo MDA.
A aplicação consiste em gerenciar as operações de compra e venda de um
estabelecimento comercial qualquer, disponibilizando ao usuário as
funcionalidades de cadastro de produtos e fornecedores, bem como o registro de
uma compra e de uma venda realizando o controle de estoque. O usuário cadastra
os produtos, clientes, vendedor e os fornecedores e após disso está apto a
registrar uma compra ou uma venda.
No cadastro de produtos é possível cadastrar a porcentagem que se está
acrescentando ao valor pago por ele, facilitando um possível desconto no
momento da venda. Também é cadastrada a quantidade mínima de que o produto
deve ter no estoque. Um produto é fornecido por apenas um fornecedor, sendo
que um fornecedor pode oferecer vários produtos.
A compra consiste na aquisição de uma lista de produtos de um
determinado fornecedor para o estabelecimento, sendo confirmada o estoque
deve ser atualizado. A venda é semelhante à compra, porém na venda o vendedor
40
pode oferecer um desconto para o cliente com base na porcentagem que o
produto está sendo vendido e o cliente adquire uma lista de produtos
independente de fornecedores.
6.2 Arquitetura da aplicação
Optamos por utilizar uma arquitetura de três camadas (MVC), apesar de a
ferramenta nos dar outras opções, por ela fornecer uma maneira de dividir a
funcionalidade envolvida na manutenção e apresentação dos dados de uma
aplicação de forma a facilitar o entendimento.
Nesta arquitetura o modelo representa os dados da aplicação e as regras
do negócio que gerenciam o acesso e a modificação dos dados. O modelo
mantém o estado persistente do negócio e fornece ao controlador a capacidade de
acessar as funcionalidades da aplicação encapsuladas pelo próprio modelo.
A visualização renderiza o conteúdo de uma parte particular do modelo e
encaminha para o controlador as ações do usuário, também acessa os dados do
modelo via controlador e define como esses dados devem ser apresentados.
Um controlador define o comportamento da aplicação, é ele que interpreta
as ações do usuário e as mapeia para chamadas do modelo. As ações realizadas
pelo modelo incluem ativar processos de negócio ou alterar o estado do modelo.
Com base na ação do usuário e no resultado do processamento do modelo, o
controlador seleciona uma visualização a ser exibida como parte da resposta a
solicitação do usuário. Há normalmente um controlador para cada conjunto de
funcionalidades relacionadas.
6.3 Aplicando o MDA
No desenvolvimento da aplicação nós podemos identificar quais PSMs e
modelos de código podem ser derivados e quais definições de transformações
podem ser usadas para gerar os PSMs e o modelo de código. Todos os modelos
41
MDA usados no exemplo são mostrados na figura abaixo. Os retângulos
representam os modelos e as setas as transformações usadas.
Figura 11 - Três Níveis de Modelo
6.3.1 PIM e PSM
Para iniciarmos o processo devemos construir um modelo de plataforma
independente que compreenda o negócio da aplicação. Nosso PIM será um
diagrama de classe UML. Esse será o único modelo a ser construído, os outros
serão gerados.
Cada camada usa uma tecnologia diferente e, portanto necessitamos de um
modelo específico para cada camada (PSM). O primeiro modelo é um modelo
relacional que descreve entidades e relacionamentos.
O PSM para a camada intermediária, chamada de modelo EJB, é escrita
em uma linguagem que é variante de UML. Ela usa classes, associações e assim
42
por diante, como em UML, mas há um número de estereótipos definidos
explicitamente para a plataforma EJB.
O PSM para interface Web também é escrito por uma variante de UML.
Essa linguagem usa estereótipos diferentes da variante UML utilizadas para o
modelo EJB.
6.3.2 Transformações PIM para PSM
Como três modelos PSMs precisam ser gerados, nós precisamos de três
transformações de PIM para PSM:
• Transformação de PIM para modelo relacional: Essa transformação
consite em pegar o modelo de entrada, no nosso caso o diagrama de
classes, e produzir um modelo escrito em termos de entidade-
relacionamento. O template para essa transformação não utiliza
nenhuma variante de UML, consiste apenas em um mapeamento.
• Transformação de PIM para modelo EJB: A transformação usa o PIM
como entrada e escreve o modelo EJB com variantes UML usando
estereótipos especiais para EJB, podemos também utilizar o PSM
entidade-relacionamento para gerarmos o modelo EJB.
• Transformação de PIM para modelo Web: O nosso modelo de
entrada é o PIM novamente, a transformação utiliza variante UML
agora com estereótipos especiais para a interface Web para gerar o
modelo Web.
6.3.3 Transformação de PSM para modelo de código
Para cada PSM nós precisamos gerar código. O código foi incluído
explicitamente para caber em nossa definição do modelo. Conseqüentemente, nós
podemos falar dos modelos do código escritos em alguma linguagem de
programação. Para a nossa aplicação exemplo nós temos três modelos de código,
43
em SQL, Java e JSP. Consequentemente nós precisamos de três transformações
de PSM para código:
• Transformação de modelo relacional para SQL: A transformação usa
o modelo de entidade-relacionamento para gerar o modelo SQL.
• Transformação do modelo EJB para Java: Essa transformação pega
o modelo EJB e produz um modelo Java.
• Transformação do modelo web para JSP e HTML: Essa
transformação usa o modelo de web como entrada e escreve um
modelo em JSP e HTML
Tanto as transformações de PIM para PSM como de PSM para Modelo de
códigos, são realizadas com base em templates que estão acoplados a
ferramenta.
6.3.4 Três Níveis de Abstração
Todos os modelos descritos especificam o mesmo sistema, sendo que a
diferença entre eles é o nível de abstração. O nível mais alto de abstração é
definido pelo PIM, nosso diagrama de classe. Esse modelo define os conceitos
sem especificar nenhuma tecnologia, podendo ser usado para gerar PSMs
diferentes dos que estamos gerando.
No próximo nível estão os PSMs, eles abstraem os padrões de codificação
das tecnologias, porém são específicos da plataforma.
O último nível compreende os modelos de código. Esses modelos são de
fato puros e específicos da plataforma, abrangendo até mesmo padrões de
codificação da linguagem escolhida.
Podemos ver na figura (figura do livro) bem a diferença entre os três níveis
de abstração e a transformação entre eles. É importante observar que temos três
camadas e três níveis de abstração, as camadas são escritas da direita para a
esquerda enquanto que a abstração é escrita de cima para baixo.
44
6.3.5 Transformação PIM para Relacional
A regra de transformação para gerar um modelo de base de dados
relacional tipicamente consiste em mapear objetos consistentes. Embora muito
dessas regras seja direta e bem conhecida, pode ser um trabalho difícil executá-
las manualmente. Pequenas mudanças no PIM podem ter grande impacto no
modelo relacional.
6.4 PIM
O diagrama de classes abaixo, figura 12, apresenta as características da
nossa aplicação sem vincular nenhuma tecnologia. O PIM diz o que a aplicação
faz sem dizer como ela vai fazer, é o modelo com o nível mais alto de abstração.
Figura 12 - Diagrama de Classes da Aplicação
45
Podemos observar que temos as informações apenas gerais, como que
dados devemos conhecer sobre um cliente, quais dados são necessários
conhecermos de um vendedor, o que devemos saber sobre um produto e sobre
uma venda, entre outros. Como falamos anteriormente a aplicação é
relativamente simples, consiste em registrar um pedido de compra ou uma venda.
A compra está vinculada a um fornecedor e a uma lista de produtos,
representados pelos relacionamentos entre Fornecedor e PedidoCompra e entre
PedidoCompra e ItemPedidoCompra. A cada compra realizada a quantidade de
itens do produto adquirida deve ser atualizada. Também deve ser fornecida uma
margem máxima de desconto para ser praticada na venda.
A venda está vinculada a um produto ou a uma lista de produtos, podemos
observar isso através do relacionamento das classes PedidoVenda e
ItemPedidoVenda, a um vendedor, e a um cliente. Quando um cliente realizar uma
compra no estabelecimento, ao passar o produto é apresentado ao usuário o
desconto máximo que ele pode oferecer ao cliente. Na efetivação da venda, o
estoque é atualizado e os dados armazenados. Uma venda não está
necessariamente atrelada a um cliente, mas caso esteja esses dados são
utilizados posteriormente para possíveis promoções.
6.5 Modelo Relacional
O modelo relacional, figura 13, mostrado abaixo corresponde ao
mapeamento do nosso PIM para um modelo de entidade-relacionamento. Esse
modelo não é complexo de ser construído, mas sem a geração teríamos que
construí-lo na mão o que seria trabalhoso.
46
Figura 13 - Diagrama de Entidade e Relacionamento
Não há nada de especial no diagrama, ele representa a mesma aplicação
que o PIM, porém representado de uma forma diferente, de uma maneira que o
template que gera o código SQL possa interpreta-lo para gerar nossa base de
dados.
A transformação do PIM para o modelo, apenas mapeia as entidades e
relacionamentos, acrescentando informações específicas para a geração do
código SQL. Deve-se ter cuidado quanto a consistências dos objetos mapeados,
verificando se todas as entidades estão mapeadas e estão com os atributos
corretos, se não existe nenhuma entidade a mais e principalmente se os
relacionamentos entre elas estão corretos.
6.6 Modelo de Componentes EJB
A persistência de objetos é uma das partes mais importantes de uma
aplicação e também a que julgamos por nosso tempo de experiência como
desenvolvedores a mais trabalhosa. A ferramenta que escolhemos nos possibilita
a escolha de algumas formas de persistência, nós optamos por utilizar
componentes EJB.
47
Figura 14 - Diagrama Componentes EBJ
Note que todas as entidades estão representadas, estando associadas a
um serviço. Como a ferramenta modela tudo modularmente, podemos observar
que além dos módulos das entidades e dos serviços também forma representadas
interface para os mesmos. Os relacionamentos também estão representados, por
exemplo, o PedidoVenda está associado ao produto, ao cliente e ao vendedor.
Esse diagrama utiliza templates baseado em variantes de UML específicas
para EJB, que adicionam informações específicas sobre a plataforma que nos
permite gerar em seguida o código EJB. O OptimalJ nos permite gerar esse
modelo com base no PIM ou no modelo relacional, sendo que nós decidimos gerar
pelas duas formas para ver se ocorriam diferenças e também para termos uma
transformação de um modelo PSM para PSM com mesmo nível de abstração.
Como sabemos, podemos apartir do modelo ER, através de engenharia
reversa obter o PIM e conseguir gerar então os demais modelos, porém
transformação de PSM para PSM, que estamos nos referindo é direta, isso é
possível uma vez que o modelo ER não está atrelado a nenhuma variante
48
específica de UML e também porque o modelo EJB é o modelo de persistência
dos dados, sendo comum e simples a sua geração através de modelos ER.
Como era de se esperar os modelos gerados não apresentaram diferença.
Esse modelo representa igualmente nossa aplicação como o PIM e modelo ER,
mas assim como o modelo ER ele está vinculado a uma tecnologia específica,
neste caso a plataforma EJB.
6.7 Modelo Web
No modelo Web temos representado o que estará visível para o usuário, o
que realmente o usuário poderá realizar no sistema. Como vemos no diagrama
abaixo o usuário terá acesso à manutenção de clientes, produtos, vendedor e
fornecedor, bem como aos pedidos de compra e venda.
Figura 15 - Diagrama Componentes WEB
Podemos observar que o usuário terá acesso aos mesmos serviços
disponibilizados no modelo EJB. Assim como o modelo EJB, o modelo web é
construído com templates que usam variantes de UML específicas para JSP, que
49
acrescentam ao modelo informações para a confecção dos mesmos
posteriormente. O modelo Web é construído especificando apenas a camada de
apresentação, sem considerar as demais camadas.
O relacionamento entre as camadas é realizado através das pontes de
comunicação.
6.8 Última Transformação – PSM para código
Agora que já temos todos os PSM da nossa aplicação de exemplo gerados,
o próximo passo é a última transformação, PSM para código. Esse passo não
apresenta grandes novidades, visto que um modelo específico de plataforma é
uma visão da aplicação muito próximo ao código da plataforma que este
representa, tornado esta transformação mais simples.
O objetivo deste tópico é apresentar uma visão da tecnologia empregada
para nossa aplicação de exemplo, bem como a arquitetura na qual esta foi
desenvolvida.
6.8.1 Modelo Relacional para Código SQL
A partir do nosso modelo de negócio, foram gerados três diferentes PSM’s.
Dentre eles esta presente um modelo relacional, que nada mais é do que a
representação da nossa aplicação de exemplo, na visão de um modelo de
Entidade e Relacionamento.
Este modelo é uma representação muito próxima de uma base de dados
relacional, com seus conceitos e características. A partir dele é fácil a geração de
código SQL, e existem várias ferramentas disponíveis no mercado para tal
funcionalidade.
A partir deste modelo, são criados um par de SCRITP’s SQL, um para a
criação da base de dados, outro para deleção da base de dados. Estes scripts
contém todos os comandos necessários para a criação da base de dados e
50
tabelas, bem como os comandos para deleção de cada uma das tabelas e base
de dados.
Estes scripts podem ser analisados no 9.2.
6.8.2 Modelo EBJ para código Java
O segundo modelo gerado a partir do nosso modelo independente de
plataforma foi o modelo EJB, mas antes de prosseguir apresentararemos um
pouco da arquitetura relacionada a esta camada da aplicação.
Como pode ser visto no modelo EJB, existem para cada entidade
representada no nosso PIM, existem dois componentes mapeados no modelo
EJB, o primeiro deles é um Entity Bean, e o segundo um Session Bean, que nada
mais é que um Session Facade para o Entity Bean em questão.
6.8.2.1 Entity Bean
Entity Beans são componentes que representam entidades persistentes.
Em outras palavras, são componentes de negócio com mecanismo de persistência
de dados. O estado do Entity Bean pode ser persistido em um banco de dados
relacional, arquivo XML além de outros tipos de repositórios de dados. Isto quer
dizer que o estado do Entity Bean é mantido além do tempo de vida da aplicação
ou do servidor J2EE. Esta é uma característica muito útil em situações onde se
deseja utilizar os dados desta entidade em momentos que seria inviável mantê-los
em memória.
Existem dois tipos de Entity Beans:
• Bean Managed Persistence (BMP).
51
Utilizando esta estratégia, a codificação das chamadas de acesso à base
de dados estão na classe de negócios do EJB e são de responsabilidade do
desenvolvedor. Então, para os métodos de busca (métodos utilizados para
encontrar Entity Beans na base de dados) e para os métodos de criação, remoção
e atualização dos Entity Beans, deve-se codificar os comandos responsáveis por
realizar estas operações.
O Entity Bean BMP oferece ao desenvolvedor a flexibilidade de desenvolver
as operações de persistência de dados que em alguns casos, podem ser
complexas de serem implementadas pelo container.
• Container Managed Persistence (CMP).
Entity Beans CMP (Bean de Entidade com Persistência Gerenciada pelo
Container) oferecem mais rapidez e facilidade no desenvolvimento de objetos
persistentes, pois o desenvolvedor não precisa escrever os comandos para
persistir e manipular os dados.
O container se encarrega de realizar estas operações e retornar os valores
desejados. Ele faz isso para as operações triviais tais como inserção do objeto,
remoção, atualização e seleção pela chave primária (create, remove, store e
findByPrimaryKey respectivamente).
Para as operações específicas de consulta a objetos persistidos, se faz
necessário o uso de uma linguagem de consulta conhecida como EQL (EJB Query
Language). Uma linguagem muito parecida com SQL, porém voltada para
componentes do tipo Entity Bean CMP.
Estas operações devem ser definidas no arquivo de deploy do componente
utilizando-se de EQL para cada operação desejada. Neste arquivo define-se quais
campos que serão persistidos e os relacionamentos entre Entity Beans.
52
6.8.2.2 Session Bean
Session Beans são componentes que apresentam serviços para seus
clientes. Estes serviços são fornecidos para o cliente pelas interfaces do EJB
Session Bean e implementadas pelos métodos de negócio no próprio Bean. O
estado do objeto Session Bean consiste no valor da instância de seus atributos,
sendo que estes não são persistidos.
Figura 16 - Diagrama de Classe UML do Session Bean
Analisando o diagrama de classes acima temos uma classe e duas
interfaces. A classe do EJB Session Bean SBExampleBean (EJBSession) e as
interfaces SBExample (Remote) e SBExampleHome (Home). Para cada classe do
Bean devemos definir as interfaces (Remote e/ou Local e Home e/ou LocalHome).
No exemplo acima, foram definidas as interfaces Remote e Home, mas poderiam
ter sido definidas as interfaces Local e LocalHome ou todas elas (com isto
teríamos acesso local e remoto ao mesmo EJB).
53
O Bean deve conter os métodos definidos para um EJB Session Bean
conforme a API J2EE que são: ejbCreate(), ejbRemove(), ejbActivate(),
ejbPassivate() e setSessionContext(). Também devem apresentar os métodos de
negócio com suas devidas implementações que serão os serviços disponibilizados
pelo EJB.
Na interface Home do EJB devemos definir o método create(), que será
utilizado pelo cliente para solicitar ao container que crie uma instância do Bean e
forneça uma referência para acessar os seus serviços ou os métodos de negócio
através da interface Remote.
6.8.2.3 Session Façade
Criar uma aplicação EJB controlável requer quebrar a camada do EJB em
duas partes. O modelo de dados é construído via entity beans e geralmente
corresponde à camada de banco de dados base. A lógica de negócio (que em
aplicações antigas poderia ter sido mantida em uma aplicação cliente ou em
stored procedures dentro do banco de dados) é mantida nos session beans. Em
muitas circunstâncias, clientes acessarão session beans que efetuarão ações
sobre entity beans e retornarão resultados apropriados para a aplicação cliente.
É claro, é possível adicionar lógica de negócio diretamente a um entity
bean, mas isto deve ser minimizado. Tirar a lógica de negócio dos entity beans e
colocá-la na aplicação cliente também é problemático, já que cada aplicação
cliente (além de fornecer uma interface para o usuário) deve incluir todas as
regras de negócio para modificar a estrutura do entity bean, e deve ter
conhecimento de cada entity bean mesmo que tenha sido invocado remotamente
na transação. A separação das camadas cliente e de negócio efetivamente
desaparece, e qualquer alteração nas regras de negócio irá requerer a atualização
de todos os clientes.
Mesmo com a lógica de negócio distribuída em vários session beans, ainda
há o problema do overhead da rede. Clientes EJB acessam o servidor EJB da
54
rede, e chamadas na rede significam atrasos. Acessar um objeto local é sempre
muito mais rápido do que acessar um objeto remoto, e cada entity bean ou
session bean que um cliente usa resulta em uma outra chamada remota.
A solução é empacotar transações de nível mais alto em um session
façade. Session façade é um session bean que organiza um conjunto de métodos
de negócio relacionados. A session façade é responsável por acessar recursos,
atualizar dados e realizar a transação com uma interação limitada com o cliente. O
propósito da session façade é fornecer uma interface simples e unificada para
todos os clientes da aplicação. Os clientes podem usar a session façade como um
ponto de entrada único para os dados e para a funcionalidade de uma aplicação.
Agora que vimos como componentes EJB’s funcionam e como se
interagem, fica mais fácil de compreender o modelo EJB gerado. Os Entity Beans
são nossos componentes que representam nossas entidades persistentes, que
são responsáveis pelo acesso à base de dados da aplicação. No nosso exemplo
foram gerados componentes do tipo CMP, no qual a responsabilidade de
persistência dos dados fica a cargo do container EJB.
Acima destes componentes existe outra camada de componentes EJB, que
são Session Façade que detém toda a regra de negócio da aplicação, e são
responsáveis pelo acesso aos Entity Beans.
Para cada um dos componentes representados neste modelo, são gerados
as interfaces Local, LocalHome, Remote, RemoteHome, bem como o a classe
Bean, que implementa as funcionalidades relacionadas a este.
Além disso, também são gerados os arquivos de configuração dos
componentes (deployment descriptor), bem como a ponte de comunicação com a
base de dados em questão.
Todo o código da aplicação pode ser visualizado no Apêndice 9.3.
6.8.3 Transformação do Modelo WEB para Código
Para implementar componentes WEB, nós temos que gerar código que
manipule as requisições do usuário e produza HTML como resposta. Em geral, a
55
complexidade deste código pode ser alta. Uma boa ferramenta MDA fornece esta
transformação utilizando-se de padrões de código bem estabelecidos.
Para cada um dos componentes WEB do modelo, são criados arquivos
JSP, e classes Java que atendem as requisições do usuário, processam e enviam
a resposta de acordo com a requisição. Os componentes WEB gerados são
baseados no framework STRUTS.
6.8.3.1 JSP
É uma tecnologia baseada em Java que simplifica o processo de
desenvolvimento de sites da web dinâmicos, esta tecnologia está intimamente
ligada ao novo tipo de desenvolvimento para a Internet. Na verdade pode-se
considerar JSP como “uma linguagem de criação de scripts no servidor”. Os
arquivos JSP são arquivos textos comuns interpretados pelo servidor quando
requisitados pelo cliente.
Os benefícios conseguidos por utilizar a plataforma JSP para o
desenvolvimento de aplicativos na web são muito grandes. Primeiramente, sendo
uma tecnologia baseada em Java, ela se aproveita de todas as vantagens que a
linguagem Java fornece em relação a desenvolvimento e acionamento. Como uma
linguagem orientada a objetos com forte encapsulamento, tratamento de exceções
e gerenciamento automático da memória, o uso de Java conduz a uma
produtividade aumentada do programador além de um código mais robusto.
Completando, assim como o Java que não possui restrição de sistema
operacional, o JSP também não possui.
A performance da plataforma JSP é mais rápida e melhor que outras
linguagens de aplicação dinâmica, por fazer o tratamento de múltiplas solicitações
necessitando de uma única instância do processo no servidor, isto lhe garante a
rapidez e melhor tratamento das requisições.
56
6.8.3.2 Struts
É uma framework que implementa a arquitetura padrão MVC em Java. O
Struts é um projeto open source mantido pela Apache Software Foundation. O
objetivo do pattern MVC é separar de maneira clara a camada de apresentação da
camada de Negócio.
O Framework Struts é uma implementação cliente-servidor de MVC,
combinado JSP, taglibs e Servlets Java.
Figura 17 - Implementação MVC do Struts
A figura acima mostra o fluxo de uma requisição para a maioria das
aplicações que usam o Struts. Este processo pode ser dividido em 4 passos
básicos. Estes passos descrevem as classes ActionServlet e Action.
1. Uma requisição para aplicação é feita.
2. A requisição é interceptada pelo ActionServlet que atua como
controlador. O ActionServlet, a partir de configurações em arquivo XML,
determina a classe action que irá processar toda a lógica de negócio
associada a requisição.
3. Uma vez que a classe action completou seu processamento, ele retorna
o controle para o ActionServlet. A classe Action fornece ao ActionServlet
uma chave que indica o resultado do processamento. O ActionServlet
57
usa esta chave para determinar para onde o fluxo de execução deve ser
direcionado.
4. A requisição é finalizada quando o ActionServlet responde direcionando
a requisição para a Visão (View) que foi associada a chave de retorno.
Esta visão apresenta o resultado do Action.
Além do controlador da aplicação o framewor Struts também fornece uma
vasta biblioteca de tag que facilitam a construção dos arquivos JSP’s bem como
um plug-in para validação dos campos de entrada da aplicação, validações como
de campos obrigatórios, datas, numéricos, entre outras.
6.9 Resultado
Como nosso maior resultado tivemos um ganho de produtividade notável
obtendo uma aplicação que atende aos mais conceituados padrões de qualidade e
robustez, devido ao emprego de alguns padrões de desenvolvimento e a utilização
de tecnologias bem conceituadas.
Todo o processo de desenvolvimento foi direcionado a construção e
refinamento do PIM, sendo que foram gerados automaticamente todos os demais
modelos (ER, EJB e WEB). Durante toda a fase de design estes modelos
permaneceram sincronizados, garantindo assim que nossa documentação de
análise estivesse sempre atualizada, facilitando assim as alterações necessárias
durante o desenvolvimento.
Quase a totalidade do código necessário para nossa aplicação de exemplo
foi gerada automaticamente, sendo que pequenas customizações foram
necessárias, especificamente para o cálculo do valor total para compra e venda,
bem como a atualização do estoque para estes casos.
Mas o que mais esperávamos com resultado deste estudo, é o real ganho
de produtividade que uma tecnologia como MDA pode oferecer. Para termos uma
visão mais realista deste possível ganho de produtividade, fizemos uma estimativa
de horas, desconsiderando o uso de ferramentas de automatização do processo
58
de desenvolvimento, mas considerando que teríamos uma equipe bem qualificada
para o mesmo, bem como a estabilidade dos requisitos da aplicação.
Para esta estimativa utilizamos a técnica de Use Case Points, uma das
mais utilizadas para aplicações OO. Identificamos para nossa aplicação 6 casos
de uso, que são:
1. Manter Vendedor.
2. Manter Cliente.
3. Manter Produto.
4. Manter Fornecedor.
5. Efetuar Compra.
6. Efetuar Venda.
Consideramos para esta estimativa que os casos de uso de 1 a 4 como
sendo de complexidade simples, e os dois últimos de complexidade média.
Levando em consideração todos estes parâmetros, e aplicando as regras
determinadas pela técnica de Use Case Points chegamos a um total de 345 horas.
Esta estimativa não é apenas para a construção da aplicação, mas sim para todo
o processo de desenvolvimento de uma aplicação comercial. Dentre processo de
desenvolvimento o MDA auxilia na parte de análise e design e construção. Estas
duas etapas totalizam cerca de 275 horas. A planilha com todos os parâmetros
utilizados nesta estimativa podem ser vistos no apêndice 9.1.
Com o auxilio de uma tecnologia como MDA foi possível reduzir o número
de horas da etapa de análise, design e construção para cerca de 80 horas,
considerando ainda a falta de experiência com a ferramenta escolhida, este
número de horas poderia ser ainda mais reduzido se uma equipe mais experiente
na ferramenta tivesse desenvolvido esta aplicação.
Essa redução do número de horas trás vários benefícios a empresa de
desenvolvimento, fazendo com que seu produto possa chegar antes ao mercado
aumentando lucros e diminuindo custos.
Porém devemos levar em consideração o fato de nossa aplicação possuir a
maioria de seu comportamento estático, uma vez que a ferramenta utilizada não
59
suporta a representação do comportamento dinâmico, por isso acreditamos que à
medida que complexidade aumente o ganho de produtividade decresça.
60
7. Conclusão
Neste trabalho foi possível avaliar vários problemas encontrados no
desenvolvimento de software atual bem como de todas as dificuldades de se
produzir software com qualidade, rapidez, sem comprometer os custos pré-
estipulados.
Vimos também que MDA pode ser a grande resposta para tais problemas e
que cada vez mais empresas em conjunto com a OMG estão investindo e
apostando nesta idéia.
Nos primórdios do desenvolvimento de software, construir uma aplicação
era sinônimo de escrever código, muitas vezes este código era muito próximo da
linguagem de máquina. Com a evolução da complexidade dos sistemas, este tipo
de abordagem deixou de ser viável. Por isso o processo de desenvolvimento
evoluiu de forma que se tornasse cada vez mais familiar a linguagem humana.
Muito neste aspecto foi feito, hoje em dia as linguagens de modelagem de
sistemas e linguagens de programação já estão bastante naturais para os
humanos.
Uma evolução natural é o de desenvolver sistemas aplicativos apenas
especificando suas funcionalidade e características de forma bastante abstrata.
Essa idéia até bem pouco tempo parecia um tanto utópica, mas os primeiros
passos já foram dados, e o MDA veio justamente ajudar neste sentido.
São notáveis as vantagens que um framework como MDA trás ao processo
de desenvolvimento de software. Como vimos durante o trabalho, podemos
reduzir bastante o tempo de desenvolvimento, o que diminui os custos e possibilita
que o produto chegue ao mercado ou ao cliente antecipadamente. Facilita também
o gerenciamento da documentação, portabilidade, interoperabilidade e
manutenção.
Vale ressaltar que o MDA não é apenas um processo que pode ser
facilmente adotado. Para que se tenha ganho total é necessário alguns subsídios
que dão suporte ao desenvolvimento. O principal delas é a ferramenta escolhida.
Já existem no mercados várias ferramentas que vendem este conceito, citamos
algumas delas neste trabalho. Algumas das ferramentas já estão bastante
61
evoluídas, mas nenhuma delas aparentemente aborda MDA em sua totalidade.
Em algumas delas nem todas as transformações estão previstas, em outras não é
possível modelar o comportamento dinâmico da aplicação e há ainda aquelas em
que não conseguimos gerar um modelo totalmente independente de plataforma.
Apesar de ainda não implementar MDA em sua totalidade, acreditamos que
em breve isso será possível, uma vez que as empresas estão investindo bastante
nesta tecnologia e na evolução dos templates de transformação, que são à base
do paradigma.
Ainda não existem no mercado ferramentas que atendam a todas as
plataformas e as melhores ferramentas que existem são proprietárias com um
custo elevado, porém conseguimos atender boa parte dos conceitos de MDA para
algumas plataformas utilizando algumas ferramentas free integradas como, por
exemplo, o Poseidon e o AndroMDA.
Outra grande mudança em relação ao desenvolvimento como conhecemos
hoje, são as pessoas que participam do processo. Cada vez mais será necessário
ter pessoas que conheçam muito bem as regras de negócio da aplicação, e um
número menor de pessoas, possivelmente menos especializadas para a
codificação, visto que a maior parte do código será automatizado, com apenas
customizações sendo feitas manualmente, e a medida que o processo e
ferramentas amadurecerem, a tendência é que nenhuma customização manual
seja necessária.
A utilização da arquitetura MDA e ferramentas que implementam a mesma
nos levam a conclusão que o código é importante, mas ele na verdade é resultado
de uma transformação, isto é, o código é uma “tradução” da solução de negócio
para determinado ambiente computacional, toda a “inteligência” de uma aplicação
está nas suas regras de negócio.
62
8. Referência Bibliográfica
1. Martin, James & Odell, James J. Análise e Projeto Orientados a Objetos:
Markon Books 1995.
2. Meyer, Bertrand Pbject-Oriented Software Construction 2ª edição: Prentic
Hall PTR 1997.
3. Qualidade Software Seleção de Textos: Ana Regina Cavalcanti da Rocha
& Kival Chaves Weber 1996.
4. Rezende, Denis Alcides Engenharia de Software Empresarial: Brasport
1997.
5. Martin, James Engenharia da Informação: Campus; 1991.
6. Kleppe, Anneke & Warmer, Jos & Bast, Wim MDA Explained – The Model
Driven Architecture: Practice and Promise: Addison-Wesley 2003
7. Pressman, Roger S. Engenharia de Software 5ª edição: McGraw-Hill
2002.
8. KETIS, D. Terceirizando a documentação de sistemas. Developers’ CIO
Magazine: 1999.
9. Miller, Joaquin & Mukerji, Jishnu Model Driven Architecture (MDA): 2001
10. Miller, Joaquin & Mukerji, Jishnu MDA Guide Version 1.0.1: 2003
11. Costa, Marco Arquitectura de Sistemas de Informação em UML.
12. Siegel, Jon & OMG Staff Strategy Group Developing in OMG’s Model-
Driven Architecture: 2001.
13. Common Warehouse Metamodel (CWM) Specification: 2001
14. Meta Object Facility (MOF) Specification: 2000
15. Chaves, Rafael Alves Aspectos e MDA Criando modelos executáveis
baseados em aspectos: 2004
16. Goodwil, James Mastering Jakarta Struts : 2002
17. http://www.starlink.rl.ac.uk/star/docs/sgp42.htx/node25.html
18. http://www.telehealthlab.com/about/inter.asp
19. http://www-vis.lbl.gov/Events/DOEworkshop-98/document.html
20. http://www.pr.gov.br/batebyte/edicoes/2002/bb123/armazenamento.htm
21. http://www.omg.org
63
21. http://www.componentsource.com
22. http://www.compuware.pt/pressroom/news/2003/2003040801.htm
23. http://www.compuware.com/products/optimalj/default.htm
24. http://www.itweb.com.br/itlab/artigo.asp?id=41448
25. http://www.andromda.org
26. http://www-306.ibm.com/software/rational
64
9. Apêndices
9.1 Planilha de Use Case Points
Estimativa de Tempo com Use Cases
Pesando Atores Tipo de Ator Número Total Peso Simples 0 0 1Médios 0 0 2Complexos 0 0 3 Soma 0
Pesando Use Cases Tipo de Use Case Número Total Peso Simples 4 20 5Médios 2 20 10Complexos 0 0 15 Soma 40 UUCP 40
Pesando Fatores Técnicos Descricao Peso Total Peso Sistema Distribuido 2 4 2Requisitos de Performace 2 2 1OnLine 5 5 1Processo Interno Complexo 1 1 1Código deve ser reusavel 3 3 1Fácil de Instalar 1 0.5 0.5User Friendly 5 2.5 0.5Portavel 1 2 2Flexivel a mudanças 3 3 1Concorrência 1 1 1Inplementações Especiais de Segurança 3 3 1Provê acesso direto a terceiros 1 1 1Precisa de facilitadores para treinamento a usuários 1 1 1 Tfactor 29 TCF 0.89
65
Pesando Fatores de Ambiente para Pessoas Descricao Peso Total Fator Familiaridade com Unified Process 5 7.5 1.5Experiencia em Aplicações 2 1 0.5Experiência em OO 5 5 1Capacidade do analista lider 4 2 0.5Motivação 5 5 1Estabilidade dos requisitos 5 10 2Profissionais Part Time 0 0 -1Dificuldade da linguagem de programação 4 -4 -1 Efactor 26.5 EF 0.605
UCP 21.538
Homens Hora por UCP 16 345Homens-Hora
Distribuição Média de Horas Use Cases simples medio complexo total peso total de horas peso por complexidade 20 20 0 40 345 valor médio em horas por peso 172.304 172.304 0 número de horas por cada use case, agrupado por complexidade 43.076 86.152 #DIV/0! Distribuição Média de Horas no Ciclo de Desenvolvimento 344.61 Detalhamento de Use Cases 34.46 S M C Análise & Design 103.38 Construção 172.30 21.538 43.076 #DIV/0! Transição 34.46 Resumo Simples Médio Complexo Atores 0 0 0 Use Cases 4 2 0
Lista de Use Cases Complexidade Quant
Lista de Atores Complexidade Quant
Manter Vendedor Simples 1 Manter Cliente Simples 1 Manter Produto Simples 1 Manter Fornecedor Simples 1 Efetuar Compra Médio 1 Efetuar Venda Médio 1
66
9.2 Scripts
9.2.1 Script de criação --GEN-GUARD:GENERATECREATESCHEMA$pidfed9f268bfbf70b7 -- SOLID Server 04.00.0025 create table script -- Generated by OptimalJ --GEN-FREE-GEN:Header$$GENERATECREATESCHEMA$pidfed9f268bfbf70b7 --GEN-GUARD:1$$GENERATECREATESCHEMA$pidfed9f268bfbf70b7 CREATE SCHEMA projetomda; CREATE TABLE projetomda.Vendedor ( uniqueId VARCHAR (32) NOT NULL, dataAdmissao DATE NULL, salarioBase DOUBLE PRECISION NULL, percentualComissao REAL NULL, nomeVendedor VARCHAR (40) NULL, PRIMARY KEY (uniqueId) ); CREATE TABLE projetomda.Cliente ( uniqueId VARCHAR (32) NOT NULL, nome VARCHAR (40) NULL, endereco VARCHAR (40) NULL, bairro VARCHAR (40) NULL, cidade VARCHAR (40) NULL, uf VARCHAR (40) NULL, cep VARCHAR (40) NULL, cpfCnpj VARCHAR (40) NULL, RG VARCHAR (40) NULL, PRIMARY KEY (uniqueId) ); CREATE TABLE projetomda.PedidoVenda ( ClienteUniqueId VARCHAR (32) NULL, VendedorUniqueId VARCHAR (32) NOT NULL, uniqueId VARCHAR (32) NOT NULL, dataVenda DATE NULL, valorTotal DOUBLE PRECISION NULL, percentualDesconto REAL NULL, PRIMARY KEY (uniqueId) -- Database doesn't support deferrable constraints. Skip constraint: -- , FOREIGN KEY (ClienteUniqueId) REFERENCES projetomda.Cliente (uniqueId) -- Database doesn't support deferrable constraints. Skip constraint:
67
-- , FOREIGN KEY (VendedorUniqueId) REFERENCES projetomda.Vendedor (uniqueId) ); CREATE TABLE projetomda.Fornecedor ( uniqueId VARCHAR (32) NOT NULL, razaoSocial VARCHAR (40) NULL, cnpj VARCHAR (40) NULL, telefone VARCHAR (40) NULL, PRIMARY KEY (uniqueId) ); CREATE TABLE projetomda.PedidoCompra ( FornecedorUniqueId VARCHAR (32) NOT NULL, uniqueId VARCHAR (32) NOT NULL, dataCompra DATE NULL, valorTotal DOUBLE PRECISION NULL, PRIMARY KEY (uniqueId) -- Database doesn't support deferrable constraints. Skip constraint: -- , FOREIGN KEY (FornecedorUniqueId) REFERENCES projetomda.Fornecedor (uniqueId) ); CREATE TABLE projetomda.Produto ( uniqueId VARCHAR (32) NOT NULL, codigoBarras VARCHAR (40) NULL, descricao VARCHAR (40) NULL, margemDesconto REAL NULL, qtdEstoque INTEGER NULL, qtdMinima VARCHAR (40) NULL, imagem VARCHAR (40) NULL, valorVenda DOUBLE PRECISION NULL, PRIMARY KEY (uniqueId) ); CREATE TABLE projetomda.ItemPedidoVenda ( PedidoVendaUniqueId VARCHAR (32) NOT NULL, ProdutoUniqueId VARCHAR (32) NOT NULL, uniqueId VARCHAR (32) NOT NULL, quantidade INTEGER NULL, valorUnitario DOUBLE PRECISION NULL, percentualDesconto REAL NULL, PRIMARY KEY (uniqueId, PedidoVendaUniqueId) -- Database doesn't support deferrable constraints. Skip constraint: -- , FOREIGN KEY (PedidoVendaUniqueId) REFERENCES projetomda.PedidoVenda (uniqueId) -- Database doesn't support deferrable constraints. Skip constraint: -- , FOREIGN KEY (ProdutoUniqueId) REFERENCES projetomda.Produto (uniqueId) );
68
CREATE TABLE projetomda.ItemPedidoCompra ( PedidoCompraUniqueId VARCHAR (32) NOT NULL, ProdutoUniqueId VARCHAR (32) NOT NULL, uniqueId VARCHAR (32) NOT NULL, qtd INTEGER NULL, valorUnitario DOUBLE PRECISION NULL, PRIMARY KEY (uniqueId, PedidoCompraUniqueId) -- Database doesn't support deferrable constraints. Skip constraint: -- , FOREIGN KEY (PedidoCompraUniqueId) REFERENCES projetomda.PedidoCompra (uniqueId) -- Database doesn't support deferrable constraints. Skip constraint: -- , FOREIGN KEY (ProdutoUniqueId) REFERENCES projetomda.Produto (uniqueId) ); COMMIT WORK; --GEN-FREE-GEN:Footer$$GENERATECREATESCHEMA$pidfed9f268bfbf70b7 --GEN-GUARD:2$$GENERATECREATESCHEMA$pidfed9f268bfbf70b7
9.2.2 Script de Remoção --GEN-GUARD:GENERATEDROPSCHEMA$pidfed9f268bfbf70b7 -- SOLID Server 04.00.0025 drop table script -- Generated by OptimalJ --GEN-FREE-GEN:Header$$GENERATEDROPSCHEMA$pidfed9f268bfbf70b7 --GEN-GUARD:1$$GENERATEDROPSCHEMA$pidfed9f268bfbf70b7 DROP TABLE projetomda.ItemPedidoCompra; DROP TABLE projetomda.ItemPedidoVenda; DROP TABLE projetomda.Produto; DROP TABLE projetomda.PedidoCompra; DROP TABLE projetomda.Fornecedor; DROP TABLE projetomda.PedidoVenda; DROP TABLE projetomda.Cliente; DROP TABLE projetomda.Vendedor; DROP SCHEMA projetomda; COMMIT WORK; --GEN-FREE-GEN:Footer$$GENERATEDROPSCHEMA$pidfed9f268bfbf70b7 --GEN-GUARD:2$$GENERATEDROPSCHEMA$pidfed9f268bfbf70b7
69
9.3 Códigos
Ver arquivo projetoMDA.zip