PyMDAGenerator: Uma Ferramenta para Geração Automática de Aplicações Baseada em MDA

C.E.S.A.
R CENTRO DE ESTUDOS E SISTEMAS

AVANADOS DO RECIFE
RICARDO ROBERTO DE LIMA
Uma orquestrao de componentes para gerao

semi-automtica de aplicaes baseada em MDA
RECIFE
2014

Dissertao apresentada ao programa de
Mestrado em Engenharia de Software do Centro
de Estudos e Sistemas Avanados do Recife,
como requisito para a obteno do ttulo de Mestre
em Engenharia de Software.
Orientao: Prof. Vinicius Cardoso Garcia, D.Sc.
RECIFE
2014
C.E.S.A.R CENTRO DE ESTUDOS E SISTEMAS

AVANADOS DO RECIFE

Dissertao apresentada ao programa de

Mestrado em Engenharia de Software do
Centro de Estudos e Sistemas Avanados do
Recife, como requisito para a obteno do ttulo
de Mestre em Engenharia de Software.
Data de aprovao:
31 / JANEIRO / 2014.
Banca examinadora:
____________________________________
Prof. Vinicius Cardoso Garcia, D.Sc.
CIN-UFPE / C.E.S.A.R
____________________________________
Prof. Kiev Santos Gama, D.Sc.
CIN-UFPE / C.E.S.A.R
____________________________________
Prof. Robson do Nascimento Fidalgo, D.Sc
CIN-UFPE
Dedicatria
Pensar o trabalho mais difcil que existe.

Talvez por isso to poucos se dediquem a ele.
Henry Ford [1901]
Agradecimentos
Em primeiro lugar, agradeo a Deus que a fonte de toda fora e sabedoria
existente e por ter me dado toda fora e sabedoria suficientes para a concluso
deste trabalho.
Agradeo aos meus avs Maternos e Paternos (in memorian), por sempre ter sido
um grande exemplo de honestidade, perseverana e f.
Aos meus pais, Orlando Sebastio de Lima e Edivnia Maria de Lima e aos meus
irmos Vaneo Clio de Lima e Regina Coeli de Lima por sempre demonstrarem seu
carinho, amor e confiana em todos os momentos da minha vida.
Ao meu Orientador Vinicius Garcia, por ter confiado em mim e por ter compartilhado
de seus conhecimentos para a melhoria deste trabalho.
minha Esposa Beatriz Costa, por seu carinho, pacincia, amor e confiana, que
esteve sempre ao meu lado, me incentivou e nunca mediu esforos para me ajudar.
Aos meus filhos, Maria Clara Costa Lima e Joo Guilherme Costa Lima pelo amor,
carinho e compreenso durante este perodo da minha vida.
todos os meus professores, principalmente Felipe Furtado, Vinicius Garcia, Luiz

Maurcio, Kiev Gama, Robson do Nascimento Fidalgo, Gustavo Alexandre, Cea,
Left, Rodrigo Assad, Roberto Capistrano, Trajano, Ana Paula Cavalcanti e Heriberto
pelas boas conversas e grandes exemplos que so para mim.
Agradeo aos meus amigos de sala de aula, Adilson, Aprgio, Josu, Pedro, Ana Claudia
pela amizade, confiana e respeito depositados em mim durante este perodo de estudo. E
por fim, agradeo a todos que de forma direta ou indireta contriburam para a concluso
deste trabalho.
Epgrafe
"O homem de valor nunca morre. Seus exemplos e suas obras atestam a sua
imortalidade".
Hlder Sena de Sousa [1981]
Resumo
A engenharia de software baseada em componentes vem crescendo devido

complexidade dos sistemas e o consequente aumento no custo necessrio para
desenvolver software. Vrias tcnicas surgiram ao longo do tempo com este
objetivo, com a definio do nvel de abstrao dos artefatos e o avano das
ferramentas e frameworks de desenvolvimento orientados a objetos. Uma dessas
iniciativas a Arquitetura Dirigida a Modelo (MDA) que permite a modelagem e a
aplicao de transformaes sobre modelos, garantindo assim, a construo de
sistemas de forma automatizada. Este trabalho tem como objetivo principal propor
uma abordagem prtica e extensvel para definio de transformaes unidirecionais
entre modelos (PIM para PSM e PSM para cdigo), que permita a sua utilizao
atravs de um parser XMI, junto com uma biblioteca intitulada UML2DJ e um
conjunto de tratadores implementados em Shell Script para executar o processo de
transformao e gerao semi-automtica de aplicaes baseada em MDA, sendo
realizado
de
maneira
assistida
atravs
de
uma
ferramenta
chamada
PyMDAGenerator, implementados com a linguagem Python e o Django. E por fim,

foi feito um estudo de caso comparativo entre: desenvolvimento do projeto utilizando
a engenharia de software baseada em componentes.
Palavras-chave
Reuso de Software. Engenharia de Software baseada em componentes. MDA.
Python. Django. Transformaes entre modelos.
Abstract
The software engineering based on components has been growing due to the
increase of the system complexity and also to the consequent increase of the
software development cost. Several techniques have appeared throughout the time
with this objective. They have appeared through the increase of the artifacts
abstraction levels and the tools and frameworks advance object-targeted. One of
these initiatives is the architecture driven model (MDA) that allows the modeling and
application of models, thus ensuring the construction of automated systems. This
work aims to propose a practical and extensible approach to definition of
unidirectional transformations between models (PIM to PSM and PSM to code) to
allow its use through an XMI parser, along with a library entitled UML2DJ and a set of
handlers implemented in Shell Script to execute the transformation process and
semi-automatic generation of MDA-based applications, being held assisted way
through a tool called PyMDAGenerator implemented with Python and Django
language. Finally, make a comparative case study: project development using
engineering-based software components.
Key Words: Software Reuse. Component-Based Software Engineering. MDA.

Python. Django. Models Transformations.
SUMRIO:
1. Introduo .....................................................................................................................
1.1 Contexto e Motivao ...................................................................................................
1.2 Objetivos ......................................................................................................................
1.2.1 Objetivos Gerais ........................................................................................................
1.2.2 Objetivos Especficos ................................................................................................
1.3 Estrutura do Trabalho ...................................................................................................
2. Embasamento Terico .................................................................................................
2.1 Desenvolvimento baseado em componentes ...............................................................
2.2 Unifiel Modeling Language (UML) ................................................................................
2.3 Model Driven Architecture (MDA) .................................................................................
2.4 A Linguagem Python ....................................................................................................
11
2.5 O framework django .....................................................................................................
13
2.6 A linguagem Shell Script ..............................................................................................
16
2.7 O Sistema de gerenciamento de dados (Postgresql e SQLite3) .................................
18
2.8 Concluso do Captulo .................................................................................................
18
3. Fundamentao Terica da Proposta .........................................................................
20
3.1 Caracterizao da pesquisa .........................................................................................
20
3.2 Problematizao ...........................................................................................................
21
3.3 Modelos utilizados pelo MDA .......................................................................................
22
3.4 Padro reusvel visual para modelagem estrutural bsica, meta-modelagem: a

Infraestrutura UML2: ...........................................................................................................
30
3.5 Meta-modelagem: MOF2 e ECORE..............................................................................
34
3.6 A Modelagem comportamental: Superestrutura UML2 ................................................
36
3.7 Linguagem textual para modelagem, metamodelagem avanada OCL2 .....................
38
3.8 Abordagens para projetos de linguagens de modelagem avanada ............................
40
3.9 Consideraes Finais deste captulo ............................................................................
42
4. A Ferramenta PyMDAGenerator: "A abordagem proposta" .....................................
43
4.1 Definio da ferramenta ...............................................................................................
43
4.2 Viso geral da abordagem proposta ............................................................................
45
4.3 Apoio definio de transformaes ...........................................................................
46
4.4 Etapas de transformao entre os modelos usando a biblioteca UML2DJ .................
55
4.5 Consideraes Finais deste captulo ............................................................................
62
5. Exemplo: Sistema "Retriever" e o Sistema Patrimonial "Asset Inventory" ...........
63
5.1 Definio do problema .................................................................................................
63
5.2 Stakeholders, requisitos funcionais e no funcionais ..................................................
64
5.3 Modelos de artefatos e documentos do projeto ...........................................................
69
5.4 Interfaces da aplicao e requisitos do sistema "Retriever" .........................................
73
5.5 O sistema de gesto de inventrios patrimoniais "Asset Inventory" ............................
78
5.6 Consideraes finais deste captulo .............................................................................
82
6. Estudo comparativo entre a ferramenta ANDROMDA (Java) PyMDAGenerator

(Python) .............................................................................................................................
84
6.1 O projeto "Retriever" na arquitetura Java JEE com ANDROMDA ..............................
85
6.2 Representao dos dados aplicados ao projeto "Asset Inventory" desenvolvimento

na linguagem Python com Django .....................................................................................
87
6.3 Grfico comparativo entre os dos processos ...............................................................
90
6.4 Consideraes finais sobre este captulo .....................................................................
93
7. Consideraes Finais ..................................................................................................
95
7.1 Eplogo .........................................................................................................................
95
7.2 Contribuies ...............................................................................................................
96
7.3 Limitaes ....................................................................................................................
98
7.4 Trabalhos Futuros ........................................................................................................
99
8. Referncias Bibliogrficas ...........................................................................................
101
9. Apndices ....................................................................................................................
107
Apndice 1 ........................................................................................................................
108
Apndice 2 ........................................................................................................................
114
Apndice 3 ........................................................................................................................
118
Apndice 4 ........................................................................................................................
123
Apndice 5 ........................................................................................................................
127
Lista de Figuras.
Figura [1] - Taxonomia dos diagramas da UML 2.1.................................................................
Figura [2] - Arquitetura da MDA ...............................................................................................
10
Figura [3] - Processo de transformao do PIM para PSM e do PSM em cdigo..................
24
Figura [4] - Processo de transformao MDA (Guide).............................................................
25
Figura [5] Ciclo de vida do desenvolvimento baseado em MDA .........................................
26
Figura [6] - Interoperabilidade MDA usando Pontes ..............................................................
29
Figura [7] - Infraestrutura em UML2 Meta Modelagem ..........................................................
31
Figura [8] - Infraestrutura do diagrama de classe segundo UML2 e MOF ............................
32
Figura [9] - Infraestrutura do diagrama de Data Type segundo UML2 e MOF......................
33
Figura [10] - Infraestrutura do diagrama de package segundo UML2 e MOF.........................
33
Figura [11] - Estrutura completa do MO at M3.......................................................................
34
Figura [12] - Estrutura completa EMF ECORE.......................................................................
35
Figura [13] - Estrutura interna Diagrama de Activity - UML2 e MOF .....................................
37
Figura [14] Estrutura Interna do Diagrama de Atividades - UML2 e MOF ..........................
38
Figura [15] - Modelagem UML do Sistema de Controle de Vo (OCL)....................................
40
Figura [16]- Diagrama que representa a ferramenta PyMDAGenerator ................................
44
Figura [17] - Figura que representa o Meta Modelo do UML2DJ ..........................................
47
Figura [18] - Figura que representa as transformaes do modelo Django Framework.........
47
Figura [19] - Detalhes do Meta Modelo componente UML2DJ ...............................................
48
Figura [20] - Detalhes do Meta Modelo UML2DJ - Viso tipos de atributos ......................
49
Figura [21] - Detalhes do Meta Modelo UML2DJ - Associao .............................................
50
Figura [22] - Figura que representa o esquema de ligao dos componentes do django ......
51
Figura [23] - Diagrama de Instalao ......................................................................................
52
Figura [24] - Componentes internos do django .......................................................................
54
Figura [25] - Diagrama de classe modelo do sistema retriever ...............................................
56
Figura [26] - Arquivo no formato XMI - representao do domnio .........................................
57
Figura [27] - Detalhe do processo de transformao entre PSM to Cdigo Fonte .................
58
Figura [28] - Arquivo com os comandos em shell script do PIM - GeradorMDAPIM.sh .........
59
Figura [29] - Arquivo com os comandos em shell script do PSM GeradorMDAPSM.sh ........
61
Figura [30] - Diagrama de casos de uso "Retriever" ............................................................
69
Figura [31] - Diagrama de classes - "Retriever ......................................................................
70
Figura [32] - Diagrama de componentes - viso interna (MVC) .............................................
72
Figura [33] - Diagrama de instalao - viso externa "Retriever" ............................................
73
Figura [34] - "Retriever" - Tela de Autenticao de usurios no sistema ................................
74
Figura [35] - "Retriever" - Seleo de Hospital para administrar .............................................
75
Figura [36] - "Retriever" - Tela de cadastro de ativos hospitalares .........................................
76
Figura [37] - "Retriever" - Tela de cadastro de unidades ........................................................
77
Figura [38] - "Retriever" - Tela de Cadastro de usurios .........................................................
77
Figura [39] - Sistema (Asset Inventory) - Tela com o menu principal do sistema ..................
79
Figura [40] - Sistema (Asset Inventory) - Tela de cadastro de Andar .....................................
80
Figura [41] - Sistema (Asset Inventory) Tela de Cadastro de rea .........................................
80
Figura [42] - Sistema (Asset Inventory) Tela de Cadastro de equipamentos ..........................
81
Figura [43] - Sistema (Asset Inventory) Tela de Cadastro de Eventos ...................................
82
Figura [44] - Pgina do Projeto PyMDAGenerator na Internet ...............................................
93
Lista de Tabelas
Tabela [1] Requisitos Funcionais ...........................................................................................
67
Tabela [2] Requisitos No-Funcionais ...................................................................................
68
Tabela [3] Quadro demonstrativo entre o projeto "Retriever" e o "Asset Inventory" .............
85
Tabela [4] Quadro demonstrativo dando nfase ao Projeto em Python com Django ..........
87
Tabela [5] Tabela informaes do projeto dando nfase ao n de linhas de cdigo .............
91
Lista de Grficos
Grfico [1] Informaes Estatsticas do Projeto "Retriever" JEE.......................................................
87
Grfico [2] Grfico com os dados estatsticos do projeto em Python + Django................................
89
Grfico [3] Grfico com as informaes unificadas entre o desenvolvimento Java JEE x Python Django ......
90
Grfico [4] Grfico com as informaes estatsticas, azul para o Python e Laranja para Java.......................
91
Grfico [5] Grfico com a variao dos percentuais entre os projetos (Java x Python) ...................
92
ACRNIMOS
Sigla
Significado
ATL
ATL TRANSFORMATION LANGUAGE
BPEL
BUSINESS PROCESS EXECUTION LANGUAGE
BPM
BUSINESS PROCESS MANAGEMENT
CIM
COMPUTER INDEPENDENT MODEL
CWM
COMMON WAREHOUSE METAMODEL
DSL
DOMAIN SPECIFIC LANGUAGE
EMF
ECLIPSE MODELING FRAMEWORK
HTML
HYPERTEXT MARKUP LANGUAGE
IDE
INTEGRATION DEVELOPMENT ENVIRONMENT
JSON
JAVA SCRIPT OBJECT NOTATION
MDA
MODEL DRIVEN ARQUITECTURE
MDE
MODEL DRIVEN ENGENIEER
MOF
META MODEL OBJECT FACILITY
MVC
MODEL VIEW CONTROLLER
OMG
OBJECT MANAGEMENT GROUP
ORM
OBJECT RELATIONAL MAPPING
OSGI
OPEN SERVICES GATEWAY INITIATIVE
PIM
PLATAFORM INDEPENDENT MODEL
PSM
PLATAFORM SPECIFIC MODEL
QVT
QUERY VIEW TRANSFORMATION
RUP
RATION UNIFIELD PROCESS
SGBD
SISTEMA GERENCIADOR DE BANCO DE DADOS
SQL
STRUCTURE QUERY LANGUAGE
SSL
SECURE SOCKET LAYER
UML
UNIFIELD MODELING LANGUAGE
XMI
XML METADATA INTERCHANGE
XML
EXTENSIBLE MARKUP LANGUAGE
1. INTRODUO
1.1 Contexto e Motivao

Segundo (SOMMERVILLE, 2011, p. 89-100) a Engenharia de Software vem
evoluindo ao longo dos anos no que diz respeito a arquiteturas, linguagens de
programao, arcabouos de desenvolvimento de software, novos paradigmas e
processos de desenvolvimento, dentre outros aspectos. Apesar desses avanos,
ainda um grande desafio desenvolver software com qualidade devido a fatores
como: (a) crescente demanda por sistemas complexos e de grande porte, com uma
alta portabilidade e de fcil manuteno; (b) mudanas de tecnologia e requisitos; (c)
alto acoplamento com a plataforma escolhida; (d) m gerncia dos projetos de
desenvolvimento.
Com o objeto de propor uma soluo para os problemas supracitados, em
2001, a Object Management Group (OMG)1 apresentou uma iniciativa chamada de
Arquitetura Orientada a Modelos, do ingls Model Driven Architecture (MDA), cujo
principal objetivo mudar o foco do desenvolvimento de software para a importncia
que os modelos devem ter nesse cenrio. Tais modelos passam a ter um papel
fundamental na documentao e nas demais fases do ciclo de vida do processo de
desenvolvimento de software, inclusive na fase de codificao.
Um modelo pode ser entendido com um conjunto de elementos que
descrevem alguma realidade fsica ou abstrata. A utilizao de modelos eleva o nvel
de abstrao no desenvolvimento de sistemas, auxiliando no planejamento e
entendimento dos mesmos, alm de promover uma clara separao entre aspectos
lgicos, responsveis por descrever as regras de negcio do software, da tecnologia
usada para implementao (MELLOR, 2005, p. 56-87).
Organizao internacional que aprova padres abertos para aplicaes orientadas a objetos
2
A proposta da MDA aumentar o nvel de abstrao no desenvolvimento de
sistemas de tal forma que os modelos gerados sejam independentes de plataforma.
A partir dos modelos de mais alto nvel, novos modelos so derivados, passando
pelo Modelo Independente de Plataforma, do Ingls Platform Independent Model
(PIM), em seguida para o Modelo Especfico de Plataforma, do ingls Platform
Specific Model (PSM), at o nvel mais baixo abstrao que o prprio cdigo-fonte
da aplicao. Para isso, ferramentas de transformao entre modelos e gerao de
cdigo devem ser utilizadas. Com isso, mudanas de requisitos ou mesmo de
tecnologia no impactaro em um alto custo para realizao das alteraes, sendo
necessrio somente repetir a transformao do modelo PIM, para o novo modelo
PSM agora especfico da nova plataforma alvo e por fim gerar o cdigo-fonte.
Diante desse contexto, o objeto deste trabalho definir uma orquestrao de
componentes reutilizveis de software, visando garantir uma semi-automatizao do
processo de gerao de cdigo baseando-se nos conceitos propostos pela MDA.
Para demonstrar a viabilidade da abordagem proposta, uma ferramenta para
gerao automtica aplicaes para a Web foi desenvolvida, utilizando a linguagem
Python e o framework Django.
3
1.2 Objetivos
1.2.1 Objetivo Geral

O objetivo geral deste trabalho propor e avaliar uma abordagem extensvel
baseada na orquestrao de componentes reutilizveis de software, para definio
de transformaes unidirecionais entre modelos (PIM para PSM e PSM para cdigo).
Tal abordagem deve permitir sua utilizao atravs de um parser XMI, junto com
uma biblioteca intitulada UML2DJ e um conjunto de tratadores implementados em
Shell Script para executar o processo de transformao e gerao semi-automtica
de aplicaes baseada em MDA, sendo realizado de maneira assistida atravs de
uma ferramenta chamada PyMDAGenerator.
1.2.2 Objetivos Especficos
Definir uma orquestrao de componentes reutilizveis de software,

visando garantir uma semi-automatizao do processo de gerao de
cdigo com a arquitetura dirigida a modelos MDA;
Propor uma soluo para o desenvolvimento de software para Web

baseados em modelos utilizando diagramas escritos na linguagem UML;
Criar e estruturar um meta modelo da biblioteca UML2DJ2 aplicado ao

framework Django que servir de modelo de referncia para gerao das
transformaes;
Melhorar o mecanismo de leitura dos dados existentes nos arquivos XML,

UML2DJ;
Biblioteca UML to Django - Faz a converso direta de modelos UML para estrutura dos projetos do Django
Construir uma ferramenta para gerar de forma automtica aplicaes para

a Web, utilizando a linguagem Python e o Framework Django;
Realizar um estudo comparativo entre o desenvolvimento baseado em

componentes com MDA.
5
1.3 Estrutura do Trabalho
Este trabalho estruturado da seguinte forma:
O Primeiro Captulo introduz e apresenta o contexto desta dissertao,

descreve, comenta e motiva o trabalho, seus objetivos gerais e especficos e
estrutura dos captulos;
O Segundo Captulo relata o embasamento terico onde so apresentadas

informaes bsicas sobre as metodologias, ferramentas, linguagens e
frameworks tais como: MDA, Python, Django, entre outros;
O Terceiro Captulo prossegue no embasamento terico especificando em

detalhes as caractersticas da UML e MDA com vises de meta modelo e
transformaes entre modelos com demais caractersticas;
O Quarto Captulo descreve informaes detalhadas sobre a orquestrao de

componentes reutilizveis de software e a metodologia de MDA aplicada
para gerao do cdigo;
O Quinto Captulo apresenta informaes sobre o estudo de casos do projeto

"Retriever" e do projeto "Asset Inventory" com sua definio do problema,
requisitos, soluo proposta e conjunto de artefatos produzidos, interfaces
grficas e caractersticas;
O Sexto Captulo propriamente dita a anlise comparativa entre o

desenvolvimento do projeto MDA com a ferramenta ANDROMDA e o projeto
com as tecnologias baseadas em reuso de software (MDA) com a ferramenta
PyMDAGenerator;
O Stimo captulo emite as consideraes finais onde so apresentados as

epgrafe, contribuies, limitaes, pontos positivos e negativos, inclusive os
trabalhos futuros.
2. EMBASAMENTO TERICO
Neste captulo ser feita a contextualizao desta pesquisa. Inicialmente,
iremos apresentar uma definio das principais tecnologias da informao e
comunicao (TIC) utilizadas nesta pesquisa, tais conceitos so importantes para a
Engenharia de reuso de Software, bem como de suas principais caractersticas e,
ainda, as influncias que exercem na Engenharia de Software baseada em Modelos
do tipo (MDA/MDE) e UML. Em seguida, sero discutidas as tecnologias baseadas
na linguagem Python com Framework Django, juntamente com SGBD, Postgresql e
SqLite3, tais como definio, caractersticas e tambm suas vantagens e
desvantagens.
2.1 Desenvolvimento Baseado em Componente
O desenvolvimento baseado em componentes um paradigma de
desenvolvimento de software caracterizado pela composio de partes j existentes,
ou pela composio de partes desenvolvidas independentes e que so integradas
para atingir um objetivo final. Conforme (SZYPERSKI, 1999, p. 20-30), construir
solues pela combinao de componentes garante o reuso do cdigo. Com isso, o
desenvolvimento baseado em componentes auxilia na manuteno dos sistemas e o
uso dela associado elaborao de linhas de produtos de software reduz
significativamente o redesenvolvimento de linhas de cdigo. Para que o reuso de
software seja eficiente em um ambiente produtivo de fbrica de software, por
exemplo, os arquitetos procuram expressar os relacionamentos entre as unidades
de design, tais como Web services e componentes de negcio. Para garantir o
sucesso no ciclo de vida de desenvolvimento de software o arquiteto tem o desafio
de mapear as funcionalidades desejadas sobre os componentes existentes nvel
de negcio, infraestrutura e arquitetura do domnio da aplicao (CHEESMAN, 2001,
p. 49-70).
Na engenharia de reuso de software os componentes so blocos de
construo bsicos, que aliceram esta arquitetura. A distribuio e fragmentao
7
destes blocos implica no aumento do reuso, melhoria da produtividade e
manutenabilidade dos componentes.
Nesta arquitetura possvel mapear a maneira de automao de um
processo de produo de software analisando as especificidades do modelo de
negcio e seus componentes bsicos para realizar as transformaes.
Para aumentar a velocidade de produo dos projetos de software
importante ter uma base de componentes extremamente granular, separando-os do
desenvolvimento em domnios independentes de plataforma com a UML, dos
domnios
especficos
de
plataforma
baseados
em
DSL,
minimizando
especificidade do modelo de negcio.

2.2 Unifield Modeling Language (UML)
A presente seo apresenta uma breve descrio da Unified Modeling
Language (UML) e os principais conceitos e padres relacionados mesma. Esses
conceitos so de grande importncia para um bom entendimento por parte de
leitores que no estejam familiarizados com esta tecnologia, tendo em vista que a
mesma tem um importante papel no presente trabalho.
Segundo (JACOBSON, 1999, p. 30-50), Unified Modeling Language (UML)
uma
linguagem
grfica,
para
especificao,
visualizao,
construo
documentao de artefatos de sistemas de software, principalmente sistemas

orientados a objetos. A UML nasceu da unificao das muitas linguagens grficas de
modelagem orientada a objetos que surgiram no final dos anos oitenta e inicio dos
anos noventa (FOWLER, 2005, p. 24-54).
Hoje, a UML a linguagem padro no mundo para a modelagem de sistemas
orientados a objetos. Isso se deve a algumas caractersticas, tais como: ser uma
linguagem de propsito geral, ou seja, independente de uma etapa do
desenvolvimento de software; no est presa a um processo; independe de uma
linguagem de programao; no possui semntica formal bem definida, entre outras
caractersticas. Este trabalho usar como base a verso 2.1 da UML que tem como
base os treze diagramas da UML 2.0 apresentados na figura 02, conforme os
8
modelos Estrutural da UML e Comportamental da UML, tal referncia encontra-se no
documento de
especificao da UML
2.1
no site da OMG
(UML
2.1
SPECIFICATION, 2012, p. 31-80).
Figura [1]: Taxonomia dos diagramas da UML 2.1

Fonte: UML 2.1 SPECIFICATION
Na prxima seo, sero apresentadas algumas informaes sobre a

arquitetura dirigida a modelos (MDA) seus conceitos, caractersticas e principais
recursos, este estudo, tem como principal abordagem o Model Driven Architecture
(MDA), por isto, tem-se um devido destaque apropriado.
2.3 Model Driven Architecture (MDA)
A presente seo apresenta uma breve descrio do MDA. Esses conceitos
so de grande importncia para um bom entendimento por parte de leitores que no
estejam familiarizados com esta tecnologia, tendo em vista que a mesma tem um
importante papel no presente trabalho. Model Driven Architecture (MDA) uma
abordagem para desenvolvimento de software que tem como princpio a importncia
dos modelos dentro do processo de desenvolvimento de software. MDA foi uma
iniciativa da OMG, lanada em 2001. Dentro da MDA, o processo de
9
desenvolvimento do software impulsionado pela atividade de modelagem do
sistema de software que passa a ter um papel fundamental. Alm de apenas
documentar o sistema, a modelagem passa a ter um papel ativo nas etapas de
desenvolvimento do software (KLEPPE, 2003, p. 42-50).
A utilizao do MDA possibilita a automatizao de algumas das etapas
dentro do processo de desenvolvimento de software, incluindo a gerao do cdigofonte para a plataforma escolhida a partir de um determinado modelo. De acordo
com a MDA GUIDE, version 1.0.1 (2005) os trs principais objetivos da MDA so
promover uma maior portabilidade, interoperabilidade e a reusabilidade.
2.3.1 Arquitetura do MDA
O Model Driven Architecture representado atravs da Figura 3, nela
possvel identificar as principais tecnologias, reas de negcio da abordagem do
MDA na viso da OMG. Analisando-a, tem-se no centro o ncleo da arquitetura que
baseada nos padres de modelagem: UML (JACOBSON, 1999), MOF (MOF,
2013) e CWM (CWM, 2013), padres esses adotados pela OMG. As outras duas
camadas completam a arquitetura. A primeira representa as plataformas alvo do
framework atualmente e a segunda apresenta os servios que devem existir
independentes da plataforma adotada (MILLER e MUKERJI, 2001, p. 60-90).
Figura [2]: Arquitetura da MDA

Fonte: (OMG, 2013)
10
2.3.2 Ncleo
O ncleo do MDA compreende um conjunto de metamodelos UML,
desenvolvidos pela OMG, cada um abrangendo determinada rea do processo de
desenvolvimento. Esses metamodelos representam as caractersticas comuns de
todas as plataformas alvos, porm ser independente de qualquer plataforma
especfica (MILLER e MUKERJI, 2001, p. 84-99).
Como foi mencionado anteriormente, o ncleo da arquitetura MDA formado
pelos padres de metamodelagem da OMG. Sendo eles:
Meta-Object Facility (MOF): Padro criado pela OMG que define uma
linguagem para a definio de linguagens de modelagem. Como o MOF
uma linguagem para criao de linguagens, ela pode ser considerada
uma metalinguagem. O MOF a linguagem em que os metamodelos de
UML e CWM so escritos (MILLER e MUKERJI, 2001, p. 71-90).
Common Warehouse Metamodelo (CWM): Linguagem para modelagem

de dados. A CWM derivada da MOF e utilizada dentro das
transformaes entre modelos (MILLER e MUKERJI, 2001, p. 93-109).
Unified Model Language (UML): Utilizada para especificar, visualizar e

documentar modelos de software, incluindo sua estrutura e designer, de
modo que englobe todos os requisitos (JACOBSON, 1999, p. 32-56).
Outro importante conceito que est diretamente ligado aos padres de

modelagem citados acima, que vale a pena ressaltar e que no mostrada na figura
3, o XML Metadata Interchange (XMI, 2013).
XML Metadata Interchange um padro em MOF da OMG para troca de

informaes baseado em XML. O uso mais comum na troca facilitada de
metadados entre as ferramentas de modelagem e os repositrios.
(XMI, 2013).
Sobre os domnios e caractersticas aplicados a MDA esto o conceito de CIM

(Modelo Computacional) depois a transformao para PIM (Modelo Independente de
11
Plataforma) na sequncia a criao do PSM (Modelo Especfico de Plataforma),
consiste em realizar as transformaes de PSM para cdigo e depois rodar a
aplicao. Na prxima seo sero apresentadas algumas informaes sobre a
linguagem Python seus conceitos, caractersticas e principais recursos.
2.4 A Linguagem Python
A presente seo apresenta uma breve descrio da linguagem Python.
Esses conceitos so de grande importncia para um bom entendimento por parte de
leitores que no estejam habituados com esta tecnologia.
Segundo (DAVI M. BEAZLEY, 2009, p. 35-43), Python uma linguagem de
programao de alto nvel, interpretada, imperativa, orientada a objetos, de tipagem
dinmica e forte. Foi lanada por Guido van Rossum em 1991. Atualmente possui
um modelo de desenvolvimento comunitrio, aberto e gerenciado pela organizao
sem fins lucrativos Python Software Foundation. Apesar de vrias partes da
linguagem possurem padres e especificaes formais, a linguagem como um todo
no formalmente especificada. A linguagem foi projetada com a filosofia de
enfatizar a importncia do esforo do programador sobre o esforo computacional.
Prioriza a legibilidade do cdigo sobre a velocidade ou expressividade. Combina
uma sintaxe concisa e clara com os recursos poderosos de sua biblioteca padro e
por mdulos e frameworks desenvolvidos por terceiros.
2.4.1 - Caractersticas da Linguagem
Sobre o ponto de vista das suas caractersticas, a linguagem Python possui
construes que incluem: estrutura de deciso (if, else, elif); estruturas de repetio
(for, while), que iteram por um container, capturando cada elemento em uma varivel
local dada; construo de classes (class); construo de subrotinas (def); construo
de escopo (with) entre outros recursos da linguagem. A linguagem possui tambm
caractersticas comuns s outras linguagens de programao entre elas:
Palavras reservadas, operadores, interpretador interativo, anlise lxica,

indentao, compilador de bytecode, orientao a objetos, programao
funcional, tratamento de excees, biblioteca padro.
12
Mdulos e frameworks: Outra caracterstica da linguagem Python o grande

nmero de frameworks para desenvolvimento de software, entre eles
podemos citar: Django, Pylons, TurboGears, PyOpenGL, Pygame, Twisted,
Pyro, ZODB, Plone, CherryPy, Web2py, Visual Python, SQLObject, etc.
Um dos motivos de escolha da linguagem Python neste trabalho foi a grande
aceitao pela comunidade que trata de solues de cdigo aberto, em especial

Linux, e pela aceitao nas empresas (pblicas e privadas) e instituies de ensino
superior e universidades federais, hoje em dia, a quantidade de frameworks de
desenvolvimento para web vem crescendo nos ltimos anos, e empresas como a
globo.com, serpro, embratel, entre outras. So algumas das organizaes que
trabalham com solues desenvolvidas com a linguagem Python.
13
2.5 O Framework Django
O Django um framework de desenvolvimento web, escrito em Python, que
foi criado pelo grupo editorial "The World Company" para a criao da verso web
dos seus jornais. Posteriormente, em 2005, foi liberado sob a licena BSD,
tornando-se assim um software de cdigo aberto (DAVID M. BEAZLEY, 2009, p. 3060).
Assim como outros frameworks geis para desenvolvimento web, o Django
utiliza o conceito de DRY - Dont repeate yourself (No se repita), que trabalha com
a ideia de utilizar convenes em substituio s configuraes.
Isso quer dizer que, se for seguir determinadas convenes na maneira de
organizar seu cdigo, no precisar ficar configurando caractersticas especficas
dele. Isso agiliza muito o desenvolvimento. preciso utilizar configuraes um
pouco mais complexas somente nas situaes em que o comportamento padro do
Django no o esperado ou quando no possvel seguir as convenes criadas
pelo framework, algo raro de acontecer.
Existem
atualmente,
diversas
solues
baseadas
em
Python
para
desenvolvimento para Web, possvel citar alguns frameworks: Web2Py, CherryPy

e Plone.
Em virtude disso, foi escolhido o framework django para estes projeto, pois o
mesmo possui uma melhor distribuio dos componentes existente, facilitando assim
o desenvolvimento e execuo deste projeto, conforme caractersticas em detalhe
na prxima seo.
14
2.5.1 - O Projeto Django
O Django considerado um "superframework", pois composto de vrios
frameworks menores, entre eles possvel citar:
ORM: permite programar utilizando objetos sem se preocupar com a

persistncia desses dados no seu banco de dados relacional. Essa
camada de software abstrai toda a comunicao com seu banco de
dados, permitindo que voc manipule seus objetos sem o uso de SQL
( possvel acessar diretamente o banco de dados em uma aplicao
Django, mas esse tipo de uso s se torna interessante na otimizao
de determinadas queries).
Template System: fornece uma linguagem para a criao de

templates (HTML, XML, JSON, etc). Usados na gerao de pginas
dinmicas.
Sistema de Administrao: O Django um dos poucos frameworks

web
que
disponibilizam
uma
interface,
gerada
quase
que
automaticamente, que permite a administrao dos objetos de

negcios da sua aplicao.
URL dispatcher: cuida do processamento das URLs do sistema

executando funes especificas pelo desenvolvedor e possibilitando o
uso de URLs amigveis ao usurio.
Internacionalizao: facilita a internacionalizao de seus sistema,

permitindo que ele funcione corretamente com diversos idiomas.
Formulrios: gerao automtica de formulrios e facilitao na

manipulao dos dados enviados por meio deles.
Segurana: gerenciamento de autenticao de usurios e controle de

permisses.
15
Outros componentes: serializao de dados, sistema de testes

automatizado, servio de mensagens (e-mail e mensagens entre
usurios do sistema), sistema de cache de objetos, gerao de feeds
(RSS/Atom), paginao de resultados etc.
2.5.2 Paradigma MVC (Model-View-Controller)

O
Django
utiliza
paradigma
MVC
(Model-View-Controller)
para
desenvolvimento de aplicaes. Em algumas referncias do Django, possvel

encontrar a sigla MTV (Model-Templeate-View), que representa basicamente a
mesma coisa dita com palavras diferentes. Embora no seja obrigatrio o
desenvolvimento usando esse paradigma, extremamente recomendado, pois,
dessa forma, voc estar modularizando seu cdigo e desacoplando a camada de
negcio da aplicao das camadas de interface com o usurio. Alm disso, o Django
automaticamente organiza o esqueleto de seu projeto nesse formato e se baseia
nesse paradigma para suas convenes (conforme foi explicado anteriormente
sobre DRY) (GENNADIY ZLOBIN, 2013, p. 89-109).
Isso significa que a sua aplicao tem trs partes principais:
Model: contm a representao dos dados do projeto. Normalmente a parte

que se comunica com o banco de dados e que persiste seus dados. No caso
do Django, o sistema de ORM frequentemente usado na criao de nossas
classes de Model.
View:
cuida
da
visualizao
do
contedo
no
formato
escolhido.
Frequentemente, h vrias Views para um mesmo tipo de Model. No caso do

Django, o sistema de Templates quem cumpre esse papel.
Controller: cuida do acesso e da manipulao dos dados do Model, bem

como de outras partes que no envolvem o Model diretamente. No Django,
esse papel feito por dois componentes: o URL dispatcher e as views (por
isto MTV).
16
Na prxima seo sero apresentadas algumas informaes sobre a
linguagem Shell Script seus conceitos, caractersticas e principais recursos.
2.6 A Linguagem Shell Script
A presente seo apresenta uma breve descrio sobre o Shell Script, suas
definies caractersticas e principais aes. Segundo Julio Cezar Neves no livro
Programao em Shell Linux define que Shell Script uma linguagem de script
usada em vrios sistemas operacionais, com diferentes dialetos, dependendo do
interpretador de comandos utilizado. Um exemplo de interpretador de comandos o
bash, usado na grande maioria das distribuies GNU/Linux (JULIO CEZAR NEVES,
2006, p. 30-45).
Uma boa parte dos usurios definem o Shell Script como uma linguagem de
fcil aprendizagem. O primeiro passo , saber o que se deseja fazer, ento ver qual
o cdigo que executa este comando em Shell e a criar, basta escrever o cdigo em
algum editor de texto e salvar. Depois de salvo voc tem que executar o arquivo.
2.6.1 - Shell
Na linha de comandos de um Shell possvel utilizar diversos comandos um
aps o outro, ou mesmo combin-los numa mesma linha. Se colocarmos diversas
linhas de comandos em um arquivo texto simples, teremos em mos um Shell Script,
ou um script em Shell, j que script uma descrio geral de qualquer programa
escrito em linguagem interpretada, ou seja, no compilada. Outros exemplos de
linguagens para scripts so o PHP, Perl, Python, JavaScript e muitos outros.
Podemos ento ter um script em php, um script perl e assim em diante. (JULIO
CEZAR NEVES, 2006, p. 60-71)
Uma vez criado, um Shell Script pode ser reutilizado quantas vezes for necessrio.
Seu uso, portanto, indicado na automao de tarefas que sero realizadas mais de
uma vez. Todo sistema Unix e similares so repletos de scripts em shell para a
17
realizao das mais diversas atividades administrativas e de manuteno do
sistema.
Os arquivos de lote (batch - arquivos *.bat) do windows so tambm exemplos de
Shell Scripts, j que so escritos em linguagem interpretada e executados por um
Shell do Windows, em geral o command.com ou hoje em dia o cmd.exe. Os Shells
do Unix, porm, so inmeras vezes mais poderosos que o interpretador de
comandos do Windows, podendo executar tarefas muito mais complexas e
elaboradas. (JULIO CEZAR NEVES, 2006, p. 56-85)
Os scripts Shell podem ser agendados para execuo atravs da tabela crontab,
entre outras coisas. uma ferramenta indispensvel aos administradores de
sistemas Unix.
O Shell mais comum e provavelmente o que possui mais scripts escritos para ele
tambm um dos mais antigos e simples, o sh. Este Shell est presente em todo o
sistema tipo Unix, includo o Linux, FreeBSD, AIX, HP-UX, OpenBSD, Solaris,
NetBSD, Irix, etc. Por ser o shell nativo mais comum natural que se prefira
escrever scripts para ele, tornando o script mais facilmente portvel para outro
sistema. (JULIO CEZAR NEVES, 2006, p. 70-105)
Um dos motivos da escolha da linguagem Shell Script para este projeto foi a
sua sintaxe rica e simples, outro ponto importante a sua execuo no ambiente de
sistemas de arquivos do prprio sistema operacional e a facilidade de integrao dos
comandos do python com comandos da linguagem shell script, alm da execuo
em arquivos de shell com a extenso .sh.
Na prxima seo sero apresentadas algumas informaes sobre o sistema
gerenciador de banco de dados Postgresql e o SQLite seus conceitos,
caractersticas e principais recursos. O motivo da escolha entre os dois sistemas
gerenciadores de banco de dados foi o seguinte: O SQLite nativo e vem instalado
de forma padro para todas as verses do Django, inclusive para demonstrao
bastante utilizado, e o Postgresql foi aplicado no estudo de caso do projeto, e possui
18
uma grande aceitao na rea em virtude da sua popularidade e distribuio livre e
de cdigo aberto. Mais importante salientar que possvel utilizar a maioria dos
SGBD's de mercado inclusive o Mysql, Postgresql, etc.
2.7 O Sistema de Bancos de Dados (Postgresql e SQLite3)
A presente seo apresenta uma breve descrio do Postgresql e do
SQLite3, suas definies, caractersticas modelos de ao e tpicos operacionais.
Segundo (ANDREW YU e JOLLY CHEN, 1994, p. 45-60). O Postgresql um
Sistema Gerenciador de Banco de Dados (SGBD) relacional, utilizado para
armazenar informaes de solues de informtica em todas as reas de negcios
existentes, bem como administrar o acesso a estas informaes.
Para Andrew, hoje em dia o postgresql um dos principais SBGDs do mercado,
possui uma linguagem prpria baseada em PL/SQL, multiplataforma pode rodar no
Linux, Windows, MAC e possui uma grande aceitao nas Universidades e
Governos das esferas federais, estaduais e municipais, arquitetura simples e
modular escalvel e bastante robusto. Estas so algumas das pospostas do
PostgreSQL.
2.8 - Concluso do captulo
Neste captulo buscou-se apresentar o contexto inicial no qual esta pesquisa.
O crescimento e desenvolvimento cada vez maior destas tecnologias contriburam
muito para a evoluo da Engenharia de Software como um todo. De fato, cada
vez maior o nmero de empresas e instituies que fazem uso desta tecnologia,
garantindo assim um maior reaproveitamento dos modelos criados de software no
que tange os artefatos de anlise, projeto e especificao de software como tambm
o reuso do cdigo.
Esta pesquisa se prope a projetar uma ferramenta para gerao automtica
de cdigo baseada em MDA. Para ser utilizado com a linguagem Python e o
framework Django na construo rpida de sistemas de informao para web.
19
No prximo captulo sero apresentados mais detalhes sobre o embasamento
terico desta dissertao, que vem a ser um dos temas centrais desta pesquisa.
20
3. FUNDAMENTAO TERICA DA PROPOSTA

Este captulo apresenta algumas informaes sobre a caracterizao da
pesquisa em questo como tambm um complemento da fundamentao terica
deste trabalho incluindo um detalhamento sobre a Engenharia de Reuso de Software
e conceitos avanados de UML, OCL e MDA.
3.1 Caracterizao da Pesquisa

A pesquisa realizada nesta dissertao caracteriza-se como terica por
investigar as tcnicas propostas pela MDA. Segundo (DEMO, 2000, p. 45-56),
pesquisa terica uma pesquisa que dedicada a reconstruir teoria, conceitos,
ideias, ideologias, polmicas, tendo em vista, em termos imediatos, aprimorar
fundamentos tericos. Assim sendo, baseia-se na abordagem de pesquisa
qualitativa, tendo em vista que se prope a responder perguntas tais como: Quais os
atuais problemas identificados dentro do atual cenrio de desenvolvimento de
software baseados na engenharia de reuso de software? Como as tcnicas
propostas pela MDA iro solucionar alguns desses problemas? Quais os passos
necessrios para criao de uma ferramenta para gerao automtica de cdigo
para WEB?
Segundo (OLIVEIRA, 2008, p. 23-43), a abordagem qualitativa pode ser
caracterizada como sendo o processo de reflexo e anlise da realidade atravs da
utilizao de mtodos e tcnicas para a compreenso detalhada do fenmeno de
estudo em seu contexto histrico, segundo sua estruturao.
Neste contexto, o tipo de pesquisa adotado foi o exploratrio, devido ao fato
do principal objeto deste trabalho aplicar os conceitos de MDA para criao de um
PSM (Modelo Especfico de Plataforma). De acordo com (OLIVEIRA, 2008, p. 89100), pesquisa exploratria tem como objetivo fornecer uma explicao geral sobre
um determinado tema, atravs da delimitao do estudo, levantamento bibliogrfico,
leitura e anlise de documentos.
21
3.2 Problematizao
A atividade de desenvolvimento de software vem evoluindo nos ltimos

tempos, deixando de ser uma tarefa individual para coletiva e de artesanal para
baseada em modelos de Fbrica de Software, com papis bem definidos e
atividades gerenciadas. Mesmo assim, ainda possvel identificar algumas falhas
neste processo tais como: falhas no levantamento inicial das informaes baseados
em requisitos funcionais e no funcionais, falta de gerenciamento das atividades e
controle de produtividade da equipe, falta de treinamento necessrio sobre as
tecnologias aplicadas ao projeto, tais como: linguagem de programao, IDE,
ferramentas de modelagem e de gerenciamento de projetos. Em meio a esses
problemas, foram criadas diversas tcnicas de engenharia de software como, por
exemplo, os processos de desenvolvimento que tinham como objetivo melhor definir
todas as atividades que deveriam ser seguidas at que conseguisse um produto de
software. (SOMMERVILLE, 2011, p. 43-67)
Os processos de desenvolvimento melhoram bastante a forma de se
desenvolver software, e vrios problemas que antes assolavam as empresas, foram
mitigados. Infelizmente com o passar dos anos, novos problemas surgiram, e
atualmente o cenrio de desenvolvimento de software enfrenta diversos problemas.
Segundo
(SOMMERVILLE,
2011,
p.
109-134),
as
atuais
tcnicas
de
desenvolvimento de software conseguem em parte suprir as necessidades

gerenciais dentro dos projetos de software, na maioria dos casos continuam gerando
problemas como: produtividade, portabilidade, interoperabilidade, documentao e
manuteno.
Uma abordagem que visa mudar o foco do desenvolvimento de software
proposta pela OMG, chamada de MDA, objetiva propor novas formas de realizar o
desenvolvimento de software baseada no reuso de modelos abstratos de
componentes.
Nesse sentido, a grande pergunta que fundamentou a pesquisa foi seguinte:
Como realizar uma orquestrao entre componentes de software reutilizveis,
22
baseados na arquitetura dirigida a modelos (MDA), utilizando a plataforma Python +
Django?
Uma outra contribuio deste trabalho foi a modelagem do Meta

Modelo da biblioteca UML2DJ, haja vista que a mesma ainda no existia?
Como identificar os pontos em comum e as caractersticas necessrias
identificados no Meta Modelo da Biblioteca UML2DJ para realizar as
transformaes de Diagramas UML para arquivos no formato XMI em outras
plataformas alvo do tipo: Ruby on Rails por exemplo?
3.3 Modelos utilizados pelo MDA

Como mencionado anteriormente dentro da MDA, os modelos passam a ter
um papel chave dentro do processo de desenvolvimento de software, mas de fato o
que seria um modelo dentro da viso do MDA?
De acordo com (MELLOR, 2005, p. 34-59) um modelo consiste em conjuntos
de elementos que descrevem alguma realidade fsica, abstrata ou hipottica.
Atrelando esse conceito de modelo ao universo da MDA, tem-se que um modelo de
um sistema uma descrio ou especificao desse sistema e seu ambiente para
algum propsito determinado. Um modelo frequentemente apresentado como uma
combinao de desenhos e textos. O texto pode estar em uma linguagem de
modelagem ou em uma linguagem natural (MDA GUIDE, 2005, p. 102-145).
Dentro da MDA, os modelos representam uma parte da estrutura e/ou
comportamento de um sistema. Existe ainda a noo de criar diferentes modelos em
diferentes nveis de abstrao e depois lig-los, para formar uma implementao.
Alguns desses modelos existiro independentes de plataforma de software,
enquanto que outros sero especficos para uma plataforma alvo. Tendo em vista
essa abstrao, a MDA define trs modelos: Modelo Independente de Computao
(CIM), Modelo Independente de Plataforma (PIM) e Modelo Especfico de Plataforma
(PSM) (KLEPPE, 2003, p. 46-50).
23
3.3.1 Modelo Independente de Computao
O Modelo Independente de Computao (do ingls Computation Independent
Model, CIM) fornece a viso de um sistema de computao dentro de uma
perspectiva independente, ou seja, no mostra detalhes da estrutura do sistema,
modela-o considerando apenas as regras de negcios. Ele tem como foco os
requisitos do software (KLEPPE, 2003, p. 56-70).
Segundo o (MDA GUIDE,2005, p. 34-87), esse modelo tambm pode ser
chamado modelo de domnio, como ele independente de plataforma, acaba sendo
til para servir como fonte para um vocabulrio entre modelos, alm de ajudar na
comunicao entre equipe de desenvolvimento e o cliente.
3.3.2 Modelo Independente de Plataforma

O Modelo Independente de Plataforma (do ingls Platform Independent
Model, PIM) possui um alto nvel de abstrao por ser independente de qualquer
tecnologia. Na construo do PIM, so especificados a estrutura e o comportamento
de um sistema, alm de ser construdo de forma a no utilizar nenhuma
caracterstica que seja especfica de uma plataforma. O PIM deve apresentar uma
independncia que possa ser aplicada a diferentes plataformas alvo, ou seja, um
mesmo PIM pode se utilizado para plataformas diferentes (KLEPPE, 2003, p. 56-74).
Algumas das caractersticas que o PIM deve possuir so:
Conter informaes sobre o domnio da aplicao;
Dispensar dados sobre plataformas que sero utilizadas ou tecnologias
que sero empregadas;
Ser um modelo detalhado, sendo em geral, representado em UML.
24
3.3.3 Modelo Especfico de Plataforma
O Modelo Especfico de Plataforma (do ingls Platform Specific Model, PSM)
descreve o sistema a partir de uma plataforma especfica. Combina as
especificaes do PIM com os detalhes que mostram como o sistema usa um tipo
especfico de plataforma. (MDA GUIDE, 2005, p. 56-80).
O PSM gerado a partir de um PIM atravs do uso de UML Profile3, no
sentido em que um dado PSM possui informaes de como gerar artefatos
correspondentes a elementos do modelo que estejam marcados com esteretipos
do PIM. A partir de um PIM pode-se gerar vrios PSM.
3.3.4 Transformao entre modelos
Outro conceito chave dentro da MDA a transformao entre modelos, que
consiste no processo de converter modelos em outros modelos do sistema.
Basicamente
dentro
da
MDA,
existem
duas
grandes
transformaes:
transformao do PIM para o PSM e, posteriormente, a transformao do PSM em

cdigo-fonte para a(s) tecnologia(s) alvo. Essas transformaes podem ser feitas de
modo automatizado atravs de uma ferramenta de transformao, ou manualmente
por uma pessoa especializada. A Figura 05 ilustra esse cenrio (KLEPPE, 2003).
Figura [03]: Processo de transformao do PIM para o PSM e do PSM em cdigo

Fonte: (MELLOR, 2005)
Extenses UML para representar uma plataforma especfica.
25
Essas transformaes ocorrem por meio de regras de mapeamento que ditam
quais elementos do modelo fonte correspondem com elementos do modelo alvo.
Quando um mapeamento executado entre um modelo de origem e um modelo de
destino, ele define algum ou todo o contedo do modelo (MELLOR, 2005, p. 45-60).
De acordo com (MELLOR, 2005, p. 33-53), as transformaes automticas de
modelos aumentam a portabilidade e a eficincia no desenvolvimento de software,
que por sua vez, aumentam a qualidade do software enquanto reduz o tempo e
custo de desenvolvimento.
Como podem ser observadas na Figura 06, as ferramentas de transformao
so umas caixas pretas. Isso se deve ao fato de que a ferramenta de transformao
precisa ter definida uma regra de transformao, que descreve como o modelo deve
ser transformado. Dentro desse cenrio, um importante conceito o de Marcas
(KLEPPE, 2003, p. 65-109).
As Marcas so utilizadas para inserir nos elementos do modelo PIM, que
posteriormente sero transformados, por meio do mapeamento, para o modelo PSM.
Uma marca representa um conceito no PSM e aplicada a um elemento do PIM,
para indicar como esse elemento deve ser transformado. A Figura 06 representa o
conceito de marcar (MDA GUIDE, 2005, p. 32-54).
Figura [04]: Processo de transformao MDA GUIDE

Fonte: (MDA GUIDE, 2005)
26
3.3.5 Ciclo de vida do desenvolvimento na MDA
O ciclo de vida do desenvolvimento baseado em MDA ilustrado na Figura
07, nele pode-se observar que o ciclo proposto pela MDA no muito diferente do
ciclo de vida tradicional de desenvolvimento de software. As mesmas fases so
identificadas. Uma das principais diferenas reside nos artefatos que so produzidos
durante o processo de desenvolvimento. Os artefatos so modelos formais, ou seja,
modelos que podem ser entendidos por computadores (MELLOR, 2005, p. 41-54).
Figura [05]: Ciclo de vida do desenvolvimento baseado em MDA

Fonte: (KLEPPE, 2003), traduzido pelo prprio autor.
O PIM, o PSM, e cdigo fonte so mostrados como artefatos em diferentes

etapas do ciclo de vida de desenvolvimento. Dentro desse cenrio, eles representam
diferentes nveis de abstrao na especificao do sistema. A capacidade de
transformar um PIM em um PSM eleva o nvel de abstrao em que um
27
desenvolvedor pode trabalhar. Isso permite que um desenvolvedor possa lidar com
sistemas mais complexos, com menos esforo (KLEPPE, 2003, p. 65-90).
Seguindo esse ciclo de vida, primeiro realizado o levantamento de requisitos
do sistema, depois realizada a fase de anlise, nessa fase feita modelagem do
modelo PIM, de acordo com os requisitos identificados. Na fase de design,
realizada a transformao para PSM, levando-se em conta a tecnologia alvo usada
no desenvolvimento do sistema.
Na fase de codificao, realizada a segunda transformao proposta pela
MDA, que a transformao do PSM para cdigo fonte do sistema. Posteriormente
so realizadas as fases de testing e a deployment. Caso seja identificado algum erro
na fase de deployment, uma nova iterao realizada, sendo iniciada a partir da
fase de anlise, de forma a identificar e corrigir o erro no prprio modelo PIM. Com
isso a documentao do sistema, sempre estar atualizada.
3.3.6 Benefcios da MDA
Nesta seo foram apresentados alguns problemas encontrados no atual
processo de desenvolvimento de software, dentre eles: problemas de produtividade,
portabilidade, interoperabilidade e manuteno e documentao. Nessa seo ser
mostrado como a MDA pretende solucionar esses problemas.
De acordo com (KLEPPE, 2003, p. 45-60), a aplicao da MDA, dentro do
processo de desenvolvimento de software, apresenta melhorias na produtividade,
portabilidade, interoperabilidade, documentao e manuteno.
3.3.7 Produtividade
Na MDA, o foco principal est na modelagem do PIM. Os detalhes tcnicos

especficos de uma plataforma so acrescentados ao PIM a partir da transformao
deste para o PSM. Alm disso, uma boa parcela do cdigo-fonte da aplicao alvo
ser gerada da transformao do PSM para o cdigo fonte.
28
A tarefa mais difcil nesse contexto a definio de forma exata de como
sero feitas as transformaes. Essa definio uma tarefa difcil e complexa, que
necessita ser feita por pessoas qualificadas. Uma vez definida as transformaes, as
mesmas podem ser aplicadas para diversos projetos, resultando em um alto ganho
de produtividade (KLEPPE, 2003, p. 56-80).
Como parte do cdigo fonte da aplicao gerada a partir do PSM, a equipe
de desenvolvimento pode, dentro do cronograma previsto, despender mais tempo
para analisar as regras de negcio do sistema a ser desenvolvido e,
consequentemente, identificar e corrigir mais erros em tempo de anlise e assim
produzir um modelo PIM com uma maior qualidade.
Um alto ganho de produtividade pode ser alcanado atravs da utilizao de
ferramentas que automatizem a transformao do PIM para o PSM. Isso acarreta
que muitas informaes sobre a aplicao devem ser incorporadas no PIM e/ou na
ferramenta de transformao utilizada, pois agora o modelo de alto nvel (PIM) est
diretamente relacionado com o cdigo-fonte gerado. As exigncias em relao
integridade e coerncia do PIM so maiores que no desenvolvimento sem a
utilizao de uma ferramenta que automatize a transformao PIM para PSM
(KLEPPE, 2003, p. 76-91).
3.3.8 Portabilidade
Dentro da MDA, a portabilidade conseguida com foco na modelagem do
PIM, que por definio independente de plataforma. Logo o mesmo PIM pode ser
automaticamente transformado em diversos PSMs para diferentes plataformas. Com
isso, tudo o que voc modelar ao nvel do PIM, totalmente porttil (KLEPPE, 2003,
p. 78-80).
Se dentro do processo de desenvolvimento alguma ferramenta de automao
de transformao for utilizada, a portabilidade estar limitada a ela. Para as
plataformas mais populares j existem ferramentas que possibilitam essa automao
nas transformaes, para outras, necessrio ter uma ferramenta que suporte um
29
plugin4 para definio de transformaes e essas definies devem ser descritas
manualmente (KLEPPE, 2003, p. 103-120).
3.3.9 Interoperabilidade
O conceito de interoperabilidade que o MDA se refere a comunicao entre
os PSMs. Vrios PSMs de plataformas diferentes so gerados a partir de um mesmo
PIM, e s conseguem se comunicar graas ao conceito de bridges definido pela
MDA. A Figura 08 ilustra o conceito de interoperabilidade (KLEPPE, 2003, p. 45-60).
Figura [06]: Interoperabilidade MDA usando pontes

Fonte: (KLEPPE, 2003) - traduzida pelo prprio autor
Sendo capaz de transformar um PIM em dois PSMs para duas plataformas

diferentes, todas as informaes necessrias para fazer a ponte entre os dois PSMs
esto disponveis. Para cada elemento em um PSM, conhecido qual elemento do
PIM o originou e, para cada elemento PIM conhecido qual o elemento
correspondente no segundo PSM. Pode-se concluir, portanto, como elementos de
Dentro da informtica, plugin um software usado para adicionar funes a outros softwares
maiores, provendo alguma funcionalidade especial ou muito especfica
30
um PSM se relacionam com os elementos do segundo PSM, desde que tambm se
conhea todos os detalhes tcnicos dos dois PSMs. Com isso, tm-se todas as
informaes necessrias para gerar uma conexo entre os dois (KLEPPE, 2003, p.
34-67).
A utilizao de ferramentas que gerem alm dos PSMs, os bridges entre elas,
ir proporcionar a interoperabilidade das plataformas, proposta pela MDA.
3.3.10 Documentao e Manuteno
Dentro da MDA, o PIM representa um documento de alto nvel de abstrao
para um software. A grande diferena que o PIM tem um papel chave no
desenvolvimento do software, logo ele no pode ser descartado depois de
construdo. As mudanas realizadas no sistema iro obrigatoriamente refletir em
mudanas no PIM, para a partir da, ser feita uma nova gerao do PSM e
posteriormente do cdigo-fonte (KLEPPE, 2003, p. 30-50).
Existem ferramentas que mantm o PIM, o PSM e o cdigo-fonte gerado,
sincronizados, ou seja, qualquer alterao em algum destes elementos refletir em
alteraes correspondentes nos demais (KLEPPE, 2003, p. 30-45).
A documentao de mais alto nvel (PIM) estar diretamente ligada
implementao do sistema, tornando assim a manuteno do sistema e da prpria
documentao menos custosa, o que faz com que a documentao esteja sempre
atualizada e de boa qualidade, pois a desatualizao e m qualidade da
documentao afetam diretamente a qualidade do software.
3.4 - Padro reusvel visual para modelagem estrutural bsica, metamodelagem: A infraestrutura UML2
A UML2 cresceu de forma a incorporar diversas estruturas e componentes,
sobre o ponto de vista de estruturas de modelagem e diagramas ela ficou dividida
entre a infraestrutura (Diagram Type, Diagram Class, Diagram DataType, Diagram
Package).
31
O Diagram Type tem como caractersticas principal a de nomear tipos de
elemento seu meta-modelo constitudo de uma classe chamada Element, como
subclasses dela existem o NamedElement e o Comment que se relacionam tambm
entre si atravs da associao, o TypedElement e o Type so subclasses de
NamedElement e esto associadas entre si. Este modelo de abstrao perfeito
para criao de novos elementos da UML em nosso caso especificamente foi
utilizado para criao dos novos elementos do SPEMLM.
Figura [07]: Infraestrutura em UML2 Meta Modelagem

Fonte: (UML2.0 Infraestruture, 2009)
O Diagrama de Classe tem como caracterstica principal a definio e

criao de classes baseadas em modelo, a Figura 07 exibe a estrutura de
componentes do diagrama de classes conforme UML2, uma Class herda de Type, a
prpria classe possui um auto-relacionamento com si prpria para representar outras
super-classes, uma classe composta por Property e Operation as operaes
podem ou no ter Parmetros e seus os mesmos tem multiplicidade ou tipos, uma
propriedade ou atributo herda de TypedElement tambm herdam as caractersticas
de MultiplicityElement.
32
Figura [08]: Infraestrutura do Diagrama de Classe segundo UML2 e MOF

O Diagrama de DataType definem as meta-classes que modelam e

implementam os tipos de dados, sua principal caractersticas de integrar o modelo
a novos tipos de esteretipos definidos ao modelos, a class Type o principal
elemento deste modelo, j a classe DataType que herda de Type serve de base
para definio de novos elementos e tipos j existentes da UML2, tais como
enumeration, interface, entre outros. Ligadas a elas esto duas sub-classes a
PrimitiveType e o Enumeration que por sua vez, composta por EnumerationLiteral
que representa seus tipos e o prprio herda as caractersticas de NamedElement.
33
Figura [09]: Infraestrutura do

Diagrama
de
DataType
segundo
UML2
MOF
J para o Diagrama de Package sua principal caracterstica definir a

estrutura bsica de construo do ambiente onde ficaro os objetos modelos, a
classe Package herda as caractersticas do NamedElement, para simplificar esta
ao um Package est associado a um Type por composio, e possvel
implementar uma ao relativa a si prprio atravs do auto-relacionamento,
conforme ilustra a Figura 10.
Figura [10]: Infraestrutura do Diagrama de Package segundo UML2 e MOF

34
3.5 A metamodelagem: MOF2 e ECORE
O MOF2 (Meta Object Facility) um padro criado pela OMG que define uma
linguagem para a definio de linguagem de modelagem. Como o MOF uma
linguagem para criao de outras linguagens ela pode ser considerada uma
metalinguagem. O MOF2 reside na camada M3 da arquitetura dirigida a modelos
(MDA), e como no h uma camada superior para definir o MOF2, ele definido
atravs dele mesmo. O MOF2 a linguagem em que as definies de UML e CWM,
ou seja, os meta-modelos da UML2 e CWM so escritos.
A Figura 11 representa a viso de modelo, meta-modelo, meta-meta-modelo e
a camada M3 onde fica localizado o MOF2.
Figura [11]: Estrutura completa do MO at M3

Fonte: (http://www.thefullwiki.org, 2011)
O EMF (Eclipse Modeling Framework) um ambiente completo de

gerenciamento e construo
de modelos
predefinidos
(meta-modelos)
em
ferramentas e atravs dele possvel realizar algumas operaes existentes, tais
35
como: transformaes entre modelos, gerao de cdigo, engenharia reversa, entre
outras coisas.
O ECORE utilizado de ponte entre os ambientes e possibilita a integrao
entre a parte ou modelo construdo e sua implementao, ou seja, cdigo fonte.
Figura [12]: Estrutura completa EMF ECORE

Fonte: (http://download.eclipse.org/modeling/emf/emf/javadoc/2.6.0/org/eclipse/emf/ecore/packagesummary.html, 2011)
Um dos benefcios do uso do ECORE a sua capacidade de alta coeso e

baixo acoplamento, garantindo assim integrao com linguagens e formatos
diversos, como tambm integrao com ferramentas de modelagem e transformao
entre modelos.
36
Uma das caractersticas interessante do ECORE a possibilidade de
integrao com outras linguagens, transformaes entre modelos, diversas
ferramentas utilizam este recurso para realizar suas transformaes um exemplo o
BRModelo ferramenta de modelagem de banco de dados desenvolvida por uma
equipe de pesquisadores da UFRS que usam o EMF ECORE para realizar as
transformaes entre os modelos dos diagramas Entidade Relacionamento para o
modelo lgico do lgico para o modelo fsico (Script do Banco de Dados), outra
soluo partindo para o modelo de MDA a ferramenta ANDROMDA que reusa
EMF e ECORE para realizao das transformaes entre os modelos.
3.6 A modelagem comportamental: superestrutura UML2
Com o crescimento da UML2 cresceu significativamente na superestrutura, ou

seja, sobre o ponto de vista de comportamento dos objetos de modelagem e
diagramas ela ficou dividida nos seguintes diagramas: (Action, Activity, Common
Behavior, Interaction, State Machine, Use Case).
Para exemplo de definio iremos detalhar apenas os diagramas de Ao e

Atividades por fazerem parte do estudo deste trabalho.
Uma Action tem como caracterstica principal ser uma unidade da
especificao de comportamento serve como um conjunto de entrada e sada. Sobre
o ponto de vista comum as aes bsicas incluem aqueles que realizam operaes
de chamada, envio de sinal, invocao de comportamento entre outros.
37
Figura [13]: Estrutura Interna do Diagrama de Ao (Action) UML2 e MOF

Fonte: (UML2.1 SuperStructure, 2009)
A atividade de modelagem enfatiza a sequncia e as condies de

coordenao de comportamentos de nveis inferiores, a caractersticas de
modelagem dos processos de negcio, ou o desenvolvimento de algoritmo pode e
deve ser caracterizados e modelos atravs de diagramas de atividades.
No entanto, com o advento da UML2 agora possvel realizar a execuo
simultnea de objetos de forma estrutural ou comportamental, no nosso caso
necessrio modelar o problema de forma comportamental pra depois executar o
processo de forma automtica.
A Figura 13 representa a estrutura completa de classes e associaes
relacionadas ao diagrama de atividades.
38
Figura [14]: Estrutura Interna do Diagrama de Atividades (Activity) UML2 e MOF

Fonte: (UML2.1 SuperStructure, 2009)
A classe Activity herda as caractersticas de uma Behavior, a Activity

composta de um Activity Node a mesma generaliza suas aes com uma Action e
herda suas caractersticas de um NamedElement, conforme ilustrado na Figura 16.
3.7 Linguagem textual para modelagem avanada: OCL2

A presente seo apresenta uma introduo ao Object Constraint Language
(OCL) segundo (Dresden, 2013, link: http://dresden-ocl.sourceforge.net) e suas
principais caractersticas, conceitos e padres relacionados mesma. Esses
conceitos so de grande importncia para um bom entendimento por parte de
leitores que no estejam familiarizados com a linguagem de restrio ao modelo
orientada a objetos, tendo em vista que a mesma tem um importante papel no
presente trabalho.
Object Constraint Language (OCL) uma linguagem formal usada para
descrever expresses e restries sobre modelos orientados a objetos e outros
39
artefatos da UML. A OCL definida como uma norma adicional a UML, sendo
adotada pela OMG. A atual especificao aceita pela OMG a OCL 2.0 (OCL, 2006,
p. 34-50).
Os diagramas UML no fornecem todos os aspectos relevantes para a
especificao de um sistema orientado a objetos. Verifica-se, entre outras coisas, a
necessidade de se descrever restries adicionais sobre os objetos nos modelos. A
falta dessas restries pode levar a interpretaes ambguas de um mesmo modelo
(OCL, 2006, p. 45-89).
A OCL foi desenvolvida para ser uma linguagem formal, mas que fosse fcil de
ler e escrever. Ela foi desenvolvida inicialmente como uma linguagem de
modelagem de negcios dentro da International Business Machines (IBM)
Algumas das caractersticas da OCL so: no possui efeitos colaterais, tipada, tem
avaliao instantnea, no uma linguagem de programao, possui sintaxe e
semntica bem definida (OCL, 2006, p. 32-48).
Apesar de poder ser usada em alguns diagramas da UML, para o
desenvolvimento desse trabalho, a OCL ser mais utilizada em conjunto com o
diagrama de classes para se obter um modelo mais completo, para que possa ser
usado no processo de desenvolvimento baseado em MDA e com isso se obter uma
aplicao com uma maior qualidade.
A Figura 15 ilustra uma invariante OCL para realizar uma restrio no contexto
Vo onde o nmero de passageiros no pode ser maior do que o nmero de
assentos do Vo.
Empresa estadunidense voltada para a rea de informtica.
40
Figura [15]: Modelagem UML do Sistema de controle de Vo

Fonte: Slides Plano da Disciplina de Tpicos avanados em MDE
3.8 Abordagens para linguagens de modelagem avanada

Nesta seo sero apresentadas algumas abordagens relacionadas a
linguagens de modelagem de projetos baseados em DSL, Meta-modelo UML, Profile
UML, Framework OO UML e MLM, para o nosso trabalho a abordagem escolhida foi
a extenso do meta-modelo UML2, pois a mesma adotada atravs da biblioteca
UML2DJ.
3.8.1 Linguagens especficas de Domnio (DSL)

Segundo Martin Fowler uma Domain Specific Language (DSL) uma
linguagem de programao limitada para computador com um conjunto de
elementos e expressividade focada em um domnio especfico bem determinado. A
maioria das linguagens so de GPL (General Purpose Languages), que pode lidar
com qualquer tipo de informao e estrutura que se encontra durante um projeto de
desenvolvimento de software. Cada DSL s pode tratar de um aspecto especfico de
um sistema.
3.8.2 Extenso de meta-modelo UML2

Para
(WOODY,2002,
p.
56-98)
caracterstica
de
representar
conhecimento de forma abstrata se chama modelar, o que especifica as estruturas e

caractersticas de um modelo j existente e definem sua qualidade se chama metamodelagem, sua caracterstica de especializar a si prprio se chama meta-meta-
41
modelagem, isto acontece, pois o sentido de abstrao e representao do
conhecimento est em tudo que fazemos atualmente, quando precisamos explicar
determinada situao para as pessoas de forma grfica, fica mais fcil de entender.
Eles so bastante confundidos com Ontologias mais de diferem no uso de sua
gramtica e vocabulrio mais especfico.
3.8.3 Definio de Perfil UML2

Um Perfil contm vrios mecanismos que permitem meta-classes de metamodelos existentes para ser estendida ou modificada para diferentes fins, isto
importante quando precisamos adaptar um metamodelo UML para diferentes
plataformas tais como: (J2EE ou .NET), desta forma os domnios podem ser
alterados em tempo real ou atravs da modelagem de processo de negcio. Este
mecanismo consistente e segue o modelo da OMG e reusa MOF.
3.8.4 Definio de um PIM OO framework in UML2

Nesta viso a modelagem do PIM OO Framework in UML2 tem como
caracterstica principal no ser um meta-modelo, nem um profile, e sim um modelo
independente que representa as vises bsicas e objetivas de um determinado
domnio, sua principal caractersticas a simplicidade da modelagem e execuo,
partindo do princpio que o analista no precisa ter conhecimentos anteriores para
poder modelar nesta viso, o mesmo poder implementar as caractersticas
especificas diretamente utilizando somente UML2.
3.8.5 Modelagem Multi-Level

A Modelagem Multi-Level um novo conceito aplicado a distribuir as vises
de organizao de um modelo atravs da perspectiva de vises lingusticas e
ontolgicas aplicadas a modelagem dos objetos, nesta viso existe uma nova figura
intitulada ClaObject cuja funo definir as caractersticas em comum de Classe e
Objetos ao mesmo tempo sendo aplicadas em uma nova perspectiva de
representao deste modelos.
42
No prximo captulo sero discutidas e apresentados os detalhes sobre o
estudo de caso do projeto Retriever, seus requisitos funcionais e no funcionais,
modelos de arquitetura, designer de interface e alguns detalhes de sua arquitetura
com diagramas da UML.
3.9 Consideraes finais deste captulo

Neste captulo buscou-se apresentar uma fundamentao terica mais
detalhada sobre o MDA e os conceitos de transformao baseado em MOF e CMOF
e outras abordagens caractersticas da engenharia de software baseada em
componentes, j no prximo captulo ser apresentado informaes sobre a
ferramenta PyMDAGenerator suas etapas e elementos de transformao da parte
de requisitos at a aplicao propriamente dita.
43
4. A FERRAMENTA PYMDAGENERATOR: "A ABORDAGEM

PROPOSTA DA ORQUESTRAO DE COMPONENTES"
Este captulo tem como objetivo principal descrever o processo de

orquestrao entre os componentes reutilizveis de software, e propor uma
abordagem prtica e extensvel para definio de transformaes unidirecionais
entre modelos (PIM para PSM e PSM para cdigo), que permita sua utilizao
atravs de um parser XMI, junto com uma biblioteca intitulada UML2DJ e um
conjunto de tratadores implementados em Shell Script para executar o processo de
transformao e gerao semi-automtica de aplicaes baseada em MDA, sendo
realizado
de
maneira
assistida
atravs
de
uma
ferramenta
chamada
PyMDAGenerator, utilizando a linguagem Python e o framework Django.
4.1 Definio da Ferramenta

No Captulo 3, foram apresentados os principais conceitos sobre Arquitetura
Orientada por Modelos (MDA) e o impacto de sua utilizao no desenvolvimento de
software. Alm disso, foram descritos diversos tipos de transformao possveis e
uma categorizao das abordagens que utilizam o framework MDA, suas principais
caractersticas e deficincias.
A figura 16 representa um diagrama da arquitetura da orquestrao entre os
componentes, iniciando pela partes dos requisitos, depois pelo PIM, passando pelo
componente em Shell Script e da biblioteca em Python do (UML2DJ), logo em
seguida pelo PSM e por fim o cdigo fonte da aplicao.
44
Figura [16]- Diagrama que representa a Orquestrao de componentes

Fonte: Prprio autor.
A orquestrao composta por aes relacionadas a parte de requisitos,

conforme a figura 16, depois de elencados e descritos os requisitos funcionais e no
funcionais, os mesmos so transformados em artefatos da UML juntamente com a
linguagem OCL, sendo considerados no momento, modelos caractersticos do
domnio do problema atravs dos diagramas de classe, diagrama de componentes,
diagrama de casos de uso e instalao, juntamente com as aes relacionadas.
Para a execuo das instrues na caixa (Shell Script UML2DJ) so escritos
arquivos na linguagem Shell Script para gerar a importao do Arquivo XMI para a
plataforma Python Django atravs da biblioteca UML2DJ, produzindo a criao de
do is arquivos admin.py e models.py conforme a estrutura da caixa (PSM) no
diagrama lido, neste momento o Django j reproduziu o modelo de domnio da
aplicao, ficando agora responsvel pela gerao do modelo de dados baseado no
modelo UML e por fim a gerao automtica do cdigo fonte da aplicao em
Python pelo framework Django.
Neste captulo, apresentamos uma abordagem prtica para a definio e
execuo de transformaes, levando em considerao os critrios estabelecidos no
Captulo 3, que so: (a) independncia de ferramenta CASE ou ambiente de
desenvolvimento; (b) utilizao de formatos e linguagens padronizados ou de fcil
aprendizado; (c) apoio definio e execuo de transformaes modelo-modelo;
45
(d) apoio obteno da implementao atravs da gerao de cdigo
(transformaes modelo-texto); (e) possibilidade de extenso das transformaes
pr-definidas; (f) orquestrao de componentes reutilizveis de software baseado
em MDA.
A abordagem proposta neste captulo abrange os cenrios de transformao
do tipo modelo-modelo e as transformaes. As prximas sees detalham esta
abordagem e esto organizadas da seguinte forma: a Seo 4.2 apresenta uma
viso geral da abordagem e suas principais caractersticas; a Seo 4.3 descreve
como so definidas as transformaes entre modelos; a Seo 4.4 apresenta as
tcnicas de programao utilizadas em Shell script para realizar as transformaes
de PIM para PSM e PSM para Cdigo; a Seo 4.5 encerra o captulo, apresentando
algumas consideraes finais.
4.2 - Viso geral da abordagem proposta
Uma viso geral da abordagem proposta exibida na Figura 17. A
abordagem foi concebida para permitir a definio de transformaes de forma
independente de ferramenta CASE parte (a). O Projetista pode definir
transformaes sobre modelos UML. Essa definio de transformaes ser
detalhada na Seo 4.3. Aps elaborar os modelos na sua ferramenta CASE parte
(b), o Engenheiro de Software pode aplicar as transformaes previamente definidas
atravs de uma mquina de transformaes parte (c) e gerar a implementao
dos modelos na plataforma desejada. Para executar transformaes sobre modelos,
pode ser necessria a preparao prvia do modelo a ser transformado, atravs de
marcaes. Essa marcao e a execuo das transformaes sero detalhada na
Seo 4.4. Na Seo 4.5 so apresentadas rotinas em Shell Script que visam
automatizar o processo de transformao e por fim ser exibida as consideraes
finais sobre este captulo.
Algumas caractersticas gerais da abordagem foram definidas com base nos
critrios definidos nos captulos 2 e 3 e sero apresentadas nas prximas sees.
46
A Figura 17 descreve as aes de especificao do sistema de informao
baseado nos requisitos do projeto, depois o processo de modelagem utilizando uma
ferramenta, no prximo passo descreve marcao e execuo das transformaes e
por ltimo a gerao da aplicao baseada no modelo descrito anteriormente em
uma plataforma alvo especfica.
4.3 Apoio definio de transformaes
Conforme foi apresentado no captulo anterior, uma transformao pode ser
definida como um processo que realiza a converso de um modelo em um outro
modelo do mesmo sistema (OMG, 2003b). Estas transformaes seguem uma
sequncia de passos que foram mencionados anteriormente. Atualmente algumas
ferramentas de modelagem de dados tais como: BrModelo, ERWin, Astah, Borland
Together, IBM Rational Software e de banco de dados possuem um mecanismo de
transformao de Modelo Entidade Relacionamento para o modelo Lgico e do
lgico para o modelo Fsico, exemplo: Linguagem DDL e vice-versa.
4.3.1 - Exemplo do Meta Modelo da Biblioteca UML2DJ
O UML2DJ uma biblioteca de componentes responsvel pela transformao
de modelo de diagrama estrutural (Classe) em um arquivo no formato XMI que
posteriormente ser transformado para o modelo de projeto do framework Django.
Na prxima seo ser detalhado a estrutura do Meta Modelo do componente
UML2DJ. Para realizar esta modelagem foi necessrio entender o funcionamento
interno do componente como tambm suas principais caractersticas de execuo,
este meta modelo considerado uma grande contribuio para este trabalho, pois a
partir dele ser possvel customizar o componente para que o mesmo possa ser
utilizado em outras plataformas. Esta pesquisa teve como ponto de partida as
classes do referido componente e sua execuo em projetos previamente definidos.
47
Figura [17] Figura que representa a arquitetura do Meta Modelo do componente UML2DJ
Fonte: Prprio autor
O diagrama que representa o meta modelo da Figura 17 distribudo em vrios

componentes, entre os quais possvel mencionar em detalhes as seguintes
classes detalhadas na especificao da Figura 18.
48
Figura [18] Detalhes do Meta Modelo componente UML2DJ.

Conforme a Figura 18 que relata as aes em detalhe do Meta Modelo possvel

realizar as aes, a meta modelagem foi feita colocando os componentes com o
nome em Ingls, haja vista que o mesmo poder ser reusado em outros projetos.
O referido diagrama possui caractersticas tais como: A "Class" uma meta classe
da UML2DJ que herda as caractersticas de "Models.Model" uma classe abstrata
que define das caractersticas de transformao entre os modelos, da mesma forma
ela faz uma herana mltipla com Meta classe "Type".
Seguindo o modelo a classe "Property" possui uma associao do tipo composio
com a Classe "Class" descrevendo que a mesma pode ter nenhuma ou vrias
property e que uma property pode est associado a nenhuma ou uma classe.
A mesma "Property" realiza uma herana mltipla entre as classes "TypeElement" e
"MultiplicityElement". Partindo deste princpio uma classe do tipo "Package" est
herdando as caractersticas do "NamedElement".
49
Tais aes so necessrias para realizar as transformaes entre os modelos
abstratos de componente com os modelos concretos saindo do PIM para o PSM da
plataforma alvo.
Figura [19] Detalhes do Meta Modelo componente UML2DJ - Viso Direita

De acordo com a Figura 19, a classe "Db_Table" herda as caractersticas da classe

"Models.Model" baseadas no processo de especificao tem como caracterstica
fundamental e gerao e associao das Classes em Tabelas do modelo de banco
de dados, geralmente isto feito pela ferramenta ORM nativa da plataforma alvo, tal
como: SQLDB (Python), Hybernete (Java), etc. A classe "Package" possui uma
composio com a meta classe "Type".
Um "Package" possui um auto-relacionamento com si prprio para garantir o reuso
dos componentes baseado em pastas e estrutura de rvores.
50
Figura [20] Detalhes do Meta Modelo UML2DJ - Viso Tipos de Atributos, Operaes
Fonte: Prprio autor
De acordo com a Figura 20, a classe "AttributeType" herda est associada com a
classe "Db_table" nela possvel identificar as caractersticas das tabelas e
consequentemente as caractersticas definidas pelos atributos TextFiel, CharField,
DataField, FloatField, IntegerField, etc so os tipos de atributos definidos.
A mesma classe "AttributeType" est associada a classe "Operation" que descreve
as operaes realizadas a uma classe ou a atributos de classe, da mesma forma a
classe "Operation" est associada com a Classe "Type" da UML. Outra associao
identificada a composio existente entre as classes "Parameter" com a classe
"Operation". A mesma classe "Parameter" possui uma herana mltipla com as
classes "TypedElement" e "MultiplicityElement".
51
Figura [21] Detalhes do Meta Modelo UML2DJ - Associao

Fonte: Prprio autor
Para finalizar a explicao sobre o meta modelo so representadas atravs de uma

associao entre a classe "Association" com as Classes "Class" e "AttributeType".
Alm disso, a classe "Class" est associada entre uma composio com a classe
"Operation", estas caractersticas esto ilustradas na Figura 21.
4.3.2 - Exemplo de Arquitetura usando o Django em um Projeto Real

O Django possu um modelo de componentes que fornece um conjunto de
convenes, regras e padres para a implementao de sistemas para web, visando
a reutilizao dos componentes do Django (SUN, 2003, p. 34-50). o Django possui
caractersticas especiais e considerado um super framework, internamente existe
um mdulo de autenticao de usurios e perfis, um mecanismo de ORM
mapeamento objeto relacional de persistncia de dados, um template de interface
grfica predefinido, um mecanismo de URL Dispatcher.
52
Figura [22] Figura que representa o esquema de ligao dos componentes do Django
Fonte: Prprio autor
A Figura 22 representa o modelo de classe abstrata implementada no Django

conhecida como models.Model, so componentes localizados internamente no
Framework e encapsulam a lgica de negcio da aplicao. A utilizao do
models.Model possibilita o desenvolvimento de aplicaes escalveis, pois sua
execuo pode estar distribuda por diferentes aplicaes de forma transparente.
Ligado ao models existe um componente ORM responsvel pela gerao das
tabelas e integrao das informaes via SQL, alinhado a este conceito existe uma
URL Dispatcher responsvel por gerenciar toda s as URL aplicadas ao projeto, outro
recurso importante o seu Template SET, o Django possui um mdulo
administrativo com um template pr-definido podendo ser aplicado a todos os
projetos existentes em uma mquina, estas caractersticas podem ser vistas neste
modelo que representa os componentes da arquitetura.
Nesta parte do trabalho ser apresentado o modelo de arquitetura atravs do
diagrama UML de Instalao conforme Figura 23.
53
Figura [23] - Diagrama de instalao

Fonte: Prprio autor
A Figura 23 ilustra o diagrama de instalao o mesmo tem caracterstica de

instalao dos componentes externos, existe um mdulo de controle de usurios,
perfil e senhas, este componente faz parte do framework do django, alm disso,
existe um outro mdulo servios diversos onde ficam localizadas as informaes
referentes ao models. Model chamado de equipamento e tipo de equipamento estes
arquivos tem como caractersticas bsica os aspectos de negcio da aplicao, j
um outro mdulo administrao fica responsvel pelas classes entidade e sensor
ambas possuem ligao ao modelo de negcio tambm e ficam responsveis pela
redistribuio das classes do domnio desta aplicao.
O Diagrama de componentes da UML pode representar de forma mais
especfica os componentes internos do Django, servindo de base para o nosso PSM,
a descrio dos principais componentes sero apresentados na prxima pgina:
54
Estes componentes so:
__init__.py: Um arquivo vazio que diz ao Python que esse diretrio deve ser
considerado como um pacote Python. (Funciona como um arquivo principal
do projeto, idealizado para descrever a origem e inicializao do projeto).
manage.py: Um utilitrio de linha de comando que permite interagir com esse

projeto Django de vrias maneiras. possvel ler todos os detalhes sobre o
manage.py em 7http://www.djangobrasil.org, existem diversos comandos de
execuo de servidor, criao da instncia dos objetos da classe, validao
dos arquivos do modelo e configurao do ambiente como um todo, entre
outras opes, maiores informaes esto disponveis em django-admin.py e
manage.py.
settings.py: Configuraes para este projeto Django. Atravs deste arquivo

possvel definir todas as configuraes do projeto em geral, tais como:
configurao de banco de dados, timezone, estruturas e modelos de
configurao.
urls.py: As declaraes de URLs para este projeto Django; um "ndice" de

seu site movido a Django. Voc pode ler mais sobre URLs em
URLDispatcher.
55
Figura [24] - Componentes Internos do Django

Fonte: Prprio autor
Na Figura 24 descrito o Mdulo Administrador, que possui arquivos tais

como admin.py responsvel pela identificao da sequncia dos arquivos criados no
models.Model como tambm os mdulos de arquivos relacionados rea restrita da
aplicao, o arquivo models.py possui todas as caractersticas e classes gerados
sobre a regra de negcio da aplicao e do controle do domnio da mesma, tais
caractersticas so identificadas pelo conjunto de classes que fazem parte da regra
de domnio da aplicao, j os arquivos tests.py fica responsvel por executar os
testes unitrios da aplicao atravs de test.case e test.suite, enquanto que ao
arquivo views.py responsvel pela representao dos dados do projeto
relacionado a interface grfica da aplicao como um todo, caso no seja
implementada ir definir as caractersticas bsicas desta aplicao atravs do
template set.
56
4.4 - Etapas de Transformao entre os modelos biblioteca UML2DJ
Para realizar este procedimento foi utilizada a biblioteca UML2DJ6 necessrio
descrever esta ao em partes individualizadas chamadas de etapas, a primeira
chamada de CIM, depois o PIM e por ltimo a construo do PSM.
4.4.1 Construo do CIM (Modulo Independente de Computao)
Esta etapa consiste na identificao das regras de negcio baseadas no
domnio da aplicao, para este caso o Sistema de Gesto de Inventrios
Hospitalares "Retriever". Aps a coleta dos dados atravs de requisitos funcionais e
no funcionais, foi necessrio transcrever tais caractersticas para modelos, no
prximo captulo 5, sero descritos os requisitos funcionais e no funcionais do
projeto, como tambm alguns diagramas UML relatados aqui e que fazem parte da
descrio de arquitetura do sistema de informao.
4.4.2 A Construo do PIM (modulo independente de plataforma)
Para elaborao do Diagrama de classes foi preciso resgatar as informaes
do modelo CIM (Modelo Independente Computacional) atravs dos requisitos
funcionais e no funcionais, depois foi feita a modelagem funcional e estrutural do
Projeto "Retriever", o mesmo foi realizado de forma prtica atravs da UML pelo
diagrama de classes, importante resaltar que neste momento este artefato tem
como funo descrever a meta modelo da aplicao. Detalhes da modelagem e das
classes existentes no sistema so detalhadas na figura 25.
Site do UML to Django (UML2DJ) http://code.google.com/p/uml-to-django/
57
Figura [25] - Diagrama de Classe Modelo do Sistema "Retriever"

Fonte: Prprio autor
A Figura 25 apresenta o diagrama de domnio / modelo conceitual de classe

descreve de forma simples e objetiva as principais classes do modelo como tambm
suas multiplicidades e associaes, modelagem com as caractersticas estruturais
do domnio da aplicao.
Para realizar esta modelagem no diagrama de classe do projeto no foi
necessrio atribuir nenhum esteretipo as classes modeladas, isto acontece em
virtude do componente de integrao UML2DJ possuir caractersticas bsicas de
transformao
baseadas
no
MOF
que
independem dos
mecanismos
de
transformao e seguem o modelo UML2 padro. Diante desta caracterstica fica

mais simples e rpido realizar as transformaes empregadas neste estudo de caso.
Aps concluir este processo, o prximo passo consiste em exportar o
diagrama de classe modelado para um arquivo com a extenso XMI, este passo
corresponde ao formato de extenso mais conhecido para realizar o parsing entre as
plataformas.
58
A exportao feita atravs da ferramenta ARGOUML conforme Figura 26,
nela possvel identificar as caractersticas do modelo criado baseado em XMI.
Figura [26] - Arquivo no formato XMI - Representao do Domnio do Sistema

Fonte: Prprio autor
Atravs deste formato XMI possvel identificar os nomes das classes tais
como Evento, o nvel de visibilidade, neste caso "public", os atributos existentes
como cdigos, seus nveis de visibilidade, como tambm as associaes e
multiplicidades aplicadas ao modelo de domnio em questo, tais caractersticas so
de fundamental importncia para realizar as transformaes, neste caso, so
cruciais para o sucesso do projeto, isto acontece porque as ferramentas de gerao
de cdigo tem como descrever seus comportamentos justamente pelos detalhes
empregados no modelo de diagrama modelado.
59
Este arquivo foi copiado para a pasta lib. Do projeto feito em Python + Django
e o mesmo ser executado atravs do script em Shell chamado geradorMDAPIM.sh
este arquivo ir ler o XMI e realizar as referidas transformaes.
4.4.3 Aplicando transformaes da biblioteca UML2DJ, Modelo PSM
Para realizar as transformaes atravs da biblioteca UML2DJ, primeiro
necessrio configurar o ambiente, para que isto acontea necessrio instalar o
Python + Django e depois acrescentar a biblioteca libxml2, a mesma precisa estar
instalada no ambiente do projeto, este procedimento encontra-se no apndice 4
desta dissertao de mestrado, na figura 27 detalha este processo e etapas.
Figura [27] - Detalhe do processo de transformao entre PSM to Cdigo Fonte.

Fonte: Prprio autor
Esta figura 27 representa o procedimento de transformao de PSM para

cdigo, o procedimento consiste na execuo do arquivo geradorMDAPSM.sh que
na sequncia ir inicializar os componentes do Django URL Dispacher para construir
as URL da aplicao, Template System para construir as view, o mecanismo de
ORM chamado SqlDB que responsvel por transformar as classes em estruturas
do banco de dados e o Administrator System responsvel por criar o mdulo de
autenticao do sistema com login, senha e administrao dos papis e usurios do
sistema, estes componentes integrados realizam as transformaes e geram o
cdigo fonte.
60
Figura [28]- Arquivo com os comandos em Shell script - geradorMDAPIM.sh

A figura 28 representa o arquivo que chamado geradorMDAPIM.sh este

responsvel por executar as aes relacionadas transformao do Modelo UML
arquivo que foi feito pela ferramenta ArgoUML. Sua execuo simples e direta e
representa um conjunto com arquivos feitos na linguagem Shell Script. Na prxima
tabela ser exibida a lista com os comandos e a descrio de sua execuo no
formato de passo a passo, esta informao encontra-se no apndice V.
61
4.4.4 Continuando com as transformaes, modelo execuo PSM
Neste ponto possvel verificar que algumas aes j foram realizadas,
visando consolidar as transformaes foi criado um outro arquivo chamado
gerarMDAPSM.sh. Este aplicativo responsvel pela continuao da execuo dos
projetos e das aes de orquestrao.
Atravs do gerenciador ORM chamado SQLDB que o django possui
possvel descrever tambm a sintaxe dos comandos representados atravs da
modelagem UML (Diagrama de Classes) com o modelo de banco de dados,
descrito na DDL (Data Defination Language) conforme apndice III, maiores
detalhes sero apresentados no referido apndice III desta dissertao.
Nesta sequencia de comandos possvel ver como feita a transformao
entre o modelo conceitual de classes no modelo fsico do banco de dados, isto
acontece de forma automtica atravs do comando python manage.py syncdb.
A Figura 29 descreve a execuo em shell script dos principais comandos de
execuo da transformao do PSM para o cdigo fonte.
62
Figura [29] - Arquivo em shell script execuo do PSM - geradorMDAPSM.sh

Fonte: Prprio autor
O segundo arquivo chamado geradorMDAPSM.sh responsvel pela

continuidade das aes do arquivo anterior, consolidando as transformaes e
gerando o cdigo fonte necessrio para poder executar a aplicao e o sistema em
si. Na prxima tabela ser exibida a lista com os comandos e sua execuo, sua
execuo encontra-se em detalhes no Apndice V.
Como foi visto nas etapas anteriores de criao do CIM, modelagem do PIM,
transformao do PIM para PSM e gerao para cdigo, os arquivos executados
descrevem as etapas da transformao e fazem parte da orquestrao. O arquivo do
projeto criado pode ser executado atravs da URL: http://localhost:3000. No
momento da criao do projeto foi solicitado a implantao de um usurio para
63
administrar o sistema, este tem a responsabilidade de administrar a orquestrao e
os mdulos criados na aplicao do sistema.
Na prxima seo ser apresentado um resumo do captulo com
consideraes finais sobre o mesmo e uma pequena apresentao do prximo
captulo desta dissertao.
4.5 - Consideraes Finais deste captulo

Neste captulo, buscou-se apresentar os procedimentos necessrios de
orquestrao
entre
os
componentes
que
deram
origem
ferramenta
pyMDAGenerator, sendo apresentado primeiro, atravs do modelo CIM, depois, pela

criao do PIM e logo em seguida pelo PSM, por ltimo, foi efetivada a gerao do
cdigo. Durante estas aes importante resaltar o valor das aes e os passos
necessrios para realizar as transformaes entre os modelos, nesta plataforma
importante integrar as aes e os scripts, dando nfase ao modelo do framework.
Esta pesquisa se prope a realizar uma orquestrao entre os componentes
na plataforma para ser utilizado com a linguagem Python e o framework Django, na
construo rpida de sistemas de informao para web.
No prximo captulo sero apresentados o estudo de casos deste trabalho,
como tambm informaes detalhadas sobre o Sistema "Retriever" e "Asset
Inventory", que vm a ser um dos temas centrais desta pesquisa.
64
5 EXEMPLO: SISTEMA "RETRIEVER" E O SISTEMA DE GESTO

PATRIMONIAL "ASSET INVENTORY"
O objetivo deste captulo apresentar alguns conceitos relacionados ao
Sistema de Gesto de Inventrios Hospitalares "Retriever", com suas caractersticas
internas de arquitetura e modelos de componentes, requisitos funcionais e no
funcionais, interfaces das aplicao e demais funes dos sistema. Alm disso,
sero abordadas a categorizao dos objetivos trabalho e o estudo de caso deste
sistema. Lembrando que o referido sistema foi desenvolvido no Mestrado
Profissional em Engenharia de Software do CESAR.EDU turma: 2012.1 para o
cliente BeagleTech atravs da Fbrica de Software 7Gofactory
e no final das
atividades das disciplinas desenvolvemos tambm um novo software da prpria

Gofactory para gesto de inventrios patrimoniais chamado "Asset Inventory", o
mesmo ser apresentado tambm neste captulo.
5.1 Definio do problema
Um dos grandes desafios dos gestores de hospitais e clnicas mdicas
manter o controle sobre seus ativos hospitalares, tais como: equipamentos, material
hospitalar, medicamentos, banco de sangue, roupas de cama, vesturios e utenslio.
Para solucionar o problema, tornou-se necessrio criar um sistema de informao
que permita rastrear e identificar a localizao em tempo real dos itens do hospital.
Devendo tambm manter um registro das movimentaes no ambiente hospitalar.
GoFactory - Fbrica de Software do Mestrado Profissional Cesar.edu.br "http://www.gofactory.com.br"
65
5.1.1 O impacto
A ausncia de controle desses ativos tem influencia direta nos custos das
organizaes mdicas, no desperdcio de material e no mau uso do patrimnio
hospitalar. Como consequncia, essas aes tm contribudo para aumentar os
prejuzos como roubo e furto de itens existentes no hospital, alavancando assim,
enorme prejuzo para a organizao.
O processo de gerenciamento de equipamentos ativos dentro de hospitais
algo bastante complexo e envolve risco, inclusive de vida ou contgio, no que se
refere a infeces por exemplo.
5.1.2 A soluo
Foi criado um sistema de informao destinado a auxiliar o processo de
gerenciamento hospitalar cujo objetivo informar a localizao em tempo real de
equipamentos e medicamentos obedecendo a alguns preceitos no que se refere a
um sistema de informao. Alm disso, os hospitais podem utilizar e dispor, de
forma mais eficiente, os equipamentos que possuem, reduzindo as despesas
referentes reposio e ao transporte dos equipamentos. A combinao dessas
atribuies elimina problemas frequentemente observados dentro de hospitais, tendo
como consequncias, melhores servios oferecidos aos pacientes, agregando a
esses servios, nveis de custos aceitveis e competitivos para o negcio ao qual se
prope.
5.2 Stakeholders, Requisitos Funcionais e No funcionais
Nesta parte do trabalho sero apresentados algumas informaes sobre os
Stakeholders do projeto e a lista de requisitos funcionais e no funcionais do projeto,
estas aes so importante para definir tanto as caractersticas funcionais
relacionadas a execuo das atividades no projeto "Retriever" como tambm as
caractersticas de usabilidade, performance, segurana, etc. Identificadas atravs
dos requisitos no funcionais deste projeto.
66
5.2.1 Stakeholders
Na engenharia de requisitos, os stakeholders so definidos como pessoas
ou organizaes que sero afetadas pelo sistema e que direta ou indiretamente
tem influncia sobre os requisitos.
Basicamente, os stakeholders do projeto "Retriever" podem ser divididos
em cinco grupos descritos a seguir:
Enfermeiro: Colaboradores do setor de Enfermaria.
Engenheiro clnico: Colaboradores que esto responsveis

pelo Item e blocos do Prdio.
Segurana: Equipe de Vigilncia.
Gestor: Gerente Administrativo do Hospital.
Administrador: Super usurio do Sistema.
5.2.2. Atores
1. Administrador
2. Enfermagem
3. Gestor
4. Engenheiro Clnico
5. Segurana
6. Sensor
67
5.2.3 Requisitos (funcionais e no funcionais)
Os requisitos definem os servios que o sistema dever oferecer, o conjunto
deles determina a operao do sistema. So divididos em Requisitos Funcionais e
No Funcionais.
Os requisitos funcionais referem-se aos pressupostos que esto relacionados
com a forma com que o sistema deve operar, onde se especificam as entradas e
sadas do sistema e o relacionamento comportamental entre elas, assim como a
interao com o usurio.
Desta forma, os requisitos funcionais identificados so:
REF.
ATORES
REQUISITO
RF01
Todos
Autenticar usurios
RF02
Todos
Listar itens de material por setor
RF03
Ges
Gerenciar relatrios de equipamentos por ritmos in ambiente
RF04
Ges
Gerenciar usurios
RF05
Ges
Gerar relatrio por ambiente
RF06
Adm
Gerenciar hospitais
RF07
Adm
Gerenciar gestor do hospital
RF08
Adm
Registrar alertas emitidos
RF09
Adm
Gerar log de eventos inesperados
RF10
Adm
Auditar sistema
RF11
Eng
Gerenciar prdios/blocos
RF12
Eng
Listar itens na tela de incio
RF13
Eng
Gerenciar equipamento
68
REF.
ATORES
REQUISITO
RF14
Eng
Gerenciar reas
RF15
Eng
Gerenciar andares
RF16
Eng
Gerenciar movimentaes
RF17
Eng
Gerenciar identificadores
RF18
Eng
Gerenciar sensores
RF19
Sensor / Seg
Alertar movimentao indevida
RF20
Sensor / Seg
Receber alerta de segurana
Tabela [1]: Requisitos Funcionais

Fonte: Prprio Autor
5.2.4 Definio dos Requisitos No Funcionais

REFERNCIA
REQUISITO NO FUNCIONAL
RNF01
O sistema deve permitir mltiplos usurios.
RNF02
O sistema deve ter uma disponibilidade de 99,50 % dos casos.
RNF03
As informaes de login/senha dos usurios do sistema devem ser

protegidas atravs de conexes seguras (HTTPS).
RNF04
Deve ser utilizado o GIT como repositrio para o cdigo-fonte.
RNF05
O Sistema deve garantir o acesso simultneo de mais de 1000

usurios, durante 01 minuto.
69
REFERNCIA
RNF06
REQUISITO NO FUNCIONAL
Os testes funcionais, carga e unitrios devem ser feitos de forma
semi ou automtica, baseada nas ferramentas Selenium, Jmeter e
Junit.
RNF07
Para as consultas e relatrios o tempo de resposta no pode ser

superior a 5 segundos.
RNF08
O sistema deve ser executado nos navegadores Internet Explorer

9, Mozilla 13.0 e Chrome 20.0).
RNF09
As senhas dos usurios cadastrados no sistema devem ser

criptografadas baseadas no Hash MD5.
RNF10
O sistema deve est adaptado para o padro internacional (Ingls,

Portugus e Espanhol).
Tabela [2]: Requisitos No-Funcionais

Fonte: Prprio Autor
5.2.5. Escopo negativo

O escopo Negativo do Projeto "Retriever" est relacionado a no evoluo do
mdulo de tratamento de eventos (Middleware). O trabalho de pesquisa e
desenvolvimento do Middleware no ser implementado agora, em virtude do
escopo prioritrio que a construo do mdulo WEB. Isto pode ser constatado
atravs do plano de clculo de esforo e pontos e quebra sistemtica, contidos na
documentao do sistema no apndice desta Dissertao.
70
5.3 Modelos de Artefatos e documentos do projeto

Nesta seo sero apresentados alguns artefatos produzidos neste projeto
incluindo diagramas estruturais e comportamentais da UML e diagramas de
modelagem, entidade, relacionamento do banco de dados e modelo lgico, estas
caractersticas so importantes para descrever os aspectos arquiteturais do projeto e
suas principais caractersticas.
5.3.1 - Diagrama de casos de uso
Figura [30] - Diagrama de casos de uso "Retriever"

Fonte: Prprio Autor
O diagrama de casos de uso, conforme Figura 30 do projeto "Retriever"

responsvel por descrever os aspectos funcionais do sistema e suas interaes
71
entre os atores, suas associaes, generalizaes, e caractersticas de dependncia
do tipo: extends e includes. importante salientar o papel dos atores Gestor,
Engenharia Clnica e Administrador, pois os mesmos so os mais importantes e
interagem com as principais funcionalidades da aplicao. Nele possvel identificar
os principais requisitos funcionais identificado neste projeto como: Gerenciar
Identificadores, Gerenciar Movimentaes, Receber Alerta de Segurana, entre
outros.
5.3.2 - Diagrama de Classe
O Diagrama estrutural da UML - o diagrama de classes possibilita a
verificao da estrutura dos dados existentes no domnio do problema, tornando
possvel
identificar
suas
principais
classes,
associaes,
multiplicidades,
agregaes, composies e estruturas de generalizao, herana ou composio.

Estes dados so apresentados na Figura 31.
Figura [31] - Diagrama de classes - "Retriever"

Fonte: Prprio Autor.
72
importante ressaltar que o domnio do problema o sistema de gesto de
inventrios hospitalares, o domnio da soluo visa gerenciar as informaes
vivenciadas em hospitais e segment-las por blocos, andares, rea, equipamentos,
tipos de equipamentos, rea, s3PlantaBaixa que consiste na forma de selecionar
uma figura com a representao do registro.
De posse dessa informao fica mais fcil estabelecer a soluo utilizando os
conceitos de anlise e projeto de sistemas, pois com o reuso de software possvel
melhorar e adaptar as solues aplicadas ao domnio de gesto ao sistema de
gesto de inventrios, este um dos principais diagramas deste projeto pois tem
como caractersticas bsicas a representao da estrutura das classes seus
principais atributos e alguns mtodos referenciados no projeto em anlise.
5.3.3 - Diagrama de Componentes
Este diagrama tem como objetivo descrever as caractersticas internas de
componentes de arquitetura do projeto, fazer a arquitetura baseada no modelo MVC
(Model View Controller) e servir de modelo para os engenheiros de software,
arquitetos e desenvolvedores do projeto. Atravs deste modelo possvel realizar as
operaes interligadas entre as classes reusando componentes e aplicando alguns
padres de projeto conhecidos tais como Singleton, Facade, DAO etc.
O diagrama de componentes especifica de forma clara as camadas de
negcio, modelo e interface da aplicao, o play framework representa
De acordo com o diagrama apresentado na Figura 32 a camada Modelo
possui uma interface chamada play.Model que implementas as classes do modelo
conceitual do projeto, neste caso as classes Usurios e Movimentacao implementam
esta interface.
J na camada Negcio so apresentados componentes de negcio e
interfaces da aplicao, a exemplo da classe AutenticadorBD, Movimentaco e
ValidadorMovimentacaoImpl, estas so classes de regras de negcio da aplicao,
j a camada de interface caracterizada pelas interfaces grficas da aplicao e
73
servem de modelo de comunicao tambm com o Middleware de Integrao a
exemplo das classes FrmUsuario, FrmMovimentacao e MiddlewareMovimentacao.
Figura [32] - Diagrama de componentes - Viso Interna (MVC) "Retriever"

Fonte: Prprio Autor
O prximo diagrama de Instalao, apresentado na Figura 33, tem como

caracterstica fundamental a apresentao da viso externa dos componentes de
software, esta viso importante para descrever as aes relacionadas
principalmente a interoperabilidade e a possibilidade de integrao com outros
sistemas externos, haja vista que atualmente j desenvolvemos na nossa Fbrica de
Software o nosso prprio Middleware de integrao no dependendo mais das
aes dos outros componentes de Middleware existentes.
74
Figura [33] - Diagrama de Instalao - Viso Externa "Retriever"

Fonte: Prprio Autor
5.4 Interfaces da aplicao e requisitos do sistema "Retriever"

Nesta parte do trabalho apresentado algumas interfaces da aplicao
"Retriever", desta forma possvel identificar as caractersticas visuais relacionadas
ao projeto. Pretendemos assim apresentar algumas interfaces do projeto em
questo.
5.4.1 Tela de Autenticao de Usurios do Sistema "Retriever"
A interface referente a tela de autenticao dos usurios no sistema pode ser
feita atravs do seu email e uma senha previamente cadastrada no sistema, estes
dados so validados pela aplicao e servem de base para dar acesso ao ambiente
do sistema "Retriever". A figura 34 representa a tela de autenticao.
75
Figura [34] - "Retriever" - Tela de Autenticao de usurios no sistema

Fonte: Prprio Autor
O plugin de interface desta aplicao foi modificado de acordo com o cliente

para garantir uma maior usabilidade.
5.4.2 Tela principal do Sistema Selecione o Hospital
A tela principal do sistema representada atravs do Nome "Retriever"
Sistema de Gerenciamento de Equipamentos Hospitalares, alm disso existem os
cones de Home, Ativos, Unidades, Equipamentos e Usurios no menu principal do
sistema, na parte superior direita da aplicao possvel alterar a unidade e existem
informaes sobre o usurio conectado e a opo de logout.
Na Figura 35 possvel identificar o designer da aplicao, seus elementos
de composio, entre eles, o topo com o nome "Retriever", a barra de menus com os
principais menus de opo, o rodap com informaes do sistema e do fornecedor,
entre outras.
76
Figura [35] - (Retriever) - Seleo de Hospital para Administrar

Fonte: Prprio Autor
5.4.3 Tela de Ativos Hospitalares sobre o Sistema "Retriever"

A tela do cadastro de ativos hospitalares faz parte do menu Ativos e
corresponde a uma das telas de gesto do sistema, atravs desta tela possvel
incluir, alterar, excluir e listar todos os ativos hospitalares cadastrados no sistema.
Esta informao importante e serve de base para alimentar aos outros dados
relacionados a movimentao dos ativos, equipamentos, sensores e demais itens do
hospital, tais detalhes e implementaes esto sendo visualizados atravs da Figura
36.
77
Figura [36] - "Retriever" - Tela de cadastro de Ativos Hospitalares

Fonte: Prprio Autor
5.4.4 Tela de Unidades do Sistema "Retriever"

A Figura 37 exibe a interface do cadastro de Unidades, que faz parte do menu
Unidades e corresponde a uma das telas de gesto do sistema, atravs desta tela
possvel incluir, alterar, excluir e listar todas as unidades ou seja hospitais
relacionados ao sistema, para isto preciso informar o Nome do hospital, Telefone,
Endereo, Cidade e Estado e por ltimo pressionar o boto salvar para gravar as
informaes.
Como possvel ver na Figura 37 o cadastro de Unidades, que faz parte do
menu Unidades e corresponde a uma das telas de gesto do sistema, atravs desta
tela possvel incluir, alterar, excluir e listar todas as unidades dos hospitais
relacionados ao sistema, para isto preciso informar o Nome do hospital, Telefone,
Endereo, Cidade e Estado e por ltimo pressionar o boto salvar para gravar as
informaes.
78
Figura [37] - "Retriever" - Tela de Cadastro de Unidades

Fonte: Prprio Autor
5.4.4 Tela de Usurios do sistema "Retriever".

Na Figura 38, a tela do Cadastro de Usurios faz parte do menu Usurios e
corresponde a uma das telas de gesto do sistema, atravs desta tela possvel
incluir, alterar, excluir e listar todos os usurios cadastrados nos hospitais, servindo
tambm para definir as caractersticas de Perfil tais como: Administrador do Hospital,
Engenharia Clnica, Enfermeiro, etc.
79
Figura [38] - "Retriever" - Tela de Cadastro de Usurios

Fonte: Prprio Autor
5.4.5 - Consideraes finais sobre esta seo

Nesta parte do captulo foi apresentada algumas telas do sistema de gesto
de Inventrios Hospitalares "Retreiver", este projeto serviu de base para realizar o
estudo comparativo entre o desenvolvimento tradicional e o desenvolvimento
baseado em componentes com MDA, na prxima seo sero apresentadas as
interfaces grficas do projeto "Asset Inventory" um sistema de gesto de inventrios
patrimoniais desenvolvidos utilizando a ferramenta PyMDAGenerator.
5.5 - O Sistema de Inventrios Patrimoniais "Asset Inventory"
Nesta parte do trabalho possvel apresentar um prottipo funcional da
aplicao feita na plataforma Python + Django, este sistema possui algumas
caractersticas bem parecidas com a aplicao anterior, alterando apenas o seu
domnio de negcio que agora Inventrios Patrimoniais. Em vista disso,
importante salientar que este projeto tem como fonte descrever uma ferramenta de
desenvolvimento baseada em componentes utilizando o MDA (Model Driven
Architecture).
80
5.5.1 Tela Principal do Sistema - "Asset Inventory"
A tela principal do sistema "Asset Inventory" composta pelo menu principal
da rea administrativa do sistema, nele existem os itens Andar, rea, Bloco,
Entidade, Equipamento, Evento, identificador, como tambm as reas de
movimentao, sensores e tipos de equipamento. Alm destas informaes
possvel visualizar tambm as aes recentes realizadas no projeto na parte lateral
direita, na guia Auth possvel gerenciar informaes sobre novos usurios do
sistema e grupos de usurios relacionados, este componente faz parte do Django e
j vem implementado de forma automtica na aplicao, tais dados so visualizados
na Figura 39.
Figura [39] - Sistema (Asset Inventory) - Tela com o menu principal do sistema
Fonte: Prprio Autor
5.5.2 Tela de Gerenciamento de Andar - "Asset Inventory"

A tela de Gerenciamento de Andar composta por alguns elementos visuais
como barra de ttulos com o nome da aplicao "Asset Inventory" e do lado direito o
nome do usurio logado no sistema, com as opes de alterar senha e Encerrar
sesso, tais informaes so melhor visualizadas atravs da Figura 40.
81
importante relatar as caractersticas bsicas dos atributos da entidade
Andar como: Cdigo, Descrio do Andar, Nome e URL da imagem, alm disto,
todas as operaes de manipulao do andar esto contempladas tais como: incluir,
alterar, excluir e listagem geral dos andares.
Figura [40] - Sistema (Asset Inventory) Tela de Cadastro de Andar

Fonte: Prprio Autor
5.5.3 Tela de Gerenciamento de rea - "Asset Inventory"

Na Figura 41 exibida a tela de Gerenciamento de rea, que composta por
alguns elementos visuais como barra de ttulos com o nome da aplicao "Asset
Inventory" e do lado direito o nome do usurio, alm disso, existem as
caractersticas tais como: Cdigo, background, descrio, polgono, restrita e cdigo
do andar. Alm do cadastro destas informaes so realizadas tambm
operacionais como listagem geral das reas, alterao da rea e excluso da
mesma.
82
Figura [41] - Sistema (Asset Inventory) - Tela de cadastro de rea

Fonte: Prprio Autor
5.5.4 Tela de Gerenciamento de Equipamento - "Asset Inventory"

A tela de Gerenciamento de Equipamentos composta por alguns elementos
visuais como barra de ttulos com o nome da aplicao "Asset Inventory" e do lado
direito o nome do usurio, alm disso, possvel verificar algumas informaes
referentes aos equipamentos tais como: Cdigo do equipamento, descrio do
equipamento, modelo do mesmo, cdigo do patrimnio, nmero identificador e tipo
de equipamento. Por se tratar de equipamentos patrimoniais importante salientar
que possvel realizar os ajustes necessrios para adaptar posteriormente estes
informaes a bens mveis e imveis relacionados a organizao, conforme Figura
42.
83
Figura [42] - Sistema (Asset Inventory) - Tela de Cadastro de Equipamentos

Fonte: Prprio Autor
5.5.5 Tela de Gerenciamento de Evento - "Asset Inventory"

A tela de Gerenciamento de Eventos composta por alguns elementos
visuais como barra de ttulos com o nome da aplicao Asset Inventory e do lado
direito o nome do usurio, alm disso, possvel verificar algumas informaes
referentes aos eventos relacionados a movimentao dos equipamentos, atravs
desta tela possvel gerenciar informaes tais como: cdigo, data e informaes
sobre o identificar e sensor instalado no ambiente organizacional, a cada
movimentao dos equipamentos estas informaes so repassadas para o
software e o registro de movimentao fica armazenado no sistema, tais informao
encontra-se na Figura 43.
84
Figura [43] - Sistema (Asset Inventory) - Tela de Cadastro de Eventos

Fonte: Prprio Autor
5.6 Consideraes Finais desde captulo

Neste captulo foi possvel conhecer melhor o estudo do caso desta pesquisa,
e a partir dela foi produzido o prottipo em Python + Django "Asset Inventory", bem
como, a necessidade do desenvolvimento deste projeto atravs da Engenharia de
Reuso de Software. O Engenheiro/Arquiteto de Software precisa destas informaes
para melhor se adequar ao propsito desejado.
Com esse intuito, esta pesquisa pretende, conforme j enfatizado, elaborar
uma ferramenta baseada em MDA (Model Driven Architecture), atravs de um PSM
modelos especfico de plataforma que permita ao Engenheiro / Arquiteto e
Desenvolvedor de Software desenvolver com maior velocidade e facilidade as
rotinas contnuas do processo de desenvolvimento de software. Essa ferramenta
dever ainda ser incorporada a todo s os principais conceitos e princpios da
avaliao inclusos nesta pesquisa.
No prximo captulo sero discutidos e apresentados os procedimentos
necessrios para validao desta pesquisa atravs de um estudo comparativo entre
o desenvolvimento tradicional feito atravs do "Retriever" e o desenvolvimento
baseado em modelos com a ferramenta PyMDAGenerator"Asset Inventory".
85
6. ESTUDO COMPARATIVO ENTRE A FERRAMENTA ANDROMDA

(JAVA) X PYMDAGENERATOR (PYTHON)
Este captulo tem como objetivo descrever algumas informaes estatsticas
relacionadas a um estudo comparativo entre o desenvolvimento do projeto
"Retriever" utilizando os dados relativos ao desenvolvimento WEB plataforma Java
JEE (Framework AndroMDA) e demais componentes com o desenvolvimento
dirigido a modelos com MDA e a ferramenta PyMDAGenerator aplicado ao projeto
"Asset Inventory" com o a Linguagem Python e o Framework Django.
Para apresentar alguns dados estatsticos deste trabalho construmos tabelas
e grficos visando obter informaes quantitativas e qualitativas sobre o estudo de
caso em questo, sendo representados em ambas as plataformas conforme a lista
abaixo:
- Descrio dos dados relacionados ao nmero de linhas de cdigo;
- Apresentao dos dados relacionados ao nmero de classes criadas;
- Apresentao dos dados relacionados ao nmero total de arquivos gerados;
- Quantidade de Artefatos de anlise e especificao do projeto gerados;
- Nmero de dias trabalhados;
- Quantidade de horas de trabalho realizadas no projeto;
- Nmero de Sprints produzidas durante a execuo do desenvolvimento do projeto;
- Tabelas com informaes compartilhadas de artefatos, cdigo e demais recursos;
- Criao dos grficos associados a pesquisa com as informaes em destaque;
- Pargrafo final com as consideraes finais deste captulo.
86
6.1 - O projeto "Retriever" na arquitetura Java JEE com o ANDROMDA
Nesta parte do trabalho sero apresentadas informaes sobre o andamento
das atividades relacionadas ao projeto original da Fbrica de Software Gofactory,
entre elas possvel identificar informaes tais como exibidas na tabela 5:
QUADRO DO PROJETO COM ANDROMDA (JAVA) X PYMDAGENERATOR (PYTHON)
DESCRIO
JAVA
PYTHON
DIFERENA
QUANTIDADE / NMERO DE CLASSES CRIADAS
54
38
16,00
QUANTIDADE / NMERO TOTAL DE ARQUIVOS GERADOS
90
82
QUANTIDADE DE ARTEFATOS PRODUZIDOS (UML)
14
16
2,00
QUANTIDADE DE DIAS TRABALHADOS
13
15
2,00
QUANTIDADE DE HORAS DE TRABALHO REALIZADA
56
60
4,00
QUANTIDADE / NMERO DE SPRINTS PRODUZIDAS
SOMATRIO
229,00
213,00
8,00
16,00
Tabela [3]: Quadro demonstrativo entre o projeto "Retriever" e o "Asset Inventory"

Fonte: Prprio Autor
Conforme apresentado na tabela 5 possvel identificar que na coluna JAVA

(JEE) o nmero de linhas de cdigo aplicadas ao projeto, sobre o ponto de vista que
as duas linguagens so orientadas a objeto e que o paradigma no garante um
nmero menor de linhas de cdigo e consequentemente de classes j que a
especificao deve garantir as melhores prticas aplicadas aos projetos, inclundo o
uso de padres de projeto do tipo singleton, abstract factory e factory method. Neste
caso o nmero de classes criadas chegando exatamente a 54 classes, isto ocorre
por conta do Framework AndroMDA e de sua estrutura interna baseado no modelo
MVC (Model View Controller), este modelo fora a criao de no mnimo 8 classes
para representar o Bean, DAO, Business Controller. Lembrando que para realizar tal
atividade contamos com a participao de 02 Programadores divididos em 04 horas
de trabalho por dia para realizar os procedimentos e o desenvolvimento da soluo
como um todo.
Para o nmero de arquivos gerados o nmero foi de 90 includos os arquivos
de interface da aplicao tais como JSF, XHTML, CSS, JS, XML entre outros
87
necessrios para gerao da aplicao, na construo da interface da aplicao foi
necessrio a construo de Template.
Na fase de anlise e especificao do sistema foram gerados diversos
artefatos de anlise incluindo documento de requisitos, documento de viso,
diagramas de casos de uso, diagramas de classe, diagrama de componentes entre
outros, totalizando 14 artefatos gerados para o projeto em Java atravs da
linguagem de modelagem UML seguindo a metodologia RProcess e o ciclo de vida
interativo e incremental baseado em casos de uso e aspectos geis baseado no
SCRUM.
Para caracterizar os dias trabalhados dividimos o trabalho de segunda a
sexta-feira com 08 horas de trabalho dirio nossa equipe foi dividida em 06 pessoas,
sendo 01 gerente de projetos, 02 Programadores, 01 Engenheiro / Arquiteto de
Software, 01 Designer, 01 DBA/Engenheiro de Testes. O registro das atividades
realizadas foi feito atravs do RedMine. Durante este perodo realizamos diversas
reunies em um conjunto de 02 interaes / Sprints totalizando 15 dias de trabalho
para cada Sprint no total.
Quanto ao nmero de horas trabalhadas foi seguindo o nmero de dias 13
com 8 horas de atividade por dia, neste momento conseguimos realizar as
atividades com 56 horas de trabalho no final do projeto, dividindo estas informaes
em meses tivemos menos de 01 ms de trabalho para desenvolver o nmero de 17
casos de uso apresentados nesta dissertao de Mestrado isto nos garantiu a
completa execuo das funcionalidades da aplicao solicitadas pelo nosso cliente:
BeagleTech.
O grfico 1 ilustra de forma quantidade de Sprints, horas, dias, artefatos,
classes e demais aes exemplificados neste trabalho, foi observado nesta pesquisa
em questo que todos os nmeros apresentados aqui descrevem uma viso
imparcial que foi aplicada ao desenvolvimento com a ferramenta ANDROMDA
baseado em anlise, projeto e implementao de cdigo pilares fortes aplicados da
88
Engenharia de Software, que consiste em uso de tcnicas, ferramentas e modelos,
no definindo quais so e sim que existem e podem ser aplicados.
Grfico [01]: Grfico com as informaes estatsticas do projeto desenvolvido em Java JEE ANDROMDA
Fonte: Prprio Autor
6.2 - Representao dos dados aplicados ao projeto "Asset Inventory"

desenvolvimento na linguagem Python com Django
Nesta parte do trabalho sero apresentadas informaes sobre a anlise,
projeto e especificao do projeto "Asset Inventory" da Fbrica de Software
Gofactory, entre elas possvel identificar informaes tais como exibidas na tabela
6:

JAVA
PYTHON
DIFERENA
DESCRIO
54
38
16,00
90
82
14
16
2,00
13
15
2,00
56
60
4,00
2
229,00
SOMATRIO
2
213,00
Tabela [4]: Quadro demonstrativo dando nfase ao projeto em Python (Django)

Fonte: Prprio Autor
8,00
16,00
89
Este projeto foi idealizado atravs da disciplina de Reuso de Software do
Mestrado Profissional do Cesar.edu.br, nos mdulos de Reuso Intermedirio e
Profissional, como nossa fbrica de software GoFactory tinha que desenvolver um
projeto que envolvesse a parte de transformaes entre modelos atravs com MDD
(Model Driven Development) ou MDA (Model Driven Architecture), foi criada a
ferramenta PYMDAGenerator para proporcionar a transformao, a linguagem
Python e o framework Django foram escolhidos por possuir uma fcil integrao
entre o mecanismo de gerao de cdigo baseados na classe abstrata
models.Model e no mecanismo de gerao ORM SQLdb.
Para este projeto foi aproveitada a estrutura de criao dos objetos do Django
em conjunto com a linguagem Python facilitando assim a aplicao do MVC e na
diminuio do nmero de linhas de cdigo do projeto, no Django o arquivo
Models.py concentra em um s lugar todas as instrues do modelo de arquitetura
MODEL evitando assim a criao de novas classes e sub-divises do modelo.
nmero de classes criadas no projeto foi 38 classes importante salientar que o
Framework ajuda na estruturao deste projeto diminuindo de forma considervel as
classes reusando inclusive o seu Template.
Neste projeto o nmero de membros foi reduzido para 02 (01 Engenheiro /
Arquiteto) e (01 Desenvolvedor Python + Django) como papel de modelagem e
diagramao o engenheiro/arquiteto construiu todos os artefatos de anlise e
especificao, juntamente com os diagramas da UML acrescentando apenas 02
novos diagramas o diagrama de instalao e o Diagrama de estrutura composta
aplicados ao projeto para classificar os componentes e a ligao entre os modelos
(PIM) para (PSM) e depois para cdigo o nmero de artefatos de anlise em UML foi
16 e a quantidade de arquivos gerados no final de tudo foram 82 arquivos
envolvendo todas as etapas de elaborao, construo, implantao e deploy da
aplicao.
90
Grfico [2]: Grfico com os dados estatsticos do projeto em Python + Django

Fonte: Prprio Autor
Por conta desta ao o nmero de dias trabalhados neste projeto foi reduzido
para 15 no projeto em Python + Django, trabalhando 8 horas por dia durante 03
semanas de trabalho, o desenvolvimento gil baseado na construo da ferramenta
e na gerao automtica do projeto baseado na modelagem UML depois na
exportao do arquivos XMI, na etapa de transformao utilizando a biblioteca
UML2DJ para captura das estruturas do domnio do problema e exportao para os
arquivos admin.py e models.py do projeto, a programao dos Scripts em Shell
ajudam no processo de automao das transformaes entre os modelos,
garantindo assim apenas 60 horas de trabalho no projeto e o desenvolvimento em
apenas 02 Sprints de 8 dias cada. Tais informaes podem ser conferidas no
Grfico 2.
91
6.3 - Grfico comparativo entre os dois processos
Nesta parte do trabalho apresentado um grfico comparativo com os
valores identificados na tabela anterior:
Grfico [3]: Grfico com as informaes unificadas entre o desenvolvimento em Java JEE AndroMDA
x Python Django
Fonte: Prprio Autor
Nesta parte da pesquisa foi possvel identificar a diferena existente entre os

modelos apresentados neste grfico a primeira srie barra na horizontal representa
o desenvolvimento atravs da linguagem Python + Django e o paradigma de reuso
de software baseado em MDA, j a representao da 2 barra logo em seguida
representa o desenvolvimento utilizando a ferramenta AndroMDA baseado em Java.
No quadro da tabela 03 so aplicadas informaes de diferena entre os
percentuais
do
projeto
mencionados
entendimento e suas diferenas.
nesta
pesquisa
facilitando
assim o
92
DESCRIO
JAVA
PYTHON
DIFERENA
1002
945
57,00
54
38
16,00
90
82
8,00
14
16
2,00
13
15
2,00
56
60
4,00
QUANTIDADE / NMERO DE LINHAS DE CDIGO
SOMATRIO
1231,00
1158,00
16,00
Tabela [5]: Tabela com as informaes do projeto nfase ao Nmero de Linhas de cdigo
Fonte: Prprio autor
Na coluna percentual do Python observem que o valor representado por

23,58% corresponde ao nmero de linhas de cdigo aplicado ao projeto se
eliminarmos este critrio tanto para o projeto em Python como tambm o projeto
feito em Java os valores ficam mais prximos entre os critrios de avaliao e
visualizao das estatsticas.
Grfico [4]: Grfico com as informaes estatsticas dos dois projetos, Azul para Python e Laranja
para Java
Fonte: Prprio Autor
93
O grfico de barras descreve de forma prtica diferena em formato de
porcentagem entre os itens avaliados nesta pesquisa, incluindo tambm a diferena
entre os dois projetos, a linha de Java corresponde aos indicadores aplicados ao
projeto Java JEE, j a linha de Python corresponde aos indicadores aplicados ao
Grfico com os Percentuais de Diferena entre o Java e

Python
projeto Python Django.
QUANTIDADE / NMERO DE SPRINTS

PRODUZIDAS
0,87%
0,94%
QUANTIDADE DE HORAS DE TRABALHO

REALIZADA
24,45%
28,17%
5,68%
7,04%
Java
QUANTIDADE DE ARTEFATOS
PRODUZIDOS (UML)
Python
6,11%
7,51%
QUANTIDADE / NMERO TOTAL DE

ARQUIVOS GERADOS
39,30%
38,50%
QUANTIDADE / NMERO DE CLASSES

CRIADAS
23,58%
17,84%
0,00% 10,00% 20,00% 30,00% 40,00% 50,00%

Grfico [5]: Grfico variao dos percentuais entre os projetos (Java JEE x Python Django)
Fonte: Prprio Autor
Com base neste grfico ficou claro que o desenvolvimento baseado em

componentes
com
Python
Django
mantm
uma
singularidade
consequentemente baixa oscilao entre os critrios avaliados nesta pesquisa j o

desenvolvimento com o Framework AndroMDA com Java JEE variam um pouco
principalmente nos critrio de Nmero de Arquivos Gerados de 38,50% para 39,30%
a diferena foi 0,80% e Quantidade de Horas de Trabalho realizada de 28,17% para
24,45% sua diferena foi de 3,71%.
94
Outro ponto importante desta pesquisa o nmero de dias trabalhados neste
projeto, levando em considerao que o primeiro projeto durou 13 dias com a
ferramenta AndroMDA foi mais rpido e o ltimo 15 dias de trabalho com a
ferramenta PyMDAGenerator j possvel ver que com o reuso do software e o uso
da engenharia de software baseada em componentes podemos reaproveitar
inmeros artefatos produzidos e acelerar de forma drstica a gerao dos cdigo em
plataformas totalmente distintas.
6.4 Consideraes Finais sobre este captulo
Este captulo representou em nmeros diversas aes realizadas em ambos
os projetos, retratando dados estatsticos sobre o projeto feito em Java e o mesmo
projeto desenvolvimento em Python atravs do reuso de software e da Arquitetura
Dirigida a Modelos, um dos frutos do projeto foi a construo da ferramenta
PYMDAGenerator responsvel pela gerao automtica de cdigo baseado em
Python junto com o Framework Django, maiores informaes sobre o projeto e a
prpria
ferramenta
podem
ser
https://sites.google.com/site/pymdagenerator2014/
Figura [44]: Pgina do projeto PyMDAGenerator

Fonte: Prprio Autor
vistos
no
site:
95
Como foi possvel identificar, os ganhos representados em nmeros do
desenvolvimento baseado em componentes com a abordagem MDA bem
significativo, evidentemente comparado a uma outra ferramenta que utiliza a mesma
filosofia, mais importante resaltar tambm a questo da manutenabilidade,
alteraes nas vises sobre consultas e relatrios personalizados que de certa
forma no foram tratados neste trabalho.
Na Figura 44 apresentado o site onde possvel baixa uma verso demo da
ferramenta, junto com os componentes aplicados ao projeto, incluindo um passo a
passo para gerao de uma aplicao exemplo, outro ponto consiste na parte de
servios que podem ser feito baseados na engenharia de reuso de software com
MDA e MDD, como tambm o telefone, email de contato do responsvel pela
criao da ferramenta, documentos do projeto e tutoriais.
No prximo captulo ser apresentada as consideraes finais sobre este
trabalho incluindo os pontos positivos e negativos, como tambm os trabalhos
futuros desta dissertao de mestrado.
96
7. CONSIDERAES FINAIS
7.1 - Eplogo
O padro de engenharia de software baseado em modelos da MDA (Model
Driven Architecture) tem como proposta a construo sistemtica baseada em
exemplos estruturais e comportamentais da UML, isto acontece de forma natural
durante a transferncia dos aspectos tcnicos de desenvolvimento para as primeiras
fases de planejamento e projeo. Entre outros benefcios esto um alto nvel de
reuso, reduo do Time-to-market, entre outros.
A experincia entre os arquitetos, engenheiros e analistas de sistemas um
dos problemas identificados no uso deste paradigma sob o ponto de vista de
explorar os aspectos comportamentais e estruturais da UML visando detalhar o
mximo possvel s caractersticas de negcio de um domnio especificado,
lembrando que, infelizmente, o foco se concentra mais na especificao do cdigo e
muito pouco nos requisitos de modelagem conceituais e lgicos da arquitetura de
software.
Dessa forma, uma das primeiras preocupaes consiste na identificao e na
representao destas informaes em considerao aos aspectos de construo do
CIM - modelo computacional de requisitos e regras de negcio, depois na
transformao em PIM - Modelo Independente de Plataforma atravs dos artefatos
da UML e da linguagem de restrio ao modelo OCL, esta caracterstica ser
transformada em PSM - Modelo Especfico de Plataforma - caracterizado pelos
aspectos tcnicos de implementao da plataforma em questo, por ltimo, a
transformao de PSM para cdigo fonte, depois para o cdigo objeto (executvel).
A modelagem dos aspectos estruturais e comportamentais da UML uma das
primeiras atividades de desenvolvimento e implementao do sistema de informao
na busca para identificar pontos em comum que so realizados pelos citados
profissionais anteriormente questionados. O modelo de caractersticas, gerado a
partir dessas atividades utilizado como ponto de partida para o recorte necessrio
instanciao de novos sistemas de informao na WEB, Alm disso, permite
97
uniformizar
entendimento
entre
todos
os
envolvidos
no
processo
de
desenvolvimento.
Esta dissertao apresenta uma orquestrao de componentes reutilizveis
de software baseados em MDA, que visa criar um mtodo integrado para gerao de
aplicaes para sistemas de informaes na Web, utilizando a linguagem Python e o
framework de desenvolvimento gil Django, juntamente com a UML. Esta
abordagem est dividida em trs partes/componentes: PyMDAGenerator mdulo
PIM, PyMDAGenerator mdulo PSM e o mdulo de gerao em shell script para
integrar as aes etapas de desenvolvimento e gerao final do projeto.
Um estudo preliminar realizado para avaliar a ferramenta foi testado atravs
do projeto da Fbrica de Software Gofactory do sistema de gesto de inventrios
hospitalares no produto "Retriever". Esse estudo contribuiu para a melhoria da
abordagem e motivou o desenvolvimento de um prottipo para apoiar a aplicao da
orquestrao. Esse exemplo foi desenvolvido no contexto do ambiente da
ferramenta PyMDAGenerator, envolvendo as etapas de planejamento, anlise,
projeto, implementao e testes.
7.2 Contribuies
O trabalho de pesquisa apresentado teve como objetivo principal propor uma
orquestrao entre componentes reutilizveis de software para implementao de
sistemas de informao para Web baseado no paradigma MDA. Atravs da
linguagem Python e do framework de desenvolvimento gil Django. Entre as suas
principais contribuies, podemos destacar:
Definio de uma orquestrao de componentes reutilizveis de software

aplicado ao MDA, simples, prtica e objetiva, incluindo as etapas do CIM,
PIM, PSM e transformaes para cdigo fonte. (1) o reuso de uma notao
para a representao explcita dos conceitos de CIM em UML, (2) um
mecanismo para gerao dos arquivos admin.py e models.py de forma
automtica atravs da biblioteca UML2DJ (so os arquivos no formato *.sh
98
feitos em Shell Script), (3) um ambiente de gerao automtica de tabelas e
atributos seguindo o modelo ORM parecido com hibernete/JPA, (4) um outro
mecanismo integrado para fazer a instalao dos projetos e a integrao com
o ambiente de verso e publicao das aplicaes. importante salientar que
a abordagem proposta baseada no mesmo tipo de modelo comumente
utilizado para a gerao automtica de cdigo baseado em MDA.
Avaliao preliminar da ferramenta PyMDAGenerator, por meio de um estudo

realizado
pelos
alunos
do
Mestrado
Profissional
do
Cesar.edu.br,
especificamente da Fbrica de Software Gofactory. Os resultados obtidos

foram utilizados para melhoria da ferramenta e podero servir como base
para planejamento de uma avaliao mais completa da mesma.
Desenvolvimento de um prottipo que implementa a abordagem proposta no

contexto
do ambiente
de
orquestrao. Sendo
orquestrao
de
componentes, o meta-modelo da biblioteca UML2DJ e a ferramenta

PyMDAGenerator as principais atribuies. A mesma gerou uma verso do
Projeto "Retriever" com todas as caractersticas existentes no ambiente Java
plataforma JEE tambm feitos com a linguagem Python e o framework
Django. possvel ainda ressaltar as seguintes contribuies secundrias:
o
Estudo das reas de Engenharia de Reuso de Software e Modelagem

Dirigida a Modelos de Software, buscando identificar as oportunidades
de pesquisa existentes;
Identificao
das
extenses
necessrias
para
possibilitar
representao dos modelos conceituais de classe, atributos e mtodos

na plataforma Python para o framework django;
o
Identificao dos diferentes mecanismos existentes de transformaes

entre modelos de PIM, PSM e Cdigo Fonte.
99
7.3 Limitaes
Algumas limitaes deste trabalho foram identificadas a partir de uma anlise
crtica da abordagem proposta e do prottipo desenvolvido. As principais so
listadas logo a seguir:
A orquestrao de componentes reutilizveis de software limitada atravs

da plataforma Linux, posto que utiliza a linguagem Shell Script para realizar
as transformaes entre os modelos de PIM para PSM e PSM para Cdigo
Fonte;
A aplicao restrita ao modelo de caractersticas baseado em MDA e

funciona especificamente para Python com o framework Django;
No foi realizado nenhum estudo para avaliar o prottipo desenvolvido,

necessrio realizar testes de performance e testes funcionais automatizados
para testar o aumento do nmero de entidades e atributos dos domnios e o
nvel de complexidade dos mtodos;
No foi possvel tambm validar os artefatos de UML do modelo

comportamental atravs de diagramas de atividades, mquina de estados e
diagramas de sequncia por exemplo, nem as restries OCL aplicados aos
modelos;
No foi possvel gerar uma aplicao em Shell Script baseada em Interfaces

Grficas mais ricas, por exemplo utilizando o componente Dialog, isto
melhoraria a usabilidade da aplicao e provavelmente a sua adoo para os
usurios menos familiarizados com o Shell do Linux e comandos da
linguagem Python e do framework Django.
100
7.4 Trabalhos Futuros
Ao longo do desenvolvimento deste trabalho, algumas oportunidades de
melhoria, tanto da abordagem proposta quanto do prottipo desenvolvido, foram
destacadas. Alm disso, novas oportunidades de pesquisa foram identificadas. Os
possveis trabalhos futuros envolvem:
Aplicao
do
prottipo
desta
orquestrao
utilizando
modelo
comportamental em atividades de monitoramento e acompanhamento dos

ativos com restries OCL aplicados ao modelo do Diagrama de Classes e
Diagramas de Atividades;
Planejamento e execuo de estudos de avaliao mais complexos e

completos que envolvam a abordagem proposta como um todo e a utilizao
do prottipo em outros estudos de casos e domnios diferentes;
Representao dos artefatos baseados em servios, conhecendo suas

dependncias em relao aos modelos de componentes de software com
UML e suas relaes aplicadas ao modelo de processo de negcio com
BPMN e BPEL.
Aplicao e construo do modelo especfico de plataforma para outras

linguagens do tipo: Java Plataforma JEE, a linguagem Ruby e o framework
On Raills, este ltimo j sendo testado em pequenos prottipos nas fases de
criao e especificao;
Integrao da abordagem proposta com tecnologias que suportem a

reconfigurao dinmica do modelo, como por exemplo: OSGI (OSGI
ALLIANCE, 2009);
Construo de um ambiente mais complexo e rico de execuo que suporte

a reconfigurao dos sistemas desenvolvidos com base nas extenses
propostas que permita a incluso de novas caractersticas e regras de
adaptao em tempo de execuo.
101
Criao de novos componentes que garantam a interoperabilidade atravs

de servios do tipo SOA/REST, visando aproveitar as transformaes de
componentes da aplicao em servios que podero ser usados por outras
aplicaes.
Melhorar a Interface grfica da ferramenta e os recursos de configurao e

gerenciamento da mesma.
Aprimorar o mecanismo de parse XML, aplicando novas regras de

extensibilidade baseadas no MOF 2, visando garantir o uso em outras
plataformas distintas.
102
8. REFERNCIAS BIBLIOGRFICAS
ARGOUML, 2012
Argo UML. 2012. Documents ArgoUML. Disponvel em:

<http://argouml.tigris.org/documentation/>.
ltimo
acesso:
01/12/2012.
ANDR, 2009
Andr Milani. "PostgreSQL guia do programador - backup,

recovery, SQL, otimizao, segurana". Editora: Novatec.
2009.
ATKINSON e al ,
2001
Atkinson, C., Bayer, J., Bunse, C., Kamsties, E., Laitenberger,

O., Lagua, R., Muthig, D., Paech, B., Wst, J. and Zettel, J.
Component-Based Product Line Engineering with UML.
The Component Software Series. Addison-Wesley. 2001.
BEYDEDA e
GRUHN, 2005
Beydeda, S. and Gruhn V. Model-Driven Software

Development". Springer-Verlag New York, Inc. Secaucus. NJ.
2005.
BUSCHMANN e al,
1996
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. and

Stal M. Pattern-Oriented Software Architecture: A System
of Patterns. John Wiley and Sons. 123- 168. 1996.
BYDINKSY e al,
2009
Budinsky, F., Steinberg, D., Merks, E., Ellersick, R. and Grose,

T., J. Eclipse Modeling Framework: A Developer's Guide.
Addison Wesley. 2009.
CHE, 2001
CHEESMAN, John; DANIELS, John. UML Components: a

Simple Process for Specifying Component-Based Software.
Addison-Wesley, 2001.
CHERRYPY, 2013
Docs CherryPy 3.2.4 Documentao, Disponvel em:

<http://cherrypy.readthedocs.org/en/latest/index.html> - ltimo
acesso: 12/12/2013.
CWM, 2013
Common Warehouse Metamodel (CWM). 2013. Disponvel

em:
<http://www.omg.org/spec/CWM/>.
ltimo
acesso:
11/12/2013.
DANIEL, 2007
Daniel Gouveia Costa. "Administrao de Redes com

Scripts - Bash Script, Python e VBScript". Editora: Brasport.
2007.
103
DAVI M. BEAZLEY,
2009
Beazley,
Python
Essential
Reference:
Ingls,
ISBN:
9780768687026: Ed. Addison-Wesley. 2009.

DI, 2005
Object Management Group. UML Diagram Interchange (DI)

Specification. 2005. Disponvel em: <http://www.omg.org/
cgi-bin/doc?ptc/2005-06-07>. ltimo acesso: 01/02/2005.
DJANGO, 2013
Django. 2013. Disponvel em: <http://www.djangoproject.com>.

ltimo acesso: 07/01/2013.
DRESDEN, 2013
Dresden OCL Toolkit. 2013. Disponvel em: <http://dresdenocl.sourceforge.net/>. ltimo acesso: 04/01/2013.
ECLIPSE, 2013
Eclipse
Project.
2013.
Disponvel
<http://www.eclipse.org/>. ltimo acesso: 05/01/2013.
ECORE, 2013
Ecore.
2013.
Disponvel
em:
<http://help.eclipse.org/help33/index.jsp?
topic=/org.eclipse.emf.doc/references/javadoc/org/eclipse/
emf/ecore/package-summary.html>.
ltimo
acesso:
25/04/2013.
EMF, 2013
Eclipse Modeling Framework. 2013. Disponvel em:

<http://www.eclipse.org/modeling/emf/>.
ltimo
acesso:
07/08/2013.
EMF, 2013A
The Eclipse Modeling Framework (EMF) Overview. Disponvel

em:
<http://help.eclipse.org/ganymede/index.jsp?topic=/
org.eclipse.emf.doc/references/overview/EMF.html>.
ltimo
acesso: 20/03/2013.
EMFV, 2009
The Eclipse Modeling Framework (EMF) Validation Framework

Overview.
2009.
Disponvel
em:
<http://help.eclipse.org/ganymede/
topic/org.eclipse.emf.doc/references/overview/
EMF.Validation.html>. ltimo acesso: 04/01/2009.
GAMMA e al, 2007
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.

"Padres de Projeto Solues reutilizveis de software
orientado a objetos". Bookman. 2007.
ERIKSSON e al,
2003
Eriksson, H. E., Penker, M., Lyons, B. And Fado, D. UML 2

Toolkit. Wiley Computer Publishing. 2003.
FOWLER AND
STANWICK, 2004
Fowler, S. e Stanwick, V. Web Application Design

Handbook: Best Practices for Web-Based Software.
Morgan Kaufmann Publishers. 2004.
em:
104
FRANKEL e
PARODI, 2002
Fowler, S. e Stanwick, V. Web Application Design

Handbook: Best Practices for Web-Based Software.
Morgan Kaufmann Publishers. 2004.
GACC, 2013
Google
Account
API.
2013.
<http://code.google.com/apis/accounts>.
02/01/2013.
Disponvel
em:
ltimo
acesso:
GAE, 2009
Google
App
Engine.
2009.
<http://code.google.com/appengine/>.
05/03/2009.
Disponvel
em:
ltimo
acesso:
GAE, 2009A
Google App Engine SDK for Java v.1.2.2. 2009. Disponvel

em:
<http://code.google.com/appengine/downloads.html>.
GAEJRE, 2009
The GAE JRE Class White List. Disponvel em:

<http://code.google.com/intl/en/appengine/docs/java/jrewhitelis
t.html>. ltimo acesso: 29/05/2009.
GAMMA e al, 1994
Gamma, E., Helm, R., Johnson, R. and Vlissides, J. M.

Design Patterns: Elements of Reusable Object-Oriented
Software. Addison-Wesley Professional. 1994.
ZLOBIN, 2013
Gennadiy Zlobin, Learning Python Design Patterns: Ingls,

Ed. Packt Publishing Ltda. Nov/2013.
RUMBAUGH,
JACOBSON,
BOOCH, 1999
JSON, 2013
.1 James Rumbaugh, Ivar Jacobson, Grady Booch,

The Unifield Modeling Language Reference
Manual, 1999, Ed. Addison-Wesley. ]1 Ed.
JavaScript Object Notation (JSON). 2013. Disponvel em:
<http://www.json.org/>. ltimo acesso: 04/01/2013.
JULIO, 2006
Jlio Cezar Neves. "Programao Shell Linux". Edio: 6.

Editora: Brasport. 2006.
KOLOVOS e al,
2006
Kolovos, D. S., Paige, R. F. and Polack, F. A. C. Eclipse

Development Tools for Epsilon. Eclipse Summit Europe.
2006.
KOLOVOS e al,
2006a
Kolovos, D. S., Paige, R. F., Kelly, T., Polack, F. A. C.

Requirements for Domain-Specific Languages. In
Proceedings of the First ECOOP Workshop on DomainSpecific Program Development, 2006.
105
KOLOVOS et al,
2008
Kolovos, D., Paige, R., Rose, L. and Polack, P. The Epsilon

Book.
2008.
Disponvel
em:
<http://www.eclipse.org/gmt/epsilon/doc/book/>. ltimo acesso:
04/10/2008.
LAWLEY, 2004
Lawley, M., Duddy, K., Gerber, A. and Raymond, K.

Language Features for Re-Use and Maintainability of MDA
Transformations. CRC for Enterprise Distributed Systems
(DSTC). 2004.
LEFF e RAYFIELD,
2001
Leff, A. e Rayfield, J. T. Web-Application Development

Using the Model/View/Controller Design Patter. Proc. IEEE
International Enterprise Distributed Object Computing
Conference. IEEE. 2001.
LEVITT, 2009
Leavitt, N. Is Cloud Computing Really Ready for Prime

Time. Innovative Technology for Computer Professionals.
2009
LUTZ, 2006
Lutz, M. Programming Python. OReilly. 3 ed. 2006.
MAGICDRAW,
2013
Magic
Draw.
2013.
Disponvel
em:
<http://www.magicdraw.com/>. ltimo acesso: 09/06/2013.
MARINHO e al,
2009
Marinho, W. A. T., Machado, B. B., Pereira, F. M. and Robin, J.

P. L. Um Framework UML2 para Modelagem de
Aplicaes Web dentro de um Processo de Engenharia de
Software Dirigido por Modelos e Baseado em
Componentes. III Workshop de Desenvolvimento Rpido de
Aplicaes. 2009.
MARINHO, 2009
Marinho, W. A. T. A Web GUI for a Multi-View ComponentBased Modeling CASE Tool. Master Thesis (Master Degree)
Federal University of Pernambuco, Recife, 2009.
FOWLER e
SCOTT, 2006
Martin Fowler, Kendall Scott. "UML Essencial". 2 Edio.

Editora: Bookman. 2006.
MDR, 2013
Metadata
Repository.
2013.
Disponvel
<http://mdr.netbeans.org/>. ltimo acesso: 01/03/2013.
MELI e al, 2003
Meli, S., Cachero, C. e Gomez, J. Using MDA in Web

Software Architectures. 2nd OOPSLA Wsh. Generative
Techniques in the Context of Model Driven Architecture. 2003.
em:
106
MELLOR, 2005
MELLOR, Stephen J.;SCOTT, Kendall; UHL, Axel; WEISE, Dirk.

MDA Destilada: Princpios de Arquitetura Orientada por Modelos.
Rio de Janeiro: Editora Moderna Ltda., 2005.
MILLER e
MUKEREJI, 2001
Joaquim
Miller
and
Jishnu
Mukereji.
"Model
Driven
Architecture (MDA): A Draft with anottations of issues to

resolve Architecture Board ORMSC. 2001. Disponvel em:
<http://www.cin.ufpe.br/~redis/mda/01-07-01.pdf>.
ltimo
acesso: 11/12/2013.
MOF, 2013
OCLE, 2009
OCLMDT, 2009
OCTOPUS, 2013
Object Management Group. Meta-Object Facility (MOF) 2.0

Specification.
2013.
Disponvel
em:
<http://www.omg.org/spec/MOF/2.0/>.
ltimo
acesso:
10/11/2013.
OCLE 2.0 - Object Constraint Language Environment. 2009.
Disponvel em: <http://lci.cs.ubbcluj.ro/ocle/index.htm>. ltimo
acesso: 04/01/2009.
Eclipse
OCL
MDT.
2009.
Disponvel
em:
<http://www.eclipse.org/modeling/mdt/downloads/?project=ocl>
. ltimo acesso: 04/01/2009.
Octopus: OCL Tool for Precise Uml Specifications. 2013.
Disponvel em: <http://octopus.sourceforge.net/>. ltimo
acesso: 04/01/2013.
OMG, 2012A
Object Management Group. UML 2.0 Metamodel in Rose.

2012. Disponvel em: <http://www.omg.org/spec/UML/2.1.2/>.
OMG, 2013
Object Management Group. 2013. Disponvel

<http://www.omg.org/>. ltimo acesso: 03/11/2013.
SANTANA e
GALESI, 2010
Osvaldo Santana e Thiago Galesi. "Python e Django Desenvolvimento gil de aplicaes web". Novatec.
Trveos. 2010.
PYMOF, 2013
PyEMOF.
2013.
Disponvel
<http://www2.lifl.fr/~marvie/software/pyemof.html>.
acesso: 15/04/2013.
PYYAML, 2013
PyYAML. 2013. Disponvel em: <http://pyyaml.org>. ltimo

acesso: 08/01/2013.
em:
em:
ltimo
107
RODRIGUES, 2004
Rodrigues, M. G. C. Metodologia da Pesquisa Cientfica.

Rio de Janeiro, 2004.
SOMMERVILLE,
2011
Engenharia de Software, 9 Edio, 2011, Ed. Pearson

Education, 568 Pginas.
SZYPERSKI, 1999
SZYPERSKI,
Clemens.
Component
Software:
beyond
object-oriented programming. Harlow: Addison-Wesley. 1999.

GALESI, SANTANA
2010
Osvaldo Santana e Thiago Galesi. "Python e Django Desenvolvimento gil de aplicaes web". Novatec.
Trveos. 2010
TOGETHER, 2012
Borland
Together.
2012.
Disponvel
em:
<http://www.borland.com/us/products/together/index.html>.
WARMER e
KLEPPE, 2003
Warmer, J., Kleppe, A. The Object Constraint Language:

Getting Your Models Ready for MDA. Addison Wesley. 2
ed. 2003.
WEB2PY, 2013
Complete Reference Manual, 6th Edition (pre-release).

written by Massimo Di Pierro in English, Disponvel em:
<http://www.web2py.com/books/default/chapter/29>
ltimo
acesso: 12/12/2013.
WEBOB, 2012
WebOb. 2012. Disponvel em: <http://pythonpaste.org/webob>.

WEBOBJECT,
2012
WebObjects Web Applications Programming Guide: How

Web
Applications
Work.
2012.
Disponvel
em:
<http://developer.apple.com/documentation/WebObjects/
Web_Applications/
Articles/1_Architecture.html>.
ltimo
acesso: 03/03/2012.
PDUA , 2011
Wilson de Pdua, Engenharia de Software Fundamentos,

Mtodos e Padres, 2011, Edio 3, Ed. LTC gen.
XMI, 2013
Object Management Group. XML Metadata Interchange

(XMI), v2.1.1. 2013. Disponvel em: <http://www.omg.org/
technology/xml/index.htm>. ltimo acesso: 15/10/2013.
XML, 2009
Extensible Markup Language (XML). 2009. Disponvel em:

<http://www.w3.org/XML/>. ltimo acesso: 04/01/2009.
108
APNDICES
APNDICE I - DETALHAMENTO DOS REQUISITOS DO PROJETO - 109

APNDICE II - MODELOS DE DIAGRAMAS UML DO PROJETO - 115
APNDICE III - GLOSSRIO DO BANCO DE DADOS - 119
APNDICE IV - BIBLIOTECA UML2DJ - 124
APNDICE V - SCRIPT EM SHELL COMANDOS COM TRANSFORMAES - 128
109
Apndice 1
Lista de Detalhamento e Descrio dos Requisitos Funcionais

Nesta sesso sero apresentadas algumas informaes mais detalhadas
sobre os requisitos funcionais do projeto, seus atores e suas principais referncias,
estas informaes so importantes para detalhar os dados relacionados ao projeto e
suas principais funcionalidades.
[RF01] - Autenticao de usurios e senhas.
Atores: Todos
Descrio: Este procedimento consiste realizar a operao de autenticao dos
usurios no sistema, compreende no lanamento do login e senha do usurio e
validao atravs do banco de dados do sistema. Referncia: RF1
[RF02] Listar itens de material por setor.
Atores: Todos
Descrio: Este procedimento consiste em listar todos os itens de material
catalogados por setor, tal atividade implica em criar uma tela com um item para
busca identificado com o nome do setor. Tal pesquisa pode ser feita de maneira
global todos os setores ou por um setor especfico. Referncia: RF1, RF2
[RF03] Gerenciar relatrios de equipamentos por ritmos in ambiente.
Atores: Gestor e Administrador
Descrio: Este procedimento consiste em gerar um relatrio de todos os
equipamentos que passaram por um determinado ambiente, informando data e hora
de movimentao e local de origem e destino, o referido relatrio servir tambm
com ponto de auditoria do sistema. Referncia: RF1, RF3, RF5
110
[RF04] Gerenciar usurios.
Descrio: Este procedimento consiste em realizar as operaes bsicas
relacionadas ao usurio identificando os seus principais atributos tais como nome do
usurio, login, senha, perfil, etc. Outro ponto a identificao de seus mtodos tais
como incluso, alterao, excluso e listagem geral de todos os usurios do
sistema, alm de alterar a senha do usurio atualmente conectado no sistema.
Referncia: RF1, RF4
[RF05] Gerar relatrio por ambiente.
Descrio: Este procedimento consiste em gerar um relatrio no formato PDF de
todos os materiais existentes por ambiente operacional do hospital. Referncia:
FR1, FR5
[RF06] Gerenciar hospitais.
Atores: Administrador
relacionadas ao hospital identificando os seus principais atributos tais como: cdigo
do Hospital, descrio do hospital, CNPJ, razo social, etc. Outro ponto a
identificao de seus mtodos tais como incluso, alterao, excluso e listagem
geral de todos os hospitais. Referncia: RF1, RF6
[RF07] Gerenciar gestor por hospital.
relacionadas ao Usurio Administrador do Hospital identificando os seus principais
atributos tais como nome do usurio, login, senha, perfil avanados de
111
administrao do hospital, delegao de nvel, etc. Outro ponto a identificao de
seus mtodos tais como: delegao de funo, nveis de permisso, controle de
acesso a recursos especficos do hospital. Referncia: RF1, RF4, RF6, RF7
[RF08] Registrar alertas emitidos
Descrio: Este procedimento consiste em registrar todos os alertas emitidos pelos
sensores no hospital. Referncia: RF1, RF8
[RF09] Gerar log de eventos inesperados
Descrio: Este procedimento consiste em gerar uma pequena relao de eventos
inesperados para o sistema, eventos tais como: materiais que no podem entrar em
determinados ambientes do tipo UTI, Salas de Cirurgias, etc. Referncia: RF1, RF9,
RF10
[RF10] Auditar Sistemas
Descrio: Este procedimento consiste em gerar a parte de auditoria do sistema
como um todo: operaes de incluso, alterao, excluso sero armazenadas com
data e hora de realizao como tambm o nome do usurio que fez a referida ao.
Referncia: RF1, Todos.
[RF11] Gerenciar Prdios e Blocos
Atores: Engenharia Clnica, Gestor e Administrador.
relacionadas ao Prdio e Blocos do Hospital identificando os seus principais
atributos tais como: cdigo predio, descrio prdio, Localizao, etc. Outro ponto
112
a identificao de seus mtodos tais como incluso, alterao, excluso e listagem
geral de todos os prdios e blocos. Referncia: RF1, RF11
[RF12] Listar Itens na Tela de Incio do Sistema
Atores: Engenharia Clnica, Gestor e Administrador
Descrio: Este procedimento consiste em listar as aes de movimentao de
itens que ocorreram nos ltimos minutos do sistema. Referncia: RF1, RF12
[RF13] Gerenciar Equipamento

Atores: Engenharia Clnica
relacionadas aos Equipamentos do Hospital identificando os seus principais atributos
tais como: cdigo equipamento, descrio, tipo, localizao da Etiqueta RFID, etc.
Outro ponto a identificao de seus mtodos tais como incluso, alterao,
excluso e listagem geral de todos os equipamentos. Referncia: RF1, RF13
[RF14] Gerenciar reas.
relacionadas as reas do Hospital identificando os seus principais atributos tais
como: cdigo rea, descrio, tipo, localizao dos sensores, etc. Outro ponto a
identificao de seus mtodos tais como incluso, alterao, excluso e listagem
geral de todas as reas. Referncia: RF1, RF14
[RF15] Gerenciar Andares.
113
relacionadas aos andares existentes no Hospital identificando os seus principais
atributos tais como: cdigo andar, descrio, tipo, localizao no prdio, etc. Outro
ponto a identificao de seus mtodos tais como incluso, alterao, excluso e
listagem geral de todos os andares. Referncia: RF1, RF15
[RF16] Gerenciar Movimentaes.
relacionadas as movimentaes existentes de equipamentos e materiais no Hospital
identificando os seus principais atributos tais como: cdigo da movimentao,
observaes, tipo de equipamento e material, data da movimentao, hora da
movimentao, etc. Outro ponto a identificao de seus mtodos tais como
incluso, alterao, excluso e listagem geral de todas as movimentaes.
Referncia: RF1, RF16
[RF17] Gerenciar Identificadores (label) Etiquetas.

relacionadas aos identificadores (Etiquetas FRID) em cada equipamento e material
do Hospital identificando os seus principais atributos tais como: cdigo identificador,
descrio, tipo, localizao, etc. Outro ponto a identificao de seus mtodos tais
como incluso, alterao, excluso e listagem geral de todos os identificadores.
Referncia: RF1, RF15
[RF18] Gerenciar Sensores.
114
relacionadas aos sensores instalados em cada ambiente do Hospital identificando
os seus principais atributos tais como: cdigo sensor, etiqueta RFID, descrio, tipo,
localizao, etc. Outro ponto a identificao de seus mtodos tais como incluso,
alterao, excluso e listagem geral de todos os andares. Referncia: RF1, RF18
[RF19] Alertar Movimentao Indevida.
Atores: Sensor / Segurana
Descrio: Este procedimento consiste em emitir um aviso sonoro de alerta de
movimentao indevida de materiais e equipamentos de um lugar para outro dentro
do hospital. Referncia: RF1, RF19
[RF20] Receber alerta de segurana.
Atores: Sensor / Segurana.
Descrio: Este procedimento consiste em enviar uma mensagem por SMS, MMS e
Email, alm de mensagem de voz para o segurana de planto. Referncia: RF1,
RF20
115
Apndice 2
Modelos de Diagramas da UML / Arquitetura do Projeto e Artefatos

de Anlise e Especificao do Sistema.
Nesta sesso so apresentados os diagramas da UML e demais
caractersticas do sistema, relacionados ao projeto Retriever e demais aes.
Diagrama de Casos de Uso do Sistema de Gerenciamento de Inventrios

Hospitalares "Retriever".
116
Diagrama de Classes do Sistema.
Diagrama do Modelo ER (Entidade Relacionamento), sistema Retriever..
117
Diagrama do Modelo Lgico do Sistema "Retriever".
Diagrama de Componentes do Sistema - Viso Arquitetura do Play 2.0 Framework.
118
Diagrama
de
Instalao
Componentes e
Middleware
de
Integrao
Desenvolvidos pela nossa Fbrica de Software Gofactory.
Diagrama de Arquitetura Externa, viso Integrao entre os servios baseado

no Middleware da Empresa BeagleTech Cesar.edu.
119
Apndice 3
Glossrio do Banco de Dados com Script (DDL).

Nesta sesso sero apresentadas algumas informaes mais detalhadas
sobre os requisitos funcionais do projeto, seus atores e suas principais referncias,
estas informaes so importantes para detalhar os dados relacionados ao projeto
BEGIN;
CREATE TABLE "Administrador_tipoequipamento" (
"id" integer NOT NULL PRIMARY KEY,
"codigo" varchar(5) NOT NULL,
"descricao" varchar(50) NOT NULL,
"urlimagem" varchar(50) NOT NULL );
CREATE TABLE "Administrador_area" (
"codigo" integer,
"background" varchar(50) NOT NULL,
"poligono" varchar(50) NOT NULL,
"retrita" integer,
"andar_id" integer );
CREATE TABLE "Administrador_identificador" (
120
"cod" integer,
"codigo" varchar(50) NOT NULL,
"epc" varchar(50) NOT NULL,
"tecnologia" integer );
CREATE TABLE "Administrador_sensor" (
"codigo" integer,
"localizacao" varchar(40) NOT NULL,
"modelo" varchar(40) NOT NULL,
"tecnologia" integer );
CREATE TABLE "Administrador_evento" (
"codigo" integer,
"data" date,
"identificadorold_id"
integer
NOT
NULL
REFERENCES
"Administrador_identificador" ("id"),
"sensorid_id"
integer
NOT
NULL
("id"));
CREATE TABLE "Administrador_entidade" (
"codigo" integer,
"nomeEntidade" varchar(50) NOT NULL,
REFERENCES
"Administrador_sensor"
121
"endereco" varchar(50) NOT NULL,
"fone" varchar(30) NOT NULL,
"status" integer );
CREATE TABLE "Administrador_bloco" (
"codigo" integer,
"entidade_id"
integer
NOT
NULL
REFERENCES
("id"));
CREATE TABLE "Administrador_andar" (
"codigo" integer,
"descricaoAndar" varchar(50) NOT NULL,
"nome" varchar(50) NOT NULL,
"urlimagem" varchar(50) NOT NULL );
"Administrador_entidade"
122
CREATE TABLE "Administrador_s3plantabaixa" (
"coordenadas_X" integer,
"coordenadas_Y" integer,
"areaCompleta" integer );
CREATE TABLE "Administrador_equipamento" (
"codigo" integer,
"model" varchar(50) NOT NULL,
"patrimonio" varchar(50) NOT NULL,
"identificador_id"
integer
NOT
NULL
REFERENCES
"Administrador_identificador" ("id"),
"tipo_id" integer NOT NULL REFERENCES "Administrador_tipoequipamento"
("id"));
CREATE TABLE "Administrador_movimentacao" (
"evento_id" integer NOT NULL REFERENCES "Administrador_evento" ("id"),
"entidade_id"
integer
NOT
NULL
REFERENCES
"Administrador_entidade"
("id"),
"bloco_id" integer NOT NULL REFERENCES "Administrador_bloco" ("id"),
"equipamento_id"
integer
NOT
NULL
REFERENCES
"Administrador_equipamento" ("id"),
"andar_id" integer NOT NULL REFERENCES "Administrador_andar" ("id"),
123
"area_id" integer NOT NULL REFERENCES "Administrador_area" ("id"));
CREATE
INDEX
"Administrador_evento_17578276"
ON
"Administrador_evento"
"Administrador_evento_3e5e76b5"
ON
"Administrador_evento"
"Administrador_bloco_1c4c4e74"
ON
"Administrador_bloco"
("identificadorold_id");
CREATE
INDEX
("sensorid_id");
CREATE
INDEX
("entidade_id");
CREATE
INDEX
"Administrador_equipamento_4c2413d6"
ON
"Administrador_equipamento"
ON
"Administrador_equipamento"
("identificador_id");
CREATE
INDEX
"Administrador_equipamento_27e4f492"
("tipo_id");
CREATE INDEX "Administrador_movimentacao_213b366b" ON "Administrador_movimentacao"
("evento_id");
CREATE INDEX "Administrador_movimentacao_1c4c4e74" ON "Administrador_movimentacao"
("entidade_id");
CREATE INDEX "Administrador_movimentacao_10cac466" ON "Administrador_movimentacao"
("bloco_id");
CREATE INDEX "Administrador_movimentacao_7f0e96d9" ON "Administrador_movimentacao"
("equipamento_id");
CREATE INDEX "Administrador_movimentacao_3bc48ff9" ON "Administrador_movimentacao"
("andar_id");
CREATE INDEX "Administrador_movimentacao_202f16e9" ON "Administrador_movimentacao"
("area_id");
COMMIT;
124
Apndice 4
Biblioteca UML2DJ.
'''
uml2dj.py
Run without arguments to see the documentation
@author: Goffer Looney
TODO:
detect failures of external command calls (e.g. mysql, python)
...
'''
import libxml2
import libxslt
import sys
import re
import os
def start():
if (len(sys.argv) < 2):
print """Converts a XMI file to a models.py and admin.py files
%s application [/d] [/s] [/r]
/d
drop all the tables used by that application, USE WITH CAUTION!
/s
run syncdb
/r
run django web server
125
XMI file must be in the current directory and its name is [application].xmi
""" % sys.argv[0]
else:
import settings
import os
prj_name = os.getcwd().rpartition(os.sep)[2]
app_name = sys.argv[1]
if '%s.%s' % (prj_name, app_name) not in settings.INSTALLED_APPS:
print 'Application not installed %s.%s' % (prj_name, app_name)
exit(1)
if not os.path.exists("%s/__init__.py" % app_name):
print '%s module not found' % (app_name)
exit(1)
if not os.path.exists("%s.xmi" % app_name):
print '%s.xmi not found' % (app_name)
exit(1)
allchars = ''
for arg in sys.argv[1:]:
if (re.match('^/\w$', arg)):
allchars += arg[1:2]
pass
if 'd' in allchars:
print 'Drop tables'
126
run_command('python manage.py sqlclear %s > droptables.sql' % app_name)
run_command('mysql -u %s --password=%s %s < droptables.sql'
(settings.DATABASE_USER, settings.DATABASE_PASSWORD, settings.DATABASE_NAME))
print 'Generate code'

generate_code(app_name)
if 's' in allchars:
print 'Sync DB'
import settings
result = run_command('python manage.py syncdb')
if 'r' in allchars:
print 'Run Server'
result = run_command('python manage.py runserver')
def generate_code(app_name):
xmi_file = '%s.xmi' % app_name
transform('xmi2djmodels.xsl', xmi_file, app_name+'/_models.py')
transform('xmi2djmodels_generic.xsl', xmi_file, app_name+'/models_generic.py')
transform('xmi2djadmin.xsl', xmi_file, app_name+'/admin.py')
transform('xmi2djadmin_custom.xsl', xmi_file, app_name+'/_admin_custom.py')
transform('xmi2djadmin_generic.xsl', xmi_file, app_name+'/admin_generic.py')
def run_command(command):
#
args = re.split('\s+', command.strip())
import subprocess
ret = subprocess.call(args)
return ret
127
import os
ret = os.system(command)
return ret
def transform(xslt, source, target):
styledoc = libxml2.parseFile(xslt)
style = libxslt.parseStylesheetDoc(styledoc)
doc = libxml2.parseFile(source)
result = style.applyStylesheet(doc, None)
style.saveResultToFilename(target, result, 0)
style.freeStylesheet()
doc.freeDoc()
result.freeDoc()
start()
128
Apndice V
SCRIPT EM SHELL comandos com as transformaes.
Comando
Descrio
#!/bin/bash
Comando que serve para inicializar o script e

executar
os
comandos
da
linguagem
Shell
(Interpretador).
# Sistema
Comentrio
sobre
Sistema
Ferramenta
pyMDAGenerator
# Autor
Comentrio sobre o Autor.
# SubMdulo
Comentrio sobre o SubMdulo.
echo "Lendo os dados do Arquivo XMI.
O comando echo responsvel pela exibio da
Posso continuar? [sn] "
mensagem na tela e fica aguardando a resposta se

[s para SIM] ou [n para NO]
read RESPOSTA
O comando read RESPOSTA responsvel por

armazenar a resposta da pergunta em uma varivel
chamada RESPOSTA.
if [ $RESPOSTA = s ] then
Este comando responsvel por realizar uma

deciso, se o contedo da varivel RESPOSTA for
python UML2DJ /ProjetoRetriever

echo "Realizando as Transformacoes
entre os modelos"
igual a s ento, ir exibir uma mensagem na tela e

comear a executar os comandos. Este comando
ir gerar os arquivos models.py e admin.py em sua
pasta
sleep 2
ProjetoRetriever,
_admin_custom.py
em
renomear
admin_custom.py
_models.py em models.py.
mv
/administrator/_admin_custom.py
admin_custom.py
Na
prxima
execuo
comando
python
manage.py syncdb responsvel por executar as

transformaes do arquivos models.py na estrutura
129
Comando
Descrio
do banco de dados. O prximo passo verificar as
mv
/administrador/_models.py
models.py
aes e parmetros de configurao do projeto

atravs do arquivo settings.py, nele so exibidas
informaes de configurao do projeto, como
tambm os links simblicos, e demais aes do
echo
"[PIM]-Fazendo
as
projeto em si.
tranformaes para o [PSM] Django

Por
Python"
fim
ser
chamado
arquivo
geradorMDAPSM.sh que ficar responsvel pela

continuao..
sleep 4
python manage.py syncdb
echo "Aplicando as mudanas no
settings.py...."
sleep 5
nano settings.py
echo "Aplicando as transformaes
no models.py..."
sleep 2
./geradorMDAPSM.sh
Fi
if [ $RESPOSTA = n ] then
Este comando ir interromper o script e demais

aes..
echo
Script:..."
sleep 3
exit
fi
"Execuo
Interrompida
do
130
Tabela [1]: Tabela com os comandos arquivo geradorMDAPIM.sh
Fonte: Prprio Autor.
Comando
Descrio
#!/bin/bash
Comando que serve para inicializar o script e

executar
os
comandos
da
linguagem
Shell
(Interpretador)..
# Sistema
Comentrio
sobre
Sistema
Ferramenta
pyMDAGenerator
# Autor
Comentrio sobre o Autor.
# SubMdulo
Comentrio sobre o SubMdulo.
echo
"Continuar
com
as
O comando echo responsvel pela exibio da
transformaes. Posso continuar? [sn] "
mensagem na tela e fica aguardando a resposta se

[s para SIM] ou [n para NO]. O comando read
read RESPOSTA
RESPOSTA armazena o valor digitado na varivel

RESPOSTA.
if [ $RESPOSTA = s ] then
Este comando tem como caracterstica realizar uma

deciso atravs do IF, se a resposta for igual a s
echo "Realizando as Transformaes

de PIM para PSM..."
ento ser realizado o comando python manage.py

syncdb que ir atualizar o banco de dados e as
informaes de persistncia do sistema. Depois o
sleep 2
comando python manage.py sqlall ir exibir todos

os comandos realizados para criao da estrutura
python manage.py syncdb
de dados (banco de dados) da aplicao em si,

echo
"[PIM]-Fazendo
as
modelo este que ser aplicado neste exemplo do
tranformaes para o [PSM] Django
sistema. O prximo comando ser o python
Python"
manage.py runserver este responsvel por

inicializar o servidor de aplicao do python para
sleep 4
rodar a aplicao propriamente dita.
python manage.py sqlall

echo
"Startando
aplicaes ...."
servidor
de
131
Comando
Descrio
sleep 5
python manage.py runserver
echo "Pronto para Executar"
fi
http://localhost:3000
if [ $RESPOSTA = n ] then
Este comando ir interromper o script e demais

aes..
echo "Transformao Interrompida"

fi
# O date mostra a data e a hora
Comando responsvel pela exibio da data e hora
correntes
da gerao do aplicativo.
echo "Data e Horrio:" date

Echo
Comando responsvel por exibir uma lista de

usurios atualmente conectados nesta mquina.
# O w mostra os usurios que esto

conectados nesta mquina
echo "Usurios conectados:" w
Tabela [2]: Tabela com os comandos do arquivo geradorMDAPSM.sh
Fonte: Prprio Autor

PyMDAGenerator: Uma Ferramenta para Geração Automática de Aplicações Baseada em MDA

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PyMDAGenerator: Uma Ferramenta para Geração Automática de Aplicações Baseada em MDA

Uploaded by

Copyright:

Available Formats

C.E.S.A.

R CENTRO DE ESTUDOS E SISTEMAS

RICARDO ROBERTO DE LIMA

Uma orquestrao de componentes para gerao

RICARDO ROBERTO DE LIMA

Uma orquestrao de componentes para gerao

Orientao: Prof. Vinicius Cardoso Garcia, D.Sc.

C.E.S.A.R CENTRO DE ESTUDOS E SISTEMAS

Uma orquestrao de componentes para gerao

RICARDO ROBERTO DE LIMA

Dissertao apresentada ao programa de

Pensar o trabalho mais difcil que existe.

Henry Ford [1901]

todos os meus professores, principalmente Felipe Furtado, Vinicius Garcia, Luiz

A engenharia de software baseada em componentes vem crescendo devido

PyMDAGenerator, implementados com a linguagem Python e o Django. E por fim,

Key Words: Software Reuse. Component-Based Software Engineering. MDA.

1.1 Contexto e Motivao ...................................................................................................

1.2 Objetivos ......................................................................................................................

1.2.1 Objetivos Gerais ........................................................................................................

1.2.2 Objetivos Especficos ................................................................................................

1.3 Estrutura do Trabalho ...................................................................................................

2. Embasamento Terico .................................................................................................

2.1 Desenvolvimento baseado em componentes ...............................................................

2.2 Unifiel Modeling Language (UML) ................................................................................

2.3 Model Driven Architecture (MDA) .................................................................................

2.4 A Linguagem Python ....................................................................................................

2.5 O framework django .....................................................................................................

2.6 A linguagem Shell Script ..............................................................................................

2.7 O Sistema de gerenciamento de dados (Postgresql e SQLite3) .................................

2.8 Concluso do Captulo .................................................................................................

3. Fundamentao Terica da Proposta .........................................................................

3.1 Caracterizao da pesquisa .........................................................................................

3.2 Problematizao ...........................................................................................................

3.3 Modelos utilizados pelo MDA .......................................................................................

3.4 Padro reusvel visual para modelagem estrutural bsica, meta-modelagem: a

3.5 Meta-modelagem: MOF2 e ECORE..............................................................................

3.6 A Modelagem comportamental: Superestrutura UML2 ................................................

3.7 Linguagem textual para modelagem, metamodelagem avanada OCL2 .....................

3.8 Abordagens para projetos de linguagens de modelagem avanada ............................

3.9 Consideraes Finais deste captulo ............................................................................

4. A Ferramenta PyMDAGenerator: "A abordagem proposta" .....................................

4.1 Definio da ferramenta ...............................................................................................

4.2 Viso geral da abordagem proposta ............................................................................

4.3 Apoio definio de transformaes ...........................................................................

4.4 Etapas de transformao entre os modelos usando a biblioteca UML2DJ .................

4.5 Consideraes Finais deste captulo ............................................................................

5. Exemplo: Sistema "Retriever" e o Sistema Patrimonial "Asset Inventory" ...........

5.1 Definio do problema .................................................................................................

5.2 Stakeholders, requisitos funcionais e no funcionais ..................................................

5.3 Modelos de artefatos e documentos do projeto ...........................................................

5.4 Interfaces da aplicao e requisitos do sistema "Retriever" .........................................

5.5 O sistema de gesto de inventrios patrimoniais "Asset Inventory" ............................

5.6 Consideraes finais deste captulo .............................................................................

6. Estudo comparativo entre a ferramenta ANDROMDA (Java) PyMDAGenerator

6.1 O projeto "Retriever" na arquitetura Java JEE com ANDROMDA ..............................

6.2 Representao dos dados aplicados ao projeto "Asset Inventory" desenvolvimento

6.3 Grfico comparativo entre os dos processos ...............................................................

6.4 Consideraes finais sobre este captulo .....................................................................

7. Consideraes Finais ..................................................................................................

7.1 Eplogo .........................................................................................................................

7.2 Contribuies ...............................................................................................................

7.3 Limitaes ....................................................................................................................