Você está na página 1de 146

C.E.S.A.

R – CENTRO DE ESTUDOS E SISTEMAS
AVANÇADOS DO RECIFE

RICARDO ROBERTO DE LIMA

Uma orquestração de componentes para geração
semi-automática de aplicações baseada em MDA

RECIFE
2014

RICARDO ROBERTO DE LIMA

Uma orquestração de componentes para geração
semi-automática de aplicações baseada em MDA
Dissertação apresentada ao programa de
Mestrado em Engenharia de Software do Centro
de Estudos e Sistemas Avançados do Recife,
como requisito para a obtenção do título de Mestre
em Engenharia de Software.

Orientação: Prof. Vinicius Cardoso Garcia, D.Sc.

RECIFE
2014

C.E.S.A.R – CENTRO DE ESTUDOS E SISTEMAS
AVANÇADOS DO RECIFE

Uma orquestração de componentes para geração
semi-automática de aplicações baseada em MDA

RICARDO ROBERTO DE LIMA

Dissertação apresentada ao programa de
Mestrado em Engenharia de Software do
Centro de Estudos e Sistemas Avançados do
Recife, como requisito para a obtenção do título
de Mestre em Engenharia de Software.
Data de aprovação:
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

Dedicatória

Pensar é o trabalho mais difícil que existe.
Talvez por isso tão poucos se dediquem a ele.

Henry Ford [1901]

Agradecimentos
Em primeiro lugar, agradeço a Deus que é a fonte de toda força e sabedoria
existente e por ter me dado toda força e sabedoria suficientes para a conclusão
deste trabalho.
Agradeço aos meus avós Maternos e Paternos (in memorian), por sempre ter sido
um grande exemplo de honestidade, perseverança e fé.

Aos meus pais, Orlando Sebastião de Lima e Edivânia Maria de Lima e aos meus
irmãos Vaneo Célio de Lima e Regina Coeli de Lima por sempre demonstrarem seu
carinho, amor e confiança 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, paciência, amor e confiança, que
esteve sempre ao meu lado, me incentivou e nunca mediu esforços para me ajudar.
Aos meus filhos, Maria Clara Costa Lima e João Guilherme Costa Lima pelo amor,
carinho e compreensão durante este período da minha vida.

Á todos os meus professores, principalmente Felipe Furtado, Vinicius Garcia, Luiz
Maurício, Kiev Gama, Robson do Nascimento Fidalgo, Gustavo Alexandre, Ceça,
Left, Rodrigo Assad, Roberto Capistrano, Trajano, Ana Paula Cavalcanti e Heriberto
pelas boas conversas e grandes exemplos que são para mim.
Agradeço aos meus amigos de sala de aula, Adilson, Aprígio, Josué, Pedro, Ana Claudia
pela amizade, confiança e respeito depositados em mim durante este período de estudo. E
por fim, agradeço a todos que de forma direta ou indireta contribuíram para a conclusão
deste trabalho.

Epígrafe

"O homem de valor nunca morre. Seus exemplos e suas obras atestam a sua
imortalidade".
Hélder Sena de Sousa [1981]

Resumo

A engenharia de software baseada em componentes vem crescendo devido
à complexidade dos sistemas e o consequente aumento no custo necessário para
desenvolver software. Várias técnicas surgiram ao longo do tempo com este
objetivo, com a definição do nível de abstração dos artefatos e o avanço das
ferramentas e frameworks de desenvolvimento orientados a objetos. Uma dessas
iniciativas é a Arquitetura Dirigida a Modelo (MDA) que permite a modelagem e a
aplicação de transformações sobre modelos, garantindo assim, a construção de
sistemas de forma automatizada. Este trabalho tem como objetivo principal propor
uma abordagem prática e extensível para definição de transformações unidirecionais
entre modelos (PIM para PSM e PSM para código), que permita a sua utilização
através de um parser XMI, junto com uma biblioteca intitulada UML2DJ e um
conjunto de tratadores implementados em Shell Script para executar o processo de
transformação e geração semi-automática de aplicações baseada em MDA, sendo
realizado

de

maneira

assistida

através

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. Transformações 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.

SUMÁRIO:
1. Introdução .....................................................................................................................

1

1.1 Contexto e Motivação ...................................................................................................

1

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

3

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

3

1.2.2 Objetivos Específicos ................................................................................................

4

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

5

2. Embasamento Teórico .................................................................................................

6

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

6

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

7

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

8

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 Conclusão do Capítulo .................................................................................................

18

3. Fundamentação Teórica da Proposta .........................................................................

20

3.1 Caracterização da pesquisa .........................................................................................

20

3.2 Problematização ...........................................................................................................

21

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

22

3.4 Padrão reusável visual para modelagem estrutural básica, 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 avançada OCL2 .....................

38

3.8 Abordagens para projetos de linguagens de modelagem avançada ............................

40

3.9 Considerações Finais deste capítulo ............................................................................

42

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

43

4.1 Definição da ferramenta ...............................................................................................

43

4.2 Visão geral da abordagem proposta ............................................................................

45

4.3 Apoio à definição de transformações ...........................................................................

46

4.4 Etapas de transformação entre os modelos usando a biblioteca UML2DJ .................

55

4.5 Considerações Finais deste capítulo ............................................................................

62

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

63

5.1 Definição do problema .................................................................................................

63

5.2 Stakeholders, requisitos funcionais e não funcionais ..................................................

64

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

69

5.4 Interfaces da aplicação e requisitos do sistema "Retriever" .........................................

73

5.5 O sistema de gestão de inventários patrimoniais "Asset Inventory" ............................

78

5.6 Considerações finais deste capítulo .............................................................................

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 Representação dos dados aplicados ao projeto "Asset Inventory" desenvolvimento
na linguagem Python com Django .....................................................................................

87

6.3 Gráfico comparativo entre os dos processos ...............................................................

90

6.4 Considerações finais sobre este capítulo .....................................................................

93

7. Considerações Finais ..................................................................................................

95

7.1 Epílogo .........................................................................................................................

95

7.2 Contribuições ...............................................................................................................

96

7.3 Limitações ....................................................................................................................

98

7.4 Trabalhos Futuros ........................................................................................................

99

8. Referências Bibliográficas ...........................................................................................

101

9. Apêndices ....................................................................................................................

107

Apêndice 1 ........................................................................................................................

108

Apêndice 2 ........................................................................................................................

114

Apêndice 3 ........................................................................................................................

118

Apêndice 4 ........................................................................................................................

123

Apêndice 5 ........................................................................................................................

127

Lista de Figuras.
Figura [1] - Taxonomia dos diagramas da UML 2.1.................................................................

8

Figura [2] - Arquitetura da MDA ...............................................................................................

10

Figura [3] - Processo de transformação do PIM para PSM e do PSM em código..................

24

Figura [4] - Processo de transformação 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 Vôo (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 transformações do modelo Django Framework.........

47

Figura [19] - Detalhes do Meta Modelo componente UML2DJ ...............................................

48

Figura [20] - Detalhes do Meta Modelo UML2DJ - Visão tipos de atributos ......................

49

Figura [21] - Detalhes do Meta Modelo UML2DJ - Associação .............................................

50

Figura [22] - Figura que representa o esquema de ligação dos componentes do django ......

51

Figura [23] - Diagrama de Instalação ......................................................................................

52

Figura [24] - Componentes internos do django .......................................................................

54

Figura [25] - Diagrama de classe modelo do sistema retriever ...............................................

56

Figura [26] - Arquivo no formato XMI - representação do domínio .........................................

57

Figura [27] - Detalhe do processo de transformação entre PSM to Código 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 - visão interna (MVC) .............................................

72

Figura [33] - Diagrama de instalação - visão externa "Retriever" ............................................

73

Figura [34] - "Retriever" - Tela de Autenticação de usuários no sistema ................................

74

Figura [35] - "Retriever" - Seleção 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 usuários .........................................................

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] - Página do Projeto PyMDAGenerator na Internet ...............................................

93

Lista de Tabelas

Tabela [1] Requisitos Funcionais ...........................................................................................

67

Tabela [2] Requisitos Não-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 informações do projeto dando ênfase ao nº de linhas de código .............

91

Lista de Gráficos
Gráfico [1] Informações Estatísticas do Projeto "Retriever" JEE.......................................................

87

Gráfico [2] Gráfico com os dados estatísticos do projeto em Python + Django................................

89

Gráfico [3] Gráfico com as informações unificadas entre o desenvolvimento Java JEE x Python Django ......

90

Gráfico [4] Gráfico com as informações estatísticas, azul para o Python e Laranja para Java.......................

91

Gráfico [5] Gráfico com a variação dos percentuais entre os projetos (Java x Python) ...................

92

ACRÔNIMOS
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

1. INTRODUÇÃO

1.1 Contexto e Motivação
Segundo (SOMMERVILLE, 2011, p. 89-100) a Engenharia de Software vem
evoluindo ao longo dos anos no que diz respeito a arquiteturas, linguagens de
programação, arcabouços de desenvolvimento de software, novos paradigmas e
processos de desenvolvimento, dentre outros aspectos. Apesar desses avanços,
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 fácil manutenção; (b) mudanças de tecnologia e requisitos; (c)
alto acoplamento com a plataforma escolhida; (d) má gerência dos projetos de
desenvolvimento.
Com o objeto de propor uma solução para os problemas supracitados, em
2001, a Object Management Group (OMG)1 apresentou uma iniciativa chamada de
Arquitetura Orientada a Modelos, do inglês Model Driven Architecture (MDA), cujo
principal objetivo é mudar o foco do desenvolvimento de software para a importância
que os modelos devem ter nesse cenário. Tais modelos passam a ter um papel
fundamental na documentação e nas demais fases do ciclo de vida do processo de
desenvolvimento de software, inclusive na fase de codificação.
Um modelo pode ser entendido com um conjunto de elementos que
descrevem alguma realidade física ou abstrata. A utilização de modelos eleva o nível
de abstração no desenvolvimento de sistemas, auxiliando no planejamento e
entendimento dos mesmos, além de promover uma clara separação entre aspectos
lógicos, responsáveis por descrever as regras de negócio do software, da tecnologia
usada para implementação (MELLOR, 2005, p. 56-87).

1

Organização internacional que aprova padrões abertos para aplicações orientadas a objetos

2
A proposta da MDA é aumentar o nível de abstração no desenvolvimento de
sistemas de tal forma que os modelos gerados sejam independentes de plataforma.
A partir dos modelos de mais alto nível, novos modelos são derivados, passando
pelo Modelo Independente de Plataforma, do Inglês Platform Independent Model
(PIM), em seguida para o Modelo Específico de Plataforma, do inglês Platform
Specific Model (PSM), até o nível mais baixo abstração que é o próprio código-fonte
da aplicação. Para isso, ferramentas de transformação entre modelos e geração de
código devem ser utilizadas. Com isso, mudanças de requisitos ou mesmo de
tecnologia não impactarão em um alto custo para realização das alterações, sendo
necessário somente repetir a transformação do modelo PIM, para o novo modelo
PSM agora específico da nova plataforma alvo e por fim gerar o código-fonte.
Diante desse contexto, o objeto deste trabalho é definir uma orquestração de
componentes reutilizáveis de software, visando garantir uma semi-automatização do
processo de geração de código baseando-se nos conceitos propostos pela MDA.
Para demonstrar a viabilidade da abordagem proposta, uma ferramenta para
geração automática aplicações 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 extensível
baseada na orquestração de componentes reutilizáveis de software, para definição
de transformações unidirecionais entre modelos (PIM para PSM e PSM para código).
Tal abordagem deve permitir à sua utilização através de um parser XMI, junto com
uma biblioteca intitulada UML2DJ e um conjunto de tratadores implementados em
Shell Script para executar o processo de transformação e geração semi-automática
de aplicações baseada em MDA, sendo realizado de maneira assistida através de
uma ferramenta chamada PyMDAGenerator.

1.2.2 Objetivos Específicos

Definir uma orquestração de componentes reutilizáveis de software,
visando garantir uma semi-automatização do processo de geração de
código com a arquitetura dirigida a modelos MDA;

Propor uma solução 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 referência para geração das
transformações;

Melhorar o mecanismo de leitura dos dados existentes nos arquivos XML,
UML2DJ;

2

Biblioteca UML to Django - Faz a conversão direta de modelos UML para estrutura dos projetos do Django

4

Construir uma ferramenta para gerar de forma automática aplicações 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 Capítulo introduz e apresenta o contexto desta dissertação,
descreve, comenta e motiva o trabalho, seus objetivos gerais e específicos e
estrutura dos capítulos;

O Segundo Capítulo relata o embasamento teórico onde são apresentadas
informações básicas sobre as metodologias, ferramentas, linguagens e
frameworks tais como: MDA, Python, Django, entre outros;

O Terceiro Capítulo prossegue no embasamento teórico especificando em
detalhes as características da UML e MDA com visões de meta modelo e
transformações entre modelos com demais características;

O Quarto Capítulo descreve informações detalhadas sobre a orquestração de
componentes reutilizáveis de software e a metodologia de MDA aplicada
para geração do código;

O Quinto Capítulo apresenta informações sobre o estudo de casos do projeto
"Retriever" e do projeto "Asset Inventory" com sua definição do problema,
requisitos, solução proposta e conjunto de artefatos produzidos, interfaces
gráficas e características;

O Sexto Capítulo propriamente dita a análise 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 Sétimo capítulo emite as considerações finais onde são apresentados as
epígrafe, contribuições, limitações, pontos positivos e negativos, inclusive os
trabalhos futuros.

6

2. EMBASAMENTO TEÓRICO
Neste capítulo será feita a contextualização desta pesquisa. Inicialmente,
iremos apresentar uma definição das principais tecnologias da informação e
comunicação (TIC) utilizadas nesta pesquisa, tais conceitos são importantes para a
Engenharia de reuso de Software, bem como de suas principais características e,
ainda, as influências que exercem na Engenharia de Software baseada em Modelos
do tipo (MDA/MDE) e UML. Em seguida, serão discutidas as tecnologias baseadas
na linguagem Python com Framework Django, juntamente com SGBD, Postgresql e
SqLite3, tais como definição, características e também suas vantagens e
desvantagens.
2.1 Desenvolvimento Baseado em Componente
O desenvolvimento baseado em componentes é um paradigma de
desenvolvimento de software caracterizado pela composição de partes já existentes,
ou pela composição de partes desenvolvidas independentes e que são integradas
para atingir um objetivo final. Conforme (SZYPERSKI, 1999, p. 20-30), construir
soluções pela combinação de componentes garante o reuso do código. Com isso, o
desenvolvimento baseado em componentes auxilia na manutenção dos sistemas e o
uso dela associado à elaboração de linhas de produtos de software reduz
significativamente o redesenvolvimento de linhas de código. Para que o reuso de
software seja eficiente em um ambiente produtivo de fábrica de software, por
exemplo, os arquitetos procuram expressar os relacionamentos entre as unidades
de design, tais como Web services e componentes de negócio. 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 à nível
de negócio, infraestrutura e arquitetura do domínio da aplicação (CHEESMAN, 2001,
p. 49-70).
Na engenharia de reuso de software os componentes são blocos de
construção básicos, que alicerçam esta arquitetura. A distribuição e fragmentação

7
destes blocos implica no aumento do reuso, melhoria da produtividade e
manutenabilidade dos componentes.
Nesta arquitetura é possível mapear a maneira de automação de um
processo de produção de software analisando as especificidades do modelo de
negócio e seus componentes básicos para realizar as transformações.
Para aumentar a velocidade de produção dos projetos de software é
importante ter uma base de componentes extremamente granular, separando-os do
desenvolvimento em domínios independentes de plataforma com a UML, dos
domínios

específicos

de

plataforma

baseados

em

DSL,

minimizando

a

especificidade do modelo de negócio.
2.2 Unifield Modeling Language (UML)
A presente seção apresenta uma breve descrição da Unified Modeling
Language (UML) e os principais conceitos e padrões relacionados à mesma. Esses
conceitos são de grande importância para um bom entendimento por parte de
leitores que não 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

gráfica,

para

especificação,

visualização,

construção

e

documentação de artefatos de sistemas de software, principalmente sistemas
orientados a objetos. A UML nasceu da unificação das muitas linguagens gráficas 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 padrão no mundo para a modelagem de sistemas
orientados a objetos. Isso se deve a algumas características, tais como: ser uma
linguagem de propósito geral, ou seja, é independente de uma etapa do
desenvolvimento de software; não está presa a um processo; independe de uma
linguagem de programação; não possui semântica formal bem definida, entre outras
características. Este trabalho usará como base a versão 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 referência encontra-se no
documento de

especificação 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 próxima seção, serão apresentadas algumas informações sobre a
arquitetura dirigida a modelos (MDA) seus conceitos, características 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 seção apresenta uma breve descrição do MDA. Esses conceitos
são de grande importância para um bom entendimento por parte de leitores que não
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 princípio a importância
dos modelos dentro do processo de desenvolvimento de software. MDA foi uma
iniciativa da OMG, lançada 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. Além 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 utilização do MDA possibilita a automatização de algumas das etapas
dentro do processo de desenvolvimento de software, incluindo a geração do códigofonte para a plataforma escolhida a partir de um determinado modelo. De acordo
com a MDA GUIDE, version 1.0.1 (2005) os três principais objetivos da MDA são
promover uma maior portabilidade, interoperabilidade e a reusabilidade.
2.3.1 Arquitetura do MDA
O Model Driven Architecture é representado através da Figura 3, nela é
possível identificar as principais tecnologias, áreas de negócio da abordagem do
MDA na visão da OMG. Analisando-a, tem-se no centro o núcleo da arquitetura que
é baseada nos padrões de modelagem: UML (JACOBSON, 1999), MOF (MOF,
2013) e CWM (CWM, 2013), padrões 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 serviços 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 Núcleo
O núcleo do MDA compreende um conjunto de metamodelos UML,
desenvolvidos pela OMG, cada um abrangendo determinada área do processo de
desenvolvimento. Esses metamodelos representam as características comuns de
todas as plataformas alvos, porém será independente de qualquer plataforma
específica (MILLER e MUKERJI, 2001, p. 84-99).
Como foi mencionado anteriormente, o núcleo da arquitetura MDA é formado
pelos padrões de metamodelagem da OMG. Sendo eles:
 Meta-Object Facility (MOF): Padrão criado pela OMG que define uma
linguagem para a definição de linguagens de modelagem. Como o MOF é
uma linguagem para criação de linguagens, ela pode ser considerada
uma metalinguagem. O MOF é a linguagem em que os metamodelos de
UML e CWM são 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
transformações 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 padrões de
modelagem citados acima, que vale a pena ressaltar e que não é mostrada na figura
3, é o XML Metadata Interchange (XMI, 2013).

XML Metadata Interchange é um padrão em MOF da OMG para troca de
informações baseado em XML. O uso mais comum é na troca facilitada de
metadados entre as ferramentas de modelagem e os repositórios.
(XMI, 2013).

Sobre os domínios e características aplicados a MDA estão o conceito de CIM
(Modelo Computacional) depois a transformação para PIM (Modelo Independente de

11
Plataforma) na sequência a criação do PSM (Modelo Específico de Plataforma),
consiste em realizar as transformações de PSM para código e depois rodar a
aplicação. Na próxima seção serão apresentadas algumas informações sobre a
linguagem Python seus conceitos, características e principais recursos.
2.4 A Linguagem Python
A presente seção apresenta uma breve descrição da linguagem Python.
Esses conceitos são de grande importância para um bom entendimento por parte de
leitores que não estejam habituados com esta tecnologia.
Segundo (DAVI M. BEAZLEY, 2009, p. 35-43), Python é uma linguagem de
programação de alto nível, interpretada, imperativa, orientada a objetos, de tipagem
dinâmica e forte. Foi lançada por Guido van Rossum em 1991. Atualmente possui
um modelo de desenvolvimento comunitário, aberto e gerenciado pela organização
sem fins lucrativos Python Software Foundation. Apesar de várias partes da
linguagem possuírem padrões e especificações formais, a linguagem como um todo
não é formalmente especificada. A linguagem foi projetada com a filosofia de
enfatizar a importância do esforço do programador sobre o esforço computacional.
Prioriza a legibilidade do código sobre a velocidade ou expressividade. Combina
uma sintaxe concisa e clara com os recursos poderosos de sua biblioteca padrão e
por módulos e frameworks desenvolvidos por terceiros.
2.4.1 - Características da Linguagem
Sobre o ponto de vista das suas características, a linguagem Python possui
construções que incluem: estrutura de decisão (if, else, elif); estruturas de repetição
(for, while), que iteram por um container, capturando cada elemento em uma variável
local dada; construção de classes (class); construção de subrotinas (def); construção
de escopo (with) entre outros recursos da linguagem. A linguagem possui também
características comuns às outras linguagens de programação entre elas:

Palavras reservadas, operadores, interpretador interativo, análise léxica,
indentação, compilador de bytecode, orientação a objetos, programação
funcional, tratamento de exceções, biblioteca padrão.

12

Módulos e frameworks: Outra característica da linguagem Python é o grande
número 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

aceitação pela comunidade que trata de soluções de código aberto, em especial
Linux, e pela aceitação nas empresas (públicas e privadas) e instituições 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. São algumas das organizações que
trabalham com soluções 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 criação da versão web
dos seus jornais. Posteriormente, em 2005, foi liberado sob a licença BSD,
tornando-se assim um software de código aberto (DAVID M. BEAZLEY, 2009, p. 3060).
Assim como outros frameworks ágeis para desenvolvimento web, o Django
utiliza o conceito de DRY - Don´t repeate yourself (Não se repita), que trabalha com
a ideia de utilizar convenções em substituição às configurações.
Isso quer dizer que, se for seguir determinadas convenções na maneira de
organizar seu código, não precisará ficar configurando características específicas
dele. Isso agiliza muito o desenvolvimento. É preciso utilizar configurações um
pouco mais complexas somente nas situações em que o comportamento padrão do
Django não é o esperado ou quando não é possível seguir as convenções criadas
pelo framework, algo raro de acontecer.
Existem

atualmente,

diversas

soluções

baseadas

em

Python

para

desenvolvimento para Web, é possível citar alguns frameworks: Web2Py, CherryPy
e Plone.

Em virtude disso, foi escolhido o framework django para estes projeto, pois o
mesmo possui uma melhor distribuição dos componentes existente, facilitando assim
o desenvolvimento e execução deste projeto, conforme características em detalhe
na próxima seção.

14
2.5.1 - O Projeto Django
O Django é considerado um "superframework", pois é composto de vários
frameworks menores, entre eles é possível citar:

ORM: permite programar utilizando objetos sem se preocupar com a
persistência desses dados no seu banco de dados relacional. Essa
camada de software abstrai toda a comunicação com seu banco de
dados, permitindo que você manipule seus objetos sem o uso de SQL
(é possível acessar diretamente o banco de dados em uma aplicação
Django, mas esse tipo de uso só se torna interessante na otimização
de determinadas queries).

Template System: fornece uma linguagem para a criação de
templates (HTML, XML, JSON, etc). Usados na geração de páginas
dinâmicas.

Sistema de Administração: O Django é um dos poucos frameworks
web

que

disponibilizam

uma

interface,

gerada

quase

que

automaticamente, que permite a administração dos objetos de
negócios da sua aplicação.

URL dispatcher: cuida do processamento das URLs do sistema
executando funções especificas pelo desenvolvedor e possibilitando o
uso de URLs amigáveis ao usuário.

Internacionalização: facilita a internacionalização de seus sistema,
permitindo que ele funcione corretamente com diversos idiomas.

Formulários: geração automática de formulários e facilitação na
manipulação dos dados enviados por meio deles.

Segurança: gerenciamento de autenticação de usuários e controle de
permissões.

15

Outros componentes: serialização de dados, sistema de testes
automatizado, serviço de mensagens (e-mail e mensagens entre
usuários do sistema), sistema de cache de objetos, geração de feeds
(RSS/Atom), paginação de resultados etc.

2.5.2 Paradigma MVC (Model-View-Controller)
O

Django

utiliza

o

paradigma

MVC

(Model-View-Controller)

para

desenvolvimento de aplicações. Em algumas referências do Django, é possível
encontrar a sigla MTV (Model-Templeate-View), que representa basicamente a
mesma coisa dita com palavras diferentes. Embora não seja obrigatório o
desenvolvimento usando esse paradigma, é extremamente recomendado, pois,
dessa forma, você estará modularizando seu código e desacoplando a camada de
negócio da aplicação das camadas de interface com o usuário. Além disso, o Django
automaticamente organiza o esqueleto de seu projeto nesse formato e se baseia
nesse paradigma para suas convenções (conforme foi explicado anteriormente
sobre DRY) (GENNADIY ZLOBIN, 2013, p. 89-109).
Isso significa que a sua aplicação tem três partes principais:

Model: contém a representação 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 criação de nossas
classes de Model.

View:

cuida

da

visualização

do

conteúdo

no

formato

escolhido.

Frequentemente, há várias 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 manipulação dos dados do Model, bem
como de outras partes que não envolvem o Model diretamente. No Django,
esse papel é feito por dois componentes: o URL dispatcher e as views (por
isto MTV).

16
Na próxima seção serão apresentadas algumas informações sobre a
linguagem Shell Script seus conceitos, características e principais recursos.
2.6 A Linguagem Shell Script
A presente seção apresenta uma breve descrição sobre o Shell Script, suas
definições características e principais ações. Segundo Julio Cezar Neves no livro
Programação em Shell Linux define que Shell Script é uma linguagem de script
usada em vários sistemas operacionais, com diferentes dialetos, dependendo do
interpretador de comandos utilizado. Um exemplo de interpretador de comandos é o
bash, usado na grande maioria das distribuições GNU/Linux (JULIO CEZAR NEVES,
2006, p. 30-45).
Uma boa parte dos usuários definem o Shell Script como uma linguagem de
fácil aprendizagem. O primeiro passo é, saber o que se deseja fazer, então ver qual
o código que executa este comando em Shell e aí criar, basta escrever o código 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 é possível utilizar diversos comandos um
após o outro, ou mesmo combiná-los numa mesma linha. Se colocarmos diversas
linhas de comandos em um arquivo texto simples, teremos em mãos um Shell Script,
ou um script em Shell, já que script é uma descrição geral de qualquer programa
escrito em linguagem interpretada, ou seja, não compilada. Outros exemplos de
linguagens para scripts são o PHP, Perl, Python, JavaScript e muitos outros.
Podemos então 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 necessário.
Seu uso, portanto, é indicado na automação de tarefas que serão realizadas mais de
uma vez. Todo sistema Unix e similares são repletos de scripts em shell para a

17
realização das mais diversas atividades administrativas e de manutenção do
sistema.
Os arquivos de lote (batch - arquivos *.bat) do windows são também exemplos de
Shell Scripts, já que são 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, porém, são inúmeras 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 execução através da tabela crontab,
entre outras coisas. É uma ferramenta indispensável aos administradores de
sistemas Unix.
O Shell mais comum e provavelmente o que possui mais scripts escritos para ele é
também um dos mais antigos e simples, o sh. Este Shell está presente em todo o
sistema tipo Unix, incluído 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 portável 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 execução no ambiente de
sistemas de arquivos do próprio sistema operacional e a facilidade de integração dos
comandos do python com comandos da linguagem shell script, além da execução
em arquivos de shell com a extensão .sh.
Na próxima seção serão apresentadas algumas informações sobre o sistema
gerenciador de banco de dados Postgresql e o SQLite seus conceitos,
características 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 padrão para todas as versões do Django, inclusive para demonstração é
bastante utilizado, e o Postgresql foi aplicado no estudo de caso do projeto, e possui

18
uma grande aceitação na área em virtude da sua popularidade e distribuição livre e
de código aberto. Mais é importante salientar que é possível 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 seção apresenta uma breve descrição do Postgresql e do
SQLite3, suas definições, características modelos de ação e tópicos 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 informações de soluções de informática em todas as áreas de negócios
existentes, bem como administrar o acesso a estas informações.
Para Andrew, hoje em dia o postgresql é um dos principais SBGD´s do mercado,
possui uma linguagem própria baseada em PL/SQL, é multiplataforma pode rodar no
Linux, Windows, MAC e possui uma grande aceitação nas Universidades e
Governos das esferas federais, estaduais e municipais, arquitetura simples e
modular é escalável e bastante robusto. Estas são algumas das pospostas do
PostgreSQL.
2.8 - Conclusão do capítulo
Neste capítulo buscou-se apresentar o contexto inicial no qual esta pesquisa.
O crescimento e desenvolvimento cada vez maior destas tecnologias contribuíram
muito para a evolução da Engenharia de Software como um todo. De fato, é cada
vez maior o número de empresas e instituições que fazem uso desta tecnologia,
garantindo assim um maior reaproveitamento dos modelos criados de software no
que tange os artefatos de análise, projeto e especificação de software como também
o reuso do código.
Esta pesquisa se propõe a projetar uma ferramenta para geração automática
de código baseada em MDA. Para ser utilizado com a linguagem Python e o
framework Django na construção rápida de sistemas de informação para web.

19
No próximo capítulo serão apresentados mais detalhes sobre o embasamento
teórico desta dissertação, que vem a ser um dos temas centrais desta pesquisa.

20

3. FUNDAMENTAÇÃO TEÓRICA DA PROPOSTA
Este capítulo apresenta algumas informações sobre a caracterização da
pesquisa em questão como também um complemento da fundamentação teórica
deste trabalho incluindo um detalhamento sobre a Engenharia de Reuso de Software
e conceitos avançados de UML, OCL e MDA.

3.1 Caracterização da Pesquisa
A pesquisa realizada nesta dissertação caracteriza-se como teórica por
investigar as técnicas propostas pela MDA. Segundo (DEMO, 2000, p. 45-56),
pesquisa teórica é uma pesquisa que é dedicada a reconstruir teoria, conceitos,
ideias, ideologias, polêmicas, tendo em vista, em termos imediatos, aprimorar
fundamentos teóricos. Assim sendo, baseia-se na abordagem de pesquisa
qualitativa, tendo em vista que se propõe a responder perguntas tais como: Quais os
atuais problemas identificados dentro do atual cenário de desenvolvimento de
software baseados na engenharia de reuso de software? Como as técnicas
propostas pela MDA irão solucionar alguns desses problemas? Quais os passos
necessários para criação de uma ferramenta para geração automática de código
para WEB?
Segundo (OLIVEIRA, 2008, p. 23-43), a abordagem qualitativa pode ser
caracterizada como sendo o processo de reflexão e análise da realidade através da
utilização de métodos e técnicas para a compreensão detalhada do fenômeno de
estudo em seu contexto histórico, segundo sua estruturação.
Neste contexto, o tipo de pesquisa adotado foi o exploratório, devido ao fato
do principal objeto deste trabalho aplicar os conceitos de MDA para criação de um
PSM (Modelo Específico de Plataforma). De acordo com (OLIVEIRA, 2008, p. 89100), pesquisa exploratória tem como objetivo fornecer uma explicação geral sobre
um determinado tema, através da delimitação do estudo, levantamento bibliográfico,
leitura e análise de documentos.

21
3.2 Problematização

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 Fábrica de Software, com papéis bem definidos e
atividades gerenciadas. Mesmo assim, ainda é possível identificar algumas falhas
neste processo tais como: falhas no levantamento inicial das informações baseados
em requisitos funcionais e não funcionais, falta de gerenciamento das atividades e
controle de produtividade da equipe, falta de treinamento necessário sobre as
tecnologias aplicadas ao projeto, tais como: linguagem de programação, IDE,
ferramentas de modelagem e de gerenciamento de projetos. Em meio a esses
problemas, foram criadas diversas técnicas 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 vários problemas que antes assolavam as empresas, foram
mitigados. Infelizmente com o passar dos anos, novos problemas surgiram, e
atualmente o cenário de desenvolvimento de software enfrenta diversos problemas.
Segundo

(SOMMERVILLE,

2011,

p.

109-134),

as

atuais

técnicas

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, documentação e
manutenção.
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 orquestração entre componentes de software reutilizáveis,

22
baseados na arquitetura dirigida a modelos (MDA), utilizando a plataforma Python +
Django?

Uma outra contribuição deste trabalho foi a modelagem do Meta
Modelo da biblioteca UML2DJ, haja vista que a mesma ainda não existia?
Como identificar os pontos em comum e as características necessárias
identificados no Meta Modelo da Biblioteca UML2DJ para realizar as
transformações 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 visão do MDA?
De acordo com (MELLOR, 2005, p. 34-59) um modelo consiste em conjuntos
de elementos que descrevem alguma realidade física, abstrata ou hipotética.
Atrelando esse conceito de modelo ao universo da MDA, tem-se que um modelo de
um sistema é uma descrição ou especificação desse sistema e seu ambiente para
algum propósito determinado. Um modelo é frequentemente apresentado como uma
combinação 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 noção de criar diferentes modelos em
diferentes níveis de abstração e depois ligá-los, para formar uma implementação.
Alguns desses modelos existirão independentes de plataforma de software,
enquanto que outros serão específicos para uma plataforma alvo. Tendo em vista
essa abstração, a MDA define três modelos: Modelo Independente de Computação
(CIM), Modelo Independente de Plataforma (PIM) e Modelo Específico de Plataforma
(PSM) (KLEPPE, 2003, p. 46-50).

23
3.3.1 Modelo Independente de Computação
O Modelo Independente de Computação (do inglês Computation Independent
Model, CIM) fornece a visão de um sistema de computação dentro de uma
perspectiva independente, ou seja, não mostra detalhes da estrutura do sistema,
modela-o considerando apenas as regras de negócios. Ele tem como foco os
requisitos do software (KLEPPE, 2003, p. 56-70).
Segundo o (MDA GUIDE,2005, p. 34-87), esse modelo também pode ser
chamado modelo de domínio, como ele é independente de plataforma, acaba sendo
útil para servir como fonte para um vocabulário entre modelos, além de ajudar na
comunicação entre equipe de desenvolvimento e o cliente.

3.3.2 Modelo Independente de Plataforma
O Modelo Independente de Plataforma (do inglês Platform Independent
Model, PIM) possui um alto nível de abstração por ser independente de qualquer
tecnologia. Na construção do PIM, são especificados a estrutura e o comportamento
de um sistema, além de ser construído de forma a não utilizar nenhuma
característica que seja específica de uma plataforma. O PIM deve apresentar uma
independência 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 características que o PIM deve possuir são:
 Conter informações sobre o domínio da aplicação;
 Dispensar dados sobre plataformas que serão utilizadas ou tecnologias
que serão empregadas;
 Ser um modelo detalhado, sendo em geral, representado em UML.

24
3.3.3 Modelo Específico de Plataforma
O Modelo Específico de Plataforma (do inglês Platform Specific Model, PSM)
descreve o sistema a partir de uma plataforma específica. Combina as
especificações do PIM com os detalhes que mostram como o sistema usa um tipo
específico de plataforma. (MDA GUIDE, 2005, p. 56-80).
O PSM é gerado a partir de um PIM através do uso de UML Profile3, no
sentido em que um dado PSM possui informações de como gerar artefatos
correspondentes a elementos do modelo que estejam marcados com estereótipos
do PIM. A partir de um PIM pode-se gerar vários PSM.
3.3.4 Transformação entre modelos
Outro conceito chave dentro da MDA é a transformação entre modelos, que
consiste no processo de converter modelos em outros modelos do sistema.
Basicamente

dentro

da

MDA,

existem

duas

grandes

transformações:

a

transformação do PIM para o PSM e, posteriormente, a transformação do PSM em
código-fonte para a(s) tecnologia(s) alvo. Essas transformações podem ser feitas de
modo automatizado através de uma ferramenta de transformação, ou manualmente
por uma pessoa especializada. A Figura 05 ilustra esse cenário (KLEPPE, 2003).

Figura [03]: Processo de transformação do PIM para o PSM e do PSM em código
Fonte: (MELLOR, 2005)

3

Extensões UML para representar uma plataforma específica.

25
Essas transformações 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 conteúdo do modelo (MELLOR, 2005, p. 45-60).
De acordo com (MELLOR, 2005, p. 33-53), as transformações automáticas de
modelos aumentam a portabilidade e a eficiência 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 transformação
são umas caixas pretas. Isso se deve ao fato de que a ferramenta de transformação
precisa ter definida uma regra de transformação, que descreve como o modelo deve
ser transformado. Dentro desse cenário, um importante conceito é o de Marcas
(KLEPPE, 2003, p. 65-109).
As Marcas são utilizadas para inserir nos elementos do modelo PIM, que
posteriormente serão 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 transformação 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 não é muito diferente do
ciclo de vida tradicional de desenvolvimento de software. As mesmas fases são
identificadas. Uma das principais diferenças reside nos artefatos que são produzidos
durante o processo de desenvolvimento. Os artefatos são 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 próprio autor.

O PIM, o PSM, e código fonte são mostrados como artefatos em diferentes
etapas do ciclo de vida de desenvolvimento. Dentro desse cenário, eles representam
diferentes níveis de abstração na especificação do sistema. A capacidade de
transformar um PIM em um PSM eleva o nível de abstração em que um

27
desenvolvedor pode trabalhar. Isso permite que um desenvolvedor possa lidar com
sistemas mais complexos, com menos esforço (KLEPPE, 2003, p. 65-90).
Seguindo esse ciclo de vida, primeiro é realizado o levantamento de requisitos
do sistema, depois é realizada a fase de análise, nessa fase é feita modelagem do
modelo PIM, de acordo com os requisitos identificados. Na fase de design, é
realizada a transformação para PSM, levando-se em conta a tecnologia alvo usada
no desenvolvimento do sistema.
Na fase de codificação, é realizada a segunda transformação proposta pela
MDA, que é a transformação do PSM para código fonte do sistema. Posteriormente
são realizadas as fases de testing e a deployment. Caso seja identificado algum erro
na fase de deployment, uma nova iteração é realizada, sendo iniciada a partir da
fase de análise, de forma a identificar e corrigir o erro no próprio modelo PIM. Com
isso a documentação do sistema, sempre estará atualizada.
3.3.6 Benefícios da MDA
Nesta seção foram apresentados alguns problemas encontrados no atual
processo de desenvolvimento de software, dentre eles: problemas de produtividade,
portabilidade, interoperabilidade e manutenção e documentação. Nessa seção será
mostrado como a MDA pretende solucionar esses problemas.
De acordo com (KLEPPE, 2003, p. 45-60), a aplicação da MDA, dentro do
processo de desenvolvimento de software, apresenta melhorias na produtividade,
portabilidade, interoperabilidade, documentação e manutenção.
3.3.7 Produtividade

Na MDA, o foco principal está na modelagem do PIM. Os detalhes técnicos
específicos de uma plataforma são acrescentados ao PIM a partir da transformação
deste para o PSM. Além disso, uma boa parcela do código-fonte da aplicação alvo
será gerada da transformação do PSM para o código fonte.

28
A tarefa mais difícil nesse contexto é a definição de forma exata de como
serão feitas as transformações. Essa definição é uma tarefa difícil e complexa, que
necessita ser feita por pessoas qualificadas. Uma vez definida as transformações, as
mesmas podem ser aplicadas para diversos projetos, resultando em um alto ganho
de produtividade (KLEPPE, 2003, p. 56-80).
Como parte do código fonte da aplicação é gerada a partir do PSM, a equipe
de desenvolvimento pode, dentro do cronograma previsto, despender mais tempo
para analisar as regras de negócio do sistema a ser desenvolvido e,
consequentemente, identificar e corrigir mais erros em tempo de análise e assim
produzir um modelo PIM com uma maior qualidade.
Um alto ganho de produtividade pode ser alcançado através da utilização de
ferramentas que automatizem a transformação do PIM para o PSM. Isso acarreta
que muitas informações sobre a aplicação devem ser incorporadas no PIM e/ou na
ferramenta de transformação utilizada, pois agora o modelo de alto nível (PIM) está
diretamente relacionado com o código-fonte gerado. As exigências em relação à
integridade e coerência do PIM são maiores que no desenvolvimento sem a
utilização de uma ferramenta que automatize a transformação 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 definição é 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 nível do PIM, é totalmente portátil (KLEPPE, 2003,
p. 78-80).
Se dentro do processo de desenvolvimento alguma ferramenta de automação
de transformação for utilizada, a portabilidade estará limitada a ela. Para as
plataformas mais populares já existem ferramentas que possibilitam essa automação
nas transformações, para outras, é necessário ter uma ferramenta que suporte um

29
plugin4 para definição de transformações e essas definições devem ser descritas
manualmente (KLEPPE, 2003, p. 103-120).
3.3.9 Interoperabilidade
O conceito de interoperabilidade que o MDA se refere é a comunicação entre
os PSMs. Vários PSMs de plataformas diferentes são gerados a partir de um mesmo
PIM, e só conseguem se comunicar graças 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 próprio autor

Sendo capaz de transformar um PIM em dois PSMs para duas plataformas
diferentes, todas as informações necessárias para fazer a ponte entre os dois PSMs
estão disponíveis. 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

4

Dentro da informática, plugin é um software usado para adicionar funções a outros softwares
maiores, provendo alguma funcionalidade especial ou muito específica

30
um PSM se relacionam com os elementos do segundo PSM, desde que também se
conheça todos os detalhes técnicos dos dois PSMs. Com isso, têm-se todas as
informações necessárias para gerar uma conexão entre os dois (KLEPPE, 2003, p.
34-67).
A utilização de ferramentas que gerem além dos PSMs, os bridges entre elas,
irá proporcionar a interoperabilidade das plataformas, proposta pela MDA.
3.3.10 Documentação e Manutenção
Dentro da MDA, o PIM representa um documento de alto nível de abstração
para um software. A grande diferença é que o PIM tem um papel chave no
desenvolvimento do software, logo ele não pode ser descartado depois de
construído. As mudanças realizadas no sistema irão obrigatoriamente refletir em
mudanças no PIM, para a partir daí, ser feita uma nova geração do PSM e
posteriormente do código-fonte (KLEPPE, 2003, p. 30-50).
Existem ferramentas que mantêm o PIM, o PSM e o código-fonte gerado,
sincronizados, ou seja, qualquer alteração em algum destes elementos refletirá em
alterações correspondentes nos demais (KLEPPE, 2003, p. 30-45).
A documentação de mais alto nível (PIM) estará diretamente ligada à
implementação do sistema, tornando assim a manutenção do sistema e da própria
documentação menos custosa, o que faz com que a documentação esteja sempre
atualizada e de boa qualidade, pois a desatualização e má qualidade da
documentação afetam diretamente a qualidade do software.
3.4 - Padrão reusável visual para modelagem estrutural básica, 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 características principal a de nomear tipos de
elemento seu meta-modelo é constituído de uma classe chamada Element, como
subclasses dela existem o NamedElement e o Comment que se relacionam também
entre si através da associação, o TypedElement e o Type são subclasses de
NamedElement e estão associadas entre si. Este modelo de abstração é perfeito
para criação de novos elementos da UML em nosso caso especificamente foi
utilizado para criação dos novos elementos do SPEMLM.

Figura [07]: Infraestrutura em UML2 Meta Modelagem
Fonte: (UML2.0 Infraestruture, 2009)

O Diagrama de Classe tem como característica principal a definição e
criação 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
própria classe possui um auto-relacionamento com si própria para representar outras
super-classes, uma classe é composta por Property e Operation as operações
podem ou não ter Parâmetros e seus os mesmos tem multiplicidade ou tipos, uma
propriedade ou atributo herda de TypedElement também herdam as características
de MultiplicityElement.

32

Figura [08]: Infraestrutura do Diagrama de Classe segundo UML2 e MOF
Fonte: (UML2.0 Infraestruture, 2009)

O Diagrama de DataType definem as meta-classes que modelam e
implementam os tipos de dados, sua principal características é de integrar o modelo
a novos tipos de estereótipos definidos ao modelos, a class Type é o principal
elemento deste modelo, já a classe DataType que herda de Type serve de base
para definição de novos elementos e tipos já existentes da UML2, tais como
enumeration, interface, entre outros. Ligadas a elas estão duas sub-classes a
PrimitiveType e o Enumeration que por sua vez, é composta por EnumerationLiteral
que representa seus tipos e o próprio herda as características de NamedElement.

33

Figura [09]: Infraestrutura do
Fonte: (UML2.0 Infraestruture, 2009)

Diagrama

de

DataType

segundo

UML2

e

MOF

Já para o Diagrama de Package sua principal característica é definir a
estrutura básica de construção do ambiente onde ficarão os objetos modelos, a
classe Package herda as características do NamedElement, para simplificar esta
ação um Package está associado a um Type por composição, e é possível
implementar uma ação relativa a si próprio através do auto-relacionamento,
conforme ilustra a Figura 10.

Figura [10]: Infraestrutura do Diagrama de Package segundo UML2 e MOF
Fonte: (UML2.0 Infraestruture, 2009)

34
3.5 – A metamodelagem: MOF2 e ECORE

O MOF2 (Meta Object Facility) é um padrão criado pela OMG que define uma
linguagem para a definição de linguagem de modelagem. Como o MOF é uma
linguagem para criação de outras linguagens ela pode ser considerada uma
metalinguagem. O MOF2 reside na camada M3 da arquitetura dirigida a modelos
(MDA), e como não há uma camada superior para definir o MOF2, ele é definido
através dele mesmo. O MOF2 é a linguagem em que as definições de UML e CWM,
ou seja, os meta-modelos da UML2 e CWM são escritos.
A Figura 11 representa a visão 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 construção

de modelos

predefinidos

(meta-modelos)

em

ferramentas e através dele é possível realizar algumas operações existentes, tais

35
como: transformações entre modelos, geração de código, engenharia reversa, entre
outras coisas.
O ECORE é utilizado de ponte entre os ambientes e possibilita a integração
entre a parte ou modelo construído e sua implementação, ou seja, código 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 benefícios do uso do ECORE é a sua capacidade de alta coesão e
baixo acoplamento, garantindo assim integração com linguagens e formatos
diversos, como também integração com ferramentas de modelagem e transformação
entre modelos.

36
Uma das características interessante do ECORE é a possibilidade de
integração com outras linguagens, transformações entre modelos, diversas
ferramentas utilizam este recurso para realizar suas transformações 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
transformações entre os modelos dos diagramas Entidade Relacionamento para o
modelo lógico do lógico para o modelo físico (Script do Banco de Dados), outra
solução partindo para o modelo de MDA é a ferramenta ANDROMDA que reusa
EMF e ECORE para realização das transformações 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 definição iremos detalhar apenas os diagramas de Ação e
Atividades por fazerem parte do estudo deste trabalho.
Uma Action tem como característica principal ser uma unidade da
especificação de comportamento serve como um conjunto de entrada e saída. Sobre
o ponto de vista comum as ações básicas incluem aqueles que realizam operações
de chamada, envio de sinal, invocação de comportamento entre outros.

37

Figura [13]: Estrutura Interna do Diagrama de Ação (Action) – UML2 e MOF
Fonte: (UML2.1 SuperStructure, 2009)

A atividade de modelagem enfatiza a sequência e as condições de
coordenação de comportamentos de níveis inferiores, a características de
modelagem dos processos de negócio, ou o desenvolvimento de algoritmo pode e
deve ser caracterizados e modelos através de diagramas de atividades.
No entanto, com o advento da UML2 agora é possível realizar a execução
simultânea de objetos de forma estrutural ou comportamental, no nosso caso é
necessário modelar o problema de forma comportamental pra depois executar o
processo de forma automática.
A Figura 13 representa a estrutura completa de classes e associações
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 características de uma Behavior, a Activity é
composta de um Activity Node a mesma generaliza suas ações com uma Action e
herda suas características de um NamedElement, conforme ilustrado na Figura 16.

3.7 – Linguagem textual para modelagem avançada: OCL2
A presente seção apresenta uma introdução ao Object Constraint Language
(OCL) segundo (Dresden, 2013, link: http://dresden-ocl.sourceforge.net) e suas
principais características, conceitos e padrões relacionados à mesma. Esses
conceitos são de grande importância para um bom entendimento por parte de
leitores que não estejam familiarizados com a linguagem de restrição 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 expressões e restrições 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 especificação aceita pela OMG é a OCL 2.0 (OCL, 2006,
p. 34-50).
Os diagramas UML não fornecem todos os aspectos relevantes para a
especificação de um sistema orientado a objetos. Verifica-se, entre outras coisas, a
necessidade de se descrever restrições adicionais sobre os objetos nos modelos. A
falta dessas restrições pode levar a interpretações ambíguas de um mesmo modelo
(OCL, 2006, p. 45-89).
A OCL foi desenvolvida para ser uma linguagem formal, mas que fosse fácil de
ler e escrever. Ela foi desenvolvida inicialmente como uma linguagem de
modelagem de negócios dentro da International Business Machines (IBM)

5

.

Algumas das características da OCL são: não possui efeitos colaterais, é tipada, tem
avaliação instantânea, não é uma linguagem de programação, possui sintaxe e
semântica 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
aplicação com uma maior qualidade.
A Figura 15 ilustra uma invariante OCL para realizar uma restrição no contexto
Vôo onde o número de passageiros não pode ser maior do que o número de
assentos do Vôo.

5

Empresa estadunidense voltada para a área de informática.

40

Figura [15]: Modelagem UML do Sistema de controle de Vôo
Fonte: Slides Plano da Disciplina de Tópicos avançados em MDE

3.8 – Abordagens para linguagens de modelagem avançada
Nesta seção serão 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 extensão do meta-modelo UML2, pois a mesma é adotada através da biblioteca
UML2DJ.

3.8.1 – Linguagens específicas de Domínio (DSL)
Segundo Martin Fowler uma Domain Specific Language (DSL) é uma
linguagem de programação limitada para computador com um conjunto de
elementos e expressividade focada em um domínio específico bem determinado. A
maioria das linguagens são de GPL (General Purpose Languages), que pode lidar
com qualquer tipo de informação e estrutura que se encontra durante um projeto de
desenvolvimento de software. Cada DSL só pode tratar de um aspecto específico de
um sistema.

3.8.2 – Extensão de meta-modelo UML2
Para

(WOODY,2002,

p.

56-98)

a

característica

de

representar

o

conhecimento de forma abstrata se chama modelar, o que especifica as estruturas e
características de um modelo já existente e definem sua qualidade se chama metamodelagem, sua característica de especializar a si próprio se chama meta-meta-

41
modelagem, isto acontece, pois o sentido de abstração e representação do
conhecimento está em tudo que fazemos atualmente, quando precisamos explicar
determinada situação para as pessoas de forma gráfica, fica mais fácil de entender.
Eles são bastante confundidos com Ontologias mais de diferem no uso de sua
gramática e vocabulário mais específico.

3.8.3 – Definição de Perfil UML2
Um Perfil contém vários 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 domínios podem ser
alterados em tempo real ou através da modelagem de processo de negócio. Este
mecanismo é consistente e segue o modelo da OMG e reusa MOF.

3.8.4 – Definição de um PIM OO framework in UML2
Nesta visão a modelagem do PIM OO Framework in UML2 tem como
característica principal não ser um meta-modelo, nem um profile, e sim um modelo
independente que representa as visões básicas e objetivas de um determinado
domínio, sua principal características é a simplicidade da modelagem e execução,
partindo do princípio que o analista não precisa ter conhecimentos anteriores para
poder modelar nesta visão, o mesmo poderá implementar as características
especificas diretamente utilizando somente UML2.

3.8.5 – Modelagem Multi-Level
A Modelagem Multi-Level é um novo conceito aplicado a distribuir as visões
de organização de um modelo através da perspectiva de visões linguísticas e
ontológicas aplicadas a modelagem dos objetos, nesta visão existe uma nova figura
intitulada ClaObject cuja função é definir as características em comum de Classe e
Objetos ao mesmo tempo sendo aplicadas em uma nova perspectiva de
representação deste modelos.

42
No próximo capítulo serão discutidas e apresentados os detalhes sobre o
estudo de caso do projeto Retriever, seus requisitos funcionais e não funcionais,
modelos de arquitetura, designer de interface e alguns detalhes de sua arquitetura
com diagramas da UML.

3.9 – Considerações finais deste capítulo
Neste capítulo buscou-se apresentar uma fundamentação teórica mais
detalhada sobre o MDA e os conceitos de transformação baseado em MOF e CMOF
e outras abordagens características da engenharia de software baseada em
componentes, já no próximo capítulo será apresentado informações sobre a
ferramenta PyMDAGenerator suas etapas e elementos de transformação da parte
de requisitos até a aplicação propriamente dita.

43

4. A FERRAMENTA PYMDAGENERATOR: "A ABORDAGEM
PROPOSTA DA ORQUESTRAÇÃO DE COMPONENTES"

Este capítulo tem como objetivo principal descrever o processo de
orquestração entre os componentes reutilizáveis de software, e propor uma
abordagem prática e extensível para definição de transformações unidirecionais
entre modelos (PIM para PSM e PSM para código), que permita à sua utilização
através de um parser XMI, junto com uma biblioteca intitulada UML2DJ e um
conjunto de tratadores implementados em Shell Script para executar o processo de
transformação e geração semi-automática de aplicações baseada em MDA, sendo
realizado

de

maneira

assistida

através

de

uma

ferramenta

chamada

PyMDAGenerator, utilizando a linguagem Python e o framework Django.

4.1 – Definição da Ferramenta
No Capítulo 3, foram apresentados os principais conceitos sobre Arquitetura
Orientada por Modelos (MDA) e o impacto de sua utilização no desenvolvimento de
software. Além disso, foram descritos diversos tipos de transformação possíveis e
uma categorização das abordagens que utilizam o framework MDA, suas principais
características e deficiências.
A figura 16 representa um diagrama da arquitetura da orquestração 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 código fonte da aplicação.

44

Figura [16]- Diagrama que representa a Orquestração de componentes
Fonte: Próprio autor.

A orquestração é composta por ações relacionadas a parte de requisitos,
conforme a figura 16, depois de elencados e descritos os requisitos funcionais e não
funcionais, os mesmos são transformados em artefatos da UML juntamente com a
linguagem OCL, sendo considerados no momento, modelos característicos do
domínio do problema através dos diagramas de classe, diagrama de componentes,
diagrama de casos de uso e instalação, juntamente com as ações relacionadas.
Para a execução das instruções na caixa (Shell Script UML2DJ) são escritos
arquivos na linguagem Shell Script para gerar a importação do Arquivo XMI para a
plataforma Python Django através da biblioteca UML2DJ, produzindo a criação 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 domínio da
aplicação, ficando agora responsável pela geração do modelo de dados baseado no
modelo UML e por fim a geração automática do código fonte da aplicação em
Python pelo framework Django.
Neste capítulo, apresentamos uma abordagem prática para a definição e
execução de transformações, levando em consideração os critérios estabelecidos no
Capítulo 3, que são: (a) independência de ferramenta CASE ou ambiente de
desenvolvimento; (b) utilização de formatos e linguagens padronizados ou de fácil
aprendizado; (c) apoio à definição e execução de transformações modelo-modelo;

45
(d) apoio à obtenção da implementação através da geração de código
(transformações modelo-texto); (e) possibilidade de extensão das transformações
pré-definidas; (f) orquestração de componentes reutilizáveis de software baseado
em MDA.
A abordagem proposta neste capítulo abrange os cenários de transformação
do tipo modelo-modelo e as transformações. As próximas seções detalham esta
abordagem e estão organizadas da seguinte forma: a Seção 4.2 apresenta uma
visão geral da abordagem e suas principais características; a Seção 4.3 descreve
como são definidas as transformações entre modelos; a Seção 4.4 apresenta as
técnicas de programação utilizadas em Shell script para realizar as transformações
de PIM para PSM e PSM para Código; a Seção 4.5 encerra o capítulo, apresentando
algumas considerações finais.
4.2 - Visão geral da abordagem proposta
Uma visão geral da abordagem proposta é exibida na Figura 17. A
abordagem foi concebida para permitir a definição de transformações de forma
independente de ferramenta CASE – parte (a). O Projetista pode definir
transformações sobre modelos UML. Essa definição de transformações será
detalhada na Seção 4.3. Após elaborar os modelos na sua ferramenta CASE – parte
(b), o Engenheiro de Software pode aplicar as transformações previamente definidas
através de uma máquina de transformações – parte (c) – e gerar a implementação
dos modelos na plataforma desejada. Para executar transformações sobre modelos,
pode ser necessária a preparação prévia do modelo a ser transformado, através de
marcações. Essa marcação e a execução das transformações serão detalhada na
Seção 4.4. Na Seção 4.5 são apresentadas rotinas em Shell Script que visam
automatizar o processo de transformação e por fim será exibida as considerações
finais sobre este capítulo.
Algumas características gerais da abordagem foram definidas com base nos
critérios definidos nos capítulos 2 e 3 e serão apresentadas nas próximas seções.

46
A Figura 17 descreve as ações de especificação do sistema de informação
baseado nos requisitos do projeto, depois o processo de modelagem utilizando uma
ferramenta, no próximo passo descreve marcação e execução das transformações e
por último a geração da aplicação baseada no modelo descrito anteriormente em
uma plataforma alvo específica.
4.3 Apoio à definição de transformações
Conforme foi apresentado no capítulo anterior, uma transformação pode ser
definida como um processo que realiza a conversão de um modelo em um outro
modelo do mesmo sistema (OMG, 2003b). Estas transformações seguem uma
sequência 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
transformação de Modelo Entidade Relacionamento para o modelo Lógico e do
lógico para o modelo Físico, exemplo: Linguagem DDL e vice-versa.
4.3.1 - Exemplo do Meta Modelo da Biblioteca UML2DJ
O UML2DJ é uma biblioteca de componentes responsável pela transformação
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 próxima seção será detalhado a estrutura do Meta Modelo do componente
UML2DJ. Para realizar esta modelagem foi necessário entender o funcionamento
interno do componente como também suas principais características de execução,
este meta modelo é considerado uma grande contribuição para este trabalho, pois a
partir dele será possível 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 execução em projetos previamente definidos.

47

Figura [17] Figura que representa a arquitetura do Meta Modelo do componente UML2DJ
Fonte: Próprio autor

O diagrama que representa o meta modelo da Figura 17 é distribuído em vários
componentes, entre os quais é possível mencionar em detalhes as seguintes
classes detalhadas na especificação da Figura 18.

48

Figura [18] Detalhes do Meta Modelo componente UML2DJ.
Fonte: Próprio autor.

Conforme a Figura 18 que relata as ações em detalhe do Meta Modelo é possível
realizar as ações, a meta modelagem foi feita colocando os componentes com o
nome em Inglês, haja vista que o mesmo poderá ser reusado em outros projetos.
O referido diagrama possui características tais como: A "Class" é uma meta classe
da UML2DJ que herda as características de "Models.Model" uma classe abstrata
que define das características de transformação entre os modelos, da mesma forma
ela faz uma herança múltipla com Meta classe "Type".
Seguindo o modelo a classe "Property" possui uma associação do tipo composição
com a Classe "Class" descrevendo que a mesma pode ter nenhuma ou várias
property e que uma property pode está associado a nenhuma ou uma classe.
A mesma "Property" realiza uma herança múltipla entre as classes "TypeElement" e
"MultiplicityElement". Partindo deste princípio uma classe do tipo "Package" está
herdando as características do "NamedElement".

49
Tais ações são necessárias para realizar as transformações 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 - Visão Direita
Fonte: Próprio autor.

De acordo com a Figura 19, a classe "Db_Table" herda as características da classe
"Models.Model" baseadas no processo de especificação tem como característica
fundamental e geração e associação 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
composição com a meta classe "Type".
Um "Package" possui um auto-relacionamento com si próprio para garantir o reuso
dos componentes baseado em pastas e estrutura de árvores.

50

Figura [20] Detalhes do Meta Modelo UML2DJ - Visão Tipos de Atributos, Operações
Fonte: Próprio autor

De acordo com a Figura 20, a classe "AttributeType" herda está associada com a
classe "Db_table" nela é possível identificar as características das tabelas e
consequentemente as características definidas pelos atributos TextFiel, CharField,
DataField, FloatField, IntegerField, etc são os tipos de atributos definidos.
A mesma classe "AttributeType" está associada a classe "Operation" que descreve
as operações realizadas a uma classe ou a atributos de classe, da mesma forma a
classe "Operation" está associada com a Classe "Type" da UML. Outra associação
identificada é a composição existente entre as classes "Parameter" com a classe
"Operation". A mesma classe "Parameter" possui uma herança múltipla com as
classes "TypedElement" e "MultiplicityElement".

51

Figura [21] Detalhes do Meta Modelo UML2DJ - Associação
Fonte: Próprio autor

Para finalizar a explicação sobre o meta modelo são representadas através de uma
associação entre a classe "Association" com as Classes "Class" e "AttributeType".
Além disso, a classe "Class" está associada entre uma composição com a classe
"Operation", estas características estão 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
convenções, regras e padrões para a implementação de sistemas para web, visando
a reutilização dos componentes do Django (SUN, 2003, p. 34-50). o Django possui
características especiais e é considerado um super framework, internamente existe
um módulo de autenticação de usuários e perfis, um mecanismo de ORM
mapeamento objeto relacional de persistência de dados, um template de interface
gráfica predefinido, um mecanismo de URL Dispatcher.

52

Figura [22] Figura que representa o esquema de ligação dos componentes do Django
Fonte: Próprio autor

A Figura 22 representa o modelo de classe abstrata implementada no Django
é conhecida como models.Model, são componentes localizados internamente no
Framework e encapsulam a lógica de negócio da aplicação. A utilização do
models.Model possibilita o desenvolvimento de aplicações escaláveis, pois sua
execução pode estar distribuída por diferentes aplicações de forma transparente.
Ligado ao models existe um componente ORM responsável pela geração das
tabelas e integração das informações via SQL, alinhado a este conceito existe uma
URL Dispatcher responsável por gerenciar toda s as URL aplicadas ao projeto, outro
recurso importante é o seu Template SET, o Django possui um módulo
administrativo com um template pré-definido podendo ser aplicado a todos os
projetos existentes em uma máquina, estas características podem ser vistas neste
modelo que representa os componentes da arquitetura.
Nesta parte do trabalho será apresentado o modelo de arquitetura através do
diagrama UML de Instalação conforme Figura 23.

53

Figura [23] - Diagrama de instalação
Fonte: Próprio autor

A Figura 23 ilustra o diagrama de instalação o mesmo tem característica de
instalação dos componentes externos, existe um módulo de controle de usuários,
perfil e senhas, este componente faz parte do framework do django, além disso,
existe um outro módulo serviços diversos onde ficam localizadas as informações
referentes ao models. Model chamado de equipamento e tipo de equipamento estes
arquivos tem como características básica os aspectos de negócio da aplicação, já
um outro módulo administração fica responsável pelas classes entidade e sensor
ambas possuem ligação ao modelo de negócio também e ficam responsáveis pela
redistribuição das classes do domínio desta aplicação.
O Diagrama de componentes da UML pode representar de forma mais
específica os componentes internos do Django, servindo de base para o nosso PSM,
a descrição dos principais componentes serão apresentados na próxima página:

54
Estes componentes são:

__init__.py: Um arquivo vazio que diz ao Python que esse diretório deve ser
considerado como um pacote Python. (Funciona como um arquivo principal
do projeto, idealizado para descrever a origem e inicialização do projeto).

manage.py: Um utilitário de linha de comando que permite interagir com esse
projeto Django de várias maneiras. É possível ler todos os detalhes sobre o
manage.py em 7http://www.djangobrasil.org, existem diversos comandos de
execução de servidor, criação da instância dos objetos da classe, validação
dos arquivos do modelo e configuração do ambiente como um todo, entre
outras opções, maiores informações estão disponíveis em django-admin.py e
manage.py.

settings.py: Configurações para este projeto Django. Através deste arquivo é
possível definir todas as configurações do projeto em geral, tais como:
configuração de banco de dados, timezone, estruturas e modelos de
configuração.

urls.py: As declarações 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: Próprio autor

Na Figura 24 é descrito o Módulo Administrador, que possui arquivos tais
como admin.py responsável pela identificação da sequência dos arquivos criados no
models.Model como também os módulos de arquivos relacionados à área restrita da
aplicação, o arquivo models.py possui todas as características e classes gerados
sobre a regra de negócio da aplicação e do controle do domínio da mesma, tais
características são identificadas pelo conjunto de classes que fazem parte da regra
de domínio da aplicação, já os arquivos tests.py fica responsável por executar os
testes unitários da aplicação através de test.case e test.suite, enquanto que ao
arquivo views.py é responsável pela representação dos dados do projeto
relacionado a interface gráfica da aplicação como um todo, caso não seja
implementada irá definir as características básicas desta aplicação através do
template set.

56
4.4 - Etapas de Transformação entre os modelos biblioteca UML2DJ
Para realizar este procedimento foi utilizada a biblioteca UML2DJ6 necessário
descrever esta ação em partes individualizadas chamadas de etapas, a primeira
chamada de CIM, depois o PIM e por último a construção do PSM.
4.4.1 Construção do CIM (Modulo Independente de Computação)
Esta etapa consiste na identificação das regras de negócio baseadas no
domínio da aplicação, para este caso o Sistema de Gestão de Inventários
Hospitalares "Retriever". Após a coleta dos dados através de requisitos funcionais e
não funcionais, foi necessário transcrever tais características para modelos, no
próximo capítulo 5, serão descritos os requisitos funcionais e não funcionais do
projeto, como também alguns diagramas UML relatados aqui e que fazem parte da
descrição de arquitetura do sistema de informação.
4.4.2 A Construção do PIM (modulo independente de plataforma)
Para elaboração do Diagrama de classes foi preciso resgatar as informações
do modelo CIM (Modelo Independente Computacional) através dos requisitos
funcionais e não funcionais, depois foi feita a modelagem funcional e estrutural do
Projeto "Retriever", o mesmo foi realizado de forma prática através da UML pelo
diagrama de classes, é importante resaltar que neste momento este artefato tem
como função descrever a meta modelo da aplicação. Detalhes da modelagem e das
classes existentes no sistema são detalhadas na figura 25.

6

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: Próprio autor

A Figura 25 apresenta o diagrama de domínio / modelo conceitual de classe
descreve de forma simples e objetiva as principais classes do modelo como também
suas multiplicidades e associações, modelagem com as características estruturais
do domínio da aplicação.
Para realizar esta modelagem no diagrama de classe do projeto não foi
necessário atribuir nenhum estereótipo as classes modeladas, isto acontece em
virtude do componente de integração UML2DJ possuir características básicas de
transformação

baseadas

no

MOF

que

independem dos

mecanismos

de

transformação e seguem o modelo UML2 padrão. Diante desta característica fica
mais simples e rápido realizar as transformações empregadas neste estudo de caso.
Após concluir este processo, o próximo passo consiste em exportar o
diagrama de classe modelado para um arquivo com a extensão XMI, este passo
corresponde ao formato de extensão mais conhecido para realizar o parsing entre as
plataformas.

58
A exportação é feita através da ferramenta ARGOUML conforme Figura 26,
nela é possível identificar as características do modelo criado baseado em XMI.

Figura [26] - Arquivo no formato XMI - Representação do Domínio do Sistema
Fonte: Próprio autor

Através deste formato XMI é possível identificar os nomes das classes tais
como Evento, o nível de visibilidade, neste caso "public", os atributos existentes
como códigos, seus níveis de visibilidade, como também as associações e
multiplicidades aplicadas ao modelo de domínio em questão, tais características são
de fundamental importância para realizar as transformações, neste caso, são
cruciais para o sucesso do projeto, isto acontece porque as ferramentas de geração
de código 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 através do script em Shell chamado geradorMDAPIM.sh
este arquivo irá ler o XMI e realizar as referidas transformações.
4.4.3 Aplicando transformações da biblioteca UML2DJ, Modelo PSM
Para realizar as transformações através da biblioteca UML2DJ, primeiro é
necessário configurar o ambiente, para que isto aconteça é necessário instalar o
Python + Django e depois acrescentar a biblioteca libxml2, a mesma precisa estar
instalada no ambiente do projeto, este procedimento encontra-se no apêndice 4
desta dissertação de mestrado, na figura 27 detalha este processo e etapas.

Figura [27] - Detalhe do processo de transformação entre PSM to Código Fonte.
Fonte: Próprio autor

Esta figura 27 representa o procedimento de transformação de PSM para
código, o procedimento consiste na execução do arquivo geradorMDAPSM.sh que
na sequência irá inicializar os componentes do Django URL Dispacher para construir
as URL da aplicação, Template System para construir as view, o mecanismo de
ORM chamado SqlDB que é responsável por transformar as classes em estruturas
do banco de dados e o Administrator System responsável por criar o módulo de
autenticação do sistema com login, senha e administração dos papéis e usuários do
sistema, estes componentes integrados realizam as transformações e geram o
código fonte.

60

Figura [28]- Arquivo com os comandos em Shell script - geradorMDAPIM.sh
Fonte: Próprio autor.

A figura 28 representa o arquivo que é chamado geradorMDAPIM.sh este é
responsável por executar as ações relacionadas à transformação do Modelo UML
arquivo que foi feito pela ferramenta ArgoUML. Sua execução é simples e direta e
representa um conjunto com arquivos feitos na linguagem Shell Script. Na próxima
tabela será exibida a lista com os comandos e a descrição de sua execução no
formato de passo a passo, esta informação encontra-se no apêndice V.

61
4.4.4 Continuando com as transformações, modelo execução PSM
Neste ponto é possível verificar que algumas ações já foram realizadas,
visando consolidar as transformações foi criado um outro arquivo chamado
gerarMDAPSM.sh. Este aplicativo é responsável pela continuação da execução dos
projetos e das ações de orquestração.
Através do gerenciador ORM chamado SQLDB que o django possui é
possível descrever também a sintaxe dos comandos representados através da
modelagem UML (Diagrama de Classes) com o modelo de banco de dados,
descrito na DDL (Data Defination Language) conforme apêndice III, maiores
detalhes serão apresentados no referido apêndice III desta dissertação.
Nesta sequencia de comandos é possível ver como é feita a transformação
entre o modelo conceitual de classes no modelo físico do banco de dados, isto
acontece de forma automática através do comando python manage.py syncdb.
A Figura 29 descreve a execução em shell script dos principais comandos de
execução da transformação do PSM para o código fonte.

62

Figura [29] - Arquivo em shell script execução do PSM - geradorMDAPSM.sh
Fonte: Próprio autor

O segundo arquivo chamado geradorMDAPSM.sh é responsável pela
continuidade das ações do arquivo anterior, consolidando as transformações e
gerando o código fonte necessário para poder executar a aplicação e o sistema em
si. Na próxima tabela será exibida a lista com os comandos e sua execução, sua
execução encontra-se em detalhes no Apêndice V.
Como foi visto nas etapas anteriores de criação do CIM, modelagem do PIM,
transformação do PIM para PSM e geração para código, os arquivos executados
descrevem as etapas da transformação e fazem parte da orquestração. O arquivo do
projeto criado pode ser executado através da URL: http://localhost:3000. No
momento da criação do projeto foi solicitado a implantação de um usuário para

63
administrar o sistema, este tem a responsabilidade de administrar a orquestração e
os módulos criados na aplicação do sistema.
Na próxima seção será apresentado um resumo do capítulo com
considerações finais sobre o mesmo e uma pequena apresentação do próximo
capítulo desta dissertação.

4.5 - Considerações Finais deste capítulo
Neste capítulo, buscou-se apresentar os procedimentos necessários de
orquestração

entre

os

componentes

que

deram

origem

à

ferramenta

pyMDAGenerator, sendo apresentado primeiro, através do modelo CIM, depois, pela
criação do PIM e logo em seguida pelo PSM, por último, foi efetivada a geração do
código. Durante estas ações é importante resaltar o valor das ações e os passos
necessários para realizar as transformações entre os modelos, nesta plataforma é
importante integrar as ações e os scripts, dando ênfase ao modelo do framework.
Esta pesquisa se propõe a realizar uma orquestração entre os componentes
na plataforma para ser utilizado com a linguagem Python e o framework Django, na
construção rápida de sistemas de informação para web.
No próximo capítulo serão apresentados o estudo de casos deste trabalho,
como também informações detalhadas sobre o Sistema "Retriever" e "Asset
Inventory", que vêm a ser um dos temas centrais desta pesquisa.

64

5 – EXEMPLO: SISTEMA "RETRIEVER" E O SISTEMA DE GESTÃO
PATRIMONIAL "ASSET INVENTORY"
O objetivo deste capítulo é apresentar alguns conceitos relacionados ao
Sistema de Gestão de Inventários Hospitalares "Retriever", com suas características
internas de arquitetura e modelos de componentes, requisitos funcionais e não
funcionais, interfaces das aplicação e demais funções dos sistema. Além disso,
serão abordadas a categorização 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 através da Fábrica de Software 7Gofactory

e no final das

atividades das disciplinas desenvolvemos também um novo software da própria
Gofactory para gestão de inventários patrimoniais chamado "Asset Inventory", o
mesmo será apresentado também neste capítulo.
5.1 Definição do problema
Um dos grandes desafios dos gestores de hospitais e clínicas médicas é
manter o controle sobre seus ativos hospitalares, tais como: equipamentos, material
hospitalar, medicamentos, banco de sangue, roupas de cama, vestuários e utensílio.
Para solucionar o problema, tornou-se necessário criar um sistema de informação
que permita rastrear e identificar a localização em tempo real dos itens do hospital.
Devendo também manter um registro das movimentações no ambiente hospitalar.

7

GoFactory - Fábrica de Software do Mestrado Profissional Cesar.edu.br "http://www.gofactory.com.br"

65
5.1.1 O impacto
A ausência de controle desses ativos tem influencia direta nos custos das
organizações médicas, no desperdício de material e no mau uso do patrimônio
hospitalar. Como consequência, essas ações têm contribuído para aumentar os
prejuízos como roubo e furto de itens existentes no hospital, alavancando assim,
enorme prejuízo para a organização.
O processo de gerenciamento de equipamentos ativos dentro de hospitais é
algo bastante complexo e envolve risco, inclusive de vida ou contágio, no que se
refere a infecções por exemplo.
5.1.2 A solução
Foi criado um sistema de informação destinado a auxiliar o processo de
gerenciamento hospitalar cujo objetivo é informar a localização em tempo real de
equipamentos e medicamentos obedecendo a alguns preceitos no que se refere a
um sistema de informação. Além disso, os hospitais podem utilizar e dispor, de
forma mais eficiente, os equipamentos que possuem, reduzindo as despesas
referentes à reposição e ao transporte dos equipamentos. A combinação dessas
atribuições elimina problemas frequentemente observados dentro de hospitais, tendo
como consequências, melhores serviços oferecidos aos pacientes, agregando a
esses serviços, níveis de custos aceitáveis e competitivos para o negócio ao qual se
propõe.
5.2 Stakeholders, Requisitos Funcionais e Não funcionais
Nesta parte do trabalho serão apresentados algumas informações sobre os
Stakeholders do projeto e a lista de requisitos funcionais e não funcionais do projeto,
estas ações são importante para definir tanto as características funcionais
relacionadas a execução das atividades no projeto "Retriever" como também as
características de usabilidade, performance, segurança, etc. Identificadas através
dos requisitos não funcionais deste projeto.

66
5.2.1 Stakeholders
Na engenharia de requisitos, os stakeholders são definidos como pessoas
ou organizações que serão afetadas pelo sistema e que direta ou indiretamente
tem influência 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 clínico: Colaboradores que estão responsáveis
pelo Item e blocos do Prédio.

Segurança: Equipe de Vigilância.

Gestor: Gerente Administrativo do Hospital.

Administrador: Super usuário do Sistema.

5.2.2. Atores
1. Administrador
2. Enfermagem
3. Gestor
4. Engenheiro Clínico
5. Segurança
6. Sensor

67
5.2.3 Requisitos (funcionais e não funcionais)
Os requisitos definem os serviços que o sistema deverá oferecer, o conjunto
deles determina a operação do sistema. São divididos em Requisitos Funcionais e
Não Funcionais.
Os requisitos funcionais referem-se aos pressupostos que estão relacionados
com a forma com que o sistema deve operar, onde se especificam as entradas e
saídas do sistema e o relacionamento comportamental entre elas, assim como a
interação com o usuário.
Desta forma, os requisitos funcionais identificados são:
REF.

ATORES

REQUISITO

RF01

Todos

Autenticar usuários

RF02

Todos

Listar itens de material por setor

RF03

Ges

Gerenciar relatórios de equipamentos por ritmos in ambiente

RF04

Ges

Gerenciar usuários

RF05

Ges

Gerar relatório 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 prédios/blocos

RF12

Eng

Listar itens na tela de início

RF13

Eng

Gerenciar equipamento

68
REF.

ATORES

REQUISITO

RF14

Eng

Gerenciar áreas

RF15

Eng

Gerenciar andares

RF16

Eng

Gerenciar movimentações

RF17

Eng

Gerenciar identificadores

RF18

Eng

Gerenciar sensores

RF19

Sensor / Seg

Alertar movimentação indevida

RF20

Sensor / Seg

Receber alerta de segurança

Tabela [1]: Requisitos Funcionais
Fonte: Próprio Autor

5.2.4 Definição dos Requisitos Não Funcionais
REFERÊNCIA

REQUISITO NÃO FUNCIONAL

RNF01

O sistema deve permitir múltiplos usuários.

RNF02

O sistema deve ter uma disponibilidade de 99,50 % dos casos.

RNF03

As informações de login/senha dos usuários do sistema devem ser
protegidas através de conexões seguras (HTTPS).

RNF04

Deve ser utilizado o GIT como repositório para o código-fonte.

RNF05

O Sistema deve garantir o acesso simultâneo de mais de 1000
usuários, durante 01 minuto.

69
REFERÊNCIA

RNF06

REQUISITO NÃO FUNCIONAL
Os testes funcionais, carga e unitários devem ser feitos de forma
semi ou automática, baseada nas ferramentas Selenium, Jmeter e
Junit.

RNF07

Para as consultas e relatórios o tempo de resposta não 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 usuários cadastrados no sistema devem ser
criptografadas baseadas no Hash MD5.

RNF10

O sistema deve está adaptado para o padrão internacional (Inglês,
Português e Espanhol).

Tabela [2]: Requisitos Não-Funcionais
Fonte: Próprio Autor

5.2.5. Escopo negativo
O escopo Negativo do Projeto "Retriever" está relacionado a não evolução do
módulo de tratamento de eventos (Middleware). O trabalho de pesquisa e
desenvolvimento do Middleware não será implementado agora, em virtude do
escopo prioritário que é a construção do módulo WEB. Isto pode ser constatado
através do plano de cálculo de esforço e pontos e quebra sistemática, contidos na
documentação do sistema no apêndice desta Dissertação.

70

5.3 Modelos de Artefatos e documentos do projeto
Nesta seção serão 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 lógico, estas
características são importantes para descrever os aspectos arquiteturais do projeto e
suas principais características.
5.3.1 - Diagrama de casos de uso

Figura [30] - Diagrama de casos de uso "Retriever"
Fonte: Próprio Autor

O diagrama de casos de uso, conforme Figura 30 do projeto "Retriever" é
responsável por descrever os aspectos funcionais do sistema e suas interações

71
entre os atores, suas associações, generalizações, e características de dependência
do tipo: extends e includes. É importante salientar o papel dos atores Gestor,
Engenharia Clínica e Administrador, pois os mesmos são os mais importantes e
interagem com as principais funcionalidades da aplicação. Nele é possível identificar
os principais requisitos funcionais identificado neste projeto como: Gerenciar
Identificadores, Gerenciar Movimentações, Receber Alerta de Segurança, entre
outros.
5.3.2 - Diagrama de Classe
O Diagrama estrutural da UML - o diagrama de classes possibilita a
verificação da estrutura dos dados existentes no domínio do problema, tornando
possível

identificar

suas

principais

classes,

associações,

multiplicidades,

agregações, composições e estruturas de generalização, herança ou composição.
Estes dados são apresentados na Figura 31.

Figura [31] - Diagrama de classes - "Retriever"
Fonte: Próprio Autor.

72
É importante ressaltar que o domínio do problema é o sistema de gestão de
inventários hospitalares, o domínio da solução visa gerenciar as informações
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 representação do registro.
De posse dessa informação fica mais fácil estabelecer a solução utilizando os
conceitos de análise e projeto de sistemas, pois com o reuso de software é possível
melhorar e adaptar as soluções aplicadas ao domínio de gestão ao sistema de
gestão de inventários, este é um dos principais diagramas deste projeto pois tem
como características básicas a representação da estrutura das classes seus
principais atributos e alguns métodos referenciados no projeto em análise.
5.3.3 - Diagrama de Componentes
Este diagrama tem como objetivo descrever as características 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. Através deste modelo é possível realizar as
operações interligadas entre as classes reusando componentes e aplicando alguns
padrões de projeto conhecidos tais como Singleton, Facade, DAO etc.
O diagrama de componentes especifica de forma clara as camadas de
negócio, modelo e interface da aplicação, 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 Usuários e Movimentacao implementam
esta interface.
Já na camada Negócio são apresentados componentes de negócio e
interfaces da aplicação, a exemplo da classe AutenticadorBD, Movimentacão e
ValidadorMovimentacaoImpl, estas são classes de regras de negócio da aplicação,
já a camada de interface é caracterizada pelas interfaces gráficas da aplicação e

73
servem de modelo de comunicação também com o Middleware de Integração a
exemplo das classes FrmUsuario, FrmMovimentacao e MiddlewareMovimentacao.

Figura [32] - Diagrama de componentes - Visão Interna (MVC) "Retriever"
Fonte: Próprio Autor

O próximo diagrama de Instalação, apresentado na Figura 33, tem como
característica fundamental a apresentação da visão externa dos componentes de
software, esta visão é importante para descrever as ações relacionadas
principalmente a interoperabilidade e a possibilidade de integração com outros
sistemas externos, haja vista que atualmente já desenvolvemos na nossa Fábrica de
Software o nosso próprio Middleware de integração não dependendo mais das
ações dos outros componentes de Middleware existentes.

74

Figura [33] - Diagrama de Instalação - Visão Externa "Retriever"
Fonte: Próprio Autor

5.4 Interfaces da aplicação e requisitos do sistema "Retriever"
Nesta parte do trabalho é apresentado algumas interfaces da aplicação
"Retriever", desta forma é possível identificar as características visuais relacionadas
ao projeto. Pretendemos assim apresentar algumas interfaces do projeto em
questão.
5.4.1 Tela de Autenticação de Usuários do Sistema "Retriever"
A interface referente a tela de autenticação dos usuários no sistema pode ser
feita através do seu email e uma senha previamente cadastrada no sistema, estes
dados são validados pela aplicação e servem de base para dar acesso ao ambiente
do sistema "Retriever". A figura 34 representa a tela de autenticação.

75

Figura [34] - "Retriever" - Tela de Autenticação de usuários no sistema
Fonte: Próprio Autor

O plugin de interface desta aplicação 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 através do Nome "Retriever"
Sistema de Gerenciamento de Equipamentos Hospitalares, além disso existem os
ícones de Home, Ativos, Unidades, Equipamentos e Usuários no menu principal do
sistema, na parte superior direita da aplicação é possível alterar a unidade e existem
informações sobre o usuário conectado e a opção de logout.
Na Figura 35 é possível identificar o designer da aplicação, seus elementos
de composição, entre eles, o topo com o nome "Retriever", a barra de menus com os
principais menus de opção, o rodapé com informações do sistema e do fornecedor,
entre outras.

76

Figura [35] - (Retriever) - Seleção de Hospital para Administrar
Fonte: Próprio 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 gestão do sistema, através desta tela é possível
incluir, alterar, excluir e listar todos os ativos hospitalares cadastrados no sistema.
Esta informação é importante e serve de base para alimentar aos outros dados
relacionados a movimentação dos ativos, equipamentos, sensores e demais itens do
hospital, tais detalhes e implementações estão sendo visualizados através da Figura
36.

77

Figura [36] - "Retriever" - Tela de cadastro de Ativos Hospitalares
Fonte: Próprio 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 gestão do sistema, através desta tela é
possível incluir, alterar, excluir e listar todas as unidades ou seja hospitais
relacionados ao sistema, para isto é preciso informar o Nome do hospital, Telefone,
Endereço, Cidade e Estado e por último pressionar o botão salvar para gravar as
informações.
Como é possível ver na Figura 37 o cadastro de Unidades, que faz parte do
menu Unidades e corresponde a uma das telas de gestão do sistema, através desta
tela é possível incluir, alterar, excluir e listar todas as unidades dos hospitais
relacionados ao sistema, para isto é preciso informar o Nome do hospital, Telefone,
Endereço, Cidade e Estado e por último pressionar o botão salvar para gravar as
informações.

78

Figura [37] - "Retriever" - Tela de Cadastro de Unidades
Fonte: Próprio Autor

5.4.4 Tela de Usuários do sistema "Retriever".
Na Figura 38, a tela do Cadastro de Usuários faz parte do menu Usuários e
corresponde a uma das telas de gestão do sistema, através desta tela é possível
incluir, alterar, excluir e listar todos os usuários cadastrados nos hospitais, servindo
também para definir as características de Perfil tais como: Administrador do Hospital,
Engenharia Clínica, Enfermeiro, etc.

79

Figura [38] - "Retriever" - Tela de Cadastro de Usuários
Fonte: Próprio Autor

5.4.5 - Considerações finais sobre esta seção
Nesta parte do capítulo foi apresentada algumas telas do sistema de gestão
de Inventários 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 próxima seção serão apresentadas as
interfaces gráficas do projeto "Asset Inventory" um sistema de gestão de inventários
patrimoniais desenvolvidos utilizando a ferramenta PyMDAGenerator.
5.5 - O Sistema de Inventários Patrimoniais "Asset Inventory"
Nesta parte do trabalho é possível apresentar um protótipo funcional da
aplicação feita na plataforma Python + Django, este sistema possui algumas
características bem parecidas com a aplicação anterior, alterando apenas o seu
domínio de negócio que agora é Inventários 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 também as áreas de
movimentação, sensores e tipos de equipamento. Além destas informações é
possível visualizar também as ações recentes realizadas no projeto na parte lateral
direita, na guia Auth é possível gerenciar informações sobre novos usuários do
sistema e grupos de usuários relacionados, este componente faz parte do Django e
já vem implementado de forma automática na aplicação, tais dados são visualizados
na Figura 39.

Figura [39] - Sistema (Asset Inventory) - Tela com o menu principal do sistema
Fonte: Próprio 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 títulos com o nome da aplicação "Asset Inventory" e do lado direito o
nome do usuário logado no sistema, com as opções de alterar senha e Encerrar
sessão, tais informações são melhor visualizadas através da Figura 40.

81
É importante relatar as características básicas dos atributos da entidade
Andar como: Código, Descrição do Andar, Nome e URL da imagem, além disto,
todas as operações de manipulação do andar estão contempladas tais como: incluir,
alterar, excluir e listagem geral dos andares.

Figura [40] - Sistema (Asset Inventory) Tela de Cadastro de Andar
Fonte: Próprio 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 títulos com o nome da aplicação "Asset
Inventory" e do lado direito o nome do usuário, além disso, existem as
características tais como: Código, background, descrição, polígono, restrita e código
do andar. Além do cadastro destas informações são realizadas também
operacionais como listagem geral das áreas, alteração da área e exclusão da
mesma.

82

Figura [41] - Sistema (Asset Inventory) - Tela de cadastro de área
Fonte: Próprio 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 títulos com o nome da aplicação "Asset Inventory" e do lado
direito o nome do usuário, além disso, é possível verificar algumas informações
referentes aos equipamentos tais como: Código do equipamento, descrição do
equipamento, modelo do mesmo, código do patrimônio, número identificador e tipo
de equipamento. Por se tratar de equipamentos patrimoniais é importante salientar
que é possível realizar os ajustes necessários para adaptar posteriormente estes
informações a bens móveis e imóveis relacionados a organização, conforme Figura
42.

83

Figura [42] - Sistema (Asset Inventory) - Tela de Cadastro de Equipamentos
Fonte: Próprio 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 títulos com o nome da aplicação Asset Inventory e do lado
direito o nome do usuário, além disso, é possível verificar algumas informações
referentes aos eventos relacionados a movimentação dos equipamentos, através
desta tela é possível gerenciar informações tais como: código, data e informações
sobre o identificar e sensor instalado no ambiente organizacional, a cada
movimentação dos equipamentos estas informações são repassadas para o
software e o registro de movimentação fica armazenado no sistema, tais informação
encontra-se na Figura 43.

84

Figura [43] - Sistema (Asset Inventory) - Tela de Cadastro de Eventos
Fonte: Próprio Autor

5.6 Considerações Finais desde capítulo
Neste capítulo foi possível conhecer melhor o estudo do caso desta pesquisa,
e a partir dela foi produzido o protótipo em Python + Django "Asset Inventory", bem
como, a necessidade do desenvolvimento deste projeto através da Engenharia de
Reuso de Software. O Engenheiro/Arquiteto de Software precisa destas informações
para melhor se adequar ao propósito desejado.
Com esse intuito, esta pesquisa pretende, conforme já enfatizado, elaborar
uma ferramenta baseada em MDA (Model Driven Architecture), através de um PSM
modelos específico de plataforma que permita ao Engenheiro / Arquiteto e
Desenvolvedor de Software desenvolver com maior velocidade e facilidade as
rotinas contínuas do processo de desenvolvimento de software. Essa ferramenta
deverá ainda ser incorporada a todo s os principais conceitos e princípios da
avaliação inclusos nesta pesquisa.
No próximo capítulo serão discutidos e apresentados os procedimentos
necessários para validação desta pesquisa através de um estudo comparativo entre
o desenvolvimento tradicional feito através 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 capítulo tem como objetivo descrever algumas informações estatísticas
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 estatísticos deste trabalho construímos tabelas
e gráficos visando obter informações quantitativas e qualitativas sobre o estudo de
caso em questão, sendo representados em ambas as plataformas conforme a lista
abaixo:
- Descrição dos dados relacionados ao número de linhas de código;
- Apresentação dos dados relacionados ao número de classes criadas;
- Apresentação dos dados relacionados ao número total de arquivos gerados;
- Quantidade de Artefatos de análise e especificação do projeto gerados;
- Número de dias trabalhados;
- Quantidade de horas de trabalho realizadas no projeto;
- Número de Sprints produzidas durante a execução do desenvolvimento do projeto;
- Tabelas com informações compartilhadas de artefatos, código e demais recursos;
- Criação dos gráficos associados a pesquisa com as informações em destaque;
- Parágrafo final com as considerações finais deste capítulo.

86
6.1 - O projeto "Retriever" na arquitetura Java JEE com o ANDROMDA
Nesta parte do trabalho serão apresentadas informações sobre o andamento
das atividades relacionadas ao projeto original da Fábrica de Software Gofactory,
entre elas é possível identificar informações tais como exibidas na tabela 5:
QUADRO DO PROJETO COM ANDROMDA (JAVA) X PYMDAGENERATOR (PYTHON)
DESCRIÇÃO

JAVA

PYTHON

DIFERENÇA

QUANTIDADE / NÚMERO DE CLASSES CRIADAS

54

38

16,00

QUANTIDADE / NÚMERO 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 / NÚMERO DE SPRINTS PRODUZIDAS

2

2

SOMATÓRIO

229,00

213,00

8,00

16,00

Tabela [3]: Quadro demonstrativo entre o projeto "Retriever" e o "Asset Inventory"
Fonte: Próprio Autor

Conforme apresentado na tabela 5 é possível identificar que na coluna JAVA
(JEE) o número de linhas de código aplicadas ao projeto, sobre o ponto de vista que
as duas linguagens são orientadas a objeto e que o paradigma não garante um
número menor de linhas de código e consequentemente de classes já que a
especificação deve garantir as melhores práticas aplicadas aos projetos, incluíndo o
uso de padrões de projeto do tipo singleton, abstract factory e factory method. Neste
caso o número 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 força a criação de no mínimo 8 classes
para representar o Bean, DAO, Business Controller. Lembrando que para realizar tal
atividade contamos com a participação de 02 Programadores divididos em 04 horas
de trabalho por dia para realizar os procedimentos e o desenvolvimento da solução
como um todo.
Para o número de arquivos gerados o número foi de 90 incluídos os arquivos
de interface da aplicação tais como JSF, XHTML, CSS, JS, XML entre outros

87
necessários para geração da aplicação, na construção da interface da aplicação foi
necessário a construção de Template.
Na fase de análise e especificação do sistema foram gerados diversos
artefatos de análise incluindo documento de requisitos, documento de visão,
diagramas de casos de uso, diagramas de classe, diagrama de componentes entre
outros, totalizando 14 artefatos gerados para o projeto em Java através 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 diário 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 através do RedMine. Durante este período realizamos diversas
reuniões em um conjunto de 02 interações / Sprints totalizando 15 dias de trabalho
para cada Sprint no total.
Quanto ao número de horas trabalhadas foi seguindo o número 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 informações
em meses tivemos menos de 01 mês de trabalho para desenvolver o número de 17
casos de uso apresentados nesta dissertação de Mestrado isto nos garantiu a
completa execução das funcionalidades da aplicação solicitadas pelo nosso cliente:
BeagleTech.
O gráfico 1 ilustra de forma à quantidade de Sprints, horas, dias, artefatos,
classes e demais ações exemplificados neste trabalho, foi observado nesta pesquisa
em questão que todos os números apresentados aqui descrevem uma visão
imparcial que foi aplicada ao desenvolvimento com a ferramenta ANDROMDA
baseado em análise, projeto e implementação de código pilares fortes aplicados da

88
Engenharia de Software, que consiste em uso de técnicas, ferramentas e modelos,
não definindo quais são e sim que existem e podem ser aplicados.

Gráfico [01]: Gráfico com as informações estatísticas do projeto desenvolvido em Java JEE ANDROMDA
Fonte: Próprio Autor

6.2 - Representação dos dados aplicados ao projeto "Asset Inventory"
desenvolvimento na linguagem Python com Django
Nesta parte do trabalho serão apresentadas informações sobre a análise,
projeto e especificação do projeto "Asset Inventory" da Fábrica de Software
Gofactory, entre elas é possível identificar informações tais como exibidas na tabela
6:

QUADRO DO PROJETO COM ANDROMDA (JAVA) X PYMDAGENERATOR (PYTHON)
JAVA

PYTHON

DIFERENÇA

QUANTIDADE / NÚMERO DE CLASSES CRIADAS

DESCRIÇÃO

54

38

16,00

QUANTIDADE / NÚMERO 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 / NÚMERO DE SPRINTS PRODUZIDAS

2
229,00

SOMATÓRIO

2
213,00

Tabela [4]: Quadro demonstrativo dando ênfase ao projeto em Python (Django)
Fonte: Próprio Autor

8,00

16,00

89
Este projeto foi idealizado através da disciplina de Reuso de Software do
Mestrado Profissional do Cesar.edu.br, nos módulos de Reuso Intermediário e
Profissional, como nossa fábrica de software GoFactory tinha que desenvolver um
projeto que envolvesse a parte de transformações entre modelos através com MDD
(Model Driven Development) ou MDA (Model Driven Architecture), foi criada a
ferramenta PYMDAGenerator para proporcionar a transformação, a linguagem
Python e o framework Django foram escolhidos por possuir uma fácil integração
entre o mecanismo de geração de código baseados na classe abstrata
models.Model e no mecanismo de geração ORM SQLdb.
Para este projeto foi aproveitada a estrutura de criação dos objetos do Django
em conjunto com a linguagem Python facilitando assim a aplicação do MVC e na
diminuição do número de linhas de código do projeto, no Django o arquivo
Models.py concentra em um só lugar todas as instruções do modelo de arquitetura
MODEL evitando assim a criação de novas classes e sub-divisões do modelo.
número de classes criadas no projeto foi 38 classes é importante salientar que o
Framework ajuda na estruturação deste projeto diminuindo de forma considerável as
classes reusando inclusive o seu Template.
Neste projeto o número de membros foi reduzido para 02 (01 Engenheiro /
Arquiteto) e (01 Desenvolvedor Python + Django) como papel de modelagem e
diagramação o engenheiro/arquiteto construiu todos os artefatos de análise e
especificação, juntamente com os diagramas da UML acrescentando apenas 02
novos diagramas o diagrama de instalação e o Diagrama de estrutura composta
aplicados ao projeto para classificar os componentes e a ligação entre os modelos
(PIM) para (PSM) e depois para código o número de artefatos de análise em UML foi
16 e a quantidade de arquivos gerados no final de tudo foram 82 arquivos
envolvendo todas as etapas de elaboração, construção, implantação e deploy da
aplicação.

90

Gráfico [2]: Gráfico com os dados estatísticos do projeto em Python + Django
Fonte: Próprio Autor

Por conta desta ação o número 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 construção da ferramenta
e na geração automática do projeto baseado na modelagem UML depois na
exportação do arquivos XMI, na etapa de transformação utilizando a biblioteca
UML2DJ para captura das estruturas do domínio do problema e exportação para os
arquivos admin.py e models.py do projeto, a programação dos Scripts em Shell
ajudam no processo de automação das transformações entre os modelos,
garantindo assim apenas 60 horas de trabalho no projeto e o desenvolvimento em
apenas 02 Sprints de 8 dias cada. Tais informações podem ser conferidas no
Gráfico 2.

91
6.3 - Gráfico comparativo entre os dois processos
Nesta parte do trabalho é apresentado um gráfico comparativo com os
valores identificados na tabela anterior:

Gráfico [3]: Gráfico com as informações unificadas entre o desenvolvimento em Java JEE AndroMDA
x Python Django
Fonte: Próprio Autor

Nesta parte da pesquisa foi possível identificar a diferença existente entre os
modelos apresentados neste gráfico a primeira série barra na horizontal representa
o desenvolvimento através da linguagem Python + Django e o paradigma de reuso
de software baseado em MDA, já a representação da 2ª barra logo em seguida
representa o desenvolvimento utilizando a ferramenta AndroMDA baseado em Java.
No quadro da tabela 03 são aplicadas informações de diferença entre os
percentuais

do

projeto

mencionados

entendimento e suas diferenças.

nesta

pesquisa

facilitando

assim o

92
QUADRO DO PROJETO COM ANDROMDA (JAVA) X PYMDAGENERATOR (PYTHON)
DESCRIÇÃO

JAVA

PYTHON

DIFERENÇA

1002

945

57,00

QUANTIDADE / NÚMERO DE CLASSES CRIADAS

54

38

16,00

QUANTIDADE / NÚMERO TOTAL DE ARQUIVOS GERADOS

90

82

8,00

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 / NÚMERO DE SPRINTS PRODUZIDAS

2

2

-

QUANTIDADE / NÚMERO DE LINHAS DE CÓDIGO

SOMATÓRIO

1231,00

1158,00

16,00

Tabela [5]: Tabela com as informações do projeto ênfase ao Número de Linhas de código
Fonte: Próprio autor

Na coluna percentual do Python observem que o valor representado por
23,58% corresponde ao número de linhas de código aplicado ao projeto se
eliminarmos este critério tanto para o projeto em Python como também o projeto
feito em Java os valores ficam mais próximos entre os critérios de avaliação e
visualização das estatísticas.

Gráfico [4]: Gráfico com as informações estatísticas dos dois projetos, Azul para Python e Laranja
para Java
Fonte: Próprio Autor

93
O gráfico de barras descreve de forma prática à diferença em formato de
porcentagem entre os itens avaliados nesta pesquisa, incluindo também a diferença
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

Gráfico com os Percentuais de Diferença entre o Java e
Python

projeto Python Django.

QUANTIDADE / NÚMERO DE SPRINTS
PRODUZIDAS

0,87%
0,94%

QUANTIDADE DE HORAS DE TRABALHO
REALIZADA

QUANTIDADE DE DIAS TRABALHADOS

24,45%
28,17%
5,68%
7,04%
Java

QUANTIDADE DE ARTEFATOS
PRODUZIDOS (UML)

Python

6,11%
7,51%

QUANTIDADE / NÚMERO TOTAL DE
ARQUIVOS GERADOS

39,30%
38,50%

QUANTIDADE / NÚMERO DE CLASSES
CRIADAS

23,58%
17,84%

0,00% 10,00% 20,00% 30,00% 40,00% 50,00%
Gráfico [5]: Gráfico variação dos percentuais entre os projetos (Java JEE x Python Django)
Fonte: Próprio Autor

Com base neste gráfico ficou claro que o desenvolvimento baseado em
componentes

com

o

Python

e

Django

mantém

uma

singularidade

e

consequentemente baixa oscilação entre os critérios avaliados nesta pesquisa já o
desenvolvimento com o Framework AndroMDA com Java JEE variam um pouco
principalmente nos critério de Número de Arquivos Gerados de 38,50% para 39,30%
a diferença foi 0,80% e Quantidade de Horas de Trabalho realizada de 28,17% para
24,45% sua diferença foi de 3,71%.

94
Outro ponto importante desta pesquisa é o número de dias trabalhados neste
projeto, levando em consideração que o primeiro projeto durou 13 dias com a
ferramenta AndroMDA foi mais rápido e o último 15 dias de trabalho com a
ferramenta PyMDAGenerator já é possível ver que com o reuso do software e o uso
da engenharia de software baseada em componentes podemos reaproveitar
inúmeros artefatos produzidos e acelerar de forma drástica a geração dos código em
plataformas totalmente distintas.
6.4 Considerações Finais sobre este capítulo
Este capítulo representou em números diversas ações realizadas em ambos
os projetos, retratando dados estatísticos sobre o projeto feito em Java e o mesmo
projeto desenvolvimento em Python através do reuso de software e da Arquitetura
Dirigida a Modelos, um dos frutos do projeto foi a construção da ferramenta
PYMDAGenerator responsável pela geração automática de código baseado em
Python junto com o Framework Django, maiores informações sobre o projeto e a
própria

ferramenta

podem

ser

https://sites.google.com/site/pymdagenerator2014/

Figura [44]: Página do projeto PyMDAGenerator
Fonte: Próprio Autor

vistos

no

site:

95
Como foi possível identificar, os ganhos representados em números 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 também a questão da manutenabilidade,
alterações nas visões sobre consultas e relatórios personalizados que de certa
forma não foram tratados neste trabalho.
Na Figura 44 é apresentado o site onde é possível baixa uma versão demo da
ferramenta, junto com os componentes aplicados ao projeto, incluindo um passo a
passo para geração de uma aplicação exemplo, outro ponto consiste na parte de
serviços que podem ser feito baseados na engenharia de reuso de software com
MDA e MDD, como também o telefone, email de contato do responsável pela
criação da ferramenta, documentos do projeto e tutoriais.
No próximo capítulo será apresentada as considerações finais sobre este
trabalho incluindo os pontos positivos e negativos, como também os trabalhos
futuros desta dissertação de mestrado.

96

7. CONSIDERAÇÕES FINAIS
7.1 - Epílogo
O padrão de engenharia de software baseado em modelos da MDA (Model
Driven Architecture) tem como proposta a construção sistemática baseada em
exemplos estruturais e comportamentais da UML, isto acontece de forma natural
durante a transferência dos aspectos técnicos de desenvolvimento para as primeiras
fases de planejamento e projeção. Entre outros benefícios estão um alto nível de
reuso, redução do Time-to-market, entre outros.
A experiência 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
máximo possível às características de negócio de um domínio especificado,
lembrando que, infelizmente, o foco se concentra mais na especificação do código e
muito pouco nos requisitos de modelagem conceituais e lógicos da arquitetura de
software.
Dessa forma, uma das primeiras preocupações consiste na identificação e na
representação destas informações em consideração aos aspectos de construção do
CIM - modelo computacional de requisitos e regras de negócio, depois na
transformação em PIM - Modelo Independente de Plataforma através dos artefatos
da UML e da linguagem de restrição ao modelo OCL, esta característica será
transformada em PSM - Modelo Específico de Plataforma - caracterizado pelos
aspectos técnicos de implementação da plataforma em questão, por último, a
transformação de PSM para código fonte, depois para o código objeto (executável).
A modelagem dos aspectos estruturais e comportamentais da UML é uma das
primeiras atividades de desenvolvimento e implementação do sistema de informação
na busca para identificar pontos em comum que são realizados pelos citados
profissionais anteriormente questionados. O modelo de características, gerado a
partir dessas atividades é utilizado como ponto de partida para o recorte necessário
à instanciação de novos sistemas de informação na WEB, Além disso, permite

97
uniformizar

o

entendimento

entre

todos

os

envolvidos

no

processo

de

desenvolvimento.
Esta dissertação apresenta uma orquestração de componentes reutilizáveis
de software baseados em MDA, que visa criar um método integrado para geração de
aplicações para sistemas de informações na Web, utilizando a linguagem Python e o
framework de desenvolvimento ágil Django, juntamente com a UML. Esta
abordagem está dividida em três partes/componentes: PyMDAGenerator módulo
PIM, PyMDAGenerator módulo PSM e o módulo de geração em shell script para
integrar as ações etapas de desenvolvimento e geração final do projeto.
Um estudo preliminar realizado para avaliar a ferramenta foi testado através
do projeto da Fábrica de Software Gofactory do sistema de gestão de inventários
hospitalares no produto "Retriever". Esse estudo contribuiu para a melhoria da
abordagem e motivou o desenvolvimento de um protótipo para apoiar a aplicação da
orquestração. Esse exemplo foi desenvolvido no contexto do ambiente da
ferramenta PyMDAGenerator, envolvendo as etapas de planejamento, análise,
projeto, implementação e testes.

7.2 Contribuições
O trabalho de pesquisa apresentado teve como objetivo principal propor uma
orquestração entre componentes reutilizáveis de software para implementação de
sistemas de informação para Web baseado no paradigma MDA. Através da
linguagem Python e do framework de desenvolvimento ágil Django. Entre as suas
principais contribuições, podemos destacar:

Definição de uma orquestração de componentes reutilizáveis de software
aplicado ao MDA, simples, prática e objetiva, incluindo as etapas do CIM,
PIM, PSM e transformações para código fonte. (1) o reuso de uma notação
para a representação explícita dos conceitos de CIM em UML, (2) um
mecanismo para geração dos arquivos admin.py e models.py de forma
automática através da biblioteca UML2DJ (são os arquivos no formato *.sh

98
feitos em Shell Script), (3) um ambiente de geração automática de tabelas e
atributos seguindo o modelo ORM parecido com hibernete/JPA, (4) um outro
mecanismo integrado para fazer a instalação dos projetos e a integração com
o ambiente de versão e publicação das aplicações. É importante salientar que
a abordagem proposta é baseada no mesmo tipo de modelo comumente
utilizado para a geração automática de código baseado em MDA.

Avaliação preliminar da ferramenta PyMDAGenerator, por meio de um estudo
realizado

pelos

alunos

do

Mestrado

Profissional

do

Cesar.edu.br,

especificamente da Fábrica de Software Gofactory. Os resultados obtidos
foram utilizados para melhoria da ferramenta e poderão servir como base
para planejamento de uma avaliação mais completa da mesma.

Desenvolvimento de um protótipo que implementa a abordagem proposta no
contexto

do ambiente

de

orquestração. Sendo

a

orquestração

de

componentes, o meta-modelo da biblioteca UML2DJ e a ferramenta
PyMDAGenerator as principais atribuições. A mesma gerou uma versão do
Projeto "Retriever" com todas as características existentes no ambiente Java
plataforma JEE também feitos com a linguagem Python e o framework
Django. É possível ainda ressaltar as seguintes contribuições secundárias:
o

Estudo das áreas de Engenharia de Reuso de Software e Modelagem
Dirigida a Modelos de Software, buscando identificar as oportunidades
de pesquisa existentes;

o

Identificação

das

extensões

necessárias

para

possibilitar

a

representação dos modelos conceituais de classe, atributos e métodos
na plataforma Python para o framework django;
o

Identificação dos diferentes mecanismos existentes de transformações
entre modelos de PIM, PSM e Código Fonte.

99
7.3 Limitações
Algumas limitações deste trabalho foram identificadas a partir de uma análise
crítica da abordagem proposta e do protótipo desenvolvido. As principais são
listadas logo a seguir:

A orquestração de componentes reutilizáveis de software é limitada através
da plataforma Linux, posto que utiliza a linguagem Shell Script para realizar
as transformações entre os modelos de PIM para PSM e PSM para Código
Fonte;

A aplicação é restrita ao modelo de características baseado em MDA e
funciona especificamente para Python com o framework Django;

Não foi realizado nenhum estudo para avaliar o protótipo desenvolvido, é
necessário realizar testes de performance e testes funcionais automatizados
para testar o aumento do número de entidades e atributos dos domínios e o
nível de complexidade dos métodos;

Não foi possível também validar os artefatos de UML do modelo
comportamental através de diagramas de atividades, máquina de estados e
diagramas de sequência por exemplo, nem as restrições OCL aplicados aos
modelos;

Não foi possível gerar uma aplicação em Shell Script baseada em Interfaces
Gráficas mais ricas, por exemplo utilizando o componente Dialog, isto
melhoraria a usabilidade da aplicação e provavelmente a sua adoção para os
usuários 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 protótipo desenvolvido, foram
destacadas. Além disso, novas oportunidades de pesquisa foram identificadas. Os
possíveis trabalhos futuros envolvem:

Aplicação

do

protótipo

desta

orquestração

utilizando

o

modelo

comportamental em atividades de monitoramento e acompanhamento dos
ativos com restrições OCL aplicados ao modelo do Diagrama de Classes e
Diagramas de Atividades;

Planejamento e execução de estudos de avaliação mais complexos e
completos que envolvam a abordagem proposta como um todo e a utilização
do protótipo em outros estudos de casos e domínios diferentes;

Representação dos artefatos baseados em serviços, conhecendo suas
dependências em relação aos modelos de componentes de software com
UML e suas relações aplicadas ao modelo de processo de negócio com
BPMN e BPEL.

Aplicação e construção do modelo específico 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 protótipos nas fases de
criação e especificação;

Integração da abordagem proposta com tecnologias que suportem a
reconfiguração dinâmica do modelo, como por exemplo: OSGI (OSGI
ALLIANCE, 2009);

Construção de um ambiente mais complexo e rico de execução que suporte
a reconfiguração dos sistemas desenvolvidos com base nas extensões
propostas que permita a inclusão de novas características e regras de
adaptação em tempo de execução.

101

Criação de novos componentes que garantam a interoperabilidade através
de serviços do tipo SOA/REST, visando aproveitar as transformações de
componentes da aplicação em serviços que poderão ser usados por outras
aplicações.

Melhorar a Interface gráfica da ferramenta e os recursos de configuração 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. REFERÊNCIAS BIBLIOGRÁFICAS
ARGOUML, 2012

Argo UML. 2012. Documents ArgoUML. Disponível em:
<http://argouml.tigris.org/documentation/>.
último
acesso:
01/12/2012.

ANDRÉ, 2009

André Milani. "PostgreSQL guia do programador - backup,
recovery, SQL, otimização, segurança". Editora: Novatec.
2009.

ATKINSON e al ,
2001

Atkinson, C., Bayer, J., Bunse, C., Kamsties, E., Laitenberger,
O., Lagua, R., Muthig, D., Paech, B., Wüst, 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 Documentação, Disponível em:
<http://cherrypy.readthedocs.org/en/latest/index.html> - último
acesso: 12/12/2013.

CWM, 2013

Common Warehouse Metamodel (CWM). 2013. Disponível
em:

<http://www.omg.org/spec/CWM/>.

último

acesso:

11/12/2013.
DANIEL, 2007

Daniel Gouveia Costa. "Administração de Redes com
Scripts - Bash Script, Python e VBScript". Editora: Brasport.
2007.

103
DAVI M. BEAZLEY,
2009

Beazley,

Python

Essential

Reference:

Inglês,

ISBN:

9780768687026: Ed. Addison-Wesley. 2009.
DI, 2005

Object Management Group. “UML Diagram Interchange (DI)
Specification”. 2005. Disponível em: <http://www.omg.org/
cgi-bin/doc?ptc/2005-06-07>. último acesso: 01/02/2005.

DJANGO, 2013

Django. 2013. Disponível em: <http://www.djangoproject.com>.
último acesso: 07/01/2013.

DRESDEN, 2013

Dresden OCL Toolkit. 2013. Disponível em: <http://dresdenocl.sourceforge.net/>. último acesso: 04/01/2013.

ECLIPSE, 2013

Eclipse
Project.
2013.
Disponível
<http://www.eclipse.org/>. último acesso: 05/01/2013.

ECORE, 2013

Ecore.
2013.
Disponível
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. Disponível em:
<http://www.eclipse.org/modeling/emf/>.
último
acesso:
07/08/2013.

EMF, 2013A

The Eclipse Modeling Framework (EMF) Overview. Disponível
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.
Disponível
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.
"Padrões de Projeto Soluções reutilizáveis 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.

Disponível
em:
último
acesso:

GAE, 2009

Google
App
Engine.
2009.
<http://code.google.com/appengine/>.
05/03/2009.

Disponível
em:
último
acesso:

GAE, 2009A

Google App Engine SDK for Java v.1.2.2. 2009. Disponível
em:
<http://code.google.com/appengine/downloads.html>.
último acesso: 13/07/2009.

GAEJRE, 2009

The GAE JRE Class White List. Disponível 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: Inglês,
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. Disponível em:
<http://www.json.org/>. último acesso: 04/01/2013.

JULIO, 2006

Júlio Cezar Neves. "Programação Shell Linux". Edição: 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.
Disponível
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”. O’Reilly. 3 ed. 2006.

MAGICDRAW,
2013

Magic
Draw.
2013.
Disponível
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
Aplicações Web dentro de um Processo de Engenharia de
Software Dirigido por Modelos e Baseado em
Componentes”. III Workshop de Desenvolvimento Rápido de
Aplicações. 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ª Edição.
Editora: Bookman. 2006.

MDR, 2013

Metadata
Repository.
2013.
Disponível
<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: Princípios 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. Disponível 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.
Disponível
em:
<http://www.omg.org/spec/MOF/2.0/>.
último
acesso:
10/11/2013.
OCLE 2.0 - Object Constraint Language Environment. 2009.
Disponível em: <http://lci.cs.ubbcluj.ro/ocle/index.htm>. último
acesso: 04/01/2009.
Eclipse
OCL
MDT.
2009.
Disponível
em:
<http://www.eclipse.org/modeling/mdt/downloads/?project=ocl>
. último acesso: 04/01/2009.
Octopus: OCL Tool for Precise Uml Specifications. 2013.
Disponível em: <http://octopus.sourceforge.net/>. último
acesso: 04/01/2013.

OMG, 2012A

Object Management Group. “UML 2.0 Metamodel in Rose”.
2012. Disponível em: <http://www.omg.org/spec/UML/2.1.2/>.
último acesso: 04/01/2012.

OMG, 2013

Object Management Group. 2013. Disponível
<http://www.omg.org/>. último acesso: 03/11/2013.

SANTANA e
GALESI, 2010

Osvaldo Santana e Thiago Galesi. "Python e Django Desenvolvimento ágil de aplicações web". Novatec.
Tríveos. 2010.

PYMOF, 2013

PyEMOF.
2013.
Disponível
<http://www2.lifl.fr/~marvie/software/pyemof.html>.
acesso: 15/04/2013.

PYYAML, 2013

PyYAML. 2013. Disponível em: <http://pyyaml.org>. último
acesso: 08/01/2013.

em:

em:
último

107
RODRIGUES, 2004

Rodrigues, M. G. C. “Metodologia da Pesquisa Científica”.
Rio de Janeiro, 2004.

SOMMERVILLE,
2011

Engenharia de Software, 9ª Edição, 2011, Ed. Pearson
Education, 568 Páginas.

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 aplicações web". Novatec.
Tríveos. 2010

TOGETHER, 2012

Borland
Together.
2012.
Disponível
em:
<http://www.borland.com/us/products/together/index.html>.
último acesso: 09/06/2012.

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, Disponível em:
<http://www.web2py.com/books/default/chapter/29>

-

último

acesso: 12/12/2013.
WEBOB, 2012

WebOb. 2012. Disponível em: <http://pythonpaste.org/webob>.
último acesso: 08/01/2012.

WEBOBJECT,
2012

“WebObjects Web Applications Programming Guide: How
Web
Applications
Work”.
2012.
Disponível
em:
<http://developer.apple.com/documentation/WebObjects/
Web_Applications/
Articles/1_Architecture.html>.
último
acesso: 03/03/2012.

PÁDUA , 2011

Wilson de Pádua, Engenharia de Software Fundamentos,
Métodos e Padrões, 2011, Edição 3ª, Ed. LTC gen.

XMI, 2013

Object Management Group. “XML Metadata Interchange
(XMI), v2.1.1”. 2013. Disponível em: <http://www.omg.org/
technology/xml/index.htm>. último acesso: 15/10/2013.

XML, 2009

Extensible Markup Language (XML). 2009. Disponível em:
<http://www.w3.org/XML/>. último acesso: 04/01/2009.

108

APÊNDICES

APÊNDICE I - DETALHAMENTO DOS REQUISITOS DO PROJETO - 109
APÊNDICE II - MODELOS DE DIAGRAMAS UML DO PROJETO - 115
APÊNDICE III - GLOSSÁRIO DO BANCO DE DADOS - 119
APÊNDICE IV - BIBLIOTECA UML2DJ - 124
APÊNDICE V - SCRIPT EM SHELL COMANDOS COM TRANSFORMAÇÕES - 128

109

Apêndice 1

Lista de Detalhamento e Descrição dos Requisitos Funcionais
Nesta sessão serão apresentadas algumas informações mais detalhadas
sobre os requisitos funcionais do projeto, seus atores e suas principais referências,
estas informações são importantes para detalhar os dados relacionados ao projeto e
suas principais funcionalidades.
[RF01] - Autenticação de usuários e senhas.
Atores: Todos
Descrição: Este procedimento consiste realizar a operação de autenticação dos
usuários no sistema, compreende no lançamento do login e senha do usuário e
validação através do banco de dados do sistema. Referência: RF1
[RF02] – Listar itens de material por setor.
Atores: Todos
Descrição: 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 específico. Referência: RF1, RF2
[RF03] – Gerenciar relatórios de equipamentos por ritmos in ambiente.
Atores: Gestor e Administrador
Descrição: Este procedimento consiste em gerar um relatório de todos os
equipamentos que passaram por um determinado ambiente, informando data e hora
de movimentação e local de origem e destino, o referido relatório servirá também
com ponto de auditoria do sistema. Referência: RF1, RF3, RF5

110
[RF04] – Gerenciar usuários.
Atores: Gestor e Administrador
Descrição: Este procedimento consiste em realizar as operações básicas
relacionadas ao usuário identificando os seus principais atributos tais como nome do
usuário, login, senha, perfil, etc. Outro ponto é a identificação de seus métodos tais
como inclusão, alteração, exclusão e listagem geral de todos os usuários do
sistema, além de alterar a senha do usuário atualmente conectado no sistema.
Referência: RF1, RF4
[RF05] – Gerar relatório por ambiente.
Atores: Gestor e Administrador
Descrição: Este procedimento consiste em gerar um relatório no formato PDF de
todos os materiais existentes por ambiente operacional do hospital. Referência:
FR1, FR5
[RF06] – Gerenciar hospitais.
Atores: Administrador
Descrição: Este procedimento consiste em realizar as operações básicas
relacionadas ao hospital identificando os seus principais atributos tais como: código
do Hospital, descrição do hospital, CNPJ, razão social, etc. Outro ponto é a
identificação de seus métodos tais como inclusão, alteração, exclusão e listagem
geral de todos os hospitais. Referência: RF1, RF6
[RF07] – Gerenciar gestor por hospital.
Atores: Administrador
Descrição: Este procedimento consiste em realizar as operações básicas
relacionadas ao Usuário Administrador do Hospital identificando os seus principais
atributos tais como nome do usuário, login, senha, perfil avançados de

111
administração do hospital, delegação de nível, etc. Outro ponto é a identificação de
seus métodos tais como: delegação de função, níveis de permissão, controle de
acesso a recursos específicos do hospital. Referência: RF1, RF4, RF6, RF7
[RF08] – Registrar alertas emitidos
Atores: Administrador
Descrição: Este procedimento consiste em registrar todos os alertas emitidos pelos
sensores no hospital. Referência: RF1, RF8
[RF09] – Gerar log de eventos inesperados
Atores: Administrador
Descrição: Este procedimento consiste em gerar uma pequena relação de eventos
inesperados para o sistema, eventos tais como: materiais que não podem entrar em
determinados ambientes do tipo UTI, Salas de Cirurgias, etc. Referência: RF1, RF9,
RF10
[RF10] – Auditar Sistemas
Atores: Administrador
Descrição: Este procedimento consiste em gerar a parte de auditoria do sistema
como um todo: operações de inclusão, alteração, exclusão serão armazenadas com
data e hora de realização como também o nome do usuário que fez a referida ação.
Referência: RF1, Todos.
[RF11] – Gerenciar Prédios e Blocos
Atores: Engenharia Clínica, Gestor e Administrador.
Descrição: Este procedimento consiste em realizar as operações básicas
relacionadas ao Prédio e Blocos do Hospital identificando os seus principais
atributos tais como: código predio, descrição prédio, Localização, etc. Outro ponto é

112
a identificação de seus métodos tais como inclusão, alteração, exclusão e listagem
geral de todos os prédios e blocos. Referência: RF1, RF11
[RF12] – Listar Itens na Tela de Início do Sistema
Atores: Engenharia Clínica, Gestor e Administrador
Descrição: Este procedimento consiste em listar as ações de movimentação de
itens que ocorreram nos últimos minutos do sistema. Referência: RF1, RF12

[RF13] – Gerenciar Equipamento
Atores: Engenharia Clínica
Descrição: Este procedimento consiste em realizar as operações básicas
relacionadas aos Equipamentos do Hospital identificando os seus principais atributos
tais como: código equipamento, descrição, tipo, localização da Etiqueta RFID, etc.
Outro ponto é a identificação de seus métodos tais como inclusão, alteração,
exclusão e listagem geral de todos os equipamentos. Referência: RF1, RF13
[RF14] – Gerenciar Áreas.
Atores: Engenharia Clínica
Descrição: Este procedimento consiste em realizar as operações básicas
relacionadas as Áreas do Hospital identificando os seus principais atributos tais
como: código área, descrição, tipo, localização dos sensores, etc. Outro ponto é a
identificação de seus métodos tais como inclusão, alteração, exclusão e listagem
geral de todas as áreas. Referência: RF1, RF14
[RF15] – Gerenciar Andares.
Atores: Engenharia Clínica

113
Descrição: Este procedimento consiste em realizar as operações básicas
relacionadas aos andares existentes no Hospital identificando os seus principais
atributos tais como: código andar, descrição, tipo, localização no prédio, etc. Outro
ponto é a identificação de seus métodos tais como inclusão, alteração, exclusão e
listagem geral de todos os andares. Referência: RF1, RF15
[RF16] – Gerenciar Movimentações.
Atores: Engenharia Clínica
Descrição: Este procedimento consiste em realizar as operações básicas
relacionadas as movimentações existentes de equipamentos e materiais no Hospital
identificando os seus principais atributos tais como: código da movimentação,
observações, tipo de equipamento e material, data da movimentação, hora da
movimentação, etc. Outro ponto é a identificação de seus métodos tais como
inclusão, alteração, exclusão e listagem geral de todas as movimentações.
Referência: RF1, RF16

[RF17] – Gerenciar Identificadores (label) Etiquetas.
Atores: Engenharia Clínica
Descrição: Este procedimento consiste em realizar as operações básicas
relacionadas aos identificadores (Etiquetas FRID) em cada equipamento e material
do Hospital identificando os seus principais atributos tais como: código identificador,
descrição, tipo, localização, etc. Outro ponto é a identificação de seus métodos tais
como inclusão, alteração, exclusão e listagem geral de todos os identificadores.
Referência: RF1, RF15
[RF18] – Gerenciar Sensores.
Atores: Engenharia Clínica

114
Descrição: Este procedimento consiste em realizar as operações básicas
relacionadas aos sensores instalados em cada ambiente do Hospital identificando
os seus principais atributos tais como: código sensor, etiqueta RFID, descrição, tipo,
localização, etc. Outro ponto é a identificação de seus métodos tais como inclusão,
alteração, exclusão e listagem geral de todos os andares. Referência: RF1, RF18
[RF19] – Alertar Movimentação Indevida.
Atores: Sensor / Segurança
Descrição: Este procedimento consiste em emitir um aviso sonoro de alerta de
movimentação indevida de materiais e equipamentos de um lugar para outro dentro
do hospital. Referência: RF1, RF19
[RF20] – Receber alerta de segurança.
Atores: Sensor / Segurança.
Descrição: Este procedimento consiste em enviar uma mensagem por SMS, MMS e
Email, além de mensagem de voz para o segurança de plantão. Referência: RF1,
RF20

115

Apêndice 2

Modelos de Diagramas da UML / Arquitetura do Projeto e Artefatos
de Análise e Especificação do Sistema.
Nesta sessão são apresentados os diagramas da UML e demais
características do sistema, relacionados ao projeto Retriever e demais ações.

Diagrama de Casos de Uso do Sistema de Gerenciamento de Inventários
Hospitalares "Retriever".

116

Diagrama de Classes do Sistema.

Diagrama do Modelo ER (Entidade Relacionamento), sistema Retriever..

117

Diagrama do Modelo Lógico do Sistema "Retriever".

Diagrama de Componentes do Sistema - Visão Arquitetura do Play 2.0 Framework.

118

Diagrama

de

Instalação

Componentes e

Middleware

de

Integração

Desenvolvidos pela nossa Fábrica de Software Gofactory.

Diagrama de Arquitetura Externa, visão Integração entre os serviços baseado
no Middleware da Empresa BeagleTech Cesar.edu.

119

Apêndice 3

Glossário do Banco de Dados com Script (DDL).
Nesta sessão serão apresentadas algumas informações mais detalhadas
sobre os requisitos funcionais do projeto, seus atores e suas principais referências,
estas informações são 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" (
"id" integer NOT NULL PRIMARY KEY,
"codigo" integer,
"background" varchar(50) NOT NULL,
"descricao" varchar(50) NOT NULL,
"poligono" varchar(50) NOT NULL,
"retrita" integer,
"andar_id" integer );
CREATE TABLE "Administrador_identificador" (
"id" integer NOT NULL PRIMARY KEY,

120
"cod" integer,
"codigo" varchar(50) NOT NULL,
"epc" varchar(50) NOT NULL,
"tecnologia" integer );
CREATE TABLE "Administrador_sensor" (
"id" integer NOT NULL PRIMARY KEY,
"codigo" integer,
"descricao" varchar(50) NOT NULL,
"localizacao" varchar(40) NOT NULL,
"modelo" varchar(40) NOT NULL,
"tecnologia" integer );
CREATE TABLE "Administrador_evento" (
"id" integer NOT NULL PRIMARY KEY,
"codigo" integer,
"data" date,
"identificadorold_id"

integer

NOT

NULL

REFERENCES

"Administrador_identificador" ("id"),
"sensorid_id"

integer

NOT

NULL

("id"));
CREATE TABLE "Administrador_entidade" (
"id" integer NOT NULL PRIMARY KEY,
"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" (
"id" integer NOT NULL PRIMARY KEY,
"codigo" integer,
"descricao" varchar(50) NOT NULL,
"entidade_id"

integer

NOT

NULL

REFERENCES

("id"));
CREATE TABLE "Administrador_andar" (
"id" integer NOT NULL PRIMARY KEY,
"codigo" integer,
"descricaoAndar" varchar(50) NOT NULL,
"nome" varchar(50) NOT NULL,
"urlimagem" varchar(50) NOT NULL );

"Administrador_entidade"

122
CREATE TABLE "Administrador_s3plantabaixa" (
"id" integer NOT NULL PRIMARY KEY,
"coordenadas_X" integer,
"coordenadas_Y" integer,
"areaCompleta" integer );
CREATE TABLE "Administrador_equipamento" (
"id" integer NOT NULL PRIMARY KEY,
"codigo" integer,
"descricao" varchar(50) NOT NULL,
"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" (
"id" integer NOT NULL PRIMARY KEY,
"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

Apêndice 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

Apêndice V
SCRIPT EM SHELL comandos com as transformações.
Comando

Descrição

#!/bin/bash

Comando que serve para inicializar o script e
executar

os

comandos

da

linguagem

Shell

(Interpretador).
# Sistema

Comentário

sobre

o

Sistema

-

Ferramenta

pyMDAGenerator
# Autor

Comentário sobre o Autor.

# SubMódulo

Comentário sobre o SubMódulo.

echo "Lendo os dados do Arquivo XMI.

O comando echo é responsável pela exibição da

Posso continuar? [sn] "

mensagem na tela e fica aguardando a resposta se
[s para SIM] ou [n para NÃO]

read RESPOSTA

O comando read RESPOSTA é responsável por
armazenar a resposta da pergunta em uma variável
chamada RESPOSTA.

if [ $RESPOSTA = s ] then

Este comando é responsável por realizar uma
decisão, se o conteúdo da variável RESPOSTA for

python UML2DJ /ProjetoRetriever
echo "Realizando as Transformacoes
entre os modelos"

igual a s então, irá exibir uma mensagem na tela e
começar 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

e

_models.py em models.py.
mv

/administrator/_admin_custom.py

admin_custom.py

Na

próxima

execução

o

comando

python

manage.py syncdb é responsável por executar as
transformações do arquivos models.py na estrutura

129
Comando

Descrição
do banco de dados. O próximo passo é verificar as

mv

/administrador/_models.py

models.py

ações e parâmetros de configuração do projeto
através do arquivo settings.py, nele são exibidas
informações de configuração do projeto, como
também os links simbólicos, e demais ações do

echo

"[PIM]-Fazendo

as

projeto em si.

tranformações para o [PSM] Django
Por

Python"

fim

será

chamado

o

arquivo

geradorMDAPSM.sh que ficará responsável pela
continuação..

sleep 4
python manage.py syncdb
echo "Aplicando as mudanças no
settings.py...."
sleep 5
nano settings.py
echo "Aplicando as transformações
no models.py..."
sleep 2
./geradorMDAPSM.sh
Fi
if [ $RESPOSTA = n ] then

Este comando irá interromper o script e demais
ações..

echo
Script:..."
sleep 3
exit
fi

"Execução

Interrompida

do

130
Tabela [1]: Tabela com os comandos arquivo geradorMDAPIM.sh
Fonte: Próprio Autor.

Comando

Descrição

#!/bin/bash

Comando que serve para inicializar o script e
executar

os

comandos

da

linguagem

Shell

(Interpretador)..
# Sistema

Comentário

sobre

o

Sistema

-

Ferramenta

pyMDAGenerator
# Autor

Comentário sobre o Autor.

# SubMódulo

Comentário sobre o SubMódulo.

echo

"Continuar

com

as

O comando echo é responsável pela exibição da

transformações. Posso continuar? [sn] "

mensagem na tela e fica aguardando a resposta se
[s para SIM] ou [n para NÃO]. O comando read

read RESPOSTA

RESPOSTA armazena o valor digitado na variável
RESPOSTA.

if [ $RESPOSTA = s ] then

Este comando tem como característica realizar uma
decisão através do IF, se a resposta for igual a s

echo "Realizando as Transformações
de PIM para PSM..."

então será realizado o comando python manage.py
syncdb que irá atualizar o banco de dados e as
informações de persistência do sistema. Depois o

sleep 2

comando python manage.py sqlall irá exibir todos
os comandos realizados para criação da estrutura

python manage.py syncdb

de dados (banco de dados) da aplicação em si,
echo

"[PIM]-Fazendo

as

modelo este que será aplicado neste exemplo do

tranformações para o [PSM] Django

sistema. O próximo comando será o python

Python"

manage.py runserver este é responsável por
inicializar o servidor de aplicação do python para

sleep 4

rodar a aplicação propriamente dita.

python manage.py sqlall
echo

"Startando

aplicações ...."

o

servidor

de

131
Comando

Descrição

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
ações..

echo "Transformação Interrompida"
fi
# O date mostra a data e a hora

Comando responsável pela exibição da data e hora

correntes

da geração do aplicativo.

echo "Data e Horário:" date
Echo

Comando responsável por exibir uma lista de
usuários atualmente conectados nesta máquina.

# O w mostra os usuários que estão
conectados nesta máquina
echo "Usuários conectados:" w
Tabela [2]: Tabela com os comandos do arquivo geradorMDAPSM.sh
Fonte: Próprio Autor