Embed Size (px)
Citation preview
TÂNIA EIKO EISHIMA
PROPOSTA DE UM PROCESSO DE DESENVOLVIMENTODE SOFTWARE ORIENTADO A MODELO
LONDRINA–PR
2014
TÂNIA EIKO EISHIMA
PROPOSTA DE UM PROCESSO DE DESENVOLVIMENTODE SOFTWARE ORIENTADO A MODELO
Trabalho de Conclusão de Curso apresentadoao curso de Bacharelado em Ciência da Com-putação da Universidade Estadual de Lon-drina para obtenção do título de Bacharel emCiência da Computação.
Orientador: Profa. Dra. Jandira GuenkaPalma
LONDRINA–PR
2014
TÂNIA EIKO EISHIMA
PROPOSTA DE UM PROCESSO DE DESENVOLVIMENTODE SOFTWARE ORIENTADO A MODELO
Trabalho de Conclusão de Curso apresentadoao curso de Bacharelado em Ciência da Com-putação da Universidade Estadual de Lon-drina para obtenção do título de Bacharel emCiência da Computação.
BANCA EXAMINADORA
Profa. Dra. Jandira Guenka PalmaUniversidade Estadual de Londrina
Orientador
Prof. Dr. Daniel dos Santos KasterUniversidade Estadual de Londrina
Prof. Dra. Cintyan Renata Sachs C. deBarbosa
Universidade Estadual de Londrina
Londrina–PR, 20 de novembro de 2014
Aos meus familiares.Desculpem-me por estar longe de vocês.
AGRADECIMENTOS
Agradeço ao Grande Arquiteto do Universo por permitir que eu chegasse até aquie sobrevivesse longe de casa. Graças à essa experiência pude descobrir as ilimitações doconhecimento e algumas de minhas limitações.
Ao meu avô (ditian) Naohite Nakasato por todo amor e dedicação. Sua sede porconhecimento é sempre uma inspiração para mim. Aos meus pais, Silvio Iuji Eishima eYurico Nakasato Eishima e à minha irmã, Raquel Sumie Eishima, agradeço por seremmeu alicerce e minhas referências de boa índole.
À minha orientadora Prof. Dra. Jandira Guenka Palma por todos os ensinamentoscompartilhados, pelo espírito empreendedor contagiante e por todas as oportunidadesapresentadas à mim.
À todos os professores e funcionários pela colaboração na construção do meu apren-dizado. Aos professores Jacques Duílio Brancher, Rodolfo Miranda de Barros e MariaAngélica Camargo-Brunetto pela oportunidade de trabalhar em seus projetos e conhecerdiferentes áreas de atuação dentro da computação.
Ao professor Fábio Sakuray, agradeço pela boa recepção durante o período deestudos no laboratório. Ao pessoal da empresa Guenka Software, obrigada pelo suporte econhecimento dividido durante os meses de estágio.
Agradeço aos meus amigos José Henrique Santana Quinto, Luana Thayse Moreirae Naiara Calvi Oliveira, pelo companheirismo que ultrapassa quilômetros de distância.
Aos meus amigos: Carolina Massae Kita, Débora Tieme Hiroki, Estefânia MayumiFuzyi, Gilson Doi Junior, Jheyne Nayara Ortiz, Jonas Tosti, Laura Cristina do EspíritoSanto, Letícia de Cássia Santin, Luckas André Farias, Pedro Sena Tanaka e Rafael SeidiShigueoka, pela troca de conhecimentos e pela alegria da convivência.
Agradeço aos meus companheiros rondonistas e aos meus parceiros do Ramo Es-tudantil IEEE-UEL por me acompanharem na descoberta de mundos além das paredesdas salas de aula.
À todos os moradores e ex-moradores do Pensionato Albatroz pela experiência decompartilhar os dias com pessoas que me ensinam algo novo todos os dias.
“Most of the goals presented here are not new. On the contrary, they representsomething like the IT industry’s ‘Holy Grail’: no-one is inclined to believe in beneficial
promises anymore, and rightly so. But if you take a look at the history of IT orcomputer science, you can see that an ongoing evolution is taking place.”
(Markus Völter, Model-Driven Software Development - Technology, Engineering,Management, sobre os objetivos do MDD)
EISHIMA, T. E.. Proposta de um processo de desenvolvimento de software ori-entado a modelo. 76 p. Trabalho de Conclusão de Curso (Bacharelado em Ciência daComputação) – Universidade Estadual de Londrina, Londrina–PR, 2014.
RESUMO
O desenvolvimento de software orientado a modelos (Model-Driven Development - MDD)é uma abordagem que vem se destacando na indústria e na academia. Ele consiste na utili-zação de modelos de alto nível de abstração para a representação dos requisitos do sistemae para a geração de código fonte. Dessa forma, o MDD é apresentado como um meio parafacilitar a manutenção de software, a comunicação entre as pessoas envolvidas na suaconstrução e maior portabilidade de plataformas para as soluções criadas. Diante dessasvantagens, esse trabalho tem como objetivo apresentar um processo de desenvolvimentode software orientado a modelos seguindo o nível básico do modelo de maturidade emMDD.
Palavras-chave: MDD, desenvolvimento orientado a modelos, processo de desenvolvi-mento de software, rastreabilidade de modelos.
EISHIMA, T. E.. Proposal for development process to Model-Driven Develop-ment. 76 p. Final Project (Bachelor of Science in Computer Science) – State Universityof Londrina, Londrina–PR, 2014.
ABSTRACT
The Model-Driven Software Development (MDD) is an approach that has emerged inindustry and academia. It uses models to represent requirements in high-level and to gen-erate source code. Therefore, MDD presented as a way to facilitate software maintenance,communication between stakeholders and enhanced portability platforms for the solutionscreated. Given these advantages, this paper aims at presenting a software developmentprocess following the basic level of the MDD Maturity Model.
Keywords: MDD, Model-Driven Development, software development process, model’straceability.
LISTA DE ILUSTRAÇÕES
Figura 1 – Representação da engenharia de software em camadas [1]. . . . . . . . 23Figura 2 – Representação do modelo cascata [2]. . . . . . . . . . . . . . . . . . . . 24Figura 3 – Representação do modelo de processo incremental [1]. . . . . . . . . . . 25Figura 4 – Representação do modelo de prototipagem [1]. . . . . . . . . . . . . . . 26Figura 5 – Representação do modelo espiral [1]. . . . . . . . . . . . . . . . . . . . 27Figura 6 – Representação do modelo concorrente [1]. . . . . . . . . . . . . . . . . 28Figura 7 – Representação do processo unificado [1]. . . . . . . . . . . . . . . . . . 28Figura 8 – Diagramas da UML[3]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Figura 9 – Exemplo de diagrama de casos de uso [3]. . . . . . . . . . . . . . . . . 32Figura 10 – Exemplo de diagrama de atividades [3]. . . . . . . . . . . . . . . . . . . 33Figura 11 – Exemplo de diagrama de classes [3]. . . . . . . . . . . . . . . . . . . . . 34Figura 12 – Exemplo de diagrama sequência [3]. . . . . . . . . . . . . . . . . . . . . 34Figura 13 – Exemplo de diagrama de máquina de estados [3]. . . . . . . . . . . . . 35Figura 14 – Principais elementos do MDD [4]. . . . . . . . . . . . . . . . . . . . . . 38Figura 15 – Hierarquia de modelos [5]. . . . . . . . . . . . . . . . . . . . . . . . . . 40Figura 16 – Modelo de Maturidade em MDD [4]. . . . . . . . . . . . . . . . . . . . 42Figura 17 – Exemplo de diagrama de conexão entre elementos no Enterprise Archi-
tect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Figura 18 – Modelo de processo da abordagem. . . . . . . . . . . . . . . . . . . . . 49Figura 19 – Metodologia proposta. . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Figura 20 – Fases da Iteração Inicial. . . . . . . . . . . . . . . . . . . . . . . . . . . 56Figura 21 – Fases da Iteração de Desenvolvimento. . . . . . . . . . . . . . . . . . . 56Figura 22 – Proposta: Fase de Planejamento. . . . . . . . . . . . . . . . . . . . . . 60Figura 23 – Organizar Cenários. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Figura 24 – Diagrama de Caso de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . 62Figura 25 – Ligação entre requisito e caso de uso. . . . . . . . . . . . . . . . . . . . 63Figura 26 – Representação do UC003- Escolher Pizza. . . . . . . . . . . . . . . . . 63Figura 27 – Proposta: Fase de Análise. . . . . . . . . . . . . . . . . . . . . . . . . . 64Figura 28 – Exemplo de um protótipo de interface de um caso de uso. . . . . . . . 65Figura 29 – Elaboração de diagramas. . . . . . . . . . . . . . . . . . . . . . . . . . 65Figura 30 – Exemplo de diagrama de pacotes. . . . . . . . . . . . . . . . . . . . . . 66Figura 31 – Elaboração de diagrama de classes. . . . . . . . . . . . . . . . . . . . . 66Figura 32 – Elaboração de diagrama de sequência. . . . . . . . . . . . . . . . . . . 67Figura 33 – Proposta: Fase de Projeto. . . . . . . . . . . . . . . . . . . . . . . . . . 68Figura 34 – Proposta: Fase de Construção. . . . . . . . . . . . . . . . . . . . . . . . 69Figura 35 – Geração de Código em Java. . . . . . . . . . . . . . . . . . . . . . . . . 70
LISTA DE TABELAS
Tabela 1 – Ferramentas CASE Comerciais [6]. . . . . . . . . . . . . . . . . . . . . 36Tabela 2 – Ferramentas UML Open Source. . . . . . . . . . . . . . . . . . . . . . 36Tabela 3 – Modelo de Maturidade em MDD [7]. . . . . . . . . . . . . . . . . . . . 44Tabela 4 – Características do MDD no nível básico. . . . . . . . . . . . . . . . . . 54Tabela 5 – Template de descrição de Casos de Uso. . . . . . . . . . . . . . . . . . 59Tabela 6 – Template do formato de declaração dos requisitos. . . . . . . . . . . . . 60Tabela 7 – Planejamento: Documento de Auditoria. . . . . . . . . . . . . . . . . . 61Tabela 8 – Template do formato de declaração do caso de uso. . . . . . . . . . . . 61Tabela 9 – Template do formato de declaração do caso de uso refente ao mesmo
requisito. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Tabela 10 – Formato da nomenclatura de atividades. . . . . . . . . . . . . . . . . . 62Tabela 11 – Análise: Documento de Auditoria. . . . . . . . . . . . . . . . . . . . . . 67Tabela 12 – Projeto: Documento de Auditoria. . . . . . . . . . . . . . . . . . . . . 69Tabela 13 – Construção: Auditoria. . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
LISTA DE ABREVIATURAS E SIGLAS
CASE Computer-Aided Software Engineering
CIM Computational Independent Model
DSL Domain-Specific Language
MDA Model-Driven Architecture
MDD Model-Driven Development
MOF Meta-Object Facility
OMG Object Management Group
OMT Object Modeling Technique
OOSE Object-Oriented Software Engineering
PIM Platform Independent Model
PSM Platform-Specific Model
UML Unified Modeling Language
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2 PROCESSO DE SOFTWARE . . . . . . . . . . . . . . . . . . . 232.1 Modelo de Processo de Software . . . . . . . . . . . . . . . . . . 232.1.1 Modelo Cascata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.1.2 Modelo de Processo Incremental . . . . . . . . . . . . . . . . . . 242.1.3 Prototipagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.1.4 Modelo Espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.1.5 Modelo Concorrente . . . . . . . . . . . . . . . . . . . . . . . . . . 262.1.6 Modelo Especializado . . . . . . . . . . . . . . . . . . . . . . . . . 262.1.7 Processo Unificado . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2 Desenvolvimento Ágil . . . . . . . . . . . . . . . . . . . . . . . . . 272.3 Modelagem de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . 302.3.1 Unified Modeling Language . . . . . . . . . . . . . . . . . . . . . 302.3.2 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3 DESENVOLVIMENTO ORIENTADO A MODELO . . . . . . 373.1 Propriedades do MDD . . . . . . . . . . . . . . . . . . . . . . . . . 373.2 Modelagem de domínio . . . . . . . . . . . . . . . . . . . . . . . . 403.3 Desenvolvimento Orientado a Arquitetura . . . . . . . . . . . . 413.4 Modelo de Maturidade de MDD . . . . . . . . . . . . . . . . . . 423.5 Ferramentas de modelagem UML . . . . . . . . . . . . . . . . . . 453.6 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . 473.6.1 Metodologia para Colaboração B2B em Desenvolvimento Ori-
entado a Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.6.2 Uma Abordagem Orientada a Modelos para reutilização de
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.7 Vantagens e Desvantagens do MDD . . . . . . . . . . . . . . . . 50
4 PROPOSTA DA METODOLOGIA . . . . . . . . . . . . . . . . 534.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.1.1 Atividades da Fase de Comunicação . . . . . . . . . . . . . . . . 584.1.2 Atividades da Fase de Planejamento . . . . . . . . . . . . . . . . 594.1.3 Atividades da Fase de Organização de Cenários . . . . . . . . . 614.1.4 Atividades da Fase de Análise . . . . . . . . . . . . . . . . . . . . 644.1.5 Atividades da Fase de Projeto . . . . . . . . . . . . . . . . . . . . 68
4.1.6 Atividades da Fase de Construção . . . . . . . . . . . . . . . . . 694.1.7 Atividades da Fase de Emprego . . . . . . . . . . . . . . . . . . . 704.2 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
21
1 INTRODUÇÃO
A utilização de software está em constante expansão. Eles não fazem parte apenasdo computador, mas compõem caixas eletrônicos, celulares, televisões e geladeiras. Dianteda sua ampla forma de utilização e comunicação entre eles, os sistemas computacionaistornam-se muito complexos.
Os sistemas estão em constante mutação e a forma de desenvolvimento aplicadamuitas vezes gera lacunas que comprometem a qualidade do produto. Destaca-se a desa-tualização e desuso da documentação de requisitos e dos modelos produzidos no início doprocesso de produção do software.
O objetivo desse trabalho é propor uma metodologia de desenvolvimento orien-tado a modelo para uma pequena empresa. Para obter essa metodologia é necessáriocompreender as características do MDD, assim como os aspectos dos processos clássicos.
O Capítulo 2 explana sobre os ciclos de vida de desenvolvimento de software, iden-tifica seus processos e as formas de modelagem aplicadas nesses processos. O Capítulo 3descreve a forma de construção de um modelo através da abordagem de desenvolvimentoorientado a modelos. Apresenta as propriedades do MDD, conceitos de modelagem dedomínio, desenvolvimento orientado a arquitetura, o modelo de maturidade e ferramentasque suportam suas características. No Capítulo 4 a proposta da metodologia de desenvol-vimento é apresentada e na seção 4.2 são feitas as considerações finais. Para finalizar oCapítulo 5 apresenta as conclusões dos resultados alcançados.
23
2 PROCESSO DE SOFTWARE
A engenharia de software é a aplicação de uma abordagem sistemática, discipli-nada e quantificável para o desenvolvimento, operação e manutenção do software. Ela écaracterizada como uma tecnologia em camadas e seu alicerce é o nível de processo [8],como representado na Figura 1.
Figura 1 – Representação da engenharia de software em camadas [1].
Um processo de software é um conjunto de ações compostas por atividades [1, 9, 2].Diferentes abordagens organizam suas ações e atividades de maneiras distintas e sãodescritas em diferentes níveis de detalhes [2]. Os processos de software são a base para ocontrole gerencial de projetos de software e estabelecem o contexto no qual os métodostécnicos são aplicados, os produtos de trabalho (modelos, documentos e formulários) sãoproduzidos, os marcos são estabelecidos, a qualidade é assegurada e as modificações sãoadequadamente geridas [8].
2.1 Modelo de Processo de Software
Um modelo de processo de software é uma descrição simplificada de um processode software [2]. Com o objetivo de orientar o processo de software, vários modelos forampropostos: modelo cascata, modelo de processo incremental, modelo de processo evoluci-onário, modelo especializado e processo unificado [8].
Há diversas variações de processos de software. Algumas organizações idealizaramabordagens completamente diferentes para o desenvolvimento de seus produtos. Os pro-cessos evoluíram para explorar a capacidade das pessoas em uma organização, assim comoas características específicas dos sistemas que estão sendo desenvolvidos [2].
São classificados como modelos evolucionários: a prototipagem, o modelo espirale o modelo concorrente. Nessa seção serão apresentados alguns dos modelos de processoexistentes na literatura.
24
2.1.1 Modelo Cascata
O modelo cascata foi o primeiro modelo de processo de desenvolvimento de softwarepublicado. Foi denominado assim devido à sequência em cascata de uma fase para outra[2].
Esse modelo é dividido em uma série de etapas fundamentais independentes quesão realizadas sequencialmente, uma após a finalização da outra, como ilustra a Figura2. Cada fase produz um produto que é a entrada para a fase seguinte [9]. O modelo ésimples e direto [9]. No entanto, sua característica linear requer que os requisitos sejambem definidos no início do projeto e que os projetos não exijam correção de fases anterioresda vigente [8].
Figura 2 – Representação do modelo cascata [2].
2.1.2 Modelo de Processo Incremental
O modelo de processo incremental é uma combinação dos elementos do modeloem cascata aplicados de forma iterativa. Cada sequência linear produz um incremento dosoftware, como representado na Figura 3 [8].
No processo incremental, os clientes identificam as funções necessárias no sistema,identificam as mais importantes e definem uma série de estágios de entrega e o subcon-junto de funcionalidades incluídas. A alocação das funções é realizada de acordo com aprioridade[2].
25
O primeiro incremento é chamado de núcleo do produto. Nessa etapa os requisitosbásicos são satisfeitos e o sistema já pode ser utilizado ou avaliado pelo cliente [8].
Esse modelo de processo é útil quando há pouca mão-de-obra para o desenvolvi-mento completo do software ou quando há a dependência de algum item (hardware, porexemplo) para finalizar o produto [9].
Figura 3 – Representação do modelo de processo incremental [1].
2.1.3 Prototipagem
Na Prototipagem, o engenheiro de software e o cliente definem os objetivos geraisdo software, identificam as necessidades conhecidas e apontam áreas carentes de definições.Cada iteração do processo é gerado uma representação das funcionalidades visíveis aocliente (layout da interface humana)[8], como esquematizado na Figura 4.
2.1.4 Modelo Espiral
O modelo espiral leva em consideração a falta de certeza em muitos estágios du-rante o desenvolvimento do software [9] e, assim, tem um modelo de processo em espiral.Cada iteração representa uma fase do sistema [2].
26
Figura 4 – Representação do modelo de prototipagem [1].
Essa abordagem é um processo guiado por risco. É utilizada quando há diferentesinteressados concorrentes em cada versão evolucionária. O conjunto de marcos de anco-ragem garantem o comprometimento dos clientes com soluções satisfatórias [8].
2.1.5 Modelo Concorrente
O modelo de desenvolvimento concorrente é definido por uma série de atividades,ações e tarefas que podem ser executadas de forma simultânea. Para disparar a transiçãode estado para cada uma das atividades, ações e tarefas, o modelo define uma série deeventos [8].
2.1.6 Modelo Especializado
Os modelos especializados possuem semelhanças com os outros modelos apresen-tados nesse capítulo, porém são utilizados em uma abordagem bem definida [8]. Essaabordagem é representada pelo desenvolvimento baseado em Componentes, o modelo demétodos formais e o desenvolvimento orientado a aspectos [8].
2.1.7 Processo Unificado
O Processo Unificado (PU) é uma tentativa de reunir as melhores característicasdos modelos convencionais de processo de software, através do reconhecimento da impor-
27
Figura 5 – Representação do modelo espiral [1].
tância da comunicação com o cliente e de métodos diretos para a descrição da visão docliente [8].
O PU pode ser utilizado em projetos de pequeno e grande porte, independen-temente da complexidade do problema. Tem como objetivos principais: atender as ne-cessidades dos clientes e acompanhar riscos. A abordagem é composta por quatro fases:concepção, elaboração, construção e transição [9], como é representado na Figura 7.
2.2 Desenvolvimento Ágil
Em 2001, Kent Beck e outros desenvolvedores assinaram o "Manifesto para o De-senvolvimento Ágil de Software"(Manifesto for Agile Software Development), que defendiaa valorização de indivíduos, interações,colaboração dos clientes e respostas ao cliente [1].
No ambiente global atual, as empresas necessitam operar de maneira rápida paraacompanhar as oportunidades de mercado e manter os produtos e serviços competitivosno mercado. E essa rapidez é a proposta do desenvolvimento ágil [2].
Os métodos ágeis são compostos pelas atividades de comunicação, planejamento,modelagem, construção e emprego. E elas são compostas por um conjunto de tarefasmínimas que resultarão em um incremento do software que pode ser entregue ao cliente[1].
28
Figura 6 – Representação do modelo concorrente [1].
Figura 7 – Representação do processo unificado [1].
29
Os processos de especificação dos requisitos do sistema não é detalhado, já que ametodologia entende que compreender o usuário é uma tarefa que dispensa muito tempo.A documentação de requisitos contém as características mais relevantes do sistema, o quepode gerar problemas na manutenção de produtos mais complexos. O sistema é desen-volvido em diversas versões. Caso os stakeholders do sistema queiram realizar algumaalteração ou adicionar novas funcionalidades, a atualização é feita em uma nova versão[2].
30
2.3 Modelagem de Sistemas
A modelagem de sistema é o processo de desenvolvimento de modelos abstratosque representam perspectivas distintas do sistema [2] e colaboram para uma melhor com-preensão do que será construído [1]. Durante o processo de engenharia de requisitos, osmodelos ajudam a extrair os requisitos do sistema. Na fase de projeto, descrevem o sistemapara os engenheiros e, por fim, são utilizados para documentar a estrutura e operação dosoftware [2].
Os modelos de sistema podem ser representados de maneiras diferentes. No en-tanto, geralmente são utilizadas notações gráficas [2]. Para colaborar na modelagem há asferramentas CASE (Computer-Aided Software Engineering), que são software que apoiama execução de uma ou mais atividades realizadas durante o processo de engenharia de soft-ware [3].
2.3.1 Unified Modeling Language
A UML (Unified Modeling Language) é uma notação gráfica para a modelagem desoftware orientado a objetos. Ela é resultante da união de três formatos de modelagem: ométodo de Booch, o método OMT (Object Modeling Technique) de Jacobson e o métodoOOSE (Object-Oriented Software Engineering) de Rumbaugh.
Após a junção, várias empresas atuantes na área de modelagem e desenvolvimentode software passaram a contribuir para o projeto a fim de melhorar e ampliar a linguagem.Assim, em 1997 a UML foi adotada pela OMG (Object Management Group) como umalinguagem padrão de modelagem [3].
Segundo Pressman [1], a compreensão do vocabulário da UML (os elementos visu-ais e seus significados) permite o entendimento e a especificação de um sistema e a fácilexplicação de um projeto de sistema para outros interessados.
A UML apresenta como características principais [10]:
∙ é independente do domínio da aplicação;
∙ é independente do processo ou metodologia de desenvolvimento;
∙ é independente das ferramentas de modelagem;
∙ apresenta mecanismos potentes de extensão;
∙ agrega um conjunto significativo de diagramas e técnicas.
Os diagramas que compõem esse formato de modelagem são: diagrama de casos de uso,diagrama de classes, diagrama de objetos, diagrama de pacotes, diagrama de sequência,
31
diagrama de comunicação, diagrama de máquina de estados, diagrama de atividade, di-agrama de visão geral de interação (a partir da UML 2.0), diagrama de componentes,diagrama de implantação, diagrama de estrutura composta e diagrama de tempo ou detemporização [3]. Eles podem ser divididos em dois tipos: estruturais e comportamentais,de acordo com a figura 8. Segundo Sommerville [2], a essência de um sistema pode ser
Figura 8 – Diagramas da UML[3].
representado por cinco diagramas da UML: o diagrama de atividades, o diagrama de casosde uso, o diagrama de sequência, diagrama de sequência, diagrama de classes e o diagramade estados.
∙ Diagrama de casos de uso: mostra as interações entre um sistema e o ambiente[2]. Auxilia na identificação e compreensão dos requisitos do sistema, ajudando aespecificar, visualizar e documentar as funções e serviços do sistema desejados pelousuário [3]. A figura 9 apresenta um exemplo de diagrama de casos de uso.
∙ Diagrama de atividades: mostra as atividades envolvidas em um processo ou noprocessamento de dados [2]. O diagrama de atividades enfatiza a sequência e condi-ções para coordenar comportamentos de baixo nível. É provavelmente um dos maisdetalhistas [3]. A figura 10 apresenta um exemplo de diagrama de atividades.
∙ Diagrama de classes: mostra as classes de objeto e as associações entre elas [2].Apresenta os atributos e métodos do objeto instanciado de uma classe. Os métodospodem ser demonstrados a partir de diagramas de interação [3]. A figura 11 apresentaum exemplo de diagrama de classes.
32
Figura 9 – Exemplo de diagrama de casos de uso [3].
∙ Diagrama de sequência: mostra as interações entre os atores e o sistema e seu ambi-ente [2]. Busca determinar a sequência de eventos que ocorrem em um determinadoprocesso, identificando quais mensagens devem ser disparadas entre os elementosenvolvidos e em que ordem [3]. A figura 12 apresenta um exemplo de diagrama desequência.
∙ Diagrama de máquina de estados: mostra como o sistema reage aos eventos internose externos [2].O diagrama demonstra o comportamento de um elemento por meiode um conjunto finito de transições de estado [3]. A figura 13 apresenta um exemplode diagrama de máquina de estados.
2.3.2 Ferramentas
A UML é independente de ferramentas e por ser um padrão para a modelagemorientada a objetos [2], diversas ferramentas a suportam. Dessa forma, é possível escolhero meio para a construção dos diagramas [10]. As tabelas 1 e 2 demonstram algumas delas.
Cada uma possui características próprias. Já que a OMG define apenas símbolose seus significados, algumas exigências são ocasionadas pela forma de comunicação daequipe e linguagem de programação do sistema no projeto desenvolvido. No entanto,
33
Figura 10 – Exemplo de diagrama de atividades [3].
alguns fatores podem fazer a diferença na escolha como [10]:
∙ modelagem de processos de negócio;
∙ geração automática de documentação;
∙ processo de round-trip engineering1;
∙ mecanismos de extensão de funcionalidades.
1 Round-Trip Engineering: transformação de modelos para código e de código para modelos.
34
Figura 11 – Exemplo de diagrama de classes [3].
Figura 12 – Exemplo de diagrama sequência [3].
35
Figura 13 – Exemplo de diagrama de máquina de estados [3].
36
Empresa FerramentaAonix Software through PicturesArtisan Artisan StudioCasewise Casewise Corporate ModelerComputer Associates Erwin, BpwinCompuware OptimalJGentleware PodeisonIBM Rational Rational Software ArchitectIBM Rational Rational Software ModelerIDS Scheer AG ArisMega International Mega Modeling SuiteMetastorm ProVisionMicrogold WithClassMicrosoft VisioNo Magic’s MagicDraw UMLOracle Designer, DeveloperGrandite SilverrunSofteam ObjecteeringSparx Systems Enterprise ArchitectSybase PowerDesignerTelelogic Doors, Focal Point, System Architect, Rhap-
sody, TAUTroux Technologies Metis ArchitectUniversidade de Paderborn, Alemanha FujabaVisible Systems Corporation Visible AnalystVisual Object Modelers Visual UML
Tabela 1 – Ferramentas CASE Comerciais [6].
Ferramenta UMLEclipse Modeling Tools
MonoUMLPapyrus UML
Star UMLTopCasedUmbrelloUMLLet
Tabela 2 – Ferramentas UML Open Source.
37
3 DESENVOLVIMENTO ORIENTADO A MODELO
Os modelos de desenvolvimento, citados no capítulo 2, possuem um processo ondeem cada etapa há a elaboração parcial ou completa de um artefato. Os artefatos colaborampara a execução do processo, mas não são totalmente dependentes uns dos outros [8]. Egeralmente são responsabilidades de funcionários ou departamentos distintos [4].
Além dessas características, a produção de software sofre com a atualização perió-dica do produto imposta pelo mercado e com a heterogeneidade de conhecimento entre aequipe, que usualmente apresenta conhecimentos e talentos individuais [4].
Esse cenário tem como consequência documentos e diagramas incompreensíveispara a equipe, desatualizados e inutilizáveis. O que resulta em sistemas complexos semespecificações acessíveis, aumentando o custo de manutenção e possibilidade de errosconceituais [11]. Com o intuito de reverter essa situação, o desenvolvimento orientado amodelos foi proposto [12].
O desenvolvimento orientado a modelos, ou Model-Driven Development(MDD),é uma metodologia que tem como foco a criação de modelos como classe principal deartefatos para o desenvolvimento do software [13]. O MDD fornece diretrizes, linguagens,métodos, modelo de transformação e ferramentas para apoiar a representação de requisitosde negócios e permite a geração de uma solução de tecnologia específica para cada empresa[11].
A proposta do MDD é fazer com que o engenheiro de software não precise interagirmanualmente com todo o código fonte, concentrando-se em modelos de alto-nível. Dessaforma, ele fica protegido das complexidades geradas na implementação com diferentesplataformas [14]. Para que isso seja possível, a ferramenta de modelagem deve permitir queo modelo descreva todos os conceitos do domínio (problema), na modelagem de domínio.O modelo deve ser semanticamente completo e correto para que o computador ou umaequipe específica de codificação entenda e gere novos modelos ou código, através da Model-Driven Arquitecture (MDA). A Figura 14 apresenta os principais elementos desse métodode desenvolvimento.
O desenvolvimento orientado a modelo é realizado através da modelagem de do-mínio seguido pela transformações dos modelos, através do MDA.
3.1 Propriedades do MDD
A metodologia MDD apresenta características que independem de ferramenta uti-lizada e que originam seus benefícios. São elas: contexto bem definido, rastreabilidades,
38
Figura 14 – Principais elementos do MDD [4].
Round trip, geração automática de documentação e de código, controle de qualidade,colaboração e interoperabilidade.
1. Contexto bem definido
A falta de compreensão sobre o sistema é uma das principais dificuldades no de-senvolvimento de sistemas [15]. Os modelos de contexto, como o diagrama de casosde uso, permitem a delimitação do sistema [2] e o relacionamento dos requisitos emcontextos menores.
2. Rastreabilidade
A rastreabilidade é uma forma de verificação que todos os requisitos foram im-plementados e testados. Serve também para detectar erros e suas causas e assim,identificar requisitos que devem ser alterados [15].
É necessário ter esse suporte durante todo o ciclo de vida de desenvolvimento dosoftware. E apoiará as requisições de mudanças, garantindo a consistência entre osartefatos [16].
Os métodos manuais de rastreabilidade são difíceis de manter e são propensas aerros. Então, as ferramentas que fornecem esse controle proporcionam grande alíviona implantação do MDD [15].
3. Geração Automática de Documentação
A geração automática de documentos propicia a agilidade e qualidade nos padrõesformais, o que contribui para a consistência entre artefatos [16].
4. Geração Automática de Código
Essa característica permite a rápida identificação de requisitos inconsistentes, faltade componentes ou novas necessidades [16].
39
5. Round Trip
O Round Trip é a aptidão de um código fonte ser transformado em model parasincronizar as alterações do código no modelo [16].
6. Garantia de Qualidade
O MDD deve ter suporte à simulação e geração de testes de vários níveis (unidade,sistema e integração)[16].
7. Divisão de tarefas e colaboração
A produção de sistemas a partir de modelos permite que as responsabilidades sejamdivididas e que todos compreendam os requisitos. No entanto, o desenvolvimentoorientado a modelos também gera um ambiente de colaboração. Em projetos maissofisticados, por exemplo, a equipe pode interagir durante as atividades e um aspectosuprir a necessidade do outro [16].
8. Interoperabilidade entre ferramentas
As ferramentas utilizadas devem ser interoperáveis. Para isso, devem seguir padrõescomo os da OMG [16].
40
3.2 Modelagem de domínio
O desenvolvimento orientado a modelos começa a partir da modelagem do domí-nio. O domínio descreve um campo limitado de interesse ou conhecimento. Ele pode serdividido em subdomínios [17]. A partir do domínio é realizado uma análise, que consistena identificação dos principais conceitos e elementos de um domínio, na definição de seuescopo e na identificação do conjunto de artefatos a serem desenvolvidos [4].
Lucrédio(2009) enumera os objetivos da análise de domínio como:
∙ Coletar, registrar e documentar todas as informações disponíveis sobre o domínio;
∙ Definir o escopo do domínio a ser desenvolvido;
∙ Criar modelos do domínio;
∙ Identificar os subdomínios onde a automação é possível.
No contexto de MDD é fundamental que a representação do domínio seja clara.Para a formalização das informações do domínio é elaborado um metamodelo [17]. Elessão representados por uma Domain-Specific Language(DSL)[5], ou meta-metamodelo [17],que servem de base para a definição de todas as linguagens de modelagem [4].
O Meta-Object Facility(MOF) é o meta-metamodelo mais popular baseado naUnified Modeling Language(UML) [5]. O MOF consiste em um padrão orientado a objetosque permite a definição de classes com atributos e relacionamentos [4].O MOF é a sintaxeconcreta da UML, ou seja, através dessa representação é possível descrever modelos UMLde forma abstrata [5].
Dessa forma, o MOF é uma classe que instancia a UML, que por sua vez, é classeresponsável pelas instâncias dos modelos, que descreverá os elementos que representará odomínio, como mostra a figura 15:
Figura 15 – Hierarquia de modelos [5].
41
3.3 Desenvolvimento Orientado a Arquitetura
O desenvolvimento orientado a arquitetura ou Model-Driven Architecture (MDA)é um conjunto de padrões adotados pela Object Management Group 1(OMG) para o de-senvolvimento através do MDD. Esse recurso tem como intuito manter a compatibilidadeentre ferramentas de fabricantes distintos [4].
A interoperabilidade entre ferramentas é importante para a viabilidade do MDA.Ela apoiará o desenvolvimento de modelos e a transformação em código[16]. O MDA adotaos conceitos de CIM (Computational Independent Model), PIM (Platform IndependentModel), PSM (Platform-Specific Model) e transformações. [4].
∙ Modelo Independente de Computação
O Modelo Independente de Computação ou Computational Independent Model (CIM),é uma visão do sistema em que a compreensão independe do conhecimento em com-putação [4].
∙ Modelo Independente de Plataforma
O Modelo Independente de Plataforma ou Platform Independent Model (PIM), éuma visão do sistema independente da plataforma de implementação. Assim, elepode ser reaproveitado em diferentes plataformas [4].
∙ Modelo Específico de Plataforma
O Modelo Específico de Plataforma ou Platform-Specific Model (PSM) , é uma visãodo sistema que considerará detalhes específicos a plataforma de desenvolvimento [4].Ele é criado a partir do Modelo Independente de Plataforma (PIM) [5].
∙ Transformação
O MDA apresenta a fase de transformação, onde um metamodelo é transformado emmodelo ou código de acordo com as regras incluídas no metamodelo [17].Essa fase éresponsável por mapear os modelos para o nível seguinte de acordo com definiçõesde construção de modelos.
1 Object Management Group é um consórcio internacional, sem fins lucrativos que cria e mantémespecificações de interoperabilidade de software [12].
42
3.4 Modelo de Maturidade de MDD
Os modelos de processos atuais de melhorias de processo não fornecem uma vi-são muito clara sobre quais são as atividades necessárias e como devem ser executadas.Assim, o Modelo de Maturidade de MDD foi definido para auxiliar as organizações a es-tabelecerem seus processos através da abordagem de desenvolvimento orientado a modelo[7].
As práticas do modelo de maturidade estão divididas em três categorias: Engenha-ria (ENG), Gerenciamento de projetos (PJM) e Suporte (SUP). As práticas classificadascomo engenharia abrangem atividades de desenvolvimento, as de gerenciamento de pro-jetos estão relacionadas à configuração e gestão de um projeto de MDD e as de suportesão ações que apoiam as outras duas categorias.
Os níveis de maturidade foram classificados em: 1- Modelagem ad hoc; 2- MDDBásico; 3- MDD Inicial; 4- MDD Integrado e; 5- MDD Definitivo. Eles caracterizam aorganização no seu grau de adoção e implementação da metodologia, como mostra atabela 3.4 e a figura 16.
Figura 16 – Modelo de Maturidade em MDD [4].
43
Nível Práticas de Engenharia Práticas de Gerenciamento de Projeto Práticas de Suporte
Nível 1: Modelagem Ad-hoc Práticas de modelagem são esporadicamente usadas ou não são usadas.
Nível 2: MDD Básico
ENG 1: Decidir sobre convenções de modela-
gem;
ENG 2: Desenvolver um modelo técnico;
ENG 3: Gerar código a partir do modelo téc-
nico;
ENG 4: Gerar documentação a partir do mo-
delo técnico.
PJM 1: Decidir sobre as ferramentas de mode-
lagem.
Nível 3: MDD Inicial
ENG 5: Desenvolver modelo independente de
plataforma;
ENG 6: Desenvolver técnicas de transformação
modelo para texto;
ENG 7: Verificar modelos.
PJM 2: Modelo MDD de processo do projeto;
PJM 3: Aplicar o padrão estabelecido;
PJM 4: Definir, coletar e analisar as métricas
do projeto.
SUP 1: Estabelecer e manter repositórios para
modelos e transformações;
SUP 2: Definir técnicas de modelagem padrão
e critérios de qualidade;
SUP 3: Verificar aplicação prática;
SUP 4: Definir padrões de métrica, coleção de
dados e procedimentos de análise.
Nível 4: MDD Integrado
ENG 8: Desenvolver a arquitetura centrada no
metamodelo;
ENG 9: Desenvolver metamodelo indepen-
dente de plataforma;
ENG 10: Desenvolver um modelo de negócio;
ENG 11: Desenvolver uma transformação
modelo-para-modelo;
ENG 12: Manter a rastreabilidade entre os mo-
delos;
ENG 13: Integrar produto e família de produto
no desenvolvimento de infraestrutura;
ENG 14: Simular modelos.
PJM 5: Modelo automatizado do projetoSUP 5: Estabelecer o limite de performance da
modelagem da organização.
44Nível Práticas de Engenharia Práticas de Gerenciamento de Projeto Práticas de Suporte
Nível 5: MDD Definitivo
ENG 15: Desenvolver linguagem específica dedomínio;ENG 16: Verificar e validar os produtos base-ados em modelo.
PMJ 6: Estabelecer e manter artefatos de mo-delagem de software estratégicos para o MDD;PMJ 7: Promulgar o modelo de processo doprojeto.
Tabela 3 – Modelo de Maturidade em MDD [7].
45
3.5 Ferramentas de modelagem UML
O desenvolvimento orientado a modelos consiste na construção de modelos pararepresentar diversos aspectos do software e em diferentes plataformas. Com isso, as ferra-mentas desempenham um papel importante para a redução dos erros e a diminuição degastos dos custos no processo de desenvolvimento [16].
Ao criar um meio de cumprir as propriedades do MDD (seção 3.1) é possível utilizarqualquer ferramenta de modelagem de UML. Mas o tempo de construção de software serácustoso e predisposto ao erro humano [16]. Então, a escolha de um mecanismo com maisrecursos é fundamental para o sucesso da implantação da metodologia [7].
A evolução de muitas ferramentas UML foi resultado da busca por atender asnecessidades da abordagem de desenvolvimento orientado a modelos [18]. Nesse trabalhodescreveremos a ferramenta Enterprise Architect, mas existem diversas outras com essemesmo intuito [18][19]. No entanto, a ferramenta de modelagem utilizada possui um custoacessível se comparada com outras que dão o mesmo suporte[18].
Enterprise Architect
O Enterprise Architect da empresa Sparx Systems é uma ferramenta proprietáriade modelagem e projeto de software. Ela permite desde a concepção até a construção dosistema, abrangendo todo o ciclo de vida de desenvolvimento. A plataforma dá suporte ànotações UML da OMG, assim como também permite a modelagem em SysML, BPMN,BPEL, SoaML, SPEM, WSDL, XSD, DDS e outros.
Essa ferramenta de modelagem permite geração automática de documentação ecódigo fonte. Através do padrão MDA, suporta a realização de transformações a partirde um projeto MDD. O código gerado pode ser nas linguagens: Action Script, C, C ♯(forboth .NET 1.1 and .NET 2.0), C++ (standard, plus .NET managed C++ extensions),Delphi, Java (including Java 1.5, Aspects and Generics), PHP, Python, Visual Basic eVisual Basic .NET. Além de permitir a adição de plugins que viabilizam a transformaçãodos modelos em outras linguagens.
Outra característica importante do Enterprise Architect é a rastreabilidade doselementos dos diagramas, como ilustra a figura 17. Através de matrizes de relacionamentoe links entre os objetos. Dessa forma, ela permite a ligação entre os requisitos até osseus modelos de níveis mais baixos. Através desse controle de relação é possível realizarauditorias e verificar a consistência entre os modelos de um projeto. A plataforma demodelagem também permite a padronização de nomenclaturas, controle de versionamentoe engenharia reversa, com geração de modelos a partir de código, incluindo script debanco de dados 2. Essas funcionalidades do Enterprise Architect permitem que ela sejaclassificada como uma boa ferramenta para o desenvolvimento orientado a modelos.2 Retirado do site da empresa: http://www.sparxsystems.com/
46
Figura 17 – Exemplo de diagrama de conexão entre elementos no Enterprise Architect.
47
3.6 Trabalhos Relacionados
A abordagem de desenvolvimento orientado a modelo já vem sendo discutido emoutros trabalhos. Esse capítulo descreve propostas outros autores para diferentes cenáriosde produção de software.
3.6.1 Metodologia para Colaboração B2B em Desenvolvimento Orientado aModelo
Lazarte [14] propõe uma abordagem de implementação de processos de negócioscolaborativos e sistemas Business-to-Business (B2B). Esse cenário gera desafios como adescentralização de gestão, capacidade de lidar com mudança, iterações ponto-a-ponto,preservação de autonomia da empresa e interoperabilidade do projeto.
A proposta resultante foi uma metodologia baseada no desenvolvimento concei-tual e fornece uma clara separação dos domínios e os níveis de abstração dos artefatosnecessários no desenvolvimento de colaborações B2B. Ela é composta pelas etapas:
1. Análise de Negócio:
Essa fase consiste na análise do domínio do problema e na identificação dos requisitosde negócio. Também é definido os objetivos comuns dos parceiros e os parâmetrosque definirão o trabalho colaborativo entre sistemas.
2. Projeto da Solução de Negócio:
Definição de processos para a implementação de uma solução colaborativa B2B. Aspessoas envolvidas nessa fase são analistas de negócios e projetistas de sistemas quesão responsáveis por definir os aspectos da colaboração B2B.
O foco principal é sobre a definição de princípios básicos comuns, que descrevem ocomportamento comum das interações entre parceiros de um ponto de vista globale os processos em que cada um dos envolvidos terá que implementar.
3. Definição da arquitetura de TI para cada empresa:
Essa fase é implementada separadamente nas empresas envolvidas. Nela há a defini-ção da arquitetura de TI através da criação do modelo independente de plataformagerado a partir do projeto da fase anterior.
O modelo independente de plataforma é útil para facilitar a comunicação entre osanalistas de negócios e designers de TI e permite uma transição mais simples deuma solução de negócios (solução conceitual independente de plataforma) para umasolução tecnológica (para plataformas específicas).
4. Definição da solução tecnológica e implementação:
48
A partir do modelo implementado na fase de definição da arquitetura de TI paracada empresa será modelado uma solução para plataformas específicas. Essa fase édividida em duas tarefas: projeto de solução de TI específico da plataforma e geraçãode especificações B2B, que detalhará sobre as interfaces do processo específico deplataforma e permitirá a geração de código fonte.
3.6.2 Uma Abordagem Orientada a Modelos para reutilização de Software
Lucrédio [4] apresenta um modelo de processo em MDD para a reutilização desoftware, como ilustrado na Figura 18. O trabalho visa guiar o engenheiro de softwaredesde as atividades iniciais de análise até a implementação de artefatos reutilizáveis deum domínio. A abordagem é dividida em três níveis de abstração:
1. análise de domínio;
2. projeto de domínio;
3. implementação do domínio.
O modelo de processo proposto no trabalho possui atividades que acontecem deforma iterativa e interativa, e a sua ordem pode ser alterada para se adequar à realidadede uma organização de software.
O principal ciclo começa na análise de domínio (Atividade AD.1. Planejamento dodomínio) e termina na atividade da implementação do domínio (Atividade ID.5. Docu-mentação do domínio).
Na fase de projeto, novos módulos são identificados de acordo um padrão de projetoescolhido, que permitirá maior reutilização de código do sistema. A cada refinamento dessaetapa também é identificado elementos como transformações, geradores de código, DSLse ferramentas de modelagem.
A fase de implementação de domínio também é iterativa. Devido a abordagem dedesenvolvimento orientado a modelos, qualquer informação coletada durante a codificaçãoresulta na realimentação da atividade de definição das linguagens específicas de domínio,pois todos os detalhes do sistema devem compor os modelos.
49
Figura 18 – Modelo de processo da abordagem.
50
3.7 Vantagens e Desvantagens do MDD
A abordagem de desenvolvimento em MDD tem como principais vantagens:
∙ produtividade: redução de tempo de desenvolvimento com tarefas repetitivas atravésda geração de código automática [4, 17, 5] e através do conhecimento de especialistajá agregado ao modelo [12].
∙ portabilidade: modelos de alto-nível podem ser transformados em código para di-versas plataformas [4, 17].
∙ Interoperabilidade: possibilidade de criação de adaptadores e conectores para a co-municação entre diferentes plataformas [4, 17].
∙ Facilidade de manutenção: a manutenção é realizada diretamente no modelo o quefacilita a compreensão do problema e a concepção de uma solução [4, 17].
∙ Comunicação: os modelos de mais alto-nível tornam a comunicação acessível entretodas as pessoas evolvidas no processo de desenvolvimento [4, 12].
∙ Reutilização: é possível fazer a reutilização de modelos adaptando-os a um novocontexto [4, 12, 17, 20].
∙ Otimização: modelos possuem mais ferramentas para a verificação semântica e oti-mizações automáticas, assegurando implementações mais eficientes [4].
∙ Corretude de código e conceitos: o alto nível de abstração dos modelos permite umamaior corretude de conceitos de negócios e a possível automatização de geração decódigo elimina erros acidentais no código fonte [4, 17, 5, 20].
Em resumo, o desenvolvimento orientado a modelo permite que a longo prazotraga maior produtividade, qualidade e maior agregação de conhecimento nos produtos[4, 12, 17].
No entanto, a abordagem possui alguns desafios a enfrentar como:
∙ Rigidez: devido a dependência dos modelos elaborados e a pouca influência do de-senvolvedor [4], o que dificulta a propagação de mudanças.
∙ Complexidade: as ferramentas de modelagem, transformações e geradores de có-digo geram maior complexidade ao processo de desenvolvimento [4] e quanto maismodelos relacionados maior a complexidade de ligação entre os artefatos [20].
∙ Redundância: possibilidade de utilização de modelos que possuem representações deum mesmo conceito em diferentes níveis de abstração [20].
51
∙ Desempenho: na utilização de geradores automatizados, que pode ser afetado devidoa inclusão de código desnecessário no sistema [4].
∙ Curva de Aprendizado: o MDD exige profissionais com habilidades na construção demodelos, manipulação de ferramentas de modelagem, transformações e geradores decódigo [4]. Os desenvolvedores devem ter conhecimento do impacto de cada etapado processo no produto final [20].
∙ Alto Investimento Inicial: a preparação e a implantação do MDD necessita tempo eesforço, mas os ganhos posteriores são significativos [4].
Mas segundo Sanchez [21], o processo de desenvolvimento orientado a modelosoferece ganhos significativos até para as pequenas empresas, as quais não costumam adotaressa metodologia.
53
4 PROPOSTA DA METODOLOGIA
A aplicação do desenvolvimento orientado a modelos proporciona muitas vantagensao projeto de software. Assim, esse capítulo apresenta uma proposta de ciclo de vidadesenvolvimento de software de MDD.
A empresa na qual essa proposta foi direcionada é a Guenka Software, que foifundada em 2003 e atende a critérios de qualidade. Já atingiu o nível F do MPSBR e o nível2 do MoProSoft1. Dessa forma, as diretrizes apresentadas nesse capítulo visam manter aexecução de atividades que são exigidas nessas avaliações e introduzir características domodelo de maturidade de MDD.
O nível de maturidade de MDD visado nesse trabalho é o 2, chamado MDD Bá-sico, conforme o modelo descritivo da ModelWare[7]. Nessa classificação, os modelos sãoutilizados como guia da implementação e produção de documentação. A tabela 4 mostraas características de um ciclo de vida de desenvolvimento orientado a modelo no nívelbásico e insere uma coluna que descreve o que deve ser adicionado, modificado, adotadoe estudado de acordo com a cultura da empresa.
1 Retirado do site da empresa: http://www.guenka.com.br.
54
Elemento
MDD
Atributo Valor Proposta
Modelo
Técnico
Adesão às políticas
e normas organiza-
cionais
Desenvolvimento de acordo com as
normas organizacionais
Modificada parcialmente
Proposta de mo-
delo
Para dar suporte a implementação de
código e a produção de documenta-
ção relevante
Modificada parcialmente
Escopo do modelo Combinação de requisitos de negó-
cios e técnicos
À estudar
Nível de integração Parcialmente integrada com o có-
digo: grande parte da codificação
ainda é feita manualmente
Modificada parcialmente
Nível de verifica-
ção
Baixo. A verificação é realizada no
código e não no modelo técnico.
Modificada.
Profundidade de
rastreabilidade
Nenhuma rastreabilidade ou parcial
para o código
Modificada. Apesar de não ser exi-
gida nesse nível de maturidade.
Simulação Não disponível.
Execução Não disponível.
Código
Adesão às políticas
e normas organiza-
cionais
Desenvolvimento de acordo com as
normas organizacionais.
Modificada parcialmente.
Proposta de mo-
delo
Implementar funcionalidade necessá-
ria.
Adicionada.
Escopo do modelo Requisitos de negócios e técnicos. Modificada parcialmente.
Nível de integração Não integrado com o técnico. Modificada parcialmente.
Profundidade de
rastreabilidade
Sem rastreabilidade para a imple-
mentação do modelo.
Modificada. Apesar de não ser exi-
gida nesse nível de maturidade.
Simulação Disponível. À estudar.
Execução Disponível. À estudar.
Transformação
de modelo
para texto:
modelo
técnico para
documentação
Tipo de transfor-
mação
Desenvolvimento de acordo com as
normas organizacionais.
Modificada parcialmente.
Nível de automa-
ção
Implementar funcionalidade necessá-
ria.
Adicionada.
Engenharia de su-
porte round-trip
Requisitos de negócios e técnicos. Adicionada.
Mecanismo de
geração de
código
Tipo de transfor-
mação
Vertical. É feita a transformação de
modelo técnico para código.
Adicionada.
Nível de automa-
ção
Automática. Adicionada.
Engenharia de su-
porte round-trip
Não há suporte.
Ferramentas Facilidade de inte-
gração
Básico: transformação entre modelo
técnico e código.
Adicionada.
Tabela 4 – Características do MDD no nível básico.
55
A linguagem de modelagem adotada nesse projeto é a UML 2.0. A nomenclatura econexão de cada atividade serão explanadas a seguir. Os diagramas devem seguir rigorosa-mente as orientações estipuladas pela OMG e ainda devem respeitar as regras estipuladasnessa metodologia. Assim, será possível a integração de modelos de forma consistente.
A empresa alvo desse trabalho possui codificação manual. Nesse quesito, foramadicionadas técnicas que permitirão a geração automática parcial do código através dosmodelos. Os elementos do modelo possuirão rastreabilidade através de suas nomenclaturasatravés das regras indicadas nesse capítulo.
A transformação de modelo para modelo e modelo para código, assim como ageração de documentação serão apoiados pela ferramenta Enterprise Architect. Foi apro-veitado dessa ferramenta o suporte ao MDA e seus próprios códigos de transformação demodelos.
No entanto, vale ressaltar que a tabela é uma proposta inicial e que deverá passarpor um processo de evolução após uma aplicação. A falta ou excesso de burocracia noprocesso são itens possíveis de serem melhorados.
As ferramentas adotadas aqui foram:
∙ Enterprise Architect:A ferramenta Enterprise Architect foi escolhida por já ser uti-lizada na empresa Guenka Software e por ela dar suporte ao desenvolvimento ori-entado a modelo através da modelagem em UML.
∙ Eclipse Process Framework: O Eclipse Process Framework é uma aplicação quepermite a criação de processo de engenharia de software customizado a partir deum processo exemplo 2. Essa ferramenta já é utilizada pela empresa para modelarseus processos.
O objetivo desse capítulo é demonstrar ações e ferramentas que proporcionam umambiente de desenvolvimento orientado a modelos. E, assim, destacar as vantagens queuma ferramenta de modelagem adequada ao MDD promove para o processo. Serão de-monstrados apenas os itens que devem ser adicionados e modificados da tabela 4. Osexemplos demonstrados foram retirados de Guedes Guedes2009. Um dos exemplos imple-menta um sistema de pizzaria online e o outro, um sistema de controle de cinema.
2 Retirado do site da ferramenta: http://www.eclipse.org/epf.
56
4.1 Metodologia
A proposta de modelo de processo em MDD é baseada no ciclo de vida AMDDHigh-Level Life Cycle que é o primeiro modelo de desenvolvimento orientado a modelosutilizando a metodologia ágil [22]. A aceleração das atividades na codificação caracterís-tica da metodologia ágil, passaria a ser para a modelagem. E, assim, a documentação emanutenção dos sistemas não serão problemas, como visto na seção 2.2 sobre o desenvol-vimento ágil.
O processo é dividido em dois ciclos: Iteração Inicial e Iteração de Desenvolvimento,como mostrado na figura 19.
Figura 19 – Metodologia proposta.
O ciclo da Iteração Inicial é composta pelas fases de Comunicação, Planejamentoe Organização de Cenários, ilustradas na figura 20.
Figura 20 – Fases da Iteração Inicial.
O ciclo da Iteração de Desenvolvimento possui as fases de Análise, Projeto, Cons-trução e Emprego, ilustradas na figura 21.
Figura 21 – Fases da Iteração de Desenvolvimento.
A Iteração Inicial permite uma boa definição do domínio do problema, ca-racterística do MDD, para depois iniciar as modelagens mais específicas, que resultará oobjetivo da metodologia.
57
No caso de pedido de mudança de requisito, o processo de desenvolvimento podeestar em qualquer iteração, mas para que inicie as correções ou a implementação da novafuncionalidade, deve estar na Iteração Inicial. Dessa forma, todos os modelos serãoatualizados.
O processo interno das iterações, citado em Pressman [1], é composto por seisfases: comunicação, planejamento, análise, projeto, construção e emprego.
1. Comunicação: Para criação de uma solução é importante ter uma boa comunicaçãocom o cliente. Assim, é possível compreender as suas necessidades e obter informa-ções que auxiliarão na definição de funções e características do sistema [1].
2. Planejamento: O planejamento consiste em pontuar as tarefas primordiais para arealização do projeto, os riscos, o tempo de execução, os custos e os produtos re-sultantes [1]. Nessa fase também ocorre a formalização dos requisitos obtidos nafase anterior. Caso haja algum problema no desenvolvimento dessa fase, o processoretorna à fase de comunicação.
3. Organização de Cenários: Nessa fase, os casos de uso e seus fluxos de execuçãosão formalizados através da elaboração de modelos. Há a geração de documentaçãoatravés do diagrama de caso de uso e os diagramas de atividades. Caso alguma hajaalgum problema durante o desenvolvimento dessa fase, o processo retorna à fase decomunicação.
4. Análise: A fase de análise serve para o início da modelagem. Todos os artefatosadquiridos servirão de suporte para o progresso do desenvolvimento.
5. Projeto: Com os requisitos e protótipos finalizados e aprovados pelo cliente, é neces-sário formalizar as características do software através de modelos. Esse é o estágiode maior destaque na metodologia de desenvolvimento orientado a modelos, pois osartefatos resultantes formarão a pedra fundamental do sistema.
6. Construção: Os produtos gerados na fase de projeto serão transformados em código,através da geração automática ou da tradução manual realizada por programadores.
7. Emprego: O emprego consiste nos testes do sistema, nas atividades gerenciais ne-cessárias para a finalização do incremento e a entrega ao cliente.
As fases destacadas nesse ciclo de vida de software orientado a modelos serão: a dePlanejamento, Análise e Projeto, que exigem maior controle de rastreabilidade demodelos.
58
4.1.1 Atividades da Fase de Comunicação
A fase de Comunicação é dividida em duas atividades: levantamento de requisitose preenchimento do formulário de casos de uso.
1. Levantamento de Requisitos:
A concepção de um sistema pode ser realizada de várias formas. A mais convencionalé alcançada por meio de reuniões entre os stakeholders [1].
Nessas reuniões, ocorre a troca de ideias e o alinhamento de necessidades entreclientes que compõem setores distintos e equipe de desenvolvimento.
Essa etapa adotará a especificação e template da empresa para cada requisito, de-monstrado a seguir:
∙ Descrição curta: uma pequena descrição que possa identificar facilmente o pro-pósito do requisito.
∙ Alias: um identificador único para o requisito.
∙ Status: indica o status que o requisito se encontra, iniciado por:
– Proposto: indica que o requisito foi proposto pelo cliente, mas ainda de-pende de aprovação.
– Aprovado: indica que o requesito foi aprovado pelo cliente.– Implementado: invoca que o requisito foi implementado.– Validado: indica que o requisito foi testado.
∙ Prioridade (Alta, Média e Baixa): alguns critérios a serem aplicados na deter-minação da prioridade são: valor para o negócio, risco técnico ou de negócio,dificuldade de implementação, probabilidade de sucesso, conformidade legal oupolítica, relacionamento com outros requisitos, acordo entre as partes interes-sadas e urgência.
∙ Descrição detalhada: uma descrição que forneça as informações necessáriaspara a implementação e teste do requisito, tabelas, figuras e anexos podem seradicionadas para agregar mais detalhes à descrição.
∙ Dependência (rastreabilidade): já devem ser identificadas as dependências entreos requisitos de mesmo nível, ou seja, dependência entre os próprios requisitosde negócio.
Em algumas vezes, no levantamento de requisitos é possível verificar a necessidade dediagramas específicos como: diagrama de estados, diagrama de objetos, diagrama detemporização ou diagrama de implantação. Nesse contexto, é necessário especificarpara que todos os participantes da produção fiquem cientes. No entanto, eles são
59
diagramas opcionais e para a aplicação inicial não precisam ser utilizadas, pois amaior variedade de diagramas pode ser um fator de bloqueio para a adoção do MDD[23].
2. Preencher formulário de casos de uso:
O formulário de casos de uso (tabela 5) é um documento para a orientação da espe-cificação de requisitos. Através dele é possível identificar quem utilizará o sistema ecomo o cliente espera que ele funcione. Cada requisito levantado resultará em pelomenos um caso de uso.
Caso de Uso nome do caso de usoAtor Primário nome do ator
Atores Secundários nomes dos atores (entre vírgulas)PrecondiçõesDisparador
Fluxo PrincipalAção do Ator Ação do Sistema
1- ...2-...
Fluxos AlternativosAção do Ator Ação do Sistema
1- ...2-...
ExceçõesPrioridade <alta/média/baixa>
Frequência de uso
Tabela 5 – Template de descrição de Casos de Uso.
4.1.2 Atividades da Fase de Planejamento
A fase de planejamento é dividida em duas atividades: organizar requisitos e rea-lizar auditoria.
60
Figura 22 – Proposta: Fase de Planejamento.
1. Organizar requisitos
Os requisitos devem ser listados e nomeados de acordo com o template:
Nome: REQ<NÚMERO> - <VERBO><TERMO>Descrição:
Tabela 6 – Template do formato de declaração dos requisitos.
Na fase anterior, a de Comunicação, é a etapa onde o caso de uso é criado. Comonesse momento o principal objetivo é a comunicação, a forma de solução da atividadeé mais flexível para a melhor descrição do intuito do cliente.
No entanto, na fase de planejamento é necessário seguir esse template 6 para criara rastreabilidade entre os modelos.
Na ferramenta Enterprise Architect é possível correlacionar o requisito ao caso deuso e o caso de uso ao requisito.
2. Realizar auditoria
A auditoria deverá ser realizada para verificar se todos os requisitos estão sendorepresentados na modelagem e se os padrões propostos nesse documento estão sendoutilizados. O acompanhamento pode ser realizado através de uma verificação decompatibilidade entre documentos e modelos, como mostra a tabela 7.
61
Atividades: Aprovado?Formulário de UC x Lista de Requisitos ( )
Lista de Requisitos x Fluxos ( )Casos de Uso x Cenários ( )
Cenários x Atividades ( )
Tabela 7 – Planejamento: Documento de Auditoria.
4.1.3 Atividades da Fase de Organização de Cenários
A atividade é dividida em três tarefas: evoluir diagrama de casos de uso, gerardiagrama de atividades e gerar documento de cenários (figura 23).
Figura 23 – Organizar Cenários.
1. Evoluir Diagrama de Casos de Uso
Cada requisito listados na fase anterior será vinculado a pelo menos um caso de uso.Para facilitar o rastreamento da modelagem de todas as funcionalidades exigidaspelo cliente é recomendável a utilização da mesma numeração do requisito no casode uso, como demonstra a figura 24.
Inclusive na ferramenta utilizada é possível fazer a associação para navegabilidadeentre requisito e caso de uso, como ilustra a figura 25.
Cada caso de uso vinculado ao requisito pode ser uma representação muito amplado sistema. Nesse caso, ele pode se ramificar em mais casos de uso. E esse fato seestende à sua nomenclatura, como mostrado nas tabelas 8 e 9.
Nome: UC<NÚMERO REQUISITO> - <NOME REQUISITO>
Tabela 8 – Template do formato de declaração do caso de uso.
Nome: UC<NÚMERO REQUISITO>.<ID> - <NOME REQUISITO>
Tabela 9 – Template do formato de declaração do caso de uso refente ao mesmo requisito.
Cada caso de uso deve estar acompanhado dos seus atores e fluxos. Na ferramentaEnterprise Architect é possível descrever o fluxo nas configurações do caso de uso.
62
Figura 24 – Diagrama de Caso de Uso.
2. Gerar Diagrama de Atividades
A partir dos fluxos possíveis deve-se gerar um diagrama de atividades para cadacaso de uso.
As atividades devem ter os nomes:
Nome: ACT<NÚMERO DO UC><NÚMERO> - Nome da atividade
Tabela 10 – Formato da nomenclatura de atividades.
Na ferramenta de modelagem adotada nesse trabalho, após a inserção dos fluxos naconfiguração do caso de uso, é possível gerar o diagrama de atividades automatica-mente, como o diagrama da figura 26.
63
Figura 25 – Ligação entre requisito e caso de uso.
Figura 26 – Representação do UC003- Escolher Pizza.
3. Gerar Documento de Cenários
A elaboração de um documento que relate todas as funcionalidades do sistema é
64
necessária para a aprovação do cliente. Com os modelos elaborados até aqui é possí-vel demonstrar grande parte dos itens presentes em um documento de requisitos. OEA permite a geração de documentação de cenários automaticamente a partir doscasos de uso e seu fluxo principal e os alternativos.
4.1.4 Atividades da Fase de Análise
A fase de análise consiste na concretização dos requisitos em algo mais próximoà linguagem de desenvolvedor. Ela apresenta as atividades de: Elaborar protótipo deinterface, Elaborar diagramas e Realizar auditoria (figura 28).
Figura 27 – Proposta: Fase de Análise.
1. Elaborar protótipo:
Os protótipos apresentarão a interface do sistema. Cada caso de uso deve ser repre-sentado por no mínimo uma tela.
65
A figura ?? demonstra o rastreamento entre requisito, caso de uso e interface. Todosos requisitos devem ter casos de uso e protótipos de interface vinculados.
Figura 28 – Exemplo de um protótipo de interface de um caso de uso.
2. Elaborar diagramas:
Figura 29 – Elaboração de diagramas.
a) Elaborar diagrama de pacotes
O diagrama de pacotes é modelado com o intuito de agrupar elementos e for-necer denominações para esses grupos. Um pacote pode conter outros pacotes,que são sistemas, subsistemas ou bibliotecas [3].
A divisão entre pacotes permite a visão modular do sistema, como demonstradona figura 30.
66
Figura 30 – Exemplo de diagrama de pacotes.
b) Elaborar diagrama de classes
O principal objetivo do diagrama de classes é demonstrar a estruturação dasclasses que farão parte do sistema [3]. Nessa tarefa é necessário identificar todosos elementos exigidos no sistema, seus atributos e métodos.
O diagrama de classes pode ser elaborado nessa fase de acordo com os protó-tipos de interface. Cada input, campo de inserção de dados, representará umatributo e cada botão, um método.
Figura 31 – Elaboração de diagrama de classes.
c) Elaborar diagrama de sequência
O diagrama de sequência busca representar o comportamento do sistema emum determinado processo. Através dele é possível observar a comunicação entrediversas instâncias de classes declaradas no diagrama de classes [3].
67
Figura 32 – Elaboração de diagrama de sequência.
d) Elaborar outros diagramas
Elaborar outros diagramas em que a necessidade foi constatada na fase decomunicação.
3. Realizar auditoria:
A auditoria verificará se todos os objetos do diagrama de sequência são instânciasde classes que compõem o diagrama de classes. A forma única comunicação entreos objetos são através dos métodos das classes.
Atividades: Aprovado?Casos de Uso x Protótipos ( )
Protótipos x Classes ( )Classes x Sequência ( )
Sequência x Atividades ( )
Tabela 11 – Análise: Documento de Auditoria.
68
4.1.5 Atividades da Fase de Projeto
A fase de Projeto consiste na evolução dos diagramas específicos do domínio, in-cluindo o diagrama de banco de dados. A ordem do processo é demonstrado na figura33.
Figura 33 – Proposta: Fase de Projeto.
1. Evoluir diagrama de pacotes:
O diagrama de pacotes na fase de projeto incluirá outros elementos que são neces-sários para a codificação. São incluídos módulos já implementados anteriormente ebibliotecas. Deve-se aplicar estereótipos aos pacotes de acordo com o que represen-tam como : system, framework e model.
2. Evoluir diagrama de classes:
Nessa tarefa os diagramas de classes recebem novas classes, métodos e atributosnecessários para a codificação. Esses elementos não estão necessariamente vinculadosao protótipo de interface. É recomendado a utilização de design patterns3.
3. Evoluir diagrama de sequência:
O diagrama de sequência deve ser atualizado de acordo com os novos elementosinseridos no diagrama de classes.
4. Elaborar diagrama de atividades:
Cada método declarado no diagrama deve ser representado por um diagrama deatividades.
5. Evoluir outros diagramas:
Atualizar e construir outros diagramas necessários para o projeto específico.
6. Elaborar diagrama entidade-relacionamento:3 Design Patterns são conceitos de engenharia de software que descrevem soluções para problemas
recorrentes em projeto de software. Retirado de ttp://www.gofpatterns.com/
69
A partir do diagrama de classes construído deve-se elaborar o diagrama de entidade-relacionamento. Para o mapeamento de classes em tabela, a proposta seguirá as ori-entações de Guedes [3] através das etapas: de escolha da chave primária, associaçõese escolha de chaves estrangeiras.
7. Realizar auditoria:
Após a alteração e criação desses novos diagramas, é necessário verificar novamentea entre eles, assim como na fase de Análise.
Atividades: Aprovado?Casos de Uso x Protótipos ( )
Protótipos x Classes ( )Classes x DER ( )
Classes x Sequência ( )Sequência x Atividades ( )
Tabela 12 – Projeto: Documento de Auditoria.
4.1.6 Atividades da Fase de Construção
A fase de construção tem as atividade: gerar de código estrutural, gerar de códigocomportamental e realizar auditoria. Seguindo o fluxo da figura 34
Figura 34 – Proposta: Fase de Construção.
1. Gerar código estrutural:
A partir dos modelos implementados na fase de Projeto e através de uma ferramentaadequada, gerar o código do sistema. De acordo com Teppola[11], as ferramentasde transformação de modelos em código atuais são ineficientes para a construçãodo software como um todo. Assim, na metodologia proposta nesse trabalho, apenaso código responsável pelas características estruturais do sistema serão responsabi-lizadas pela automatização da implementação. Como o exemplo citado na figura35:
70
Figura 35 – Geração de Código em Java.
2. Gerar código comportamental:
Nessa atividade o sistema obterá funções comportamentais resultantes do trabalhode uma equipe de programadores. Apesar da não automatização dessa tarefa, osdesenvolvedores deverão codificar de acordo com os modelos.
3. Realizar auditoria:
A auditoria verificará se o código do sistema está de acordo com os modelos elabo-rados nas fases anteriores, através da seguinte tabela 13.
Atividades: Aprovado?Código x Classes ( )
Código x Sequência ( )
Tabela 13 – Construção: Auditoria.
4.1.7 Atividades da Fase de Emprego
Na fase de emprego as atividades atuais da empresa podem ser adotadas. Noentanto, é necessário adotar um alto controle de versionamento de modelos para que nãohaja problema na execução de próximas iterações.
71
4.2 Considerações Finais
O ciclo de desenvolvimento apresentado nesse trabalho é uma proposta de meto-dologia para o desenvolvimento orientado a modelos. Contudo, ele ainda necessita de umaavaliação e possível adaptação a partir da aplicação em um primeiro projeto. A experi-ência prática terá um custo elevado ao considerar que o MDD exige tempo e esforço depreparação, implantação e treinamento na utilização de ferramentas.
No entanto, as orientações descritas na proposta indicam um caminho para a odesenvolvimento orientado a modelos. O processo elaborado tem como objetivo adaptar-se a um modelo de processo convencional adicionando ou modificando atividades para odesenvolvimento orientado a modelo. A metodologia descrita tem como característica aabordagem de desenvolvimento ágil, como a adotada na empresa, e difere das abordagensadotadas nos trabalhos de Lazarte [14] e Lucrédio[4].
A modelagem ainda não é parte integrante da cultura das pequenas empresas.Acredita-se que dentre os motivos estão: a falta de conhecimento em modelagem, a suautilização sem critérios claros, conhecimento distribuído heterogeneamente entre a equipee a desconexão do modelo com o código.
Além de que um grupo pequeno de funcionários permite a fácil comunicação entreos responsáveis pelas fases do processo. Informalmente todos conseguem as informaçõesnecessárias para o projeto. Assim, a modelagem e auditoria para a verificação de consis-tência das mudanças torna-se dispensável, o que compromete a qualidade do sistema eresulta na manutenção custosa.
73
5 CONCLUSÃO
O ciclo de vida de desenvolvimento de software apresentado tem como objetivoressaltar características que guiam o desenvolvimento orientado a modelos. Apesar darigidez de algumas atividades herdadas do MDD, a metodologia proposta consideroucaracterísticas do desenvolvimento ágil utilizado atualmente e o template do formuláriode levantamento de requisitos. As fases de desenvolvimento foram adaptadas para a melhordivisão das atividades que devem ser realizadas para alcançar as propriedades do MDD eas propriedades do nível 2 do modelo de maturidade em MDD.
As ações necessárias para a implantação do desenvolvimento orientado a modelosna empresa não são contrárias aos aspectos avaliados por modelos de qualidade comoo MPSBR. E essa metodologia pode auxiliar empresas que almejam alcançar níveis demodelo de qualidade, colaborando com a implantação de um processo na produção dosoftware e criando um ambiente que permita a melhoria da qualidade e induzindo aocumprimento das exigências do cliente.
A aplicação e validação do processo de desenvolvimento será um trabalho futuro.Com relação à documentação e facilidade de comunicação entre os envolvidos na evoluçãodo software permite que sistemas computacionais sejam produzidos em fábricas de soft-ware. No entanto, para que empresas de desenvolvimento e fábrica consigam trabalharjuntas, será necessário um centro de capacitação que alinhe a forma de diálogo entre asenvolvidas: incluindo regras de modelagem, documentação e codificação.
75
REFERÊNCIAS
[1] PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 7th. ed. NewYork: McGraw-Hill. ISBN 2008048802.
[2] SOMMERVILLE, I. Engenharia de Software. 6th. ed. São Paulo: Pearson EducationLimited, 2003.
[3] GUEDES, G. T. A. UML 2: Uma abordagem prática. [S.l.]: Novatec, 2009. ISBN9788575221938.
[4] LUCRéDIO, D. Uma Abordagem Orientada a Modelos para Reutilização de SoftwareUma Abordagem Orientada a Modelos para Reutilização de Software. 19–232 p. Tese(Dissertação) — Universidade de São Paulo, 2009.
[5] VöLTER, M. and; BETTIN, J. Patterns for Model-Driven Software-Development.2004.
[6] SILVA, A.; VIDEIRA, C. UML - Metodologias e Ferramentas. 1a. ed. Porto: CentroAtlântico Ltda, 2008.
[7] ESI, T. B. MDD Maturity Model. p. 1–44, 2006.
[8] PRESSMAN, R. S. Engenharia de Software. 6th. ed. [S.l.]: MCGRAW-HILLHIGHER EDUCATION, 2009.
[9] BELL, D. Software Engineering for Students. 4th. ed. Harlow: Pearson EducationLimited, 2005. ISBN 0321261275.
[10] SILVA, A.; VIDEIRA, C. UML - Metodologias e Ferramentas. 1a. ed. Porto: CentroAtlântico Ltda, 2001. ISBN 9728426364.
[11] TEPPOLA, S.; PARVIAINEN, P.; TAKALO, J. Challenges in Deploymentof Model Driven Development. 2009 Fourth International Conference onSoftware Engineering Advances, Ieee, p. 15–20, set. 2009. Disponível em:<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5298434>.
[12] MELLOR, S. J. et al. Model-Driven Development. IEEE Software, 2003.
[13] VARA, J. M.; MARCOS, E. A framework for model-driven development ofinformation systems: Technical decisions and lessons learned. Journal of Systemsand Software, Elsevier Inc., v. 85, n. 10, p. 2368–2384, out. 2012. ISSN 01641212.Disponível em: <http://linkinghub.elsevier.com/retrieve/pii/S0164121212001367>.
[14] LAZARTE, I. M. et al. Model-Driven Development Methodology for B2BCollaborations. In: 2010 14th IEEE International Enterprise Distributed ObjectComputing Conference Workshops. IEEE, 2010. p. 69–78. ISBN 978-1-4244-7965-8.Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5628968>.
[15] NOLAN, B. et al. Model Driven Systems Development with Rational Products.2008.
76
[16] PARVIAINEN, P. et al. Model-Driven Development Processes and practices. [S.l.]:VTT Technical Research Centre of Finland, 2009. ISBN 9789513871758.
[17] STHAL, T.; VOLTER, M. Model-Driven Software Development - Techno-logy,Engineering, Management. Wiley, 2006.
[18] SCHEKKERMAN, J. Enterprise Architecture Tool Selection Guide. 2011.
[19] EKNOLL, R.; SCHULZ, C.; AG, S. Enterprise Arhitecture Tool Survey 2013. [S.l.]:SYRACOM, 2013.
[20] HAILPERN, B.; TARR, P. Model-driven development : The good , the bad , andthe ugly. v. 45, n. 3, p. 451–461, 2006.
[21] SáNCHEZ, J.; LUIS, J.; IZQUIERDO, C. Applying model-driven engineering insmall software enterprises. Science of Computer Programming, Elsevier B.V., 2013.ISSN 0167-6423. Disponível em: <http://dx.doi.org/10.1016/j.scico.2013.04.007>.
[22] MATINNEJAD, R. Agile Model Driven Development: An Intelligent Compromise.2011 Ninth International Conference on Software Engineering Research,Management and Applications, Ieee, p. 197–202, ago. 2011. Disponível em:<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6065641>.
[23] HUTCHINSON, J.; WHITTLE, J.; ROUNCEFIELD, M. Model-driven engineeringpractices in industry : Social , organizational and managerial factors that lead tosuccess or failure. Science of Computer Programming, Elsevier B.V., 2013. ISSN0167-6423. Disponível em: <http://dx.doi.org/10.1016/j.scico.2013.03.017>.
