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

Talvez por isso tão poucos se dediquem a ele. Henry Ford [1901] .Dedicatória Pensar é o trabalho mais difícil que existe.

Kiev Gama. Agradeço aos meus amigos de sala de aula. Maria Clara Costa Lima e João Guilherme Costa Lima pelo amor. perseverança e fé. Ana Claudia pela amizade. Left. Pedro. por sempre ter sido um grande exemplo de honestidade. Ana Paula Cavalcanti e Heriberto pelas boas conversas e grandes exemplos que são para mim. confiança e respeito depositados em mim durante este período de estudo.Agradecimentos Em primeiro lugar. Aos meus pais. Trajano. principalmente Felipe Furtado. Ao meu Orientador Vinicius Garcia. por ter confiado em mim e por ter compartilhado de seus conhecimentos para a melhoria deste trabalho. Gustavo Alexandre. Robson do Nascimento Fidalgo. que esteve sempre ao meu lado. por seu carinho. amor e confiança em todos os momentos da minha vida. Aprígio. carinho e compreensão durante este período da minha vida. Adilson. . Aos meus filhos. Á todos os meus professores. paciência. Josué. Rodrigo Assad. amor e confiança. Luiz Maurício. 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 a todos que de forma direta ou indireta contribuíram para a conclusão deste trabalho. Á minha Esposa Beatriz Costa. E por fim. Roberto Capistrano. Ceça. Vinicius Garcia. 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. me incentivou e nunca mediu esforços para me ajudar. Agradeço aos meus avós Maternos e Paternos (in memorian).

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

MDA.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. garantindo assim. Palavras-chave Reuso de Software. E por fim. Django. sendo realizado de maneira assistida através de uma ferramenta chamada PyMDAGenerator. 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. a construção de sistemas de forma automatizada. Transformações entre modelos. que permita a sua utilização através de um parser XMI. Uma dessas iniciativas é a Arquitetura Dirigida a Modelo (MDA) que permite a modelagem e a aplicação de transformações sobre modelos. 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. Engenharia de Software baseada em componentes. Python. 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). foi feito um estudo de caso comparativo entre: desenvolvimento do projeto utilizando a engenharia de software baseada em componentes. implementados com a linguagem Python e o Django. .

being held assisted way through a tool called PyMDAGenerator implemented with Python and Django language. 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. make a comparative case study: project development using engineering-based software components. They have appeared through the increase of the artifacts abstraction levels and the tools and frameworks advance object-targeted. MDA. . One of these initiatives is the architecture driven model (MDA) that allows the modeling and application of models. Several techniques have appeared throughout the time with this objective. Key Words: Software Reuse. thus ensuring the construction of automated systems.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. Django. 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. Python. Component-Based Software Engineering. Finally. Models Transformations.

..................3 Model Driven Architecture (MDA) ....9 Considerações Finais deste capítulo .............................................................................................................................................................5 Considerações Finais deste capítulo .....................................2 Visão geral da abordagem proposta ............................................................................................................................................... 6 2................. 18 3.........................................................................7 O Sistema de gerenciamento de dados (Postgresql e SQLite3) .................................5 Meta-modelagem: MOF2 e ECORE......................... 20 3....4 Padrão reusável visual para modelagem estrutural básica............... 34 3........................ 3 1........................ 62 ................................................ Embasamento Teórico ............... 43 4.. 1 1............................................................................2................................. meta-modelagem: a Infraestrutura UML2: ............... 21 3....................................................1 Objetivos Gerais .........................................SUMÁRIO: 1.....1 Contexto e Motivação ..........2 Unifiel Modeling Language (UML) ........ 3 1.........................................................3 Estrutura do Trabalho . metamodelagem avançada OCL2 ...............................................4 A Linguagem Python ........................... 13 2......................................... 40 3...........2 Objetivos Específicos .......................................................3 Modelos utilizados pelo MDA ..................6 A Modelagem comportamental: Superestrutura UML2 ............................................ 46 4.................................................................................8 Conclusão do Capítulo .....................................................................................1 Caracterização da pesquisa .............................. 1 1................................................................................................................. 42 4................. Fundamentação Teórica da Proposta ................................... 20 3................... 38 3...................................................................... 22 3........................................... 8 2............................ 7 2.........................2 Objetivos ... 43 4....................................... 6 2................... 16 2................................................................. 36 3...... 55 4........................ 45 4................................................................................................................................................... Introdução ..................1 Desenvolvimento baseado em componentes .................... 11 2...........6 A linguagem Shell Script ... 30 3.. 18 2... 5 2....................................2................................................3 Apoio à definição de transformações ................................................7 Linguagem textual para modelagem.......8 Abordagens para projetos de linguagens de modelagem avançada ....................1 Definição da ferramenta ....................................................................................................2 Problematização ...................4 Etapas de transformação entre os modelos usando a biblioteca UML2DJ ................................ 4 1..................................................5 O framework django ......................................................... A Ferramenta PyMDAGenerator: "A abordagem proposta" ..

....... 95 7.........................................2 Stakeholders.............................................. 63 5..................................................................................................................................................................... 85 6..................................................................................................2 Contribuições .................................................1 Epílogo .............................. 84 6........... 127 ............................................................................................................................. 123 Apêndice 5 ................... 69 5......................... 73 5............... 99 8...................... 95 7........................................................................................................................................................................................................... Exemplo: Sistema "Retriever" e o Sistema Patrimonial "Asset Inventory" ................. 64 5................................................................................................................. 98 7... 118 Apêndice 4 ...................................3 Limitações ......................................................................................4 Trabalhos Futuros ....... 96 7.................. 63 5............... 93 7... Apêndices ........... 90 6................................................... 107 Apêndice 1 ...4 Considerações finais sobre este capítulo ................................. 78 5......................2 Representação dos dados aplicados ao projeto "Asset Inventory" desenvolvimento na linguagem Python com Django ......................1 Definição do problema ........... requisitos funcionais e não funcionais ............................................6 Considerações finais deste capítulo ............ 87 6......................... Estudo comparativo entre a ferramenta ANDROMDA (Java) PyMDAGenerator (Python) ......................................................................................................................................5 O sistema de gestão de inventários patrimoniais "Asset Inventory" ..............................................................................1 O projeto "Retriever" na arquitetura Java JEE com ANDROMDA .. 101 9.........................................................................................................3 Gráfico comparativo entre os dos processos ................................................................ Considerações Finais ................................ 114 Apêndice 3 .........................................3 Modelos de artefatos e documentos do projeto ......................................4 Interfaces da aplicação e requisitos do sistema "Retriever" .......... Referências Bibliográficas ........................ 108 Apêndice 2 ..........................................................................5....................... 82 6.....................................................................................................

.............................................. 51 Figura [23] ........................Taxonomia dos diagramas da UML 2........... 35 Figura [13] ....Infraestrutura do diagrama de package segundo UML2 e MOF.........Detalhes do Meta Modelo UML2DJ .. 33 Figura [10] .....Detalhes do Meta Modelo UML2DJ .............Estrutura completa EMF ECORE.1...........................Interoperabilidade MDA usando Pontes ......... 26 Figura [6] ..... 38 Figura [15] ....................Infraestrutura em UML2 Meta Modelagem .................................................. 37 Figura [14] – Estrutura Interna do Diagrama de Atividades ....Estrutura interna Diagrama de Activity ...........................................................................Diagrama de classe modelo do sistema retriever ............................... 33 Figura [11] ........Arquivo no formato XMI ................................Processo de transformação do PIM para PSM e do PSM em código.............Diagrama de Instalação ......Detalhe do processo de transformação entre PSM to Código Fonte ..................................................Modelagem UML do Sistema de Controle de Vôo (OCL)..Lista de Figuras............. 29 Figura [7] .. 47 Figura [19] . 34 Figura [12] .... 48 Figura [20] ...Associação ..................................Arquitetura da MDA ...... 44 Figura [17] ..........Visão tipos de atributos ................ 50 Figura [22] ................ 58 ..........Infraestrutura do diagrama de Data Type segundo UML2 e MOF......... 49 Figura [21] .......................................Diagrama que representa a ferramenta PyMDAGenerator .........representação do domínio ..........................................................................................................................Componentes internos do django .... 10 Figura [3] ......................UML2 e MOF .............Detalhes do Meta Modelo componente UML2DJ ..............................Figura que representa o Meta Modelo do UML2DJ .... 52 Figura [24] ...................................... 31 Figura [8] .......... 32 Figura [9] ..................... 56 Figura [26] ...................... 57 Figura [27] ...........Processo de transformação MDA (Guide)...........Figura que representa as transformações do modelo Django Framework.... 8 Figura [2] ............... 25 Figura [5] – Ciclo de vida do desenvolvimento baseado em MDA ......................................... 24 Figura [4] .........................................................................................................UML2 e MOF ...... Figura [1] ...Figura que representa o esquema de ligação dos componentes do django ...................................... 47 Figura [18] ..Estrutura completa do MO até M3..............................Infraestrutura do diagrama de classe segundo UML2 e MOF ......... 54 Figura [25] .................... 40 Figura [16]..............

......Sistema (Asset Inventory) .............GeradorMDAPIM..............."Retriever" ..... 73 Figura [34] ..Tela de cadastro de ativos hospitalares ......visão externa "Retriever" .....Diagrama de casos de uso "Retriever" .................... 81 Figura [43] ......... 59 Figura [29] ......"Retriever" ...................Figura [28] ..........................................................Tela de Cadastro de usuários .. 82 Figura [44] ... 80 Figura [41] ...............................Sistema (Asset Inventory) Tela de Cadastro de Eventos ..................sh .... 80 Figura [42] ................."Retriever" ................... 74 Figura [35] ."Retriever ............................................Tela de cadastro de Andar ......................................................Página do Projeto PyMDAGenerator na Internet ............. 79 Figura [40] ..Sistema (Asset Inventory) .......................................................................Arquivo com os comandos em shell script do PIM ......... 77 Figura [38] ... 70 Figura [32] ..................Tela com o menu principal do sistema .... 69 Figura [31] ....................Sistema (Asset Inventory) Tela de Cadastro de Área ....Tela de cadastro de unidades ......Seleção de Hospital para administrar ... 76 Figura [37] .............................................. 75 Figura [36] ........visão interna (MVC) .........Diagrama de instalação .............Diagrama de componentes ........."Retriever" ....Diagrama de classes .......................sh .......................... 72 Figura [33] ..."Retriever" .................. 93 . 77 Figura [39] ... 61 Figura [30] ....Tela de Autenticação de usuários no sistema ................Sistema (Asset Inventory) Tela de Cadastro de equipamentos ..Arquivo com os comandos em shell script do PSM GeradorMDAPSM.......

................................................................................................................... 91 .................. 68 Tabela [3] Quadro demonstrativo entre o projeto "Retriever" e o "Asset Inventory" ....... 67 Tabela [2] Requisitos Não-Funcionais ..................................... 87 Tabela [5] Tabela informações do projeto dando ênfase ao nº de linhas de código ..............Lista de Tabelas Tabela [1] Requisitos Funcionais ................... 85 Tabela [4] Quadro demonstrativo dando ênfase ao Projeto em Python com Django .

..................... 91 Gráfico [5] Gráfico com a variação dos percentuais entre os projetos (Java x Python) ..............Lista de Gráficos Gráfico [1] Informações Estatísticas do Projeto "Retriever" JEE...... 92 ..................... 90 Gráfico [4] Gráfico com as informações estatísticas....................... 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 ................ azul para o Python e Laranja para Java...............

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 Organização internacional que aprova padrões abertos para aplicações orientadas a objetos . arcabouços de desenvolvimento de software. linguagens de programação. responsáveis por descrever as regras de negócio do software. da tecnologia usada para implementação (MELLOR. auxiliando no planejamento e entendimento dos mesmos. novos paradigmas e processos de desenvolvimento. além de promover uma clara separação entre aspectos lógicos. Com o objeto de propor uma solução para os problemas supracitados. com uma alta portabilidade e de fácil manutenção. 2005. Um modelo pode ser entendido com um conjunto de elementos que descrevem alguma realidade física ou abstrata. p.1 Contexto e Motivação Segundo (SOMMERVILLE. a Object Management Group (OMG)1 apresentou uma iniciativa chamada de Arquitetura Orientada a Modelos. do inglês Model Driven Architecture (MDA). INTRODUÇÃO 1. em 2001. cujo principal objetivo é mudar o foco do desenvolvimento de software para a importância que os modelos devem ter nesse cenário. p. 89-100) a Engenharia de Software vem evoluindo ao longo dos anos no que diz respeito a arquiteturas. 2011. (c) alto acoplamento com a plataforma escolhida. Apesar desses avanços.1 1. 56-87). inclusive na fase de codificação. dentre outros aspectos. (d) má gerência dos projetos de desenvolvimento. 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. A utilização de modelos eleva o nível de abstração no desenvolvimento de sistemas. ainda é um grande desafio desenvolver software com qualidade devido a fatores como: (a) crescente demanda por sistemas complexos e de grande porte. (b) mudanças de tecnologia e requisitos.

Com isso. o objeto deste trabalho é definir uma orquestração de componentes reutilizáveis de software. uma ferramenta para geração automática aplicações para a Web foi desenvolvida. do Inglês Platform Independent Model (PIM). Para demonstrar a viabilidade da abordagem proposta. em seguida para o Modelo Específico de Plataforma. para o novo modelo PSM agora específico da nova plataforma alvo e por fim gerar o código-fonte. . sendo necessário somente repetir a transformação do modelo PIM. mudanças de requisitos ou mesmo de tecnologia não impactarão em um alto custo para realização das alterações. ferramentas de transformação entre modelos e geração de código devem ser utilizadas. novos modelos são derivados. do inglês Platform Specific Model (PSM). utilizando a linguagem Python e o framework Django. A partir dos modelos de mais alto nível. Diante desse contexto. até o nível mais baixo abstração que é o próprio código-fonte da aplicação. Para isso. passando pelo Modelo Independente de Plataforma.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. visando garantir uma semi-automatização do processo de geração de código baseando-se nos conceitos propostos pela MDA.

Faz a conversão direta de modelos UML para estrutura dos projetos do Django .2 Objetivos 1. para definição de transformações unidirecionais entre modelos (PIM para PSM e PSM para código).  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.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.  Melhorar o mecanismo de leitura dos dados existentes nos arquivos XML. 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. 2 Biblioteca UML to Django .3 1. sendo realizado de maneira assistida através de uma ferramenta chamada PyMDAGenerator. 1.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.2. UML2DJ. Tal abordagem deve permitir à sua utilização através de um parser XMI.  Propor uma solução para o desenvolvimento de software para Web baseados em modelos utilizando diagramas escritos na linguagem UML.

4  Construir uma ferramenta para gerar de forma automática aplicações para a Web.  Realizar um estudo comparativo entre o desenvolvimento baseado em componentes com MDA. . utilizando a linguagem Python e o Framework Django.

ferramentas.  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.5 1. inclusive os trabalhos futuros.3 Estrutura do Trabalho Este trabalho é estruturado da seguinte forma:  O Primeiro Capítulo introduz e apresenta o contexto desta dissertação. . linguagens e frameworks tais como: MDA. requisitos.  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. entre outros. solução proposta e conjunto de artefatos produzidos. interfaces gráficas e características. seus objetivos gerais e específicos e estrutura dos capítulos. Django. pontos positivos e negativos. comenta e motiva o trabalho.  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 Segundo Capítulo relata o embasamento teórico onde são apresentadas informações básicas sobre as metodologias. contribuições. limitações. descreve. Python.  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.

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

Este trabalho usará como base a versão 2. a UML é a linguagem padrão no mundo para a modelagem de sistemas orientados a objetos. 30-50). Segundo (JACOBSON. separando-os do desenvolvimento em domínios independentes de plataforma com a UML. 2005. independe de uma linguagem de programação. tendo em vista que a mesma tem um importante papel no presente trabalho. dos domínios específicos de plataforma baseados em DSL. Isso se deve a algumas características. Hoje. não possui semântica formal bem definida. tais como: ser uma linguagem de propósito geral.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. 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. 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. principalmente sistemas orientados a objetos.7 destes blocos implica no aumento do reuso. para especificação. melhoria da produtividade e manutenabilidade dos componentes. ou seja. entre outras características. p. construção e documentação de artefatos de sistemas de software. 2. Esses conceitos são de grande importância para um bom entendimento por parte de leitores que não estejam familiarizados com esta tecnologia. p. conforme os . não está presa a um processo. minimizando a especificidade do modelo de negócio. 24-54). é independente de uma etapa do desenvolvimento de software. 1999. visualização. Unified Modeling Language (UML) é uma linguagem gráfica.1 da UML que tem como base os treze diagramas da UML 2.0 apresentados na figura 02.

tem-se um devido destaque apropriado. este estudo.3 Model Driven Architecture (MDA) A presente seção apresenta uma breve descrição do MDA. por isto. p. características e principais recursos. lançada em 2001. 2. tem como principal abordagem o Model Driven Architecture (MDA).1 SPECIFICATION.1 Fonte: UML 2. MDA foi uma iniciativa da OMG. 31-80). 2012. tendo em vista que a mesma tem um importante papel no presente trabalho.1 no site da OMG (UML 2.8 modelos Estrutural da UML e Comportamental da UML. tal referência encontra-se no documento de especificação da UML 2. Dentro da MDA. Figura [1]: Taxonomia dos diagramas da UML 2. 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. serão apresentadas algumas informações sobre a arquitetura dirigida a modelos (MDA) seus conceitos. o processo de .1 SPECIFICATION Na próxima seção. Esses conceitos são de grande importância para um bom entendimento por parte de leitores que não estejam familiarizados com esta tecnologia.

2013) e CWM (CWM.9 desenvolvimento do software é impulsionado pela atividade de modelagem do sistema de software que passa a ter um papel fundamental. 1999). As outras duas camadas completam a arquitetura. version 1. nela é possível identificar as principais tecnologias. a modelagem passa a ter um papel ativo nas etapas de desenvolvimento do software (KLEPPE. MOF (MOF. 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. De acordo com a MDA GUIDE.1 (2005) os três principais objetivos da MDA são promover uma maior portabilidade. 60-90).1 Arquitetura do MDA O Model Driven Architecture é representado através da Figura 3.3. Analisando-a. Além de apenas documentar o sistema. 2001. 2013).0. Figura [2]: Arquitetura da MDA Fonte: (OMG. 2. 42-50). 2013) . interoperabilidade e a reusabilidade. A utilização do MDA possibilita a automatização de algumas das etapas dentro do processo de desenvolvimento de software. p. áreas de negócio da abordagem do MDA na visão da OMG. p. 2003. incluindo a geração do códigofonte para a plataforma escolhida a partir de um determinado modelo. padrões esses adotados pela OMG. tem-se no centro o núcleo da arquitetura que é baseada nos padrões de modelagem: UML (JACOBSON.

que vale a pena ressaltar e que não é mostrada na figura 3. 93-109). ela pode ser considerada uma metalinguagem. p. 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. O MOF é a linguagem em que os metamodelos de UML e CWM são escritos (MILLER e MUKERJI. visualizar e documentar modelos de software. p. incluindo sua estrutura e designer. O uso mais comum é na troca facilitada de metadados entre as ferramentas de modelagem e os repositórios. é o XML Metadata Interchange (XMI. Como foi mencionado anteriormente. 2013). 2013). 71-90). 2001.2 Núcleo O núcleo do MDA compreende um conjunto de metamodelos UML. cada um abrangendo determinada área do processo de desenvolvimento.  Common Warehouse Metamodelo (CWM): Linguagem para modelagem de dados. 1999. (XMI. desenvolvidos pela OMG.3. 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 . Outro importante conceito que está diretamente ligado aos padrões de modelagem citados acima.  XML Metadata Interchange é um padrão em MOF da OMG para troca de informações baseado em XML. A CWM é derivada da MOF e é utilizada dentro das transformações entre modelos (MILLER e MUKERJI. porém será independente de qualquer plataforma específica (MILLER e MUKERJI. p. 2001. 32-56).  Unified Model Language (UML): Utilizada para especificar. 84-99). Como o MOF é uma linguagem para criação de linguagens. de modo que englobe todos os requisitos (JACOBSON.10 2. Esses metamodelos representam as características comuns de todas as plataformas alvos. 2001. p.

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

Pygame. Visual Python. entre eles podemos citar: Django. Plone. 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. embratel.com. SQLObject. entre outras. Twisted. ZODB. hoje em dia. e empresas como a globo. PyOpenGL. Pyro. Web2py. Pylons. CherryPy. serpro. TurboGears. a quantidade de frameworks de desenvolvimento para web vem crescendo nos últimos anos. em especial Linux. São algumas das organizações que trabalham com soluções desenvolvidas com a linguagem Python. e pela aceitação nas empresas (públicas e privadas) e instituições de ensino superior e universidades federais.12  Módulos e frameworks: Outra característica da linguagem Python é o grande número de frameworks para desenvolvimento de software. .

Existem atualmente. em 2005. que trabalha com a ideia de utilizar convenções em substituição às configurações. Assim como outros frameworks ágeis para desenvolvimento web. É 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. CherryPy e Plone. Isso agiliza muito o desenvolvimento. tornando-se assim um software de código aberto (DAVID M. . 2009.13 2. BEAZLEY. pois o mesmo possui uma melhor distribuição dos componentes existente. é possível citar alguns frameworks: Web2Py. o Django utiliza o conceito de DRY . facilitando assim o desenvolvimento e execução deste projeto. 3060).Don´t repeate yourself (Não se repita). algo raro de acontecer. diversas soluções baseadas em Python para desenvolvimento para Web. escrito em Python. Isso quer dizer que. Em virtude disso. Posteriormente. p. foi escolhido o framework django para estes projeto. não precisará ficar configurando características específicas dele. que foi criado pelo grupo editorial "The World Company" para a criação da versão web dos seus jornais. conforme características em detalhe na próxima seção. foi liberado sob a licença BSD.5 O Framework Django O Django é um framework de desenvolvimento web. se for seguir determinadas convenções na maneira de organizar seu código.

 Segurança: gerenciamento de autenticação de usuários e controle de permissões. pois é composto de vários frameworks menores. permitindo que você manipule seus objetos sem o uso de SQL (é possível acessar diretamente o banco de dados em uma aplicação Django. .O Projeto Django O Django é considerado um "superframework". que permite a administração dos objetos de negócios da sua aplicação. gerada quase que automaticamente. 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. Usados na geração de páginas dinâmicas. permitindo que ele funcione corretamente com diversos idiomas.14 2. XML. etc). JSON.  Formulários: geração automática de formulários e facilitação na manipulação dos dados enviados por meio deles.  Internacionalização: facilita a internacionalização de seus sistema. Essa camada de software abstrai toda a comunicação com seu banco de dados.5.  Sistema de Administração: O Django é um dos poucos frameworks web que disponibilizam uma interface.  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.  Template System: fornece uma linguagem para a criação de templates (HTML. mas esse tipo de uso só se torna interessante na otimização de determinadas queries).1 .

esse papel é feito por dois componentes: o URL dispatcher e as views (por isto MTV). geração de feeds (RSS/Atom). Embora não seja obrigatório o desenvolvimento usando esse paradigma. Normalmente é a parte que se comunica com o banco de dados e que persiste seus dados. sistema de cache de objetos.  View: cuida da visualização do conteúdo no formato escolhido. é possível encontrar a sigla MTV (Model-Templeate-View). Além disso. paginação de resultados etc.5. pois. No Django. o sistema de ORM frequentemente é usado na criação de nossas classes de Model. 2. sistema de testes automatizado.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. 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. p. bem como de outras partes que não envolvem o Model diretamente. serviço de mensagens (e-mail e mensagens entre usuários do sistema). No caso do Django. Isso significa que a sua aplicação tem três partes principais:  Model: contém a representação dos dados do projeto. é extremamente recomendado. há várias Views para um mesmo tipo de Model. 89-109). 2013. você estará modularizando seu código e desacoplando a camada de negócio da aplicação das camadas de interface com o usuário.  Controller: cuida do acesso e da manipulação dos dados do Model. Frequentemente. dessa forma. . o sistema de Templates é quem cumpre esse papel. No caso do Django. que representa basicamente a mesma coisa dita com palavras diferentes.15  Outros componentes: serialização de dados.

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

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.

aprimorar fundamentos teóricos. OCL e MDA. 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. em termos imediatos. segundo sua estruturação. pesquisa exploratória tem como objetivo fornecer uma explicação geral sobre um determinado tema. leitura e análise de documentos. através da delimitação do estudo. p. conceitos. Segundo (DEMO. 3. pesquisa teórica é uma pesquisa que é dedicada a reconstruir teoria. devido ao fato do principal objeto deste trabalho aplicar os conceitos de MDA para criação de um PSM (Modelo Específico de Plataforma). 2000. p. . p. 89100). ideologias. o tipo de pesquisa adotado foi o exploratório. De acordo com (OLIVEIRA. 2008. Neste contexto.1 Caracterização da Pesquisa A pesquisa realizada nesta dissertação caracteriza-se como teórica por investigar as técnicas propostas pela MDA. 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. 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.20 3. Assim sendo. 45-56). baseia-se na abordagem de pesquisa qualitativa. levantamento bibliográfico. polêmicas. tendo em vista. ideias. 23-43).

falta de treinamento necessário sobre as tecnologias aplicadas ao projeto. Mesmo assim. p. interoperabilidade. e vários problemas que antes assolavam as empresas. Nesse sentido. Segundo (SOMMERVILLE. tais como: linguagem de programação. 2011. com papéis bem definidos e atividades gerenciadas. novos problemas surgiram. Em meio a esses problemas. e atualmente o cenário de desenvolvimento de software enfrenta diversos problemas. p. 2011. (SOMMERVILLE. ferramentas de modelagem e de gerenciamento de projetos. foram mitigados. documentação e manutenção. chamada de MDA. 109-134). 43-67) Os processos de desenvolvimento melhoram bastante a forma de se desenvolver software. por exemplo. na maioria dos casos continuam gerando problemas como: produtividade. foram criadas diversas técnicas de engenharia de software como. os processos de desenvolvimento que tinham como objetivo melhor definir todas as atividades que deveriam ser seguidas até que conseguisse um produto de software. a grande pergunta que fundamentou a pesquisa foi à seguinte: Como realizar uma orquestração entre componentes de software reutilizáveis. Infelizmente com o passar dos anos.2 Problematização A atividade de desenvolvimento de software vem evoluindo nos últimos tempos. Uma abordagem que visa mudar o foco do desenvolvimento de software proposta pela OMG. portabilidade. deixando de ser uma tarefa individual para coletiva e de artesanal para baseada em modelos de Fábrica de Software.21 3. objetiva propor novas formas de realizar o desenvolvimento de software baseada no reuso de modelos abstratos de componentes. as atuais técnicas de desenvolvimento de software conseguem em parte suprir as necessidades gerenciais dentro dos projetos de software. 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. IDE. falta de gerenciamento das atividades e controle de produtividade da equipe. .

enquanto que outros serão específicos para uma plataforma alvo. Tendo em vista essa abstração. Modelo Independente de Plataforma (PIM) e Modelo Específico de Plataforma (PSM) (KLEPPE. os modelos passam a ter um papel chave dentro do processo de desenvolvimento de software. 102-145). Um modelo é frequentemente apresentado como uma combinação de desenhos e textos. a MDA define três modelos: Modelo Independente de Computação (CIM). . para formar uma implementação. Atrelando esse conceito de modelo ao universo da MDA. 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. p. 2005. Existe ainda a noção de criar diferentes modelos em diferentes níveis de abstração e depois ligá-los. Dentro da MDA. abstrata ou hipotética. utilizando a plataforma Python + Django? Uma outra contribuição deste trabalho foi a modelagem do Meta Modelo da biblioteca UML2DJ. O texto pode estar em uma linguagem de modelagem ou em uma linguagem natural (MDA GUIDE. mas de fato o que seria um modelo dentro da visão do MDA? De acordo com (MELLOR. p. 2005. os modelos representam uma parte da estrutura e/ou comportamento de um sistema. p.3 Modelos utilizados pelo MDA Como mencionado anteriormente dentro da MDA. 2003.22 baseados na arquitetura dirigida a modelos (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. 46-50). 34-59) um modelo consiste em conjuntos de elementos que descrevem alguma realidade física. Alguns desses modelos existirão independentes de plataforma de software.

Segundo o (MDA GUIDE. p. um mesmo PIM pode se utilizado para plataformas diferentes (KLEPPE.  Ser um modelo detalhado. ou seja. além de ser construído de forma a não utilizar nenhuma característica que seja específica de uma plataforma. 56-74).3. 2003.2 Modelo Independente de Plataforma O Modelo Independente de Plataforma (do inglês Platform Independent Model. O PIM deve apresentar uma independência que possa ser aplicada a diferentes plataformas alvo. acaba sendo útil para servir como fonte para um vocabulário entre modelos.23 3. sendo em geral.1 Modelo Independente de Computação O Modelo Independente de Computação (do inglês Computation Independent Model. ou seja. são especificados a estrutura e o comportamento de um sistema. Na construção do PIM.3. Ele tem como foco os requisitos do software (KLEPPE. p. esse modelo também pode ser chamado modelo de domínio. além de ajudar na comunicação entre equipe de desenvolvimento e o cliente. Algumas das características que o PIM deve possuir são:  Conter informações sobre o domínio da aplicação. representado em UML. 34-87). 56-70). modela-o considerando apenas as regras de negócios. p. . não mostra detalhes da estrutura do sistema. 3. CIM) fornece a visão de um sistema de computação dentro de uma perspectiva independente.2005. como ele é independente de plataforma. PIM) possui um alto nível de abstração por ser independente de qualquer tecnologia.  Dispensar dados sobre plataformas que serão utilizadas ou tecnologias que serão empregadas. 2003.

PSM) descreve o sistema a partir de uma plataforma específica. Figura [03]: Processo de transformação do PIM para o PSM e do PSM em código Fonte: (MELLOR.3.3. 56-80). 3. 2005) 3 Extensões UML para representar uma plataforma específica. p. A Figura 05 ilustra esse cenário (KLEPPE.4 Transformação entre modelos Outro conceito chave dentro da MDA é a transformação entre modelos. 2005. que consiste no processo de converter modelos em outros modelos do sistema. existem duas grandes transformações: a transformação do PIM para o PSM e. a transformação do PSM em código-fonte para a(s) tecnologia(s) alvo. A partir de um PIM pode-se gerar vários PSM. 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. Combina as especificações do PIM com os detalhes que mostram como o sistema usa um tipo específico de plataforma. Basicamente dentro da MDA. Essas transformações podem ser feitas de modo automatizado através de uma ferramenta de transformação.24 3. 2003).3 Modelo Específico de Plataforma O Modelo Específico de Plataforma (do inglês Platform Specific Model. . posteriormente. (MDA GUIDE. ou manualmente por uma pessoa especializada. O PSM é gerado a partir de um PIM através do uso de UML Profile3.

2003. 32-54). para o modelo PSM. ele define algum ou todo o conteúdo do modelo (MELLOR. 33-53). 2005) . 45-60). p. aumentam a qualidade do software enquanto reduz o tempo e custo de desenvolvimento. 2005. as transformações automáticas de modelos aumentam a portabilidade e a eficiência no desenvolvimento de software. Como podem ser observadas na Figura 06. As Marcas são utilizadas para inserir nos elementos do modelo PIM. que por sua vez. p. Quando um mapeamento é executado entre um modelo de origem e um modelo de destino. Isso se deve ao fato de que a ferramenta de transformação precisa ter definida uma regra de transformação. 65-109). Uma marca representa um conceito no PSM e é aplicada a um elemento do PIM. p. Dentro desse cenário. que posteriormente serão transformados. A Figura 06 representa o conceito de marcar (MDA GUIDE. para indicar como esse elemento deve ser transformado. p. 2005. Figura [04]: Processo de transformação MDA GUIDE Fonte: (MDA GUIDE. as ferramentas de transformação são umas caixas pretas. De acordo com (MELLOR. por meio do mapeamento. que descreve como o modelo deve ser transformado.25 Essas transformações ocorrem por meio de regras de mapeamento que ditam quais elementos do modelo fonte correspondem com elementos do modelo alvo. 2005. um importante conceito é o de Marcas (KLEPPE.

traduzido pelo próprio autor.5 Ciclo de vida do desenvolvimento na MDA O ciclo de vida do desenvolvimento baseado em MDA é ilustrado na Figura 07. 2003). As mesmas fases são identificadas. nele pode-se observar que o ciclo proposto pela MDA não é muito diferente do ciclo de vida tradicional de desenvolvimento de software. 41-54).26 3. Os artefatos são modelos formais. Figura [05]: Ciclo de vida do desenvolvimento baseado em MDA Fonte: (KLEPPE. ou seja. Dentro desse cenário. e código fonte são mostrados como artefatos em diferentes etapas do ciclo de vida de desenvolvimento. 2005.3. o PSM. modelos que podem ser entendidos por computadores (MELLOR. O PIM. A capacidade de transformar um PIM em um PSM eleva o nível de abstração em que um . p. Uma das principais diferenças reside nos artefatos que são produzidos durante o processo de desenvolvimento. eles representam diferentes níveis de abstração na especificação do sistema.

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

3. para outras. 2003. tudo o que você modelar ao nível do PIM. Logo o mesmo PIM pode ser automaticamente transformado em diversos PSMs para diferentes plataformas. identificar e corrigir mais erros em tempo de análise e assim produzir um modelo PIM com uma maior qualidade. Com isso. a portabilidade estará limitada a ela. pois agora o modelo de alto nível (PIM) está diretamente relacionado com o código-fonte gerado. Uma vez definida as transformações. Isso acarreta que muitas informações sobre a aplicação devem ser incorporadas no PIM e/ou na ferramenta de transformação utilizada. 2003.28 A tarefa mais difícil nesse contexto é a definição de forma exata de como serão feitas as transformações. 78-80). Se dentro do processo de desenvolvimento alguma ferramenta de automação de transformação for utilizada.8 Portabilidade Dentro da MDA. a portabilidade é conseguida com foco na modelagem do PIM. 2003. é totalmente portátil (KLEPPE. dentro do cronograma previsto. 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. 56-80). Como parte do código fonte da aplicação é gerada a partir do PSM. Essa definição é uma tarefa difícil e complexa. 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. resultando em um alto ganho de produtividade (KLEPPE. que necessita ser feita por pessoas qualificadas. 76-91). Para as plataformas mais populares já existem ferramentas que possibilitam essa automação nas transformações. p. que por definição é independente de plataforma. consequentemente. a equipe de desenvolvimento pode. p. as mesmas podem ser aplicadas para diversos projetos. é necessário ter uma ferramenta que suporte um . p. despender mais tempo para analisar as regras de negócio do sistema a ser desenvolvido e. 3.

3. 2003. Para cada elemento em um PSM.traduzida pelo próprio autor Sendo capaz de transformar um PIM em dois PSMs para duas plataformas diferentes. provendo alguma funcionalidade especial ou muito específica . p. 2003) . todas as informações necessárias para fazer a ponte entre os dois PSMs estão disponíveis. Pode-se concluir. 2003. e só conseguem se comunicar graças ao conceito de bridges definido pela MDA. portanto. 3.29 plugin4 para definição de transformações e essas definições devem ser descritas manualmente (KLEPPE. 103-120). para cada elemento PIM é conhecido qual o elemento correspondente no segundo PSM. 45-60).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. p. Figura [06]: Interoperabilidade MDA usando pontes Fonte: (KLEPPE. A Figura 08 ilustra o conceito de interoperabilidade (KLEPPE. como elementos de 4 Dentro da informática. é conhecido qual elemento do PIM o originou e. plugin é um software usado para adicionar funções a outros softwares maiores.

metamodelagem: A infraestrutura UML2 A UML2 cresceu de forma a incorporar diversas estruturas e componentes. p. p. Diagram DataType. .3. Diagram Class. os bridges entre elas.10 Documentação e Manutenção Dentro da MDA. 30-50). 3. p. 2003. 3. As mudanças realizadas no sistema irão obrigatoriamente refletir em mudanças no PIM. tornando assim a manutenção do sistema e da própria documentação menos custosa. 30-45). 2003. qualquer alteração em algum destes elementos refletirá em alterações correspondentes nos demais (KLEPPE.30 um PSM se relacionam com os elementos do segundo PSM. A documentação de mais alto nível (PIM) estará diretamente ligada à implementação do sistema. Existem ferramentas que mantêm o PIM. o que faz com que a documentação esteja sempre atualizada e de boa qualidade. ser feita uma nova geração do PSM e posteriormente do código-fonte (KLEPPE. desde que também se conheça todos os detalhes técnicos dos dois PSMs.Padrão reusável visual para modelagem estrutural básica. têm-se todas as informações necessárias para gerar uma conexão entre os dois (KLEPPE. sobre o ponto de vista de estruturas de modelagem e diagramas ela ficou dividida entre a infraestrutura (Diagram Type. Com isso. 2003. irá proporcionar a interoperabilidade das plataformas. pois a desatualização e má qualidade da documentação afetam diretamente a qualidade do software. sincronizados.4 . A utilização de ferramentas que gerem além dos PSMs. ou seja. para a partir daí. o PSM e o código-fonte gerado. proposta pela MDA. logo ele não pode ser descartado depois de construído. 34-67). 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. Diagram Package).

0 Infraestruture. uma propriedade ou atributo herda de TypedElement também herdam as características de MultiplicityElement.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. 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. 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. 2009) O Diagrama de Classe tem como característica principal a definição e criação de classes baseadas em modelo. uma Class herda de Type. Figura [07]: Infraestrutura em UML2 Meta Modelagem Fonte: (UML2. a Figura 07 exibe a estrutura de componentes do diagrama de classes conforme UML2. o TypedElement e o Type são subclasses de NamedElement e estão associadas entre si. . como subclasses dela existem o NamedElement e o Comment que se relacionam também entre si através da associação.

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

e é possível implementar uma ação relativa a si próprio através do auto-relacionamento. Figura [10]: Infraestrutura do Diagrama de Package segundo UML2 e MOF Fonte: (UML2. a classe Package herda as características do NamedElement. para simplificar esta ação um Package está associado a um Type por composição. 2009) . conforme ilustra a Figura 10. 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.0 Infraestruture.0 Infraestruture.33 Figura [09]: Infraestrutura do Fonte: (UML2.

Como o MOF é uma linguagem para criação de outras linguagens ela pode ser considerada uma metalinguagem. meta-modelo. tais . ou seja. os meta-modelos da UML2 e CWM são escritos.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.34 3. meta-meta-modelo e a camada M3 onde fica localizado o MOF2. A Figura 11 representa a visão de modelo. 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. e como não há uma camada superior para definir o MOF2. ele é definido através dele mesmo.thefullwiki. O MOF2 é a linguagem em que as definições de UML e CWM.org. O MOF2 reside na camada M3 da arquitetura dirigida a modelos (MDA). Figura [11]: Estrutura completa do MO até M3 Fonte: (http://www.

6. ou seja. 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. . como também integração com ferramentas de modelagem e transformação entre modelos.eclipse.35 como: transformações entre modelos. 2011) Um dos benefícios do uso do ECORE é a sua capacidade de alta coesão e baixo acoplamento. código fonte. geração de código. Figura [12]: Estrutura completa EMF ECORE Fonte: (http://download.org/modeling/emf/emf/javadoc/2.0/org/eclipse/emf/ecore/packagesummary. engenharia reversa.html. garantindo assim integração com linguagens e formatos diversos.

Use Case). 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. Sobre o ponto de vista comum as ações básicas incluem aqueles que realizam operações de chamada. sobre o ponto de vista de comportamento dos objetos de modelagem e diagramas ela ficou dividida nos seguintes diagramas: (Action.36 Uma das características interessante do ECORE é a possibilidade de integração com outras linguagens. Activity. ou seja. invocação de comportamento entre outros. 3. . State Machine. Interaction. Common Behavior. envio de sinal. Uma Action tem como característica principal ser uma unidade da especificação de comportamento serve como um conjunto de entrada e saída. transformações entre modelos.6 – A modelagem comportamental: superestrutura UML2 Com o crescimento da UML2 cresceu significativamente na superestrutura. Para exemplo de definição iremos detalhar apenas os diagramas de Ação e Atividades por fazerem parte do estudo deste trabalho.

2009) A atividade de modelagem enfatiza a sequência e as condições de coordenação de comportamentos de níveis inferiores.1 SuperStructure. A Figura 13 representa a estrutura completa de classes e associações relacionadas ao diagrama de atividades. No entanto. 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. 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. .37 Figura [13]: Estrutura Interna do Diagrama de Ação (Action) – UML2 e MOF Fonte: (UML2.

3. 2009) A classe Activity herda as características de uma Behavior.38 Figura [14]: Estrutura Interna do Diagrama de Atividades (Activity) – UML2 e MOF Fonte: (UML2. 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. 2013.1 SuperStructure. conforme ilustrado na Figura 16.7 – Linguagem textual para modelagem avançada: OCL2 A presente seção apresenta uma introdução ao Object Constraint Language (OCL) segundo (Dresden. conceitos e padrões relacionados à mesma. link: http://dresden-ocl. Object Constraint Language (OCL) é uma linguagem formal usada para descrever expressões e restrições sobre modelos orientados a objetos e outros . a Activity é composta de um Activity Node a mesma generaliza suas ações com uma Action e herda suas características de um NamedElement.net) e suas principais características. tendo em vista que a mesma tem um importante papel no presente trabalho.sourceforge.

não é uma linguagem de programação. 2006. A OCL foi desenvolvida para ser uma linguagem formal.39 artefatos da UML.0 (OCL. 32-48). . 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. Apesar de poder ser usada em alguns diagramas da UML. A OCL é definida como uma norma adicional a UML. entre outras coisas. 2006. possui sintaxe e semântica bem definida (OCL. sendo adotada pela OMG. p. Os diagramas UML não fornecem todos os aspectos relevantes para a especificação de um sistema orientado a objetos. tem avaliação instantânea. 5 Empresa estadunidense voltada para a área de informática. a OCL será mais utilizada em conjunto com o diagrama de classes para se obter um modelo mais completo. para o desenvolvimento desse trabalho. Algumas das características da OCL são: não possui efeitos colaterais. 34-50). é tipada. Ela foi desenvolvida inicialmente como uma linguagem de modelagem de negócios dentro da International Business Machines (IBM) 5 . Verifica-se. A atual especificação aceita pela OMG é a OCL 2. 2006. 45-89). mas que fosse fácil de ler e escrever. p. a necessidade de se descrever restrições adicionais sobre os objetos nos modelos. p. A falta dessas restrições pode levar a interpretações ambíguas de um mesmo modelo (OCL. para que possa ser usado no processo de desenvolvimento baseado em MDA e com isso se obter uma aplicação com uma maior qualidade.

o que especifica as estruturas e características de um modelo já existente e definem sua qualidade se chama metamodelagem. 56-98) a característica de representar o conhecimento de forma abstrata se chama modelar. 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.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.2 – Extensão de meta-modelo UML2 Para (WOODY. Meta-modelo UML. p. Framework OO UML e MLM. pois a mesma é adotada através da biblioteca UML2DJ. para o nosso trabalho a abordagem escolhida foi a extensão do meta-modelo UML2. Profile UML.2002. que pode lidar com qualquer tipo de informação e estrutura que se encontra durante um projeto de desenvolvimento de software. A maioria das linguagens são de GPL (General Purpose Languages).8. 3. sua característica de especializar a si próprio se chama meta-meta- .8.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. Cada DSL só pode tratar de um aspecto específico de um sistema.

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. e sim um modelo independente que representa as visões básicas e objetivas de um determinado domínio.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. partindo do princípio que o analista não precisa ter conhecimentos anteriores para poder modelar nesta visão. nem um profile. 3.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. 3.41 modelagem. fica mais fácil de entender.8. sua principal características é a simplicidade da modelagem e execução. 3. Eles são bastante confundidos com Ontologias mais de diferem no uso de sua gramática e vocabulário mais específico. isto acontece.8. o mesmo poderá implementar as características especificas diretamente utilizando somente UML2. isto é importante quando precisamos adaptar um metamodelo UML para diferentes plataformas tais como: (J2EE ou .8. Este mecanismo é consistente e segue o modelo da OMG e reusa MOF. pois o sentido de abstração e representação do conhecimento está em tudo que fazemos atualmente. desta forma os domínios podem ser alterados em tempo real ou através da modelagem de processo de negócio.NET). . 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. quando precisamos explicar determinada situação para as pessoas de forma gráfica.

3.42 No próximo capítulo serão discutidas e apresentados os detalhes sobre o estudo de caso do projeto Retriever. modelos de arquitetura.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. designer de interface e alguns detalhes de sua arquitetura com diagramas da UML. seus requisitos funcionais e não funcionais.

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. Além disso.43 4. passando pelo componente em Shell Script e da biblioteca em Python do (UML2DJ). . utilizando a linguagem Python e o framework Django. 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). 4. que permita à sua utilização através de um parser XMI. logo em seguida pelo PSM e por fim o código fonte da aplicação.1 – Definição da Ferramenta No Capítulo 3. sendo realizado de maneira assistida através de uma ferramenta chamada PyMDAGenerator. A figura 16 representa um diagrama da arquitetura da orquestração entre os componentes. foram apresentados os principais conceitos sobre Arquitetura Orientada por Modelos (MDA) e o impacto de sua utilização no desenvolvimento de software. depois pelo PIM. iniciando pela partes dos requisitos. 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.

juntamente com as ações relacionadas. que são: (a) independência de ferramenta CASE ou ambiente de desenvolvimento. neste momento o Django já reproduziu o modelo de domínio da aplicação. Neste capítulo.py e models. apresentamos uma abordagem prática para a definição e execução de transformações. (c) apoio à definição e execução de transformações modelo-modelo. . levando em consideração os critérios estabelecidos no Capítulo 3. conforme a figura 16. modelos característicos do domínio do problema através dos diagramas de classe. diagrama de casos de uso e instalação. diagrama de componentes. depois de elencados e descritos os requisitos funcionais e não funcionais. A orquestração é composta por ações relacionadas a parte de requisitos. 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.Diagrama que representa a Orquestração de componentes Fonte: Próprio autor. sendo considerados no momento.44 Figura [16]. produzindo a criação de do is arquivos admin. (b) utilização de formatos e linguagens padronizados ou de fácil aprendizado.py conforme a estrutura da caixa (PSM) no diagrama lido. 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. os mesmos são transformados em artefatos da UML juntamente com a linguagem OCL.

5 encerra o capítulo. a Seção 4.3 descreve como são definidas as transformações entre modelos. . através de marcações. (e) possibilidade de extensão das transformações pré-definidas. a Seção 4. (f) orquestração de componentes reutilizáveis de software baseado em MDA. pode ser necessária a preparação prévia do modelo a ser transformado. 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. 4. Após elaborar os modelos na sua ferramenta CASE – parte (b).2 .Visão geral da abordagem proposta Uma visão geral da abordagem proposta é exibida na Figura 17.3. 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.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.45 (d) apoio à obtenção da implementação através da geração de código (transformações modelo-texto). 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. A abordagem proposta neste capítulo abrange os cenários de transformação do tipo modelo-modelo e as transformações. Essa definição de transformações será detalhada na Seção 4. Essa marcação e a execução das transformações serão detalhada na Seção 4.4.2 apresenta uma visão geral da abordagem e suas principais características. Na Seção 4. Para executar transformações sobre 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. As próximas seções detalham esta abordagem e estão organizadas da seguinte forma: a Seção 4. apresentando algumas considerações finais.

3. 4. 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. Borland Together. Esta pesquisa teve como ponto de partida as classes do referido componente e sua execução em projetos previamente definidos. Na próxima seção será detalhado a estrutura do Meta Modelo do componente UML2DJ. este meta modelo é considerado uma grande contribuição para este trabalho. .1 .46 A Figura 17 descreve as ações de especificação do sistema de informação baseado nos requisitos do projeto. 4. 2003b). Astah. Para realizar esta modelagem foi necessário entender o funcionamento interno do componente como também suas principais características de execução. exemplo: Linguagem DDL e vice-versa. 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. ERWin. 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.3 Apoio à definição de transformações Conforme foi apresentado no capítulo anterior. pois a partir dele será possível customizar o componente para que o mesmo possa ser utilizado em outras plataformas. depois o processo de modelagem utilizando uma ferramenta.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. Estas transformações seguem uma sequência de passos que foram mencionados anteriormente. Atualmente algumas ferramentas de modelagem de dados tais como: BrModelo.

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

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". . O referido diagrama possui características tais como: A "Class" é uma meta classe da UML2DJ que herda as características de "Models. haja vista que o mesmo poderá ser reusado em outros projetos. Fonte: Próprio autor. 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 meta modelagem foi feita colocando os componentes com o nome em Inglês.48 Figura [18] Detalhes do Meta Modelo componente UML2DJ. A mesma "Property" realiza uma herança múltipla entre as classes "TypeElement" e "MultiplicityElement". Conforme a Figura 18 que relata as ações em detalhe do Meta Modelo é possível realizar as ações. 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. Um "Package" possui um auto-relacionamento com si próprio para garantir o reuso dos componentes baseado em pastas e estrutura de árvores.Visão Direita Fonte: Próprio autor. etc.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. A classe "Package" possui uma composição com a meta classe "Type". geralmente isto é feito pela ferramenta ORM nativa da plataforma alvo. tal como: SQLDB (Python). De acordo com a Figura 19. Figura [19] Detalhes do Meta Modelo componente UML2DJ . . Hybernete (Java). a classe "Db_Table" herda as características da classe "Models.

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. .Visão Tipos de Atributos. IntegerField. Operações Fonte: Próprio autor De acordo com a Figura 20. da mesma forma a classe "Operation" está associada com a Classe "Type" da UML. CharField. A mesma classe "AttributeType" está associada a classe "Operation" que descreve as operações realizadas a uma classe ou a atributos de classe. DataField.50 Figura [20] Detalhes do Meta Modelo UML2DJ . FloatField. A mesma classe "Parameter" possui uma herança múltipla com as classes "TypedElement" e "MultiplicityElement". etc são os tipos de atributos definidos. Outra associação identificada é a composição existente entre as classes "Parameter" com a classe "Operation".

visando a reutilização dos componentes do Django (SUN. um mecanismo de ORM mapeamento objeto relacional de persistência de dados. internamente existe um módulo de autenticação de usuários e perfis. um template de interface gráfica predefinido. Além disso. regras e padrões para a implementação de sistemas para web.2 . a classe "Class" está associada entre uma composição com a classe "Operation".3. estas características estão ilustradas na Figura 21. 2003. p. um mecanismo de URL Dispatcher. 34-50). o Django possui características especiais e é considerado um super framework. . 4.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".51 Figura [21] Detalhes do Meta Modelo UML2DJ .Exemplo de Arquitetura usando o Django em um Projeto Real O Django possuí um modelo de componentes que fornece um conjunto de convenções.

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

53 Figura [23] . perfil e senhas. 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. existe um outro módulo serviços diversos onde ficam localizadas as informações referentes ao models.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. Model chamado de equipamento e tipo de equipamento estes arquivos tem como características básica os aspectos de negócio da aplicação. existe um módulo de controle de usuários. este componente faz parte do framework do django. além disso. servindo de base para o nosso PSM. a descrição dos principais componentes serão apresentados na próxima página: .

py: Um utilitário de linha de comando que permite interagir com esse projeto Django de várias maneiras.org. maiores informações estão disponíveis em django-admin.py: Um arquivo vazio que diz ao Python que esse diretório deve ser considerado como um pacote Python. tais como: configuração de banco de dados. Você pode ler mais sobre URLs em URLDispatcher. . (Funciona como um arquivo principal do projeto.py.py em 7http://www. timezone. idealizado para descrever a origem e inicialização do projeto). validação dos arquivos do modelo e configuração do ambiente como um todo. É possível ler todos os detalhes sobre o manage.  settings. existem diversos comandos de execução de servidor.54 Estes componentes são:  __init__.djangobrasil. um "índice" de seu site movido a Django. criação da instância dos objetos da classe.  urls. entre outras opções.  manage.py: As declarações de URLs para este projeto Django. estruturas e modelos de configuração. Através deste arquivo é possível definir todas as configurações do projeto em geral.py e manage.py: Configurações para este projeto Django.

caso não seja implementada irá definir as características básicas desta aplicação através do template set. que possui arquivos tais como admin.suite.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.case e test.py fica responsável por executar os testes unitários da aplicação através de test.py é responsável pela representação dos dados do projeto relacionado a interface gráfica da aplicação como um todo.Componentes Internos do Django Fonte: Próprio autor Na Figura 24 é descrito o Módulo Administrador. tais características são identificadas pelo conjunto de classes que fazem parte da regra de domínio da aplicação. o arquivo models.py responsável pela identificação da sequência dos arquivos criados no models. já os arquivos tests.Model como também os módulos de arquivos relacionados à área restrita da aplicação. enquanto que ao arquivo views. .55 Figura [24] .

foi necessário transcrever tais características para modelos. para este caso o Sistema de Gestão de Inventários Hospitalares "Retriever".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.4. depois foi feita a modelagem funcional e estrutural do Projeto "Retriever". no próximo capítulo 5. a primeira chamada de CIM. 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 o PIM e por último a construção do PSM.56 4. é importante resaltar que neste momento este artefato tem como função descrever a meta modelo da aplicação. Após a coleta dos dados através de requisitos funcionais e não funcionais.google. 6 Site do UML to Django (UML2DJ) http://code.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.com/p/uml-to-django/ . Detalhes da modelagem e das classes existentes no sistema são detalhadas na figura 25. o mesmo foi realizado de forma prática através da UML pelo diagrama de classes.4. serão descritos os requisitos funcionais e não funcionais do projeto.4 . 4. como também alguns diagramas UML relatados aqui e que fazem parte da descrição de arquitetura do sistema de informação.

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

Figura [26] . são cruciais para o sucesso do projeto. neste caso "public". nela é possível identificar as características do modelo criado baseado em XMI. os atributos existentes como códigos.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. seus níveis de visibilidade. o nível de visibilidade.58 A exportação é feita através da ferramenta ARGOUML conforme Figura 26. neste caso. tais características são de fundamental importância para realizar as transformações. 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. . como também as associações e multiplicidades aplicadas ao modelo de domínio em questão.

Figura [27] . primeiro é necessário configurar o ambiente. 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. o procedimento consiste na execução do arquivo geradorMDAPSM. a mesma precisa estar instalada no ambiente do projeto. senha e administração dos papéis e usuários do sistema. na figura 27 detalha este processo e etapas. para que isto aconteça é necessário instalar o Python + Django e depois acrescentar a biblioteca libxml2. . Fonte: Próprio autor Esta figura 27 representa o procedimento de transformação de PSM para código.59 Este arquivo foi copiado para a pasta lib.sh este arquivo irá ler o XMI e realizar as referidas transformações. este procedimento encontra-se no apêndice 4 desta dissertação de mestrado.Detalhe do processo de transformação entre PSM to Código Fonte. Modelo PSM Para realizar as transformações através da biblioteca UML2DJ. 4. Template System para construir as view.sh que na sequência irá inicializar os componentes do Django URL Dispacher para construir as URL da aplicação. estes componentes integrados realizam as transformações e geram o código fonte. Do projeto feito em Python + Django e o mesmo será executado através do script em Shell chamado geradorMDAPIM.4.3 Aplicando transformações da biblioteca UML2DJ.

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.geradorMDAPIM.60 Figura [28]. A figura 28 representa o arquivo que é chamado geradorMDAPIM. .Arquivo com os comandos em Shell script .sh Fonte: Próprio autor. 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.

4. modelo execução PSM Neste ponto é possível verificar que algumas ações já foram realizadas.61 4. 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. Este aplicativo é responsável pela continuação da execução dos projetos e das ações de orquestração. maiores detalhes serão apresentados no referido apêndice III desta dissertação. 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.4 Continuando com as transformações.py syncdb.sh. isto acontece de forma automática através do comando python manage. visando consolidar as transformações foi criado um outro arquivo chamado gerarMDAPSM. 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.

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

buscou-se apresentar os procedimentos necessários de orquestração entre os componentes que deram origem à ferramenta pyMDAGenerator. como também informações detalhadas sobre o Sistema "Retriever" e "Asset Inventory".63 administrar o sistema. sendo apresentado primeiro. por último. 4. 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. dando ênfase ao modelo do framework. através do modelo CIM. 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. que vêm a ser um dos temas centrais desta pesquisa. na construção rápida de sistemas de informação para web. 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. pela criação do PIM e logo em seguida pelo PSM. nesta plataforma é importante integrar as ações e os scripts.5 . . No próximo capítulo serão apresentados o estudo de casos deste trabalho. depois.Considerações Finais deste capítulo Neste capítulo. este tem a responsabilidade de administrar a orquestração e os módulos criados na aplicação do sistema.

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.br" .Fábrica de Software do Mestrado Profissional Cesar. o mesmo será apresentado também neste capítulo.gofactory. interfaces das aplicação e demais funções dos sistema. Lembrando que o referido sistema foi desenvolvido no Mestrado Profissional em Engenharia de Software do CESAR. material hospitalar.com. roupas de cama. Além disso. medicamentos.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". vestuários e utensílio. 7 GoFactory . banco de sangue. serão abordadas a categorização dos objetivos trabalho e o estudo de caso deste sistema. requisitos funcionais e não funcionais.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. Para solucionar o problema. com suas características internas de arquitetura e modelos de componentes. 5.br "http://www.EDU turma: 2012. Devendo também manter um registro das movimentações no ambiente hospitalar.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".edu.

inclusive de vida ou contágio. tendo como consequências.65 5.2 Stakeholders. melhores serviços oferecidos aos pacientes. 5. alavancando assim. os hospitais podem utilizar e dispor. no desperdício de material e no mau uso do patrimônio hospitalar. Como consequência. 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. A combinação dessas atribuições elimina problemas frequentemente observados dentro de hospitais. 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.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. reduzindo as despesas referentes à reposição e ao transporte dos equipamentos.1. Além disso. enorme prejuízo para a organização. essas ações têm contribuído para aumentar os prejuízos como roubo e furto de itens existentes no hospital. segurança. no que se refere a infecções por exemplo. Identificadas através dos requisitos não funcionais deste projeto. os equipamentos que possuem. níveis de custos aceitáveis e competitivos para o negócio ao qual se propõe.1. O processo de gerenciamento de equipamentos ativos dentro de hospitais é algo bastante complexo e envolve risco. performance. de forma mais eficiente. .1 O impacto A ausência de controle desses ativos tem influencia direta nos custos das organizações médicas. agregando a esses serviços. etc. 5.

5.66 5.2. Sensor .  Administrador: Super usuário do Sistema.  Gestor: Gerente Administrativo do Hospital.1 Stakeholders Na engenharia de requisitos.  Segurança: Equipe de Vigilância. 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. Atores 1. Segurança 6. Basicamente.  Engenheiro clínico: Colaboradores que estão responsáveis pelo Item e blocos do Prédio. Engenheiro Clínico 5.2. os stakeholders do projeto "Retriever" podem ser divididos em cinco grupos descritos a seguir:  Enfermeiro: Colaboradores do setor de Enfermaria. Enfermagem 3. Administrador 2. Gestor 4.2.

2.3 Requisitos (funcionais e não funcionais) Os requisitos definem os serviços que o sistema deverá oferecer. São divididos em Requisitos Funcionais e Não Funcionais.67 5. o conjunto deles determina a operação do sistema. 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 . os requisitos funcionais identificados são: REF. Desta forma. 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. Os requisitos funcionais referem-se aos pressupostos que estão relacionados com a forma com que o sistema deve operar.

2.50 % dos casos.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. . RNF05 O Sistema deve garantir o acesso simultâneo de mais de 1000 usuários.68 REF. RNF04 Deve ser utilizado o GIT como repositório para o código-fonte. RNF03 As informações de login/senha dos usuários do sistema devem ser protegidas através de conexões seguras (HTTPS). 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. durante 01 minuto.

O trabalho de pesquisa e desenvolvimento do Middleware não será implementado agora.0). Português e Espanhol). RNF10 O sistema deve está adaptado para o padrão internacional (Inglês.0 e Chrome 20. contidos na documentação do sistema no apêndice desta Dissertação. RNF08 O sistema deve ser executado nos navegadores Internet Explorer 9. Isto pode ser constatado através do plano de cálculo de esforço e pontos e quebra sistemática. carga e unitários devem ser feitos de forma semi ou automática. . Escopo negativo O escopo Negativo do Projeto "Retriever" está relacionado a não evolução do módulo de tratamento de eventos (Middleware). RNF07 Para as consultas e relatórios o tempo de resposta não pode ser superior a 5 segundos. RNF09 As senhas dos usuários cadastrados no sistema devem ser criptografadas baseadas no Hash MD5.2. em virtude do escopo prioritário que é a construção do módulo WEB.69 REFERÊNCIA RNF06 REQUISITO NÃO FUNCIONAL Os testes funcionais. Tabela [2]: Requisitos Não-Funcionais Fonte: Próprio Autor 5.5. baseada nas ferramentas Selenium. Mozilla 13. Jmeter e Junit.

Diagrama de casos de uso Figura [30] .Diagrama de casos de uso "Retriever" Fonte: Próprio Autor O diagrama de casos de uso.3. entidade.1 . 5.70 5. conforme Figura 30 do projeto "Retriever" é responsável por descrever os aspectos funcionais do sistema e suas interações . estas características são importantes para descrever os aspectos arquiteturais do projeto e suas principais características. relacionamento do banco de dados e modelo lógico.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.

Figura [31] . Engenharia Clínica e Administrador. Gerenciar Movimentações.Diagrama de Classe O Diagrama estrutural da UML . entre outros. Nele é possível identificar os principais requisitos funcionais identificado neste projeto como: Gerenciar Identificadores. É importante salientar o papel dos atores Gestor.2 . e características de dependência do tipo: extends e includes.o diagrama de classes possibilita a verificação da estrutura dos dados existentes no domínio do problema. .Diagrama de classes . associações.3. generalizações. pois os mesmos são os mais importantes e interagem com as principais funcionalidades da aplicação.71 entre os atores. tornando possível identificar suas principais classes."Retriever" Fonte: Próprio Autor. Estes dados são apresentados na Figura 31. agregações. suas associações. 5. composições e estruturas de generalização. Receber Alerta de Segurança. multiplicidades. herança ou composição.

arquitetos e desenvolvedores do projeto.3. estas são classes de regras de negócio da aplicação. o play framework representa De acordo com o diagrama apresentado na Figura 32 a camada Modelo possui uma interface chamada play. já a camada de interface é caracterizada pelas interfaces gráficas da aplicação e .Model que implementas as classes do modelo conceitual do projeto. neste caso as classes Usuários e Movimentacao implementam esta interface. modelo e interface da aplicação.3 . O diagrama de componentes especifica de forma clara as camadas de negócio. andares. 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. tipos de equipamentos. s3PlantaBaixa que consiste na forma de selecionar uma figura com a representação do registro. fazer a arquitetura baseada no modelo MVC (Model View Controller) e servir de modelo para os engenheiros de software. 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.Diagrama de Componentes Este diagrama tem como objetivo descrever as características internas de componentes de arquitetura do projeto. área. 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. área. 5. De posse dessa informação fica mais fácil estabelecer a solução utilizando os conceitos de análise e projeto de sistemas. Movimentacão e ValidadorMovimentacaoImpl. equipamentos. o domínio da solução visa gerenciar as informações vivenciadas em hospitais e segmentá-las por blocos. DAO etc. Facade. Já na camada Negócio são apresentados componentes de negócio e interfaces da aplicação.72 É importante ressaltar que o domínio do problema é o sistema de gestão de inventários hospitalares. a exemplo da classe AutenticadorBD.

. apresentado na Figura 33. FrmMovimentacao e MiddlewareMovimentacao. Figura [32] .73 servem de modelo de comunicação também com o Middleware de Integração a exemplo das classes FrmUsuario. tem como característica fundamental a apresentação da visão externa dos componentes de software. 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.Diagrama de componentes . esta visão é importante para descrever as ações relacionadas principalmente a interoperabilidade e a possibilidade de integração com outros sistemas externos.Visão Interna (MVC) "Retriever" Fonte: Próprio Autor O próximo diagrama de Instalação.

Visão Externa "Retriever" Fonte: Próprio Autor 5.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.Diagrama de Instalação .4 Interfaces da aplicação e requisitos do sistema "Retriever" Nesta parte do trabalho é apresentado algumas interfaces da aplicação "Retriever". Pretendemos assim apresentar algumas interfaces do projeto em questão.74 Figura [33] . 5. desta forma é possível identificar as características visuais relacionadas ao projeto. .4.

75 Figura [34] .4. o rodapé com informações do sistema e do fornecedor.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. Ativos. entre eles. além disso existem os ícones de Home. a barra de menus com os principais menus de opção. Equipamentos e Usuários no menu principal do sistema. entre outras. o topo com o nome "Retriever". 5."Retriever" . Na Figura 35 é possível identificar o designer da aplicação. seus elementos de composição. 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.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. . Unidades.

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

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

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

Tela de Cadastro de Usuários Fonte: Próprio Autor 5.5 .4. 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. este projeto serviu de base para realizar o estudo comparativo entre o desenvolvimento tradicional e o desenvolvimento baseado em componentes com MDA. . é importante salientar que este projeto tem como fonte descrever uma ferramenta de desenvolvimento baseada em componentes utilizando o MDA (Model Driven Architecture).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"."Retriever" .5 . 5. Em vista disso.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. alterando apenas o seu domínio de negócio que agora é Inventários Patrimoniais.79 Figura [38] . este sistema possui algumas características bem parecidas com a aplicação anterior.

com as opções de alterar senha e Encerrar sessão.Tela com o menu principal do sistema Fonte: Próprio Autor 5. identificador. sensores e tipos de equipamento. na guia Auth é possível gerenciar informações sobre novos usuários do sistema e grupos de usuários relacionados. tais informações são melhor visualizadas através da Figura 40.5. . Equipamento. como também as áreas de movimentação."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. Além destas informações é possível visualizar também as ações recentes realizadas no projeto na parte lateral direita. nele existem os itens Andar.1 Tela Principal do Sistema . Bloco. Área.Sistema (Asset Inventory) . este componente faz parte do Django e já vem implementado de forma automática na aplicação."Asset Inventory" A tela principal do sistema "Asset Inventory" é composta pelo menu principal da área administrativa do sistema.80 5.5.2 Tela de Gerenciamento de Andar . Figura [39] . Entidade. Evento. tais dados são visualizados na Figura 39.

além disso. Descrição do Andar.Sistema (Asset Inventory) Tela de Cadastro de Andar Fonte: Próprio Autor 5. Figura [40] . existem as características tais como: Código. Nome e URL da imagem. 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. alteração da área e exclusão da mesma.5. . polígono. descrição."Asset Inventory" Na Figura 41 é exibida a tela de Gerenciamento de Área. além disto.81 É importante relatar as características básicas dos atributos da entidade Andar como: Código. Além do cadastro destas informações são realizadas também operacionais como listagem geral das áreas. restrita e código do andar.3 Tela de Gerenciamento de Área . alterar. background. todas as operações de manipulação do andar estão contempladas tais como: incluir. excluir e listagem geral dos andares.

4 Tela de Gerenciamento de Equipamento .5. conforme Figura 42. além disso. ."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. número identificador e tipo de equipamento. modelo do mesmo. é possível verificar algumas informações referentes aos equipamentos tais como: Código do equipamento.Tela de cadastro de área Fonte: Próprio Autor 5. código do patrimônio.82 Figura [41] . descrição do 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.Sistema (Asset Inventory) .

além disso. . data e informações sobre o identificar e sensor instalado no ambiente organizacional.Tela de Cadastro de Equipamentos Fonte: Próprio Autor 5. através desta tela é possível gerenciar informações tais como: código."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. tais informação encontra-se na Figura 43.5 Tela de Gerenciamento de Evento . é possível verificar algumas informações referentes aos eventos relacionados a movimentação dos equipamentos. 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.83 Figura [42] .5.Sistema (Asset Inventory) .

6 Considerações Finais desde capítulo Neste capítulo foi possível conhecer melhor o estudo do caso desta pesquisa.Sistema (Asset Inventory) . Com esse intuito. 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. 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.Tela de Cadastro de Eventos Fonte: Próprio Autor 5. . esta pesquisa pretende. elaborar uma ferramenta baseada em MDA (Model Driven Architecture). conforme já enfatizado. 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".84 Figura [43] . bem como. e a partir dela foi produzido o protótipo em Python + Django "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.

garantindo assim apenas 60 horas de trabalho no projeto e o desenvolvimento em apenas 02 Sprints de 8 dias cada. trabalhando 8 horas por dia durante 03 semanas de trabalho. 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.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. .py do projeto. a programação dos Scripts em Shell ajudam no processo de automação das transformações entre os modelos. Tais informações podem ser conferidas no Gráfico 2.py e models. 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.

nesta pesquisa facilitando assim o . 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.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.91 6.

00 QUANTIDADE / NÚMERO TOTAL DE ARQUIVOS GERADOS 90 82 8.00 QUANTIDADE DE HORAS DE TRABALHO REALIZADA 56 60 4.00 1158. Gráfico [4]: Gráfico com as informações estatísticas dos dois projetos.00 QUANTIDADE / NÚMERO DE CLASSES CRIADAS 54 38 16. Azul para Python e Laranja para Java Fonte: Próprio Autor .00 QUANTIDADE / NÚMERO DE SPRINTS PRODUZIDAS 2 2 - QUANTIDADE / NÚMERO DE LINHAS DE CÓDIGO SOMATÓRIO 1231.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.00 QUANTIDADE DE DIAS TRABALHADOS 13 15 2.00 QUANTIDADE DE ARTEFATOS PRODUZIDOS (UML) 14 16 2.92 QUADRO DO PROJETO COM ANDROMDA (JAVA) X PYMDAGENERATOR (PYTHON) DESCRIÇÃO JAVA PYTHON DIFERENÇA 1002 945 57.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.00 16.

a linha de Java corresponde aos indicadores aplicados ao projeto Java JEE.45% sua diferença foi de 3.17% 5. incluindo também a diferença entre os dois projetos.71%.00% 20. .87% 0.58% 17.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% QUANTIDADE / NÚMERO DE CLASSES CRIADAS 23.51% QUANTIDADE / NÚMERO TOTAL DE ARQUIVOS GERADOS 39. 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.80% e Quantidade de Horas de Trabalho realizada de 28.00% 30.11% 7.50% para 39.00% 40.17% para 24.68% 7.94% QUANTIDADE DE HORAS DE TRABALHO REALIZADA QUANTIDADE DE DIAS TRABALHADOS 24.00% 50.00% 10.45% 28.30% 38. QUANTIDADE / NÚMERO DE SPRINTS PRODUZIDAS 0.04% Java QUANTIDADE DE ARTEFATOS PRODUZIDOS (UML) Python 6.84% 0.30% a diferença foi 0.93 O gráfico de barras descreve de forma prática à diferença em formato de porcentagem entre os itens avaliados nesta pesquisa.

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.94 Outro ponto importante desta pesquisa é o número de dias trabalhados neste projeto. maiores informações sobre o projeto e a própria ferramenta podem ser https://sites.com/site/pymdagenerator2014/ Figura [44]: Página do projeto PyMDAGenerator Fonte: Próprio Autor vistos no site: .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. 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.google.

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

Modelo Específico de Plataforma . 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.96 7. O modelo de características. depois para o código objeto (executável).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. Além disso. 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. Dessa forma. redução do Time-to-market. esta característica será transformada em PSM . 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.caracterizado pelos aspectos técnicos de implementação da plataforma em questão.Modelo Independente de Plataforma através dos artefatos da UML e da linguagem de restrição ao modelo OCL. 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 . infelizmente.modelo computacional de requisitos e regras de negócio. a transformação de PSM para código fonte. 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. A experiência entre os arquitetos. depois na transformação em PIM . Entre outros benefícios estão um alto nível de reuso. entre outros.1 . CONSIDERAÇÕES FINAIS 7. permite . isto acontece de forma natural durante a transferência dos aspectos técnicos de desenvolvimento para as primeiras fases de planejamento e projeção. por último. lembrando que.

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. 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". prática e objetiva. incluindo as etapas do CIM. envolvendo as etapas de planejamento. Através da linguagem Python e do framework de desenvolvimento ágil Django. Entre as suas principais contribuições. 7. simples. 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.py de forma automática através da biblioteca UML2DJ (são os arquivos no formato *. podemos destacar:  Definição de uma orquestração de componentes reutilizáveis de software aplicado ao MDA. projeto. (2) um mecanismo para geração dos arquivos admin. Esta abordagem está dividida em três partes/componentes: PyMDAGenerator módulo PIM. (1) o reuso de uma notação para a representação explícita dos conceitos de CIM em UML. Esta dissertação apresenta uma orquestração de componentes reutilizáveis de software baseados em MDA.sh .97 uniformizar o entendimento entre todos os envolvidos no processo de desenvolvimento. PIM. utilizando a linguagem Python e o framework de desenvolvimento ágil Django. PSM e transformações para código fonte.py e models. análise. 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. implementação e testes. que visa criar um método integrado para geração de aplicações para sistemas de informações na Web. juntamente com a UML.

o Identificação das extensões necessárias para possibilitar a representação dos modelos conceituais de classe. (3) um ambiente de geração automática de tabelas e atributos seguindo o modelo ORM parecido com hibernete/JPA. PSM e Código Fonte. É 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.br. . especificamente da Fábrica de Software Gofactory. atributos e métodos na plataforma Python para o framework django. 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. Sendo a orquestração de componentes. buscando identificar as oportunidades de pesquisa existentes. por meio de um estudo realizado pelos alunos do Mestrado Profissional do Cesar.edu. É 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. 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. o Identificação dos diferentes mecanismos existentes de transformações entre modelos de PIM.98 feitos em Shell Script). (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.  Desenvolvimento de um protótipo que implementa a abordagem proposta no contexto do ambiente de orquestração. o meta-modelo da biblioteca UML2DJ e a ferramenta PyMDAGenerator as principais atribuições.

 A aplicação é restrita ao modelo de características baseado em MDA e funciona especificamente para Python com o framework Django. por exemplo utilizando o componente Dialog. máquina de estados e diagramas de sequência por exemplo.  Não foi possível gerar uma aplicação em Shell Script baseada em Interfaces Gráficas mais ricas.  Não foi possível também validar os artefatos de UML do modelo comportamental através de diagramas de atividades. 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.99 7. As principais são listadas logo a seguir:  A orquestração de componentes reutilizáveis de software é limitada através da plataforma Linux. é 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.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. 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. . nem as restrições OCL aplicados aos modelos.  Não foi realizado nenhum estudo para avaliar o protótipo desenvolvido.

100 7. como por exemplo: OSGI (OSGI ALLIANCE.  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. tanto da abordagem proposta quanto do protótipo desenvolvido. novas oportunidades de pesquisa foram identificadas. 2009).  Representação dos artefatos baseados em serviços.  Aplicação e construção do modelo específico de plataforma para outras linguagens do tipo: Java Plataforma JEE. Além disso.4 Trabalhos Futuros Ao longo do desenvolvimento deste trabalho. 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. 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.  Integração da abordagem proposta com tecnologias que suportem a reconfiguração dinâmica do modelo. a linguagem Ruby e o framework On Raills. . foram destacadas. este último já sendo testado em pequenos protótipos nas fases de criação e especificação. algumas oportunidades de melhoria.  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.

. visando garantir o uso em outras plataformas distintas. visando aproveitar as transformações de componentes da aplicação em serviços que poderão ser usados por outras aplicações.101  Criação de novos componentes que garantam a interoperabilidade através de serviços do tipo SOA/REST. aplicando novas regras de extensibilidade baseadas no MOF 2.  Melhorar a Interface gráfica da ferramenta e os recursos de configuração e gerenciamento da mesma.  Aprimorar o mecanismo de parse XML.

“Component-Based Product Line Engineering with UML”. and Stal M. 2001 Atkinson.2. Rohnert.. segurança". Bayer.tigris. and Zettel. R.4 Documentação. F. P..org/en/latest/index. Disponível em: <http://argouml. recovery. CWM. 2012 Argo UML.. Steinberg. J. Ellersick. UML Components: a Simple Process for Specifying Component-Based Software.. 2009. J. Meunier.omg. BUSCHMANN e al. Disponível em: <http://www.102 8. DANIELS.. 2013 Common Warehouse Metamodel (CWM). C. “Pattern-Oriented Software Architecture: A System of Patterns”.. NJ. 2009 Budinsky. Addison-Wesley.. 2013.org/documentation/>. REFERÊNCIAS BIBLIOGRÁFICAS ARGOUML. BEYDEDA e GRUHN. "PostgreSQL guia do programador . 2001. 2009. C. 2007 Daniel Gouveia Costa. 123. J. 2005. “Eclipse Modeling Framework: A Developer's Guide”. John. Documents ArgoUML. Merks. Laitenberger. Kamsties... DANIEL..último acesso: 12/12/2013. ATKINSON e al . 2012. 2007. John Wiley and Sons. E. T. The Component Software Series. Editora: Novatec.. F. R. Paech. ANDRÉ. Sommerlad.. 2001. "Administração de Redes com Scripts .. Lagua. Springer-Verlag New York. Addison Wesley.backup. 2005 Beydeda. and Gruhn V. CHERRYPY. 1996. B. 1996 Buschmann. “Model-Driven Software Development". S. Inc. último acesso: 11/12/2013. Editora: Brasport.. otimização. Bunse. 2013 Docs » CherryPy 3. D. E. and Grose. Wüst. 2001 CHEESMAN.html> .. O. R. Muthig. D. CHE. . Addison-Wesley. H. 2009 André Milani.org/spec/CWM/>. BYDINKSY e al. SQL.readthedocs. J.Bash Script. último acesso: 01/12/2012. Disponível em: <http://cherrypy. Secaucus.168. Python e VBScript". John.

ECORE. 2013.doc/references/overview/EMF.eclipse.org/>.eclipse. Ralph Johnson.eclipse. D.jsp?topic=/ org.103 DAVI M. 2013. DRESDEN. Disponível em: <http://help. último acesso: 05/01/2013.. 2013 Dresden OCL Toolkit.org/ganymede/index. último acesso: 25/04/2013. Disponível em: <http://help. H. M.emf.html>. último acesso: 01/02/2005. 2003.eclipse. 2013. "Padrões de Projeto Soluções reutilizáveis de software orientado a objetos".doc/references/javadoc/org/eclipse/ emf/ecore/package-summary.html>. And Fado.eclipse. último acesso: 04/01/2009. Python Essential Reference: Inglês. Bookman.djangoproject. 2013 Eclipse Modeling Framework.Validation. Penker. S. último acesso: 04/01/2013. 2009. 2013.org/help33/index. EMFV. ERIKSSON e al. 2003 Eriksson. 2004 Fowler. Disponível em: <http://www. Disponível em: <http://help. 2005 Object Management Group. “UML Diagram Interchange (DI) Specification”. Morgan Kaufmann Publishers.omg. Disponível em: <http://www. ECLIPSE. EMF. EMF. BEAZLEY. 2005. Richard Helm. B. Lyons.emf. 2013 Eclipse Project. E.emf. 2013A The Eclipse Modeling Framework (EMF) Overview.org/ cgi-bin/doc?ptc/2005-06-07>. FOWLER AND STANWICK. ISBN: 9780768687026: Ed. 2013.eclipse.org/modeling/emf/>.. V. DJANGO. último acesso: 07/08/2013. John Vlissides. Disponível <http://www. “UML 2 Toolkit”.eclipse. 2013 Django. Wiley Computer Publishing. 2009 Beazley.org/ganymede/ topic/org. Disponível em: <http://dresdenocl. 2007. último acesso: 20/03/2013. GAMMA e al. DI.eclipse. e Stanwick. 2004.com>.net/>. último acesso: 07/01/2013. 2013 Ecore.sourceforge. 2007 Erich Gamma. em: . 2009. 2009 The Eclipse Modeling Framework (EMF) Validation Framework Overview.html>. “Web Application Design Handbook: Best Practices for Web-Based Software”.jsp? topic=/org. Addison-Wesley. Disponível em: <http://www.doc/references/overview/ EMF.

<http://code. Johnson. Editora: Brasport. e Stanwick. V. Addison-Wesley. Grady Booch. “Eclipse Development Tools for Epsilon”. Disponível em: <http://code. 2006 Kolovos.2.. 2009 Google App Engine. JACOBSON. GAMMA e al. Edição: 6ª. 2013. 2006.com/apis/accounts>. Nov/2013. Addison-Wesley Professional. D. BOOCH.. Learning Python Design Patterns: Inglês. 1994..google. C.2. 2013 . GACC. JULIO. R. Paige. F. F. Eclipse Summit Europe. 2013 Google Account API. F.google. The Unifield Modeling Language Reference Manual. KOLOVOS e al. 2006a Kolovos.org/>. 2004. “Requirements for Domain-Specific Languages”. ]1ª Ed.com/appengine/>.html>. C. KOLOVOS e al. T. 1999.104 FRANKEL e PARODI. “Web Application Design Handbook: Best Practices for Web-Based Software”. último acesso: 13/07/2009. In Proceedings of the First ECOOP Workshop on DomainSpecific Program Development. 1994 Gamma. J. Ed..1 James Rumbaugh. Paige. A. 2006. Ed. Kelly. E. último acesso: 04/01/2013. Packt Publishing Ltda. Disponível em: último acesso: GAE. 05/03/2009. Helm. 2009. A. 2009 The GAE JRE Class White List. S. Disponível em: <http://www. 2002 Fowler. R. Morgan Kaufmann Publishers.google. último acesso: 29/05/2009. 2013 Gennadiy Zlobin.json. M. GAEJRE. .html>. and Polack. JavaScript Object Notation (JSON). S. RUMBAUGH. Polack.google. ZLOBIN. 2009.1. 02/01/2013.com/appengine/downloads. R. and Vlissides. 2006. 2013. R. 2006 Júlio Cezar Neves. S. Ivar Jacobson. D. Disponível em: <http://code. 2009A Google App Engine SDK for Java v. 1999 JSON.. <http://code. “Design Patterns: Elements of Reusable Object-Oriented Software”..com/intl/en/appengine/docs/java/jrewhitelis t. F. Disponível em: último acesso: GAE. "Programação Shell Linux".

Rose. MARINHO e al. T. 2008 Kolovos. "UML Essencial". 2nd OOPSLA Wsh. Disponível <http://mdr.eclipse. Paige. em: . 2009 Leavitt.105 KOLOVOS et al. 2009 Marinho. “Is Cloud Computing Really Ready for Prime Time”. Duddy. 2013 Magic Draw. IEEE..org/>. T. S. “The Epsilon Book”. MELIÁ e al. 2013 Metadata Repository. C. 2006.com/>. Proc. último acesso: 04/10/2008. 2006 Lutz. Cachero. J. MARINHO. R.netbeans. 2009. and Polack. Disponível em: <http://www. último acesso: 09/06/2013. Generative Techniques in the Context of Model Driven Architecture. Kendall Scott. “Um Framework UML2 para Modelagem de Aplicações Web dentro de um Processo de Engenharia de Software Dirigido por Modelos e Baseado em Componentes”. 2013. P. 2004. J. and Raymond. B.. “Using MDA in Web Software Architectures”. O’Reilly. 2013. 2006 Martin Fowler.. IEEE International Enterprise Distributed Object Computing Conference. Master Thesis (Master Degree) – Federal University of Pernambuco. “A Web GUI for a Multi-View ComponentBased Modeling CASE Tool”. 2003... Disponível em: <http://www. e Rayfield. Último acesso: 01/03/2013. Editora: Bookman. T. 2003 Meliá. and Robin. A. L. Pereira. MAGICDRAW. “Language Features for Re-Use and Maintainability of MDA Transformations”. 2009 LUTZ. A. D. A. 2008. MDR.. “Programming Python”. A. FOWLER e SCOTT. LEFF e RAYFIELD. 2ª Edição. e Gomez. M. 2001. 3 ed. F. 2006. J.org/gmt/epsilon/doc/book/>. 2009 Marinho. B. CRC for Enterprise Distributed Systems (DSTC). III Workshop de Desenvolvimento Rápido de Aplicações. K. W. LAWLEY. L. Innovative Technology for Computer Professionals. 2001 Leff. Machado. LEVITT. N.magicdraw. M. 2009. 2004 Lawley. M. Gerber. Recife. “Web-Application Development Using the Model/View/Controller Design Patter”.. P. K. W.

0 Metamodel in Rose”.ro/ocle/index. Eclipse OCL MDT. 2013 Object Management Group.Object Constraint Language Environment. acesso: 15/04/2013.br/~redis/mda/01-07-01. UHL. último acesso: 04/01/2012. PYMOF. 2009. SANTANA e GALESI. em: em: último .htm>.. PYYAML.1.0 Specification”.. último acesso: 04/01/2013. Novatec.eclipse. 2012. último acesso: 11/12/2013. 2013.lifl.omg.SCOTT. Octopus: OCL Tool for Precise Uml Specifications. Disponível em: <http://www. Axel. Kendall.org/modeling/mdt/downloads/?project=ocl> . Stephen J. Disponível em: <http://www.fr/~marvie/software/pyemof. último acesso: 04/01/2009. 2009 OCLMDT. 2013. "Model Driven Architecture (MDA): A Draft with anottations of issues to resolve Architecture Board ORMSC. 2001.sourceforge. 2013 PyYAML. Tríveos. 2013.org/>. 2009. OMG. Disponível <http://www. MILLER e MUKEREJI.org/spec/MOF/2.ufpe. 2010 Osvaldo Santana e Thiago Galesi. MOF. 2013 PyEMOF. 2013. 2013. último acesso: 04/01/2009. 2010.omg. OMG.106 MELLOR. Disponível em: <http://pyyaml.0 . MDA Destilada: Princípios de Arquitetura Orientada por Modelos. 2013 OCLE. Dirk.net/>.pdf>.ubbcluj.cin.2/>. Disponível <http://www2. “UML 2. 2009 OCTOPUS.org>. 2012A Object Management Group. "Python e Django Desenvolvimento ágil de aplicações web".omg.cs. Disponível em: <http://www.html>. último acesso: 03/11/2013. último acesso: 08/01/2013. Disponível em: <http://octopus.org/spec/UML/2. 2013 Object Management Group. 2005. último acesso: 10/11/2013. Disponível em: <http://lci. 2001 Joaquim Miller and Jishnu Mukereji. 2005 MELLOR. “Meta-Object Facility (MOF) 2. WEISE.0/>. Rio de Janeiro: Editora Moderna Ltda. OCLE 2. Disponível em: <http://www.

Novatec.. WEBOB.1”. "Python e Django Desenvolvimento ágil de aplicações web". 2012. J. Rio de Janeiro. WARMER e KLEPPE. GALESI. WEB2PY. . Component Software: beyond object-oriented programming. 2004 Rodrigues.htm>.com/books/default/chapter/29> - último acesso: 12/12/2013. SANTANA 2010 Osvaldo Santana e Thiago Galesi. PÁDUA . WEBOBJECT. 2011 Wilson de Pádua.1. último acesso: 04/01/2009.w3. 2010 TOGETHER. XML. Edição 3ª. Clemens. Pearson Education. 2003 Warmer. Tríveos. último acesso: 09/06/2012. Engenharia de Software Fundamentos. 1999. 2004. 9ª Edição. 2012 WebOb. 2012 Borland Together. 2013 Complete Reference Manual. SOMMERVILLE.org/XML/>. Disponível em: <http://www.html>. 2013.107 RODRIGUES. 2009 Extensible Markup Language (XML). Disponível em: <http://www.org/webob>. Ed. C. Disponível em: <http://www. SZYPERSKI. 2013 Object Management Group.omg.apple. Harlow: Addison-Wesley. “The Object Constraint Language: Getting Your Models Ready for MDA”. 2011 Engenharia de Software. último acesso: 08/01/2012. 6th Edition (pre-release).org/ technology/xml/index.html>. Disponível em: <http://www. Disponível em: <http://developer. Addison Wesley. 2 ed.web2py. último acesso: 03/03/2012. M. Kleppe. 2003.com/documentation/WebObjects/ Web_Applications/ Articles/1_Architecture. último acesso: 15/10/2013. Métodos e Padrões. 2009. Ed. 2012 “WebObjects Web Applications Programming Guide: How Web Applications Work”. 568 Páginas. XMI. v2. written by Massimo Di Pierro in English. G. “Metodologia da Pesquisa Científica”. 2011. 2012. 1999 SZYPERSKI.com/us/products/together/index. LTC gen. Disponível em: <http://pythonpaste. 2012. A. “XML Metadata Interchange (XMI). 2011.borland.

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

Referência: RF1. Atores: Gestor e Administrador Descrição: Este procedimento consiste em gerar um relatório de todos os equipamentos que passaram por um determinado ambiente. RF2 [RF03] – Gerenciar relatórios de equipamentos por ritmos in ambiente. RF3. informando data e hora de movimentação e local de origem e destino. 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. [RF01] .Autenticação de usuários e senhas. estas informações são importantes para detalhar os dados relacionados ao projeto e suas principais funcionalidades. Referência: RF1 [RF02] – Listar itens de material por setor. seus atores e suas principais referências. Tal pesquisa pode ser feita de maneira global todos os setores ou por um setor específico. Atores: Todos Descrição: Este procedimento consiste em listar todos os itens de material catalogados por setor. Referência: RF1. tal atividade implica em criar uma tela com um item para busca identificado com o nome do setor.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. RF5 . o referido relatório servirá também com ponto de auditoria do sistema.

etc. razão social. 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. CNPJ. exclusão e listagem geral de todos os hospitais. 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. alteração. Referência: RF1. alteração. senha. RF4 [RF05] – Gerar relatório por ambiente. RF6 [RF07] – Gerenciar gestor por hospital. senha. perfil avançados de . exclusão e listagem geral de todos os usuários do sistema. Referência: RF1. Outro ponto é a identificação de seus métodos tais como inclusão. Referência: FR1. FR5 [RF06] – Gerenciar hospitais. login. perfil.110 [RF04] – Gerenciar usuários. etc. Outro ponto é a identificação de seus métodos tais como inclusão. além de alterar a senha do usuário atualmente conectado no sistema. 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. 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. descrição do hospital.

níveis de permissão. RF4. RF7 [RF08] – Registrar alertas emitidos Atores: Administrador Descrição: Este procedimento consiste em registrar todos os alertas emitidos pelos sensores no hospital. etc. 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. delegação de nível. 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. etc. Gestor e Administrador. RF6. Referência: RF1. eventos tais como: materiais que não podem entrar em determinados ambientes do tipo UTI. Referência: RF1. controle de acesso a recursos específicos do hospital. 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. Outro ponto é . RF9. Todos. alteração. [RF11] – Gerenciar Prédios e Blocos Atores: Engenharia Clínica. etc. Outro ponto é a identificação de seus métodos tais como: delegação de função. Referência: RF1. Localização. Referência: RF1.111 administração do hospital. descrição prédio. 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. Salas de Cirurgias.

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. 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. exclusão e listagem geral de todos os prédios e blocos. RF13 [RF14] – Gerenciar Áreas. etc. descrição. exclusão e listagem geral de todas as áreas. exclusão e listagem geral de todos os equipamentos. localização da Etiqueta RFID. alteração. RF14 [RF15] – Gerenciar Andares. descrição. localização dos sensores. alteração. Outro ponto é a identificação de seus métodos tais como inclusão. 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. Outro ponto é a identificação de seus métodos tais como inclusão. tipo. etc. Referência: RF1. RF11 [RF12] – Listar Itens na Tela de Início do Sistema Atores: Engenharia Clínica. Atores: Engenharia Clínica . Referência: RF1. Referência: RF1.112 a identificação de seus métodos tais como inclusão. alteração. tipo. Referência: RF1.

RF15 [RF16] – Gerenciar Movimentações. alteração. RF16 [RF17] – Gerenciar Identificadores (label) Etiquetas. Outro ponto é a identificação de seus métodos tais como inclusão. data da movimentação. Referência: RF1. tipo. descrição. observações. Outro ponto é a identificação de seus métodos tais como inclusão. Outro ponto é a identificação de seus métodos tais como inclusão. 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. Referência: RF1. localização. hora da movimentação. etc. descrição. alteração. exclusão e listagem geral de todos os identificadores. tipo. etc. exclusão e listagem geral de todas as movimentações. exclusão e listagem geral de todos os andares.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. 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. alteração. tipo de equipamento e material. RF15 [RF18] – Gerenciar Sensores. Atores: Engenharia Clínica . etc. localização no prédio. Referência: RF1.

RF20 . além de mensagem de voz para o segurança de plantão. MMS e Email. Referência: RF1. RF19 [RF20] – Receber alerta de segurança. Referência: RF1. etc. RF18 [RF19] – Alertar Movimentação Indevida. localização. Descrição: Este procedimento consiste em enviar uma mensagem por SMS. Outro ponto é a identificação de seus métodos tais como inclusão. descrição. alteração. tipo.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. Atores: Sensor / Segurança. 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. exclusão e listagem geral de todos os andares. etiqueta RFID.

. Nesta sessão são apresentados os diagramas da UML e demais características do sistema.115 Apêndice 2 Modelos de Diagramas da UML / Arquitetura do Projeto e Artefatos de Análise e Especificação do Sistema. Diagrama de Casos de Uso do Sistema de Gerenciamento de Inventários Hospitalares "Retriever". relacionados ao projeto Retriever e demais ações.

116 Diagrama de Classes do Sistema. . sistema Retriever. Diagrama do Modelo ER (Entidade Relacionamento)..

.117 Diagrama do Modelo Lógico do Sistema "Retriever".0 Framework.Visão Arquitetura do Play 2. Diagrama de Componentes do Sistema .

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

"poligono" varchar(50) NOT NULL. "codigo" varchar(5) NOT NULL. "descricao" varchar(50) NOT NULL. "andar_id" integer ). CREATE TABLE "Administrador_area" ( "id" integer NOT NULL PRIMARY KEY. "retrita" integer. . CREATE TABLE "Administrador_tipoequipamento" ( "id" integer NOT NULL PRIMARY KEY. seus atores e suas principais referências. estas informações são importantes para detalhar os dados relacionados ao projeto BEGIN. "urlimagem" varchar(50) NOT NULL ). "descricao" varchar(50) NOT NULL. Nesta sessão serão apresentadas algumas informações mais detalhadas sobre os requisitos funcionais do projeto.119 Apêndice 3 Glossário do Banco de Dados com Script (DDL). CREATE TABLE "Administrador_identificador" ( "id" integer NOT NULL PRIMARY KEY. "codigo" integer. "background" varchar(50) NOT NULL.

"nomeEntidade" varchar(50) NOT NULL. "localizacao" varchar(40) NOT NULL. "tecnologia" integer ). "modelo" varchar(40) NOT NULL. "epc" varchar(50) NOT NULL. "sensorid_id" integer NOT NULL ("id")). "descricao" varchar(50) NOT NULL. "tecnologia" integer ). "codigo" integer. CREATE TABLE "Administrador_sensor" ( "id" integer NOT NULL PRIMARY KEY. REFERENCES "Administrador_sensor" .120 "cod" integer. "codigo" varchar(50) NOT NULL. "codigo" integer. "data" date. "codigo" integer. CREATE TABLE "Administrador_evento" ( "id" integer NOT NULL PRIMARY KEY. "identificadorold_id" integer NOT NULL REFERENCES "Administrador_identificador" ("id"). CREATE TABLE "Administrador_entidade" ( "id" integer NOT NULL PRIMARY KEY.

CREATE TABLE "Administrador_bloco" ( "id" integer NOT NULL PRIMARY KEY. CREATE TABLE "Administrador_andar" ( "id" integer NOT NULL PRIMARY KEY. "Administrador_entidade" .121 "endereco" varchar(50) NOT NULL. "descricao" varchar(50) NOT NULL. "entidade_id" integer NOT NULL REFERENCES ("id")). "status" integer ). "fone" varchar(30) NOT NULL. "descricaoAndar" varchar(50) NOT NULL. "codigo" integer. "urlimagem" varchar(50) NOT NULL ). "nome" varchar(50) NOT NULL. "codigo" integer.

"equipamento_id" integer NOT NULL REFERENCES "Administrador_equipamento" ("id"). "patrimonio" varchar(50) NOT NULL. "codigo" integer. "model" varchar(50) NOT NULL. "descricao" varchar(50) NOT NULL. "coordenadas_X" integer. CREATE TABLE "Administrador_equipamento" ( "id" integer NOT NULL PRIMARY KEY. "evento_id" integer NOT NULL REFERENCES "Administrador_evento" ("id"). CREATE TABLE "Administrador_movimentacao" ( "id" integer NOT NULL PRIMARY KEY. "andar_id" integer NOT NULL REFERENCES "Administrador_andar" ("id"). "areaCompleta" integer ).122 CREATE TABLE "Administrador_s3plantabaixa" ( "id" integer NOT NULL PRIMARY KEY. "identificador_id" integer NOT NULL REFERENCES "Administrador_identificador" ("id"). "bloco_id" integer NOT NULL REFERENCES "Administrador_bloco" ("id"). "entidade_id" integer NOT NULL REFERENCES "Administrador_entidade" ("id"). . "tipo_id" integer NOT NULL REFERENCES "Administrador_tipoequipamento" ("id")). "coordenadas_Y" integer.

CREATE INDEX "Administrador_evento_17578276" ON "Administrador_evento" "Administrador_evento_3e5e76b5" ON "Administrador_evento" "Administrador_bloco_1c4c4e74" ON "Administrador_bloco" ("identificadorold_id"). CREATE INDEX "Administrador_movimentacao_7f0e96d9" ON "Administrador_movimentacao" ("equipamento_id"). CREATE INDEX ("sensorid_id"). CREATE INDEX "Administrador_movimentacao_3bc48ff9" ON "Administrador_movimentacao" ("andar_id"). CREATE INDEX "Administrador_equipamento_4c2413d6" ON "Administrador_equipamento" ON "Administrador_equipamento" ("identificador_id"). CREATE INDEX "Administrador_movimentacao_202f16e9" ON "Administrador_movimentacao" ("area_id"). CREATE INDEX ("entidade_id"). COMMIT. CREATE INDEX "Administrador_equipamento_27e4f492" ("tipo_id"). CREATE INDEX "Administrador_movimentacao_10cac466" ON "Administrador_movimentacao" ("bloco_id"). CREATE INDEX "Administrador_movimentacao_1c4c4e74" ON "Administrador_movimentacao" ("entidade_id"). .123 "area_id" integer NOT NULL REFERENCES "Administrador_area" ("id")). CREATE INDEX "Administrador_movimentacao_213b366b" ON "Administrador_movimentacao" ("evento_id").

py files %s application [/d] [/s] [/r] /d drop all the tables used by that application.. mysql.argv) < 2): print """Converts a XMI file to a models. python) .124 Apêndice 4 Biblioteca UML2DJ. USE WITH CAUTION! /s run syncdb /r run django web server .g. ''' uml2dj.py and admin..py Run without arguments to see the documentation @author: Goffer Looney TODO: detect failures of external command calls (e. ''' import libxml2 import libxslt import sys import re import os def start(): if (len(sys.

py" % app_name): print '%s module not found' % (app_name) exit(1) if not os.exists("%s/__init__.argv[1:]: if (re.sep)[2] app_name = sys.exists("%s. arg)): allchars += arg[1:2] pass if 'd' in allchars: print 'Drop tables' .match('^/\w$'.path.%s' % (prj_name.%s' % (prj_name.path.INSTALLED_APPS: print 'Application not installed %s.argv[0] else: import settings import os prj_name = os. app_name) not in settings.argv[1] if '%s.xmi """ % sys.xmi not found' % (app_name) exit(1) allchars = '' for arg in sys.125 XMI file must be in the current directory and its name is [application].getcwd(). app_name) exit(1) if not os.xmi" % app_name): print '%s.rpartition(os.

strip()) # import subprocess # ret = subprocess.sql' % app_name) run_command('mysql -u %s --password=%s %s < droptables. settings. xmi_file.py') transform('xmi2djadmin. app_name+'/models_generic. command. app_name+'/admin.py') transform('xmi2djadmin_custom.DATABASE_USER. xmi_file.xsl'.DATABASE_PASSWORD. xmi_file.py') def run_command(command): # args = re.py runserver') def generate_code(app_name): xmi_file = '%s. app_name+'/_models. xmi_file. app_name+'/admin_generic.xsl'. settings.sql' (settings.xsl'.xmi' % app_name transform('xmi2djmodels.py syncdb') if 'r' in allchars: print 'Run Server' result = run_command('python manage.py') transform('xmi2djmodels_generic.py sqlclear %s > droptables.126 run_command('python manage.call(args) # return ret % .xsl'. app_name+'/_admin_custom.xsl'.DATABASE_NAME)) print 'Generate code' generate_code(app_name) if 's' in allchars: print 'Sync DB' import settings result = run_command('python manage.split('\s+'. xmi_file.py') transform('xmi2djadmin_generic.

parseFile(xslt) style = libxslt.applyStylesheet(doc.saveResultToFilename(target.freeDoc() result.freeDoc() start() . 0) style. None) style.freeStylesheet() doc. result.parseStylesheetDoc(styledoc) doc = libxml2.system(command) return ret def transform(xslt.parseFile(source) result = style.127 import os ret = os. target): styledoc = libxml2. source.

py em models. # Sistema Comentário sobre o Sistema - Ferramenta pyMDAGenerator # Autor Comentário sobre o Autor. Este comando irá gerar os arquivos models. if [ $RESPOSTA = s ] then Este comando é responsável por realizar uma decisão.py. # SubMódulo Comentário sobre o SubMódulo. mv /administrator/_admin_custom. _admin_custom.py na estrutura . echo "Lendo os dados do Arquivo XMI.py e admin.py Na próxima execução o comando python manage. 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. 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.128 Apêndice V SCRIPT EM SHELL comandos com as transformações.py em renomear admin_custom.py admin_custom. Comando Descrição #!/bin/bash Comando que serve para inicializar o script e executar os comandos da linguagem Shell (Interpretador).py syncdb é responsável por executar as transformações do arquivos models.py e _models.py em sua pasta sleep 2 ProjetoRetriever.

py ações e parâmetros de configuração do projeto através do arquivo settings..py echo "Aplicando as transformações no models.." sleep 5 nano settings.sh Fi if [ $RESPOSTA = n ] then Este comando irá interromper o script e demais ações. e demais ações do echo "[PIM]-Fazendo as projeto em si.." sleep 3 exit fi "Execução Interrompida do .py. tranformações para o [PSM] Django Por Python" fim será chamado o arquivo geradorMDAPSM./geradorMDAPSM. como também os links simbólicos.129 Comando Descrição do banco de dados...." sleep 2 ... echo Script:.py syncdb echo "Aplicando as mudanças no settings.sh que ficará responsável pela continuação.. O próximo passo é verificar as mv /administrador/_models.py. nele são exibidas informações de configuração do projeto.py models.py. sleep 4 python manage.

130 Tabela [1]: Tabela com os comandos arquivo geradorMDAPIM. Depois o sleep 2 comando python manage..." então será realizado o comando python manage.. O comando read read RESPOSTA RESPOSTA armazena o valor digitado na variável RESPOSTA.py syncdb que irá atualizar o banco de dados e as informações de persistência do sistema.. # Sistema Comentário sobre o Sistema - Ferramenta pyMDAGenerator # Autor Comentário sobre o Autor. O próximo comando será o python Python" manage.. 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. # SubMódulo Comentário sobre o SubMódulo." o servidor de .py sqlall irá exibir todos os comandos realizados para criação da estrutura python manage.. se a resposta for igual a s echo "Realizando as Transformações de PIM para PSM. echo "[PIM]-Fazendo as modelo este que será aplicado neste exemplo do tranformações para o [PSM] Django sistema.sh Fonte: Próprio Autor.py syncdb de dados (banco de dados) da aplicação em si. Comando Descrição #!/bin/bash Comando que serve para inicializar o script e executar os comandos da linguagem Shell (Interpretador).py sqlall echo "Startando aplicações . Posso continuar? [sn] " mensagem na tela e fica aguardando a resposta se [s para SIM] ou [n para NÃO]. if [ $RESPOSTA = s ] then Este comando tem como característica realizar uma decisão através do IF. echo "Continuar com as O comando echo é responsável pela exibição da transformações.

.sh Fonte: Próprio Autor .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.131 Comando Descrição sleep 5 python manage.