UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

Tamanho: px
Começar a partir da página:

Download "UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE"

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS EXATAS E DA TERRA DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA PROGRAMA DE PÓS-GRADUÇÃO EM SISTEMAS E COMPUTAÇÃO GEORGE HENRIQUE COSTA DANTAS CALV3 - UMA LINGUAGEM ESPECÍFICA DE DOMÍNIO PARA SEGURANÇA EM SISTEMAS CORPORATIVOS: UM ESTUDO DE CASO SISTEMÁTICO NA INDÚSTRIA Natal, RN 2012

2 GEORGE HENRIQUE COSTA DANTAS CALV3 - UMA LINGUAGEM ESPECÍFICA DE DOMÍNIO PARA SEGURANÇA EM SISTEMAS CORPORATIVOS: UM ESTUDO DE CASO SISTEMÁTICO NA INDÚSTRIA v.1 Dissertação de mestrado apresentada ao Programa de Pós- Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte, como requisito final para obtenção do grau de Mestre em Sistemas e Computação. Área de Concentração: Ciência da Computação Orientador: Prof. Dr. Jair Cavalcanti Leite Natal, RN 2012

3 iv Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial Especializada do Centro de Ciências Exatas e da Terra CCET. Dantas, George Henrique Costa. CALV3 - Uma linguagem específica de domínio para segurança em sistemas corporativos: um estudo de caso sistemático na indústria / George Henrique Costa Dantas. Natal, f. : il. Orientador: Prof. Dr. Jair Cavalcanti Leite. Dissertação (Mestrado) Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática Aplicada. Programa de Pós-Graduação em Sistemas e Computação. 1. Engenharia de software - Dissertação. 2. Linguagens específicas de domínio - Dissertação. 3. Desenvolvimento dirigido por modelos Dissertação. I. Leite, Jair Cavalcanti. II. Título RN/UF/BSE-CCET CDU:

4

5 vii AGRADECIMENTOS Em primeiro lugar a Deus, pela oportunidade de trilhar esta jornada e por me carregar nos braços nos momentos mais difíceis. À equipe da Coordenação de Plataformas Tecnológicas do Nordeste, por seu apoio e participação no estudo de caso e por ter prestigiado, muito mais do que o esperado, nosso singelo trabalho. Especialmente, ao coordenador Robson Paulo, pelo estímulo a este estudo e auxílio na disponibilização de recursos e tempo para realizá-lo. Aos meus familiares, minha mãe e meus irmãos, que, se não ajudaram diretamente na elaboração do trabalho, contribuíram indiretamente no imenso valor demandado pelo esforço de sua construção. Em particular ao meu pai, um exemplo de homem, de profissional, de genitor e de ser humano, que se despediu precocemente durante meu mestrado e voltou para junto de nosso Criador. A minha esposa Elisângela, pelo apoio nos momentos difíceis e pela compreensão por minhas repetidas ausências nos períodos em que podíamos estar mais juntos. As minhas filhas Ágatha e Jade, que, mesmo tão pequenas, souberam aceitar, de forma surpreendente, a ausência do papai nos finais de semana, aliviando um pouco meu peso na consciência. Ao meu orientador Jair, que foi muito além de seu papel, sendo um confidente, um psicólogo, e um verdadeiro amigo. Sem seu incentivo e confiança, confesso que eu teria desistido. E por último, todavia não menos importante, àqueles que contribuíram de alguma forma para a realização deste trabalho, mas não foram listados aqui. Se não estão citados nominalmente, é por que foram muitos, e eu, humildemente pedindo desculpas, dedico este trabalho a todos vocês.

6 ix RESUMO A comunidade acadêmica e a indústria de software têm demonstrado, nos últimos anos, bastante interesse em abordagens e tecnologias ligadas à área de desenvolvimento dirigido por modelos (MDD). Em paralelo a isto, continua a busca incessante da indústria por tecnologias que aumentem a produtividade e qualidade no desenvolvimento de produtos de software. Esta pesquisa visa explorar estas duas afirmações, através de um trabalho que usa uma tecnologia MDD e avalia seu uso na resolução de um problema real no contexto de segurança de sistemas corporativos. Com a construção e uso de uma ferramenta, uma DSL visual denominada CALV3, inspirada na abordagem de Fábricas de Software: uma sinergia entre linha de produto de software, linguagens específicas de domínio e MDD, avaliamos os ganhos em abstração e produtividade, através de um estudo de caso sistemático conduzido em uma equipe de desenvolvimento. Os resultados e lições aprendidas com a avaliação desta ferramenta no âmbito industrial são uma das principais contribuições deste trabalho. Palavras-chave: Desenvolvimento dirigido por modelos, linguagens específicas de domínio, estudo de caso.

7 x ABSTRACT The academic community and software industry have shown, in recent years, substantial interest in approaches and technologies related to the area of model-driven development (MDD). At the same time, continues the relentless pursuit of industry for technologies to raise productivity and quality in the development of software products. This work aims to explore those two statements, through an experiment carried by using MDD technology and evaluation of its use on solving an actual problem under the security context of enterprise systems. By building and using a tool, a visual DSL denominated CALV3, inspired by the software factory approach: a synergy between software product line, domainspecific languages and MDD, we evaluate the gains in abstraction and productivity through a systematic case study conducted in a development team. The results and lessons learned from the evaluation of this tool within industry are the main contributions of this work. Keywords: model-driven development, domain-specific languages, case study.

8 xi SUMÁRIO 1 INTRODUÇÃO CONTEXTO E MOTIVAÇÃO DESAFIOS E PROPOSTA DE SOLUÇÃO OBJETIVOS METODOLOGIA ORGANIZAÇÃO DO TRABALHO 6 2 CONCEITOS E TECNOLOGIAS PARA DESENVOLVIMENTO DIRIGIDO POR MODELOS DESENVOLVIMENTO DIRIGIDO A MODELOS ARQUITETURA DIRIGIDA A MODELOS (MODEL-DRIVEN ARCHITECTURE) LINGUAGENS ESPECÍFICAS DE DOMÍNIO (DOMAIN-SPECIFIC LANGUAGES) LINHA DE PRODUTO DE SOFTWARE (SOFTWARE PRODUCT LINE) FÁBRICAS DE SOFTWARE (SOFTWARE FACTORIES) DISCUSSÃO E CONSIDERAÇÕES 20 3 TRABALHOS RELACIONADOS USO DE TÉCNICAS DE MDD AVALIAÇÃO DA APLICAÇÃO E USO DE MDD 25

9 xii 4 O MODELO DE SEGURANÇA DOS SISTEMAS DE INFORMAÇÃO: SITUAÇÃO ATUAL ROLE-BASED ACCESS CONTROL (RBAC) UM EXEMPLO LIGADO AO DOMÍNIO DE SEGURANÇA EM SISTEMAS DE INFORMAÇÃO Framework de Controle de Acesso Corporativo Problemas e limitações da solução atual 35 5 CALV3 UMA DSL VISUAL PARA O DOMÍNIO DE SEGURANÇA DE SISTEMAS CORPORATIVOS PREMISSAS CONCEPÇÃO DA DSL VISUAL CALV Metodologia de criação Tarefas de desenvolvimento Selecionando um Workbench para a linguagem Arquitetura da solução CALV Design da CALV Sintaxe da CALV3 e Editor visual Validadores semânticos da CALV Gerador de código e framework da CALV Template de geração de código Empacotamento da solução e geração de documentação 63

10 xiii 6 ESTUDO DE CASO - AVALIAÇÃO DA CALV MÉTODOS DE AVALIAÇÃO EMPÍRICOS EM ENGENHARIA DE SOFTWARE METODOLOGIA Projeto do estudo de caso: Plano e protocolo Coleta e análise dos dados Análise das questões Ameaças à validade Resultado final 79 7 CONSIDERAÇÕES FINAIS E CONCLUSÕES CONTRIBUIÇÕES TRABALHOS FUTUROS CONCLUSÃO 86 REFERÊNCIAS 87 ANEXOS 92

11 xiv LISTA DE FIGURAS Figura 1 - Processo Básico MDA...12 Figura 2 - Processos principais da engenharia de LPS...16 Figura 3 - Mapeamento entre espaço dos problemas e soluções...17 Figura 4 - Processo de construção de uma Fábrica de SW...20 Figura 5 - Macro-Arquitetura do CA V Figura 6 - Kit de apoio dos administradores...32 Figura 7 - Console web utilizado por analistas e desenvolvedores...33 Figura 8 - Exemplo de um sistema do CA que usa funcionalidades típicas...34 Figura 9 - Principais atores e atividades realizadas no CA...35 Figura 10 - Diagrama de componentes dos principais elementos arquiteturais da solução DSL CALV Figura 11 - Classe raiz do meta-modelo e seus relacionamentos...46 Figura 12 - Relacionamentos permitidos da classe Perfil...47 Figura 13 - Relacionamento entre Usuário e Perfil...48 Figura 14 - Relacionamento de hierarquia entre Objetos...49 Figura 15 - Relacionamento de agregação entre objeto e ação...49 Figura 16 Meta-modelo completo da CALV Figura 17 - Mapeamento entre Perfil e sua classe de sintaxe visual...51 Figura 18 - Mapeamento entre a conexão hierarquia e sua classe de sintaxe visual...52

12 xv Figura 19 - Barra de ferramentas da CALV Figura 20 - Janela de propriedades para config. dos elementos de sintaxe visual...55 Figura 21 - Janela de navegação da CALV Figura 22 - Erros de validação exibidos na janela de erros da IDE...57 Figura 23 - Implementação de um validador semântico para a classe Grupo...58 Figura 24 - Experiência de modelagem completa da CALV Figura 25 - Classe CAFramework chamada pelo script de geração de código...61 Figura 26 - Trecho do template T Figura 27 - Programa de carga gerado pelo template com base em um modelo CALV Figura 28 - Empacotamento físico da solução...64 Figura 29 - Página do Wiki contendo links para o instalador e a documentação da ferramenta...64

13 xvi LISTA DE TABELAS Tabela 1 - Linguagem de meta-modelagem da DSL Tools...43 Tabela 2 Elementos da sintaxe visual da CALV3...52

14 xvii LISTA DE GRÁFICOS Gráfico 1 Resultado quantitativo da questão Gráfico 2 - Resultado quantitativo da questão Gráfico 3 - Resultado quantitativo da questão Gráfico 4 - Resultado quantitativo da questão Gráfico 5 - Resultado quantitativo da questão Gráfico 6 - Resultado quantitativo da questão Gráfico 7 - Resultado quantitativo da questão Gráfico 8 - Resultado quantitativo da questão Gráfico 9 Índice de favorabilidade da CALV3...79

15 xviii LISTA DE ABREVIATURAS E SIGLAS API Application Program Interface CIM Computation Independent Model DSL Domain-Specific Languages IDE Integrated Development Environment LPS Linhas de Produto de Software MDA Model-Driven Architecture MDD Model-Driven Development MDE Model-Driven Engineering MDSD Model-Driven Software Development MDSE Model-Driven Software Engineering OMG Object Management Group PIM Platform Independent Model PSM Platform Specific Model RBAC Role-Based Access Control UML Unified Modeling Language

16 1 1 INTRODUÇÃO A incessante busca pelo aumento de qualidade e diminuição de custos e prazos no desenvolvimento de software é um grande motivador para o surgimento de novos processos, técnicas e ferramentas. Recentemente, temos percebido um crescente interesse das comunidades acadêmica e industrial em abordagens e tecnologias ligadas à área de desenvolvimento dirigido por modelos, como podemos verificar pela grande quantidade de artigos acadêmicos e eventos sobre este assunto 1. Novas tecnologias geram necessidade de experimentação prática, a fim de avaliá-las no âmbito da resolução de problemas reais enfrentados durante o processo de desenvolvimento. Este trabalho apresenta uma linguagem visual específica de domínio, construída com uma dessas tecnologias, e realiza um estudo de caso sobre seu uso, avaliando os resultados na resolução de um problema no contexto particular da área de TI de uma grande indústria CONTEXTO E MOTIVAÇÃO A área de desenvolvimento dirigido por modelos (Model-Driven Development: MDD) tem recebido muita atenção, especialmente nos últimos 10 anos, tanto na academia quanto no âmbito industrial. Esta afirmação pode ser verificada através de uma busca nos principais motores de pesquisa de artigos, como ACM Digital Library ou IEEE Xplore, que retorna alguns milhares de artigos relacionados à área na última década, contra poucas centenas na década anterior 1. A prática oriunda das engenharias, como a civil e elétrica, de usar modelos para fazer o design de sistemas complexos começou cada vez mais a ganhar importância dentro da área de engenharia de software. Modelos ajudam a entender problemas complexos e suas potenciais soluções através de abstrações e, sendo assim, intui-se a princípio que devia ser natural para a área de desenvolvimento de software, que não está sujeita às limitações do 1 Uma busca no portal ACM (http://dl.acm.org/advsearch.cfm) retornou no total 2383 publicações com os termos Model-driven Development ou Domain-Specific Language de 2002 a 2011 contra 49 na década anterior (1991 a 2001). Na IEE Xplore (http://ieeexplore.ieee.org/search/advsearch.jsp?advanced-search), a busca pelos mesmos termos encontrou 3101 publicações na última década, contra 137 na década anterior.

17 2 mundo físico, utilizar modelos como ferramentas primárias. Contudo, historicamente, o uso de modelos, principalmente na indústria, representa um papel secundário [62] no processo de desenvolvimento. A profusão de pesquisas acadêmicas e a entrada de empresas de peso da indústria de software [54, 57] nesta área começaram a mudar este cenário e abrir caminho para a concretização da visão proposta pelo MDD: produzir tecnologias que abstraiam para os desenvolvedores as complexidades da plataforma de implementação subjacente, fazendo os modelos tornarem-se os artefatos primários do processo de desenvolvimento. As tecnologias que buscam implementar a visão de MDD focam em fazer os desenvolvedores trabalharem mais próximos do domínio dos problemas e confiar cada vez mais em ferramentas que os auxiliem a chegar até níveis de abstração mais baixos, como o código. Neste cenário, os modelos representam um papel vital, pois são o ponto de partida do processo de entender o problema e de sucessivamente refiná-lo até encontrar sua representação na implementação do software, o domínio da solução. Alguns autores citam que isto é uma evolução da iniciativa que começou com as ferramentas case, nas décadas de 80 e 90 [63], contudo, no contexto atual de MDD, o foco principal do modelo não é a documentação do sistema, o próprio modelo passa a ser o foco do desenvolvimento. Existem duas escolas de pensamento principais em MDD [61]: as baseadas em UML (Unified Modeling Language) e as baseadas em linguagens específicas de domínio (Domain- Specific Languages: DSL). Cada uma destas escolas visa concretizar os benefícios do MDD utilizando caminhos ligeiramente diferentes, mas ambas buscam um importante fator para se confirmar como uma prática bem sucedida: a participação industrial. A aplicação na indústria e a investigação dos resultados práticos são necessárias para se alcançar um entendimento mais profundo dos problemas do desenvolvimento [61]. Através da resolução de problemas reais encontrados na indústria de software, o MDD poderá confirmar se é apenas mais uma tecnologia que futuramente cairá em desuso ou se representará um novo salto evolutivo no desenvolvimento de aplicações. Contudo, na indústria de software e, em particular, de desenvolvimento de sistemas corporativos (enterprise information systems), os objetivos principais a serem alcançados são o desenvolvimento de produtos de alta qualidade e com produtividade, isto é, a um custo baixo e em prazos reduzidos. Para os praticantes, não é tão importante quais modelos,

18 3 ferramentas ou técnicas propostas pela engenharia de software sejam usadas, desde que estes objetivos sejam alcançados. Muitos deles já relegam a segundo plano investir em novas tecnologias de apoio ao desenvolvimento de software, preferindo investir em processos [62], tais como métodos ágeis ou RUP (Rational Unified Process). Isto, em parte, é explicado pelo fato de constantemente surgirem tecnologias proclamando-se ser a bala de prata (silver bullet [4]), que resolverá todos os problemas do desenvolvimento, mas que, na prática, tem uso bastante limitado ou trazem tantas dificuldades quanto benefícios. Pela visão de MDD, os benefícios em qualidade e produtividade aparentemente são óbvios, visto que ferramentas devem automatizar boa parte do processo de geração de código com base nos modelos, contudo, ainda não estão muito claros o custo e o esforço associados à construção destas ferramentas DESAFIOS E PROPOSTA DE SOLUÇÃO Existem vários desafios para a adoção de técnicas de MDD na indústria. Um dos primeiros é evidenciar que elas podem ser implantadas a um custo razoável [63]. Para isto, deve ser investigado se o modelo é significativamente menos custoso de construir e analisar do que seu equivalente em código. Precisa ficar claro para os praticantes que a construção do modelo não é um overhead desnecessário do processo, pois muitos artefatos serão gerados automaticamente com base nele, e, assim, o custo-benefício da técnica torna-se extremamente favorável, em vista do aumento da produtividade e, idealmente, da qualidade. Outro grande desafio, provavelmente o maior deles, é mostrar que aumentar o nível de abstração através de modelos realmente trará ganhos significativos ao desenvolvimento de software. Há uma grande faixa de problemas técnicos, e até mesmo sociais, interrelacionados a este desafio e espera-se que o feedback da indústria possa trazer importantes contribuições nesta área. Conforme citado por alguns autores, como Robert France e Bernhard Rumpe, uma forma prudente e prática de investigar a introdução de novas tecnologias e técnicas em um ambiente de produção existente é aplicá-las a um projeto de menor escala [61]. No contexto de MDD, isto pode significar a escolha de um segmento de negócio mais específico, onde esta

19 4 experimentação possa ser feita de forma direcionada. Isto vem ao encontro da vertente de linguagens específicas de domínio de MDD. Pode-se escolher um domínio de negócio bem específico e construir um meta-modelo para este domínio, disponibilizando-o para que as equipes de desenvolvimento possam utilizá-lo como artefato primário para a construção de demais artefatos do projeto. Assim, poderiam estar sendo avaliadas várias dimensões da implantação de uma tecnologia MDD. Seguindo a linha de raciocínio exposta acima, o principal objetivo deste trabalho é avaliar o uso de uma DSLs visual como ferramenta de apoio ao desenvolvimento de software, visando a resolução de um problema real e específico, no domínio de segurança de sistemas corporativos. Este domínio é de entendimento relativamente fácil para as equipes de desenvolvimento e, em teoria, permitirá às mesmas observarem se os benefícios propostos pelas técnicas de MDD serão percebidos na prática. Para esta avaliação, primeiramente será necessário construir a DSL, que terá como base a solução de segurança utilizada pela área de Tecnologia de Informação de uma grande indústria. Esta solução, denominada de framework de controle de acesso corporativo, é composta por um banco de dados com informações ligadas à segurança de sistemas, além de APIs (Application Program Interface) para as tecnologias Java e.net, e duas ferramentas (sistemas) de acesso a este banco, uma para os administradores e outra para os usuários, neste caso os desenvolvedores de aplicação. Este framework lida com conceitos ligados à segurança de sistemas, tais como usuários, grupos, perfis etc., mas, atualmente, não possui uma forma de modelagem visual e padronizada destes conceitos. A inexistência de uma forma padronizada e visual para modelar a segurança destes sistemas traz alguns problemas. Um dos maiores é que se torna bastante difícil para as equipes entenderem os modelos de segurança dos sistemas, principalmente quando já se passou algum tempo desde sua concepção inicial. Isto gera dificuldades nas migrações, evoluções ou reuso do modelo em novos sistemas. Sendo assim, um dos principais desafios é extrair os modelos existentes na mente dos especialistas de segurança, os criadores, ou, na melhor das hipóteses, em documentos informais e não padronizados criados por estes, e utilizá-los como base para melhorias ou criação de novas instâncias para outros sistemas.

20 5 Resumindo, há um grande gap entre os modelos mentais e a visualização dos conceitos e funcionalidades do framework de segurança que estão sendo utilizados. Conforme citado na literatura [5, 8], uma DSL visual pode preencher este gap e, de forma complementar, espera-se a obtenção de outros benefícios prometidos pelos adeptos de MDD OBJETIVOS Um dos objetivos do trabalho é o desenvolvimento de uma DSL visual para minimizar o gap que ocorre entre o modelo mental da segurança dos sistemas e sua implementação na base de dados do controle de acesso. Além disso, é também objetivo avaliar tanto o processo de desenvolvimento da DSL, quanto seu uso pelos desenvolvedores de aplicação, através de um estudo de caso. Com isto, almeja-se obter bastante informação sobre a implantação e uso de uma técnica de MDD na indústria. A técnica escolhida foi inspirada na proposta de Software Factories [7], segundo seus autores: uma sinergia entre linha de produto de software, MDD e DSL. A escolha de um estudo de caso deveu-se ao fato do problema estar ligado a um contexto muito específico, situação na qual técnicas mais experimentais apresentam bons resultados [74], visto que a generalização não é um resultado almejado. Em linhas gerais, os resultados a serem avaliados, através do estudo de caso sistemático, são se, com o uso da DSL, os desenvolvedores alcançam ou não os seguintes macro-benefícios: - Aumento do nível de abstração na modelagem do domínio, permitindo uma fácil visualização da estrutura de segurança dos sistemas, possibilitando maior entendimento e capacidade de validação prévia das funcionalidades modeladas; - Aumento de produtividade, através de geração automática de código com base no modelo e também de seu reuso em projetos diferentes.

21 METODOLOGIA Para a condução desta avaliação foi utilizada uma metodologia de pesquisa empírica. A pesquisa empírica visa explorar, descrever, prever e explicar fenômenos naturais, sociais ou cognitivos usando evidência baseada em observação ou experiência. Métodos quantitativos e qualitativos podem ser utilizados para coletar e analisar dados. Neste trabalho, foi realizado um estudo de caso, conforme a definição apresentada por Kitchenham em [74]. Também de acordo com Sjoberg em [72], um estudo de caso é uma pesquisa empírica que investiga um fenômeno contemporâneo dentro de seu contexto real, especialmente quando os limites entre fenômeno e contexto não são claramente evidentes. O estudo de caso seguiu a abordagem proposta por Runeson em [74], que é composta pelo projeto(design) do estudo de caso, seguidos da coleta e análise dos resultados e sua formatação em um relatório. Basicamente, a investigação realizada foi um estudo de caso predominantemente qualitativo: uma avaliação sistemática baseada em features sobre um método/ferramenta utilizada na prática em um projeto real [73]. Após a construção e empacotamento (deploy) da ferramenta, houve um treinamento da DSL visual para uma equipe de desenvolvimento, visando seu uso em projetos existentes ou em andamento. Foram aplicados questionários no estilo survey [75], complementados com entrevistas. Através da análise das respostas dos questionários e das entrevistas, foram avaliados se os macro-objetivos citados na seção 1.3 foram alcançados, além de outras dimensões do uso de uma tecnologia de MDD em projetos reais. Este processo será melhor detalhado no capítulo ORGANIZAÇÃO DO TRABALHO O restante deste trabalho está organizado da seguinte forma: no capítulo 2, daremos uma visão geral sobre a área de MDD, discutindo seus conceitos básicos, benefícios esperados e limitações atuais, além de discorrer sobre algumas das principais abordagens e tecnologias que aplicam suas ideias. Também faremos uma breve discussão sobre o uso atual destas idéias na indústria. No capítulo 3, discorreremos sobre trabalhos relacionados a estudos de caso em áreas correlatas e outros artigos que abordam o uso de DSLs. No capítulo 4, abordaremos o domínio de segurança de sistemas de informação, detalhando um caso real na área de TI de

22 7 uma grande indústria e relatando os problemas enfrentados na situação atual. Nesta seção detalharemos os conceitos e arquitetura utilizados pelo framework de segurança. No capítulo 5, apresentaremos o projeto da DSL proposta para resolver os problemas relatados no capítulo anterior e a tecnologia utilizada para construí-la. No capítulo 6, faremos um detalhamento da metodologia do estudo de caso, bem como, apresentaremos o resultado das análises dos dados coletados. No capítulo 7, levantaremos algumas considerações finais e conclusões.

23 9 2 CONCEITOS E TECNOLOGIAS PARA DESENVOLVIMENTO DIRIGIDO POR MODELOS O desenvolvimento dirigido a modelos, do inglês Model-Driven Development-MDD, representa uma denominação comum para uma série de abordagens que direcionam o foco principal do desenvolvimento de software para os modelos, aumentando o nível de abstração do processo de construção em direção ao domínio dos problemas. Um dos principais objetivos destas abordagens é promover um alto nível de produtividade através da geração automática de código. Na literatura, podemos encontrar uma série de acrônimos diferentes representando esta mesma ideia: Model-Driven Software Development (MDSD) Model-Driven Engineering (MDE) Model-Driven Software Engineering (MDSE) Model-Driven Architecture (MDA) Para efeitos deste trabalho, consideraremos como sinônimos de MDD os três primeiros. Trataremos a MDA de forma separada por tratar-se de uma visão de MDD específica da instituição OMG (Object Management Group) e dedicaremos uma seção específica para abordá-la. A área de MDD atualmente é bastante abrangente e possui várias abordagens que propõem diferentes implementações de sua visão. Algumas outras áreas correlatas possuem estreita ligação com MDD, seja por compartilhar alguns princípios seja por serem ferramentas e técnicas que servem ao propósito de concretizar esta visão. Neste capítulo, discorreremos sobre os conceitos básicos relacionados à área, dando uma visão geral sobre as principais abordagens de MDD, bem como das tecnologias chave para a implementação destas abordagens.

24 DESENVOLVIMENTO DIRIGIDO A MODELOS Os principais objetivos do MDD são aumentar o nível de abstração na especificação do software através de modelos e promover a automação no desenvolvimento com base nestes modelos. Estes objetivos são os mesmos encontrados em outras disciplinas de engenharia, como por exemplo, engenharia elétrica e engenharia de produção, que há muito tempo já utilizam modelos para fazer o design de sistemas complexos e ferramentas para realizar a construção automática ou semi-automática de produtos baseados nestes modelos. Sendo assim, uma das principais linhas de pesquisa nesta área é a engenharia dirigida a modelos, ou Model-Driven Engineering, MDE, acrônimo pelo qual é mais conhecida. Na MDE, os modelos são usados em diferentes níveis de abstração e, através de transformações sucessivas, chegam até níveis de abstração mais baixos, como o código. Ou seja, modelos de mais alto nível são transformados em modelos de mais baixo nível até que o modelo possa ser executável, através de geração de código ou interpretação. Um modelo, como abstração de algum aspecto do sistema, é criado para servir a objetivos específicos, por exemplo, para apresentar uma descrição humanamente inteligível ou para apresentar informação de modo que possa ser automaticamente analisada. Para especificar estas abstrações é necessário algum tipo de notação, ou linguagem do modelo. Pode parecer a princípio que, por MDE tratar de desenvolvimento de software, a notação a ser utilizada seja a mais popular e amplamente utilizada: Unified Modeling Language UML[59]. Contudo, apesar do papel vital que a UML desempenhou em unificar a modelagem de software, suas abstrações não são obrigatoriamente as mais indicadas para modelar o domínio dos problemas. Ou seja, seu nível de abstração pode estar tão próximo do nível do código que a sua transformação não represente nenhum avanço significativo em relação ao uso do código somente, e, assim, não contemple os objetivos propostos pela MDE. Assim, a linguagem do modelo pode, em vários casos, ser adaptada (tailored) ao domínio do problema. Neste caso, esta linguagem é denominada linguagem específica de domínio (Domain-Specific Language-DSL). Estes dois pontos de vista deram origem a duas escolas de pensamento distintas em MDE [61]: as baseadas em UML e as baseadas em DSLs.

25 11 Na seção seguinte discutiremos uma abordagem da primeira escola, a MDA, que utiliza a UML como sua linguagem de modelo. Nas seções subsequentes, detalharemos conceitos sobre DSLs e discutiremos duas abordagens desta segunda escola de pensamento ARQUITETURA DIRIGIDA A MODELOS (MODEL-DRIVEN ARCHITECTURE) A instituição OMG, Object Management Group, divulgou oficialmente em 2001 a abordagem MDA, Model-Driven Architecture, como um framework de padrões para MDE. A ideia da OMG é que as tecnologias MDA irão prover meios para integrar mais facilmente novas infra-estruturas de implementação a designs existentes, gerar uma quantidade significativa de artefatos (código-fonte, arquivos de configuração, entre outros) a partir de modelos, facilitar a sincronização de modelos e sua implementação durante a evolução do software, e rigorosamente simular e testar modelos. A MDA propõe a modelagem de sistemas com base em três pontos de vista (viewpoints): independente de computação, independente de plataforma e específico de plataforma. O ponto de vista independente de computação foca no ambiente no qual o sistema de interesse irá operar e nas características (features) requeridas pelos sistemas. Modelar um sistema deste ponto de vista resulta no modelo independente de computação, Computation Independent Model (CIM), que seria o modelo de requisitos do software. Já o ponto de vista independente de plataforma foca nas características do sistema que não mudarão de uma plataforma para outra. O modelo independente de plataforma, Platform Independent Model (PIM), é utilizado para apresentar este ponto de vista, que seria equivalente aos modelos de análise e design lógico. A OMG define plataforma como um conjunto de subsistemas e tecnologias que provêem um conjunto coerente de funcionalidades através de interfaces e padrões de uso especificados. Exemplos de plataforma são frameworks de componentes específicos de uma tecnologia, como CORBA ou J2EE, e implementações de tecnologias de middleware desenvolvidas pela indústria, como IBM WebSphere e Microsoft.NET. Finalmente, o ponto de vista específico de plataforma é aquele que provê uma visão do sistema na qual detalhes específicos de uma plataforma são integrados com os elementos contidos no PIM. Esta visão de um sistema é descrita por um modelo específico de

26 12 plataforma, Platform Specific Model (PSM), que representaria um modelo de design físico. A separação de detalhes independentes de plataforma e específicos de plataforma é considerada a chave para prover suporte efetivo para a migração de uma aplicação de uma plataforma de implementação para outra. O processo básico pode ser resumido nos passos seguintes, vide Figura 1. O CIM é definido por um analista de requisitos em conjunto com o usuário. Em seguida o CIM será transformado em um PIM por um arquiteto. Ele adicionará conhecimento arquitetural sem exibir detalhes da plataforma usada. O PIM resultante terá que ser direcionado para uma plataforma para completar o processo de construção. Para isto um modelo detalhado da plataforma será necessário. A transformação do PIM para o PSM será feita por um especialista na plataforma. O PSM resultante poderá ser uma implementação, se ele prover toda a informação necessária para construir um sistema e colocá-lo em operação. Figura 1 - Processo Básico MDA Durante o processo de MDA, uma série de padrões e linguagens são utilizadas. As principais são o Meta Object Facility (MOF)[58], linguagem para definir a sintaxe abstrata das linguagens de modelagem, a Unified Modelling Language (UML)[59], e o padrão Query, View, Transformation (QVT)[60], um padrão para especificar e implementar transformações entre modelos. Outros padrões da OMG também podem ser utilizados, tais como XML Metadata Interchange (XMI), Common Warehouse Meta-model (CWM), Software Process Engineering Meta-model (SPEM) e Object Constraint Language (OCL). Apesar de ser uma das primeiras e, talvez a mais conhecida, abordagem de MDD, alguns autores, como Jack Greenfield, entre outros, criticam a MDA, principalmente pelo seu forte foco na linguagem UML. Outros, como Robert France e Sudipto Gosh, citam o grande tamanho e complexidade da UML como um fator complicador para a realização da visão de

27 13 MDD [65]. Alguns outros, como Mark Dalgarno e Matthew Fowler, criticam a generalidade da linguagem e sua incapacidade de expressar abstrações em níveis mais altos [66], aspectos que são o ponto forte da escola de DSL. A OMG vem sempre evoluindo seus padrões atenta às críticas e ao feedback recebido da indústria e academia e já há fortes indícios que a próxima versão da UML caminha para um formato mais expressivo, facilitando a integração com outras linguagens de modelagem, como DSLs, ou de programação [67] LINGUAGENS ESPECÍFICAS DE DOMÍNIO (DOMAIN-SPECIFIC LANGUAGES) De acordo com a definição proposta por Deursen, Klint e Visser [5], uma linguagem específica de domínio é uma linguagem de programação ou linguagem de especificação executável que oferece, através de notações apropriadas e abstrações, poder expressivo focado em, e usualmente restrito a, um domínio de problemas em particular. Desta definição, dois conceitos são a chave para entender DSLs: expressividade e especificidade. Pelo fato do escopo destas linguagens ser restrito a um domínio de problemas, é possível fornecer um suporte mais poderoso e expressivo para a resolução de problemas dentro deste escopo. O domínio dos problemas pode ser visto tanto como um domínio do mundo real, quanto como um conjunto de sistemas semelhantes, conforme apontado pela comunidade de pesquisa de reuso sistemático de software. As DSLs podem ser expressas em uma variedade de formas [13]: textual (stand-alone ou embutida em uma linguagem de programação de propósito geral), baseada em formulários, baseada em grids ou visual (diagramática). Como exemplos, podemos citar a linguagem SQL como DSL textual, os Wizards (passo-a-passo) de instalação de software como DSLs de formulários ou grids, e linguagens de modelagem de processo tais como BPM, como DSLs visuais. Fowler [3] propõe classificar as DSL em três categorias: externas, para as quais é necessário construir um parser completo, internas (ou embutidas), que seriam uma forma idiomática de se usar uma linguagem de propósito geral, e as integradas a workbenches, ferramentas de criação de DSLs com potencial semelhante, e normalmente integrado, aos

28 14 modernos ambientes de desenvolvimento de software (IDEs). Para exemplificar, com a linguagem SQL poderíamos fazer uma sub-linguagem apenas para os comandos de consulta (select). Se construirmos uma nova ferramenta parser para interpretar os comandos textuais, seria uma DSL externa. Caso utilizássemos a máquina virtual java para interpretar os comandos integrados ao código-fonte, seria uma DSL interna ou embutida. Mas, caso configurássemos a IDE eclipse para criar um diagrama visual para modelar os comandos, seria uma DSL integrada a workbench. Em relação ao MDD, as DSLs visuais representam uma das principais formas de linguagem de modelos. As DSLs visuais integradas a workbenches tem sido cada vez mais utilizadas para possibilitar o aumento da abstração no sentido código-modelo, bem como promover um aumento de produtividade através da geração automática de código, principalmente com base em frameworks de desenvolvimento, bibliotecas de classes ou APIs (Application Program Interface). Contudo, adotar uma abordagem baseada em DSL pode oferecer riscos e oportunidades. Uma DSL bem projetada terá que encontrar o equilíbrio adequado entre eles. Dentre os principais benefícios de uso podemos citar [5]: 1. DSLs podem permitir que as soluções sejam expressas no idioma e no nível de abstração do problema do domínio e, consequentemente, especialistas no domínio conseguem entender, validar, modificar e mesmo criar as mesmas; 2. DSLs, especialmente as visuais, são auto-documentadas e podem ser utilizadas para diferentes finalidades (geração de código, validação, simulação etc.); 3. DSLs podem aumentar a produtividade, confiabilidade, manutenibilidade e portabilidade; 4. DSLs incorporam o conhecimento humano, ou seja, permitem extrair os modelos existentes na mente de indivíduos ou equipes para conservá-los e reusá-los. Possíveis desvantagens no uso de DSLs compreendem: Os custos de projetar, implementar e manter uma DSL;

29 15 Os custos de treinamento dos usuários da DSL; A dificuldade de encontrar o escopo correto para uma DSL; A dificuldade de balancear entre especificidade do domínio e as construções da linguagem de programação de propósito geral; A potencial perda de eficiência quando comparada ao código customizado. Visando minimizar as desvantagens de custo, as DSLs integradas a workbenches têm sido cada vez mais utilizadas [64], na tentativa de que elas permitam a construção e evolução de DSLs de forma menos onerosa e mais intuitiva para os desenvolvedores. Além disso, abordagens que promovem aumento de reuso através da construção de famílias de sistemas, ao invés de sistemas individuais sob medida (custom systems), também tem usado DSLs como uma forma mais criativa e expressiva de se especificar as características (features) desejadas no produto final. Discutiremos duas destas abordagens nas seções seguintes LINHA DE PRODUTO DE SOFTWARE (SOFTWARE PRODUCT LINE) Uma das abordagens mais recentes para aumento do reuso, proposta tanto pela academia quanto pela indústria, muda o foco do desenvolvimento de um sistema específico para o desenvolvimento de uma família de sistemas. De acordo com Parnas [1], uma família de sistemas é um conjunto de aplicações que compartilham funcionalidades comuns, mas que mantém funcionalidades específicas que variam de acordo com o sistema sendo considerado. O termo Linha de Produto de Software (Software Product Line - SPL) foi designado para nomear uma família de sistemas que atende necessidades específicas de um segmento de mercado particular ou missão [2]. Esta inovação na forma de pensar e construir software trouxe à tona a necessidade de prover métodos, técnicas e ferramentas para produção em grande escala de famílias de produtos, dando origem à engenharia de LPS.

30 16 O processo de engenharia de LPS está tipicamente dividido em duas fases: engenharia de domínio e engenharia de aplicação. Coordenando estas duas fases há o processo de gerenciamento (vide figura 2). Na engenharia de domínio, o foco é o desenvolvimento dos artefatos que deverão ser reusados em todas as fases da construção (ou derivação) de um produto específico da LPS. Na engenharia de aplicação os artefatos desenvolvidos, denominados ativos reusáveis (arquitetura comum, componentes, modelos etc.), são utilizados no processo de construção permitindo a rápida geração de variantes de produtos, ou de partes de produtos, que podem ser posteriormente customizados visando atender a alguma especificidade. Figura 2 - Processos principais da engenharia de LPS Dentre as várias abordagens propostas para a engenharia de LPSs, uma se destaca pelo forte foco na automatização da geração de produtos com base em especificações escritas em uma ou mais linguagens específicas de domínio, textuais ou gráficas. Esta abordagem, proposta por Czarnecki [13], ficou conhecida como Desenvolvimento Generativo de Software.

31 17 Um conceito chave no desenvolvimento generativo é o mapeamento entre o espaço dos problemas e o espaço das soluções (vide figura 3), ou modelo de domínio generativo. O espaço dos problemas é um conjunto de abstrações específicas de um domínio que podem ser utilizadas para especificar o membro desejado da família de produtos. O espaço das soluções, por outro lado, consiste de abstrações orientadas a implementação (codificação), que podem ser instanciadas para criar implementações das especificações expressas com as abstrações do espaço dos problemas. O mapeamento entre os espaços recebe uma especificação e retorna a implementação correspondente. Figura 3 - Mapeamento entre espaço dos problemas e soluções Existem duas visões diferentes deste mapeamento: a visão de configuração e a visão transformacional. Na visão de configuração, o espaço dos problemas consiste em conceitos do domínio e suas características (features). A especificação de um sistema requer a seleção das features que o sistema desejado deve ter. Combinações ilegais de features, dependências e features padrão também estão definidas no espaço dos problemas. O espaço de solução consiste em um conjunto de componentes que podem ser compostos para criar implementações de sistemas. Uma arquitetura de família de sistemas controla as regras de como os componentes podem ser compostos. Na visão de configuração, o desenvolvedor de produtos cria uma configuração de features através da seleção daquelas desejadas, que então

32 18 são mapeadas para uma configuração de componentes. O mapeamento entre ambos os espaços é definido por regras de construção e otimizações. O conjunto englobando o mapeamento e as restrições, dependências e padrões de features do espaço dos problemas é denominado conhecimento de configuração. Na visão transformacional, o espaço dos problemas é representado por uma linguagem específica de domínio, enquanto o espaço das soluções é representado por uma linguagem de implementação. O mapeamento entre os espaços é uma transformação que recebe um programa em uma linguagem específica de domínio e produz sua implementação na linguagem de implementação. Existe uma grande correspondência entre as duas visões. O espaço dos problemas com suas features comuns e variáveis e restrições na visão de configuração, frequentemente representados através de modelos de feature, podem definir uma linguagem específica de domínio. Os componentes do espaço das soluções também podem ser visualizados como uma linguagem de implementação. Sendo assim, pode-se perceber o quanto essa abordagem está fortemente relacionada à escola de DSL do MDD. A principal diferença é o foco do desenvolvimento generativo em uma família de sistemas, o que não é um requisito obrigatório em MDD ou MDE. Na seção seguinte discorreremos sobre outra abordagem de família de sistemas que está fortemente relacionada à MDD e desenvolvimento generativo FÁBRICAS DE SOFTWARE (SOFTWARE FACTORIES) Greenfield e Short [7] propuseram a ideia de Fábrica de Software (Software Factories) como uma união de inovações críticas da área de engenharia de software, como desenvolvimento baseado em componentes (Component-Based development-cbd), desenvolvimento dirigido a modelos e linha de produto de software, a fim de compor uma nova abordagem mais produtiva do que cada inovação separadamente. De acordo com estes autores, uma fábrica de software é uma linha de produto de software que configura ferramentas extensíveis, processos e conteúdo, usando um template baseado em um esquema

33 19 (schema), para automatizar o desenvolvimento e manutenção de variantes de um produto arquetípico através de adaptação, montagem e configuração de componentes baseados em um framework. Os três elementos chave na realização da visão de Fábricas de Software são os seguintes: Esquema (Software Factory Schema): Este esquema é um grafo de pontos de vista (viewpoints) definidos usando tecnologias da Fábrica. Ele descreve a arquitetura de uma linha de produto em termos de linguagens de modelagem específicas de domínio a serem usadas, e os mecanismos a serem usados para transformar modelos em outros modelos ou em artefatos de implementação. Software Factory Template: Um template de Fábrica provê os artefatos reusáveis, orientações, exemplos e ferramentas específicas necessários para construir membros da família de produtos. Um ambiente de desenvolvimento extensível: Para realizar a visão de Fábrica de Software, é necessário um framework que possa ser configurado utilizando o esquema e o template da Fábrica para produzir um ambiente de desenvolvimento para uma família de produtos. Na prática, desenvolver uma Fábrica de Software é semelhante a desenvolver uma linha de produto de software utilizando desenvolvimento generativo. Através do uso de padrões, modelos, frameworks e ferramentas, um ambiente de desenvolvimento integrado (IDE), como Visual Studio, Eclipse etc., é turbinado de modo a se tornar uma fábrica para a produção de produtos de uma família (vide figura 4).

34 20 Figura 4 - Processo de construção de uma Fábrica de SW Tal como em MDD, um dos pontos chave da iniciativa de Fábrica de Software é promover os modelos a artefatos de primeira linha no desenvolvimento, passando de simples documentação a elementos críticos para a geração automática de várias partes do produto. Isto é obtido através do uso extensivo de linguagens específicas de domínio (DSLs) integradas a mecanismos de transformação e geração de código. Uma das grandes barreiras para adoção desta técnica é a complexidade e esforço necessários para a construção de uma DSL, especialmente as visuais. Para suplantar esta dificuldade novas ferramentas de modelagem de DSLs (Domain Specific Modeling DSM) foram desenvolvidas, permitindo a viabilidade do desenvolvimento de DSLs em termos de custo e produtividade, como, por exemplo, Intentional Software [51], Meta Programming System da JetBrains [52], MetaEdit+ da MetaCase [53] e DSL Tools da Microsoft [54]. O presente trabalho exercitou o uso de uma abordagem inspirada na ideia de fábricas de software, utilizando o ambiente de desenvolvimento (IDE) como hospedeiro da DSL visual (modelo específico de domínio) e das ferramentas de transformação e geração de código DISCUSSÃO E CONSIDERAÇÕES Há um sentimento muito forte entre os praticantes de que modelos não são tão confiáveis quanto o código-fonte [62]. Muitos argumentam que durante a vida útil do

35 21 software as evoluções podem ser feitas, e frequentemente o são, sem o respectivo ajuste na documentação e, sendo assim, os modelos deixam de refletir a realidade do software. Em alguns casos, a diferença é tão grande que a própria arquitetura do software fica descaracterizada, gerando a denominada erosão arquitetural [71]. Esta realidade ocorre principalmente pelo fato de modelos ainda serem vistos apenas como artefatos de documentação. A geração de código com base nos modelos ainda é bastante incipiente na indústria e, via de regra, não passa da geração de arcabouços que precisam ser adaptados ou ter boa parte de seu código complementada manualmente. A linguagem UML trouxe grandes avanços no sentido de padronizar e unificar a notação dos modelos de desenvolvimento de software, contudo seu uso apresenta dois limitadores constantemente criticados na indústria: Gerar código com base em UML muitas vezes dá mais trabalho do que fazer o código manualmente. Um modelo UML que seja completo o suficiente para ter seu código gerado em uma linguagem de programação específica, necessita de uma série de características adicionais, tais como estereótipos, profiles, sem falar na própria ferramenta para geração automática que nem sempre é fácil de utilizar. Além disso, o código gerado não se mantém sincronizado com o modelo, ou seja, alterações no modelo não são propagadas para o código-fonte e vice-versa, gerando a desconfiança citada no parágrafo anterior. Os modelos UML utilizam uma notação muito voltada para o domínio da solução. A UML, a despeito de ser sigla de linguagem de modelagem, traz desde sua concepção fortes laços com a modelagem orientada a objetos [67]. Sendo assim, a maioria de seus diagramas, tais como classes, sequência, colaboração etc. refletem conceitos da orientação a objetos. Apesar da evolução da linguagem com o lançamento da UML 2.0, ela ainda guarda em sua essência o fato de ser genérica demais e, ao mesmo tempo, se relaciona estreitamente com o domínio OO. Isto limita a sua expressividade quando nos aproximamos do domínio dos problemas, onde os conceitos de classes, métodos e atributos nem sempre são os ideais para se representar a realidade.

36 22 Sendo assim, há uma demanda forte na indústria por modelos mais expressivos, que reflitam melhor o domínio que está sendo modelado, e por uma geração de código de maior qualidade, que abstraia o máximo possível as características da linguagem de programação subjacente, mas que ao mesmo tempo permita manter o sincronismo entre modelo e código. Atualmente, estes objetivos têm sido alcançados quando se reduz o escopo dos modelos a um domínio mais específico. Em domínios assim, as linguagens de modelagem conseguem se aproximar mais fielmente do domínio dos problemas, aumentando sua expressividade, e, com o auxilio de frameworks de código, permitem gerar código com maior qualidade, pois a especificidade do domínio ajuda a viabilizar esta atividade. Com o uso crescente desta abordagem, outros problemas e desafios têm surgido, como a integração entre os diversos modelos que são necessários para abranger todos os domínios ligados a um software e formas de viabilizar sincronismo entre modelo e código, ao mesmo tempo em que se permita a customização deste código pelas equipes de desenvolvimento. A experimentação prática na indústria tem trazido contribuições tanto em comprovar a viabilidade destas abordagens na resolução de problemas reais quanto no feedback em apontar outros problemas na aplicação desta metodologia em ambientes de produção. No capítulo 4, descreveremos um problema real enfrentado em uma grande indústria, que está estreitamente relacionado com a realidade discutida acima. No capítulo 5, será apresentada a linguagem visual específica de domínio concebida para resolver este problema e, no capítulo seguinte, será apresentado o estudo de caso, cujo objetivo foi avaliar de forma qualitativa se esta linguagem realmente conseguiu resolver o problema apontado e se isto foi feito de forma viável e adequada ao contexto existente na indústria.

37 23 3 TRABALHOS RELACIONADOS Dividimos os trabalhos relacionados em duas grandes categorias: os trabalhos que abordam o uso de técnicas de MDD, em particular DSLs visuais, em diversas áreas, e os trabalhos que avaliam a aplicação e uso destas técnicas de forma geral, especialmente na indústria USO DE TÉCNICAS DE MDD Em relação à primeira categoria, identificamos que DSLs do tipo visual ou gráfica não são as mais citadas na literatura. As DSLs textuais são muito utilizadas em artigos acadêmicos, enquanto que DSLs visuais tem um direcionamento maior na indústria do que na área de pesquisa. O trabalho mais citado sobre este assunto é o de Greenfield [8], Software factories, cujo desdobramento industrial deu origem à tecnologia para a criação de DSLs chamada Microsoft DSL Tools [54]. Kozar, Mernik e López publicaram um trabalho relatando sua experiência no uso desta tecnologia [12]. Dois outros trabalhos abordam a tecnologia desenvolvida pela empresa MetaCase, chamada MetaEdit+ [53]. Em 2004, Tolvanen apresenta uma discussão de como fazer funcionar bem a geração de código baseada em modelos [47] e apresenta como exemplo a tecnologia do MetaEdit+. Em 2009, Tolvanen retoma o assunto ao demonstrar de forma prática seu ambiente de modelagem e metamodelagem de DSL [31]. Um outro artigo aborda a tecnologia EMF [55], criada pela IBM para o ambiente Eclipse. Este artigo foi publicado em 2009 por Biermann et al. e aborda a geração de visões de simulação para linguagens de modelagem específicas de domínio [26] usando EMF. Percebe-se o grande interesse que as DSLs textuais ainda exercem sobre a área de pesquisa. Mesmo com as inovações tecnológicas e facilidades para desenvolvimento de DSLs visuais, surgidas principalmente nesta última década, a quantidade de trabalhos publicados ainda é inferior ao das textuais. Uma possível explicação é que as DSLs textuais são mais maduras, com mais tempo de pesquisa e mais publicações, e, portanto, uma parcela considerável de pesquisadores direcionam seus trabalhos para este tipo de linguagem. Já entre os praticantes é possível perceber o crescente interesse em DSLs visuais, principalmente

38 24 devido aos grandes investimentos de importantes empresas de tecnologia como Microsoft, IBM e Metacase. Outros artigos relacionados a esta categoria são: o trabalho de White e Hill na melhoria no reuso de DSLs através de técnicas de LPS [29]; o trabalho de André Santos, que direciona a construção de DSLs visuais a frameworks de aplicação [7], técnica que inspirou fortemente nosso trabalho; uma DSL visual para modelagem no domínio de redes sem fio [23], apresentado por Claypool et. al. no Simpósio IEEE Mobile em 2009; uma automatização de casos de teste através do uso de MDD [22]; e uma fábrica de software para a área de sensores sem fio [33]. Destacamos dois artigos cujo domínio tem estreita ligação com o nosso trabalho. O primeiro é a DSL para segurança de sistemas distribuídos [76], apresentada por Mosbah e Bouhoula. Contudo, o foco do trabalho destes é a política de segurança ligada a infraestrutura de rede, enquanto no nosso trabalho a segurança é voltada para os sistemas de informação. O segundo artigo apresenta a ADM-RBAC (Ariadne Development Method with RBAC ), publicado por Días et al. [78], que consiste em uma abordagem dirigida a modelos para a especificação visual de políticas RBAC [77] em sistemas web. Embora mais abrangente do que o nosso trabalho, pois a abordagem visa integrar além do domínio de segurança outros modelos ligados a sistemas web, tais como estrutura, navegação, apresentação, interação etc., este trabalho não deixa claro nenhuma forma de geração automática de código ou aumento de produtividade, itens importantes no nosso trabalho. Ainda na primeira categoria, alguns trabalhos encontrados apresentam pequenos estudos de caso. Aqueles que consideramos mais relevantes são: o trabalho de Sprinkle et al. [39] no uso de DSLs para projetar robôs numa competição conhecida como DARPA Urban challenge, o trabalho de Peter Bell [20], da SystemsForge, com sua linha de produto de software baseada em DSLs, a linguagem de modelagem para sistemas web interativos apresentada por Wright [19] e uma comparação empírica entre DSL Tools [54] e plug-ins da ferramenta Eclipse (emf, gmf) [55,56] conduzida por Pelechano et al. [48]. Em comum a quase todos estes trabalhos, temos a ausência de experiência industrial e empírica, detalhando as ferramentas em uso na prática. France e Rumpe citam a necessidade da prática industrial para fornecer feedback para adoção e melhoria nas abordagens de MDE. Em [10], eles

39 25 apresentam uma visão geral da pesquisa em MDE, apontando para alguns problemas perniciosos ( wicked problems ) envolvidos. Continuando nesta linha, outros artigos focam em apresentar ferramentas MDD. No período entre 2005 a 2009, encontramos uma série de artigos, dentre os quais destacamos: o trabalho de Kulkarni e Reddy [11], da empresa indiana Tata, que foi muito citado entre os pesquisados desta subcategoria. A ferramenta apresentada foi o chamado MDD Toolset, uma Fábrica de Software para a construção de aplicações corporativas em vários domínios como o financeiro, o bancário e o de seguros. No trabalho de Kurtev e Bézivin [32], foi apresentada a ferramenta AMMA para criação de DSLs em ambiente Eclipse. Um ponto de destaque foi o interesse em ferramentas baseadas em DSLs para a área de testes de software, como pode ser observado em [24] para casos de teste para linhas de produto e [22] para testes automatizados para as próprias DSLs AVALIAÇÃO DA APLICAÇÃO E USO DE MDD Partindo para a segunda categoria, artigos que avaliam aplicação e uso de MDD, de acordo com Whittle [68], ainda não existe nenhum programa sistemático e multidisciplinar para estudar efetividade de MDD em termos mais amplos. Atualmente não existem pesquisas (surveys) abrangentes e sistemáticas do uso industrial da MDD. Forward e Lethbridge [69] conduziram um survey online sobre opiniões e atitudes de praticantes de software em relação à MDD. Afonso et al. [70] documentaram um estudo de caso de migração de práticas centradas em código para práticas centradas em modelo [71]. Algumas empresas de ferramentas de desenvolvimento orientado a modelos comissionam estudos para apresentar resultados sobre o uso de seus produtos. Este é o caso da Metacase, que em [31] apresenta vários estudos de caso sobre sua ferramenta MetaEdit+, e também da Compuware, da ferramenta OptimalJ, que mediu os tempos de desenvolvimento e manutenção de uma petstore online usando MDA e uma IDE adaptada para MDE. Outro trabalho importante é a meta-análise da literatura de MDE feita por Mohagheghi e Dehlen em [17], que delineia como as técnicas de MDE têm sido aplicadas a uma faixa de empresas de diferentes domínios. Contudo, poucos artigos desta meta-análise fornecem forte evidência empírica do impacto em produtividade. Assim, estes autores sugerem que há uma

40 26 necessidade de mais estudos empíricos avaliando MDD e MDE, antes que dados suficientes estejam disponíveis para provar os benefícios de sua adoção. Para resumir, existe uma quantidade bastante limitada de pesquisa empírica para avaliar os benefícios de MDE. Em particular, parece haver três grandes gaps no estado de entendimento atual da área: a necessidade de conhecimento em como MDE é usada na indústria; a necessidade de entendimento de como fatores sociais afetam o uso de MDE; e a falha em avaliar MDE além da UML, tais como benefícios de geração de código, abstrações específicas de domínio e transformações de modelos. As informações coletadas no presente trabalho podem servir de subsídio para aumentar o entendimento sobre estes três assuntos.

41 27 4 O MODELO DE SEGURANÇA DOS SISTEMAS DE INFORMAÇÃO: SITUAÇÃO ATUAL Neste capítulo, abordaremos algumas questões ligadas à modelagem de segurança de sistemas de informação. Apresentaremos o framework de segurança utilizado pela área de TI de uma grande indústria, dando uma visão geral de sua arquitetura 2, e explicando seu processo de uso no dia-a-dia. Este framework foi baseado no modelo de controle de acesso com base em perfis que será apresentado na seção seguinte ROLE-BASED ACCESS CONTROL (RBAC) A partir da década de 70, sistemas de informação passaram a ser utilizados por múltiplos usuários, levando a uma preocupação crescente com questões ligadas a segurança de dados. Administradores de sistemas e desenvolvedores de software focaram em diferentes tipos de controles de acesso para garantir que somente usuários autorizados tivessem acesso a certos dados ou recursos. Um tipo de controle de acesso que emergiu foi o RBAC (Role- Based Access Control) [77]. Um papel ou perfil (role) é primordialmente a construção semântica que forma a base da política de controle de acesso. Com RBAC, administradores de sistema criam perfis de acordo com a as funções realizadas em uma empresa ou uma organização, garantindo permissões (autorizações de acesso) a estes perfis, e então atribuindo usuários aos perfis, de acordo com suas responsabilidades e qualificações. Um perfil pode representar competências para tarefas específicas, como a de um geofísico ou um técnico, mas também pode incorporar a autoridade e responsabilidade de, por exemplo, um gerente ou supervisor. Autoridade e responsabilidade são diferentes de 2 Devido a restrições de sigilo industrial, detalhes mais aprofundados sobre a solução atual não puderam ser fornecidos. Além disso, algumas figuras foram ligeiramente alteradas, mas sem prejuízo ao entendimento das funcionalidades apresentadas.

42 28 competência. Uma pessoa pode ser competente para gerenciar vários departamentos, mas ter a responsabilidade de gerenciar apenas um deles. Perfis podem também refletir atribuições de tarefas específicas que circulam por diferentes usuários, como por exemplo, aprovador, administrador, consultante etc.. Modelos RBAC e suas implementações devem convenientemente acomodar todas estas manifestações do conceito de perfil. Perfis definem tanto os indivíduos que tem permissão de acessar um recurso específico, quanto à extensão na qual estes recursos podem ser acessados. Por exemplo, o perfil de operador pode acessar todos os recursos de um computador, mas não pode modificar as permissões de acesso a estes. A combinação de usuário e permissões gerada pelo perfil tende a mudar no decorrer do tempo. As permissões associadas a um perfil, por outro lado, são mais estáveis. Elas tendem a mudar menos frequentemente do que as pessoas que executam as funções que o perfil representa. Sendo assim, basear a administração da segurança em perfis ao invés de permissões é mais simples. Usuários podem ser facilmente associados a perfis diferentes sempre que necessário. De forma similar, quando uma empresa adquire novas aplicações e sistemas, perfis podem ter novas permissões garantidas e permissões existentes revogadas. Abaixo segue um pequeno glossário de termos e conceitos genéricos do RBAC: Acesso Um tipo específico de interação entre uma entidade e um objeto que resulta no fluxo de informação de um para o outro. Controle de acesso O processo de limitar acesso aos recursos de um sistema a somente entidades autorizadas. Entidade Pessoas, processos ou sistemas participantes do processo de controle de acesso. Grupo Um conjunto de usuários. Objeto Uma entidade passiva que contém ou recebe informações.

43 29 Permissão Uma descrição do tipo de interações autorizadas que uma entidade pode possuir em um objeto. Recurso Qualquer coisa usada ou consumida na realização de uma função. As categorias de recursos são tempo, informação, objetos ou processadores. Perfil ou Papel Uma função de trabalho dentro de uma organização que descreve a autoridade e responsabilidade conferidas a um usuário atribuído a este perfil. Usuário Qualquer pessoa que interage diretamente com um sistema computacional. Administrador de Sistema O indivíduo que estabelece as políticas de segurança, realiza papeis administrativos e revisa as auditorias de segurança. Resumindo, em uma organização, perfis são criados para várias funções. As permissões para realizar certas operações são atribuídas a perfis específicos. Membros das equipes são atribuídos a perfis, e, através destas atribuições, adquirem permissões para realizar funções específicas em um sistema computacional. Como os usuários não são atribuídos diretamente às permissões, apenas adquirem-nas através de seus perfis, o gerenciamento de direitos individuais torna-se simplesmente uma questão de atribuir os perfis apropriados à conta do usuário. As três regras primárias definidas pelo RBAC são as seguintes: 1 Atribuição de perfis: Uma entidade pode exercer uma permissão somente se ela possuir algum perfil associado. 2 Autorização de perfis: O perfil ativo de uma entidade deve ser autorizado para a mesma. Com a regra 1 acima, esta regra garante que usuários podem assumir apenas perfis para os quais eles estão autorizados. 3 Autorização de permissão: Uma entidade pode exercer uma permissão somente se esta estiver autorizada para os perfis ativos desta entidade. Com as regras 1 e 2, esta regra garante que usuários podem exercer apenas as permissões para as quais eles estão autorizados.

44 30 Desde que as regras primárias sejam respeitadas, o modelo RBAC é flexível o suficiente para permitir diversas implementações. Vários sistemas, incluindo Microsoft Active Directory, Microsoft SQL Server, FreeBSD, Solaris, Oracle DBMS, SAP/R3 entre outros, efetivamente implementam alguma forma deste modelo. O framework de segurança detalhado na seção seguinte também foi implementado com base neste modelo. O uso de RBAC para gerenciar privilégios de usuários é amplamente aceito como uma boa prática UM EXEMPLO LIGADO AO DOMÍNIO DE SEGURANÇA EM SISTEMAS DE INFORMAÇÃO Uma realidade crescente, nas empresas e indústrias, é que segurança da informação é um assunto estratégico para os negócios. Motivada por este fato, uma equipe de desenvolvimento da área de TI (Tecnologia da Informação) de uma grande indústria construiu um sistema objetivando padronizar a forma como suas aplicações controlam o acesso às suas funcionalidades, indo desde a autenticação dos usuários até a autorização dos mesmos a recursos e informações. Este sistema foi baseado no modelo RBAC. Originalmente conhecido por Sistema de Controle de Acesso, ele foi evoluindo e sendo implantado cada vez em mais áreas de desenvolvimento, até que, em sua versão 3.0, passou a ser conhecido como Framework de Controle de Acesso Corporativo. Hoje em dia, praticamente todas as equipes de desenvolvimento desta empresa utilizam este framework para gerenciar a segurança de suas aplicações Framework de Controle de Acesso Corporativo O Framework de Controle de Acesso Versão 3.0, ou simplesmente CA V3, nome pelo qual é mais conhecido, é uma solução composta por um banco de dados com informações ligadas à segurança de sistemas, além de APIs (Application Program Interface) para as tecnologias Java e.net, e duas ferramentas (sistemas) de acesso a este banco, uma para os administradores de sistema e outra para os usuários, analistas e desenvolvedores.

45 31 A primeira ferramenta é um aplicativo desktop para uso exclusivo dos administradores de sistema, responsáveis por controlar a segurança em cada uma das equipes de desenvolvimento. Ela é denominada Kit de Ferramentas de Apoio e possui funcionalidades ligadas a criação de ambientes, migração de dados e outras atividades de gerenciamento e administração do CA. A segunda ferramenta, de maior uso, é um sistema web, denominado Console Web, que permite o cadastramento das funcionalidades de segurança pelos analistas e desenvolvedores no banco de dados do CA. Neste banco de dados, foi construída uma biblioteca de funções, utilizada para permitir a integração do código das aplicações com o CA, em tempo de desenvolvimento e execução. Para cada uma das tecnologias de desenvolvimento, por exemplo Java,.Net, Delphi etc., foi desenvolvida uma API (Application Program Interface) que encapsula, em objetos nativos à respectiva tecnologia, as chamadas a esta biblioteca. A figura 5 dá uma visão geral da arquitetura do CA. Figura 5 - Macro-Arquitetura do CA V3

46 32 Figura 6 - Kit de apoio dos administradores Para um sistema utilizar o controle de acesso, é necessário que o analista responsável solicite o cadastramento do seu sistema ao administrador do CA. O administrador, através do Kit de Ferramentas de Apoio (vide figura 6), irá cadastrar o sistema e conceder permissão para que o analista o acesse via Console Web. Além disso, irá fornecer informações para que futuramente a aplicação sendo desenvolvida possa acessar o CA via API de sua linguagem específica. O processo de integração de um sistema ao CA, normalmente, ocorre em duas etapas: uma de concepção e outra de desenvolvimento. Na etapa de concepção ocorrem: o levantamento de requisitos e o cadastramento dos elementos de segurança no Console Web. No primeiro passo, os analistas levantam junto aos clientes as necessidades de segurança de informação do sistema, e, em seguida, fazem um mapeamento destas necessidades com as funcionalidades disponíveis no CA. Normalmente, isto resulta na listagem de um conjunto de perfis de acesso que podem ser atribuídos a grupos de usuários ou a usuários individuais, conforme permitido pelo modelo RBAC. Além disso, cada perfil terá acesso a objetos (recursos) do futuro sistema que será desenvolvido. Estes objetos podem ser itens de menu, telas, botões, entre outros. Cada objeto pode ter associado a ele uma série de ações, por exemplo, uma tela pode ter as ações de Incluir, Alterar, Excluir e Consultar. Perfis diferentes podem ter acessos diferentes em uma mesma tela, por exemplo, um perfil de administrador

47 33 pode ter acesso a todas as ações de uma tela, enquanto um perfil de consultante teria apenas acesso à ação de Consultar nesta tela. Como última atividade desta etapa, o analista irá cadastrar manualmente, utilizando o Console Web, todas as funcionalidades levantadas. A figura 7 mostra um snapshot do console web (por questões de sigilo algumas imagens foram ligeiramente alteradas). Figura 7 - Console web utilizado por analistas e desenvolvedores A figura 8 mostra um exemplo de concepção da segurança de um sistema qualquer. Estão representadas as funcionalidades de Perfis, Grupos, Usuários e Recursos (Objetos), cujos nomes estão nos retângulos destacados. A ligação dos usuários aos perfis ou grupos é que estabelece a permissão aos respectivos recursos. Neste exemplo, o usuário X tem direito de acesso aos recursos associados aos perfis 1 e 2 (R1,R2,R3, R4,R6,R8). Já o usuário Z tem acesso aos recursos associados ao grupo XPTO, que por sua vez está associado ao perfil 3, com direito de acesso aos recursos R5, R6 e R9.

48 34 Figura 8 - Exemplo de um sistema cadastrado no CA que usa funcionalidades típicas O procedimento mais comum é cadastrar as funcionalidades ligadas a perfis, grupos e usuários no início. As funcionalidades ligadas a recursos e permissões (ligação entre perfis e objetos/ações) são cadastradas de forma iterativa e incremental, à medida em que as telas do sistema vão sendo desenvolvidas. Na segunda etapa, que ocorre durante o processo de codificação da aplicação, os desenvolvedores irão configurar o seu respectivo sistema para acessar o CA e, através de chamadas a sua API, irão gerar código para autenticar os usuários e verificar se os mesmos tem autorização para acessar recursos e realizar ações. Esta etapa não será abordada pelo presente trabalho. A figura 9 resume as atividades mais importantes realizadas pelos três principais atores relacionados ao processo de concepção e uso da segurança dos sistemas. Em destaque no quadro tracejado estão os casos de uso que serão apoiados pela ferramenta construída neste trabalho.

49 35 Figura 9 - Principais atores e atividades realizadas no CA Problemas e limitações da solução atual Apesar deste processo, em teoria, ser relativamente simples e comum, para quem conhece o domínio de segurança de sistemas, as formas de se combinar os conceitos do CA são inúmeras, e, de acordo com o sistema sendo desenvolvido e com a experiência do analista, podem resultar em diferentes modelos de segurança. Uma das principais ausências neste processo é que não há nenhum padrão para documentar as decisões e o modelo de segurança resultante. Normalmente, isto fica apenas em modelos mentais da equipe de desenvolvimento, ou, na melhor das hipóteses, em documentos textuais gerados de forma ad hoc por alguém da equipe. Em situações onde a equipe de desenvolvimento do sistema muda totalmente, ou quando uma equipe faz manutenção em um sistema desenvolvido por outra, o trabalho de entender como funciona a segurança do sistema pode ser muito difícil e propenso a erros, por tratar-se de manualmente consultar o Console Web, composto por inúmeras telas diferentes, e de varrer o código pela procura das chamadas à API.

50 36 Outra situação comum, que normalmente é bastante dispendiosa, é quando é necessário replicar partes da estrutura do CA, por exemplo, para criação de novos grupos e perfis para um novo ambiente (sistemas multi-áreas). Apesar do Kit de Apoio trazer a funcionalidade de exportação de objetos do CA, normalmente isto se aplica a uma migração entre diferentes servidores (por exemplo, desenvolvimento para homologação). Quando apenas parte dos objetos precisa ser replicada dentro de um mesmo sistema, as opções disponíveis são: - Cadastrar manualmente via sistema, processo que pode ser relativamente demorado e propenso a erros, ou - Criar programas (novas aplicações) específicos para este fim. O CA V3 em si é uma ferramenta bastante poderosa e versátil, mas o processo de uso da mesma oferece várias oportunidades de melhoria. O fato de não existir nenhum formalismo para representação do modelo de segurança de um sistema abre a oportunidade para a criação de um modelo próprio, que explicite os conceitos específicos deste domínio, aumentando o nível de abstração utilizado pelas equipes. Isto resolveria os problemas de documentação, comunicação e entendimento citados anteriormente, além de fortemente facilitar o reuso deste modelo. Se, adicionalmente, o modelo viabilizar o cadastramento automático das informações no console, o problema de digitação manual e de exportação de modelos para sistemas multiambiente também estaria endereçado, aumentando a produtividade e diminuindo as chances de erro. No próximo capítulo, será apresentada uma DSL visual objetivando englobar o modelo de segurança e os geradores de código necessários à resolução dos problemas citados acima.

51 37 5 CALV3 UMA DSL VISUAL PARA O DOMÍNIO DE SEGURANÇA DE SISTEMAS CORPORATIVOS No capítulo anterior, foi apresentado o CA V3, um framework de segurança que contém uma série de conceitos, funcionalidades e APIs de desenvolvimento associadas. Conforme discutido na seção 4.2.2, o grande gap deste framework é a ausência de um modelo ou diagrama que permita visualizar a segurança dos sistemas que o utilizam. Neste capítulo, apresentaremos a modelagem e o design da DSL visual que foi construída para representar o modelo de segurança dos sistemas que usam o CA V3. Para simbolizar a supressão do gap, adicionamos a letra L de linguagem ao nome do framework CA V3, assim denominando a DSL Visual de CALV PREMISSAS Para permitir sua implantação no contexto industrial, a DSL visual tinha que ser construída respeitando algumas premissas. Em primeiro lugar, a ferramenta deveria se integrar ao processo de desenvolvimento existente, sem impor nenhuma mudança que descaracterizasse o mesmo. Em segundo lugar, o custo de implantação da ferramenta deveria ser o menor possível, a fim de não onerar os projetos que a utilizem. E em último lugar, a ferramenta deveria ser intuitiva para as equipes, a fim de que a curva de aprendizado fosse suave e a rejeição ao uso de um novo diagrama fosse minimizada. Estas premissas são importantes, pois, na indústria, diversos fatores não ligados à parte técnica podem influenciar negativamente o uso de novas ferramentas, independente de sua qualidade ou efetividade na resolução do problema. Fatores ligados a custo, fatores sociais ou organizacionais poderiam inviabilizar a implantação da ferramenta antes mesmo do processo começar. Sendo assim, com o cumprimento destas três premissas, conseguimos obter dois itens extremamente importantes para o sucesso da DSL no âmbito da indústria: o apoio gerencial, pois sem ele a equipe e os recursos nunca seriam mobilizados, e a baixa resistência na equipe, o que foi importantíssimo para motivar o uso e avaliação da ferramenta.

52 CONCEPÇÃO DA DSL VISUAL CALV3 Para contemplar estas premissas, algumas diretrizes direcionaram a escolha da tecnologia de construção da DSL. Ela foi construída em uma tecnologia gratuita, sem custo financeiro de aquisição, e integrada ao ambiente de desenvolvimento utilizado atualmente pelas equipes. A DSL visual teria que ser intuitiva para as equipes de desenvolvimento e integrável de forma simples as suas ferramentas de desenvolvimento (IDEs). Sendo assim, a ferramenta que propomos foi baseada na ideia de Fábricas de Software (software factories, vide 2.5): a IDE turbinada com a DSL seria utilizada para a criação de diagramas com conceitos do framework de segurança, de uma forma bem intuitiva para as equipes Metodologia de criação A criação de uma DSL visual requer dois esforços principais: a especificação de uma abordagem de desenvolvimento sistemática e as definição do suporte ferramental a ser utilizado Tarefas de desenvolvimento De acordo com Deursen, Klint e Visser [5], o desenvolvimento de uma linguagem específica de domínio envolve as seguintes tarefas: [Análise] (1) Identificar o domínio do problema; (2) Reunir todo o conhecimento relevante neste domínio; (3) Agrupar este conhecimento em um conjunto de noções semânticas e operações nas mesmas; (4) Fazer o design de uma DSL que concisamente descreva aplicações neste domínio. [Implementação] (5) Construir um framework (biblioteca) que implementa as noções semânticas; (6) Projetar e implementar um compilador que traduza programas da DSL em uma sequência de chamadas ao framework. Considerando workbenches de linguagens (vide seção 2.3) e modelagem visual, Fowler [64] sugere uma tarefa inicial nesta etapa: (7) Criação de um editor visual que permita aos desenvolvedores graficamente manipular a DSL.

53 39 Considerando o contexto de Fábrica de Software (vide seção 2.5), um passo adicional também é sugerido: (8) Criação de validadores semânticos para identificar erros de modelagem em tempo de design. [Uso] (9) Escrever programas na DSL para as aplicações desejadas e compilálos. As tarefas (1), (2) e (3) foram exploradas no capítulo 4. O restante deste capítulo será focado em detalhar as outras tarefas, com exceção da tarefa (9) que será explorada pelo estudo de caso apresentado no capítulo Selecionando um Workbench para a linguagem Conforme apontado na seção 2.3, DSLs integradas a workbenches contrastam com as primeiras iniciativas de modelagem de DSLs, onde não existiam ferramentas para criar linguagens específicas de domínio e suportar sua modelagem visual de uma maneira custo efetiva. Neste novo tipo de construção de DSLs, torna-se mais fácil criar ferramentas que comparam-se ao poderio das modernas IDEs e fazem a programação orientada a linguagem mais fácil de construir e suportar, diminuindo as barreiras que faziam este tipo de programação ser considerado tão difícil para muitos desenvolvedores. A DSL CALV3 foi construída no Visual Studio 2010 (VS 2010), utilizando a tecnologia Microsoft Visualization and Modeling SDK [54], anteriormente conhecida como DSL Tools. Conforme citado por Czarnecki [13], a escolha de uma tecnologia específica depende de sua adaptabilidade técnica a um dado domínio de problema e usuários alvo. Também podem existir critérios de seleção não técnicos como linguagens de programação requeridas, infra-estrutura existente, familiaridade dos desenvolvedores com a tecnologia, política e outras considerações. No nosso trabalho, os três primeiros itens citados influenciaram na escolha da tecnologia. A IDE Visual Studio nativamente disponibiliza aos desenvolvedores e arquitetos funcionalidades que vão além da codificação de software, incluindo atividades de análise e

54 40 design, bem como modelagem de aplicações. O VS 2010 possui um conjunto de editores visuais embutidos (designers), que permitem construir uma série de modelos, tais como, diagramas de classe, diagramas de deployment, diagramas de infra-estrutura, além de diagramas de caso de uso e os outros diagramas da UML. Como a maioria das funcionalidades é comum a todos estes diagramas, como zoom, seleção múltipla, arrastar itens de uma barra de ferramenta (drag and drop) etc., a Microsoft decidiu implementar uma plataforma comum (suíte de ferramentas), na qual novos designers pudessem ser construídos. Esta plataforma, inicialmente denominada DSL Tools [54], é utilizada internamente pelos designers embutidos, mas também passou a ser disponibilizada para usuários finais como uma extensão da IDE. Ela provê um framework e um conjunto de ferramentas que permite aos desenvolvedores construir designers visuais customizados e designers de DSLs utilizando o próprio VS Em outras palavras, é possível estender o Visual Studio pela criação e adição de um novo designer, baseado em uma DSL visual. Com a tecnologia DSL Tools, desenvolvedores podem criar, editar e visualizar metadados, que tem como alicerce um framework de código, o que torna mais fácil definir esquemas específicos de um domínio para meta-dados, e, assim, construir um designer gráfico embutido no VS A suíte de ferramentas consiste em: Um wizard de projetos para a criação de uma solução totalmente configurada na qual é possível definir um modelo de domínio com um designer e um gerador de artefatos textuais. Executar esta solução no VS 2010 abre uma solução de teste em uma instância separada, denominada Experimental Hive, tornando possível testar o designer e o gerador de artefatos; Um designer gráfico para definir e editar modelos de domínio; Um formato XML para criar definições de designer; Um conjunto de geradores de código, que recebem como entrada uma definição de modelo de domínio e produzem como saída uma série classes que os representam;

55 41 Um framework para definir geradores de artefatos com base em templates, que recebem como entrada dados (diagramas) de um modelo de domínio, e gera como saída arquivos texto, baseados no template. Parâmetros no template são substituídos usando os resultados da execução de um script C# [79] embutido no mesmo Arquitetura da solução CALV3 O diagrama da Figura 10, resume os principais componentes arquiteturais que compõem a solução completa da DSL CALV3. Cada um dos principais elementos serão detalhados nas seções seguintes. Outros ativos utilizados na solução, como arquivos de configuração, componentes básicos do.net, componentes do framework da DSL Tools, foram omitidos para aumentar a clareza e objetividade do diagrama. Figura 10 - Diagrama de componentes dos principais elementos arquiteturais da solução DSL CALV3

56 42 No lado esquerdo da figura, temos o componente de especificação de um diagrama visual CALV3, que é uma instância do meta-modelo, com o estereótipo <<metaclasse>>. Ele serve de entrada para o componente Template T4 de geração de código, cuja saída será o código-fonte do programa que realizará a carga. Outra entrada do Template é o componente CaMiniFramework, cuja finalidade foi encapsular as funcionalidades do framework do CA, componente InterfaceCA, necessárias ao mapeamento do domínio da DSL CALV3. Segue uma breve explicação sobre cada um dos elementos do diagrama: Meta-Modelo CALV3 Diagrama gerado na linguagem de meta-modelagem DSL Tools que serve como base para instanciar diagramas de segurança específicos de uma determinada aplicação. Este meta-modelo representa a semântica que será seguida na geração dos diagramas, bem como as validações e regras de negócio para manter a consistência do modelo. Este elemento é detalhado nas seções a DSL CALV3 É uma instância do meta-modelo representando a segurança de um sistema específico. Um exemplo deste componente arquitetural pode ser visto na Figura 24. Template T4 Componente com base em tecnologia de templating [80], utilizado para ler um diagrama CALV3 e gerar arquivos de código-fonte em linguagem C#. Este código-fonte fará chamadas aos outros componentes que provêem os serviços de acesso ao Controle de Acesso Corporativo. Mais detalhes na seção CaMiniFramework - Componente criado para abstrair o acesso a API do Controle de Acesso, provendo uma classe que disponibiliza somente os métodos de interesse para geração dos elementos modelados pelo diagrama CALV3 na base de dados do CA. Explicações sobre os objetivos que levaram a criar este componente podem ser obtidos na seção InterfaceCA É um componente provido pela atual solução do Controle de Acesso Corporativo, que representa uma API para ser consumida na linguagem C#. É encapsulado em um arquivo chamado InterfaceCA.DLL.

57 43 Biblioteca do BD CAV3 - Todos os serviços providos pela InterfaceCA, na verdade consomem stored procedures hospedadas no banco de dados do CA. Este componente representa estes serviços. A interação do InterfaceCA (API do CA para.net) e desta biblioteca foi citada na seção 4.2.1, que detalha a solução atual Design da CALV3 Uma linguagem visual específica de domínio é composta por diferentes elementos: um grafo de conceitos (ou classes), relacionamentos (compreendendo papéis, cardinalidade, etc.), atributos, entre outros. Uma abordagem comum para especificar uma DSL visual é utilizar uma linguagem de meta-modelagem, como Eclipse Modeling Framework EMF [55] ou a linguagem de meta-modelagem da DSL Tools. Esta última foi utilizada no presente trabalho para a especificação visual da DSL CALV3. A tabela 1 apresenta uma visão geral dos conceitos relacionados a esta linguagem de meta modelagem. Tabela 1 - Linguagem de meta-modelagem da DSL Tools Nome do conceito Representação Gráfica Descrição Classe Propriedade Uma classe representa um elemento básico da DSL Visual. Ela referese a um conceito do domínio, como Perfil ou Usuário. Ela também pode ser abstrata. Representa um atributo fortemente tipado de uma classe. Por exemplo, Nome é um atributo do tipo String

58 44 da classe Perfil. Enumerações Sem representação gráfica São tipos especiais de propriedades. Definem valores discretos para as mesmas. Por exemplo, Tipo de Perfil é uma enumeração cujos valores são Administrador, Comum e Genérico. Relacionamento herança de Usado para expressar que um conceito é uma especialização de outro. Relacionamento agregação de Representa uma relação forte entre dois conceitos. Por exemplo, Objeto tem Ações. Se o Objeto for excluído do modelo, todas as suas ações também serão. Papéis (roles) e cardinalidades se aplicam a este tipo de relacionamento.

59 45 Relacionamento referência de Representa uma relação fraca entre dois conceitos. Por exemplo, Usuário pode estar associado a um Perfil, mas Perfis existem independentemente da existência de usuários. Cada lado do relacionamento define um papel (role) gerando uma propriedade na classe relacionada para acessar o outro lado do relacionamento. No exemplo, acima um perfil acessa a lista de usuários associados a ele através da propriedade Users, especificada no relacionamento. Uma linguagem de meta-modelagem é utilizada para construir um meta-modelo, que descreve uma linguagem de modelagem, como a CALV3, da mesma forma que um modelo descreve um sistema. Em domínios não muito conhecidos, pode ser essencial a definição de uma ontologia. Ontologias provêm um vocabulário comum de uma área e definem, com diferentes níveis de formalidade, o significado dos termos e relações entre eles. Assim sendo, o design da DSL fica mais intuitivo e acurado. No caso da CALV3, não foi necessária a definição de uma ontologia própria, tendo em vista o uso da ontologia do modelo RBAC.

60 46 Contudo, dois conceitos adicionais, Informação e Valor, foram incluídos no meta-modelo, pois são específicos do CA V3. Seguem suas definições: Informação Representa um meta-dado que possuirá valores associados, com o objetivo de parametrizar um sistema. O tipo dos valores de uma informação são aqui definidos e podem ser: texto, numérico ou data. Valor Dado associado a uma determinada Informação, cujo tipo de dado é definido por ela. A melhor analogia é que Valores são como registros de uma tabela, a Informação. O meta-modelo da CALV3 será apresentado nas figuras seguintes, pois, devido ao seu tamanho, sua visualização completa não ficará muito clara. A Figura 11 detalha a classe raiz do meta-modelo CAV3Model. Ela representa o próprio diagrama no qual os outros conceitos serão criados. Os conceitos que podem ser associados a este diagrama diretamente, através da operação de arrastar e soltar, aparecem relacionados à classe raiz. São eles: Role (Perfis), User (Usuário), Group (Grupo), Objeto e Information (Informação). Os conceitos restantes, Ação e Figura 11 - Classe raiz do meta-modelo e seus relacionamentos

61 47 Valor, só poderão ser arrastados para dentro de conceitos containers, Objeto e Informação, respectivamente. Com exceção de Informação e Valor, que foram definidos acima, todos os conceitos representam termos do modelo RBAC (vide seção 4.1). Além disso, a cardinalidade dos relacionamentos indica que podem existir nenhum ou vários destes elementos em cada diagrama gerado. Outro detalhe digno de nota são as propriedades especificadas na classe raiz, uma das quais, Ambiente, é uma enumeração que pode conter apenas os valores DESE, TEST, HOMO e PROD, representando os valores possíveis de ambientes de infra-estrutura do CA: desenvolvimento, teste, homologação e produção. A Figura 12 demonstra que um perfil pode ser associado aos seguintes conceitos do CA: Grupo (Group), Objeto, Ação (Action) e Valor. Esta associação demonstra uma pequena diferença entre o modelo RBAC e o modelo do CA V3, pois, neste último, não é possível associar um perfil a outros perfis. Figura 12 - Relacionamentos permitidos da classe Perfil Uma característica interessante do meta-modelo é que, dependendo como seja feito o relacionamento, a forma como os conceitos serão associados no designer gráfico será afetada. Por exemplo, na Figura 13, temos o relacionamento entre Usuário (User) e Perfil (Role). Isto

62 48 significa dizer que a conexão entre estes dois conceitos que será feita no diagrama deverá partir de Usuário para Perfil e nunca o contrário. Esta decisão de design, bem como outras Figura 13 - Relacionamento entre Usuário e Perfil exibidas até agora, foi tomada para refletir mais fielmente a forma de trabalho atual no Console do CA. A Figura 14 expressa o relacionamento entre dois conceitos iguais, no caso entre um objeto e outro. Lembrando que o conceito de objeto, no contexto da CALV3, representa um objeto de interface de usuário, tal como um item de menu, uma tela ou botão e, sendo assim, estes podem ser relacionados entre si formando uma hierarquia. Como, por exemplo, na relação hierárquica expressa abaixo: Menu principal o Sub-Menu 1 Tela 1 o Sub-Menu 2 Tela 2

63 49 Outro detalhe importante é que os nomes dos relacionamentos podem ser modificados para melhor exprimir sua semântica. Neste caso, o relacionamento foi denominado Hierarquia e suas respectivas roles foram chamadas Pai (Parent) e Filhos (Children), para deixar bem claro que um Pai pode ter vários filhos, mas um filho só tem um pai, como expresso pela cardinalidade. Figura 14 - Relacionamento de hierarquia entre Objetos Para finalizar a explanação sobre o design da CALV3, na Figura 15, apresentamos o exemplo de um relacionamento de agregação entre objetos e ações. Foram criadas duas Figura 15 - Relacionamento de agregação entre objeto e ação

64 50 classes abstratas ContainerObjAbstrato e InnerContainerObj. Estas duas classes tem a finalidade de modificar o comportamento do designer, permitindo que uma classe que herde de InnerContainerObj, no caso Ação (Action), possa ser arrastada para dentro de uma classe que herde de ContainerObjAbstrato, neste caso Objeto. O relacionamento entre Informação e Valor seguem este mesmo padrão de design. Abaixo segue a representação completa do design da CALV3, unindo as partes do modelo apresentadas até aqui. Figura 16 Meta-modelo completo da CALV3

65 Sintaxe da CALV3 e Editor visual A sintaxe de uma linguagem define como seus elementos aparecem de forma concreta e utilizável. No caso de linguagens visuais, a sintaxe não é puramente textual, ela combina gráficos, texto e convenções pelas quais os usuários podem interagir com os gráficos e o texto através da ferramenta. A linguagem de meta-modelagem da DSL Tools também permite que os conceitos do meta-modelo sejam conectados a classes que representarão os elementos da sintaxe visual. Estas classes possuem propriedades que estão relacionadas à aparência na qual os conceitos serão exibidos no diagrama, como por exemplo, forma (retangular, oval, circular), cor, decoradores (identificações textuais ou gráficas contidas nos elementos), entre outros. A Figura 17 mostra a conexão da classe Perfil com a classe que representa sua sintaxe visual RoleShape. As classes para sintaxe visual ficam em uma raia própria, chamada Swimlane dos elementos do diagrama. Figura 17 - Mapeamento entre Perfil e sua classe de sintaxe visual

66 52 Cada classe do meta-modelo que tiver alguma representação visual no diagrama será conectada a uma classe de sintaxe visual, incluindo os relacionamentos, que também são representados internamente por classes do meta-modelo. Os relacionamentos são mapeados para classes de sintaxe visual do tipo Connector, que representarão as linhas de conexão entre os conceitos. Na Figura 18 temos o exemplo do mapeamento do relacionamento Hierarquia (entre objetos) para sua classe de sintaxe visual ObjetoHierarquiaConnector. Observa-se que esta classe herda de ColorConnector, que possui uma propriedade Color. Isto significa que todas as classes de conexão que herdem da mesma permitirão ao usuário modificar a cor da linha no diagrama. Figura 18 - Mapeamento entre a conexão hierarquia e sua classe de sintaxe visual tabela 2. Os elementos mais representativos da sintaxe visual da CALV3 são apresentados na Tabela 2 Elementos da sintaxe visual da CALV3 Nome Representação Gráfica Descrição Perfil O perfil é representado por um retângulo de bordas arredondadas, com a cor escolhida pelo usuário. Contém três decoradores: o código do perfil (acima), o nome do perfil

67 53 (abaixo) e um decorador gráfico à esquerda: uma imagem simbolizando perfil (uma pasta). Usuário O usuário é representado por um círculo. Contem dois decoradores: O código do usuário, um alfanumérico de 4 posições, e um decorador gráfico representando um usuário (abaixo). Grupo de Usuários Um grupo de usuários é representado por um retângulo. Contém 3 decoradores: o código do grupo (acima), o nome do grupo (abaixo) e um decorador gráfico representando um grupo de usuários (canto superior esquerdo) Objeto Um objeto é representado por um retângulo, dentro do qual as ações serão incluídas. Possui 3 decoradores: o nome do objeto (topo), um decorador gráfico indicando o tipo do objeto ( menu, Tela) e um decorador para expandir ou colapsar o interior do objeto, no canto superior esquerdo.

68 54 Ação Associação A ação é representada por um círculo e é inserida dentro do objeto. Possui um decorador com o nome da ação. A associação é a representação da ligação entre Usuário e Perfil, Perfil e Grupo, ou Grupo e Usuário. Apresentada com uma seta. Hierarquia Esta ligação representa a conexão hierárquica entre objetos (menus, telas). Visualmente apresentada por uma reta com um triângulo na ponta. Permissão Representa a ligação de um perfil a objetos ou ações dentro do objeto. Visualmente apresentada como uma linha tracejada com um losango em cada ponta. O desenvolvedor ou analista de segurança pode adicionar Usuários, Perfis, Grupos etc. a um diagrama CALV3 através de operações de arrastar e soltar estes elementos de uma barra de ferramentas (toolbox), apresentada na Figura 19, para o diagrama. Ao passar o mouse sobre cada item da barra é exibida um dica visual sobre o que ele representa ou a quem ele poderá ser conectado.

69 55 Figura 19 - Barra de ferramentas da CALV3 As propriedades de cada classe do meta-modelo são apresentadas como propriedades de cada elemento de sintaxe visual e podem ser modificadas pelo analista de segurança através da janela de propriedades da própria IDE. Esta janela é sensível ao respectivo elemento em foco, e exibe as propriedades de acordo com o tipo especificado. Na Figura 20 temos o exemplo da configuração das propriedades de um elemento objeto. Figura 20 - Janela de propriedades para configuração dos elementos de sintaxe visual

70 56 A configuração das propriedades através desta janela é familiar aos desenvolvedores, visto que é utilizada nas tarefas normais de programação como, por exemplo, elaboração de interfaces gráficas de aplicativos. Dependendo do tipo da propriedade, podem ser disponibilizados valores específicos, como é o caso do Tipo do objeto, cuja enumeração possui 3 valores: Tela, Menu ou Botão, ou da propriedade Cor que abrirá uma interface visual para escolha das cores. As alterações efetuadas nas propriedades são automaticamente refletidas no elemento do diagrama, por exemplo, ao modificar o nome do objeto, seu decorador será atualizado. Outro exemplo é alterar o tipo do objeto de Menu para Tela, que modificará automaticamente seu decorador gráfico para o respectivo ícone. Além disso, é possível visualizar-se os elementos do diagrama CALV3 corrente de uma forma mais organizada e hierarquizada, através do uso da ferramenta chamada CAV3 Visual Language Explorer (Figura 21). É possível adicionar ou remover itens desta janela, bem como selecionar um de seus elementos e alterar suas propriedades pela janela de propriedades Figura 21 - Janela de navegação da CALV Validadores semânticos da CALV3 Além de ajudar o analista de segurança com aspectos de edição visual, a experiência de modelagem com a CALV3 também garante que a semântica da DSL seja respeitada pelo modelador. Regras semânticas podem ser implementadas como Hard constraints, por

71 57 exemplo, as cardinalidades entre os conceitos, ou soft constraints, regras de negócio que garantem a integridade do modelo gerado no contexto do CA V3. Este último tipo de regra é feito através de validadores semânticos, que são associados a conceitos do domínio e geram como saída itens na janela de erros da própria IDE, como podemos ver na Figura 22. Dar um duplo clique em um erro da lista, automaticamente faz a IDE colocar o foco no elemento do modelo que é a fonte do erro. No caso da DSL Tools, os validadores semânticos podem ser criados Figura 22 - Erros de validação exibidos na janela de erros da IDE programaticamente. Para cada conceito do domínio é gerada uma classe parcial no C#, sendo assim, para adicionamos os validadores, implementamos um novo código em uma classe parcial complementar que checa a regra de negócio e loga o erro, conforme exemplo da Figura 23. Uma característica da linguagem C# chamada attribute, semelhante às anotações da linguagem Java, é utilizada para especificar quando os validadores devem executar: após a abertura de um modelo CALV3, ao salvar o arquivo ou explicitamente, através de um menu de contexto.

72 58 Figura 23 - Implementação de um validador semântico para a classe Grupo A seguir temos uma série de regras de negócio da CALV3 que foram implementadas através do mecanismo de validação semântica: O código do usuário deve ser informado; Código, nome e descrição do Perfil devem ser informados; Se um perfil for associado a um objeto, todas as ações do objeto serão associadas ao perfil, portanto associar o mesmo perfil a uma ação deste objeto é redundante; Código e nome do Grupo devem ser informados; Código, nome e tipo do Objeto devem ser informados; O código de cada Perfil e Grupo e o nome dos Objetos devem ser únicos; Um objeto não pode ser filho de outro objeto que esteja abaixo dele em sua hierarquia (evitando referências circulares entre os objetos hierárquicos).

73 59 A Figura 24 apresenta todas as características apresentadas até o momento e dão uma visão geral da experiência de modelagem com a CALV3, integrada ao Visual Studio Figura 24 - Experiência de modelagem completa da CALV Gerador de código e framework da CALV3 Conforme apontado por Deursen [5] e pela metodologia de Fábrica de Software [8], uma DSL pode ser muito mais poderosa quando embasada em um framework ou biblioteca que implementa suas noções semânticas e um compilador que traduz programas DSL em uma sequência de chamadas ao framework. No contexto da CALV3, este framework seria a API do CA V3, o compilador é um gerador de código (cuja saída será um programa com chamadas à API) e os programas DSL a serem traduzidos serão os modelos CALV3.

74 60 Um dos benefícios esperados com o uso da DSL CALV3 é que, após a modelagem visual, não seja mais necessário o passo de cadastrar as funcionalidades de segurança no console do CA, posto que isto seja realizado automaticamente através de um script. Para este tipo de atividade a tecnologia DSL Tools disponibiliza uma API para geração de código e transformação de modelos para texto, chamada Text Template Transformation Toolkit ou T4 [80]. Este toolkit disponibiliza uma linguagem de script, semelhante ao C#, para manipular conceitos do modelo. Assim sendo, a tarefa de geração do script para carga do modelo no CA foi feita através da construção de um template T4 que recebe como entrada um diagrama CALV3 e gera como saída um programa que consome a API do CA para gerar os comandos de inclusão dos elementos do diagrama no banco de dados do controle de acesso Template de geração de código No início da construção do template, percebemos que consumir a API do CA diretamente seria relativamente confuso, visto que a quantidade de objetos e métodos disponibilizados pela API é muito grande e vai muito além das necessidades do nosso programa de carga. Sendo assim, seguindo a ideia de software factories de gerar várias camadas de frameworks até chegar do nível de abstração da DSL, construímos um componente, chamado CAMiniFramework, que abstrai a API do controle de acesso e disponibiliza apenas os métodos necessários para gerar os elementos disponíveis na DSL CALV3. Este componente possui apenas uma classe, chamada CAFramework, cujos métodos são facilmente mapeáveis a cada conceito ou conexão (relação entre conceitos) de um diagrama CALV3. A especificação desta classe pode ser vista na Figura 25. Sendo assim, o objetivo do template T4 gerado passou a ser: ler os conceitos do diagrama CALV3 e traduzi-los em um programa que instancia um objeto CAFramework e faz chamadas aos métodos para criação do respectivo conceito ou associação na base de dados do CA.

75 61 Figura 25 - Classe CAFramework chamada pelo script de geração de código A Figura 26 apresenta um pequeno trecho do template T4, responsável pela geração do programa de carga. O texto entre as tags <# e #> contém comandos de script usados para manipular os conceitos da DSL visual. O texto entre as tags <# = e #> são expressões que são avaliadas e seu resultado enxertado no texto resultante. Por exemplo, no construtor da classe CaFramework são passados parâmetros, como o nome da regional e o ambiente do CA a ser gerado (desenvolvimento, teste etc.). Estes parâmetros são gerados com base nas propriedades Regional e Ambiente do modelo CALV3 (objeto raiz). O template T4 é executado automaticamente quando o modelo CALV3 é salvo, após a execução das validações semânticas, e, como resultado, ele gera um arquivo com extensão.cs, com o mesmo nome do diagrama. A IDE Visual Studio pode ser configurada para compilar e executar a classe contida neste arquivo e assim realizar a carga automática do modelo. Contudo, para a execução ser efetuada com sucesso, ainda é necessário adicionar ao projeto da IDE: o componente da API do CA V3 e um arquivo XML de configuração. Estes itens serão melhor explicados na seção

76 62 A Figura 27 exibe um trecho do programa final gerado com base no template que representa a carga do diagrama CALV3 apresentado na Figura 10. Figura 26 - Trecho do template T4

77 63 Figura 27 - Programa de carga gerado pelo template com base em um modelo CALV Empacotamento da solução e geração de documentação O passo final para disponibilização da DSL CALV3 é a geração do pacote de instalação que permita aos desenvolvedores e analistas instalar a ferramenta como uma extensão do Visual Studio de suas respectivas máquinas. O pacote de instalação disponibiliza tanto o instalador da DSL quanto os arquivos necessários para a execução da carga automática. Na Figura 28, exibimos os arquivos gerados no empacotamento físico da solução. A instalação da DSL é feita através da execução do arquivo CAV3.CAV3VisualLanguage.DSLPackage.vsix. O arquivo InterfaceCA.dll representa o componente da API do CA e o arquivo CAMiniFramework.dll representa o componente desenvolvido para abstrair a API e gerar código mais próximo dos conceitos do modelo

78 64 CALV3. Além disso, na pasta resources, está o arquivo de configuração XML necessário para a integração da aplicação ao CA. Figura 28 - Empacotamento físico da solução Uma das premissas da abordagem de Fábricas de Software é a geração de orientação contextual (guidance). Devido a restrições de tempo, não pudemos implementar a orientação e documentação nos moldes propostos por esta abordagem. A documentação da ferramenta contendo instruções de instalação e uso foi gerada em formato wiki, um formato familiar para os desenvolvedores e analistas (vide Figura 29). Figura 29 - Página do Wiki contendo links para o instalador e a documentação da ferramenta

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

Arquitetura Orientado por Modelos aplicada a Linha de Produto de Software. Eduardo Barbosa da Costa

Arquitetura Orientado por Modelos aplicada a Linha de Produto de Software. Eduardo Barbosa da Costa Arquitetura Orientado por Modelos aplicada a Linha de Produto de Software Eduardo Barbosa da Costa Juiz de Fora, MG Julho de 2008 Arquitetura Orientado por Modelos aplicada a Linha de Produto de Software

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS RESUMO Este artigo apresenta a especificação de um sistema gerenciador de workflow, o ExPSEE, de acordo com a abordagem de desenvolvimento baseado

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

Transformação de modelos em processos de desenvolvimento de software

Transformação de modelos em processos de desenvolvimento de software 1068 X Salão de Iniciação Científica PUCRS Transformação de modelos em processos de desenvolvimento de software Vinycio de Correa Lunelli 1, Profa. Dra. Ana Paula Terra Bacelo 1 1 Faculdade de Informática,

Leia mais

Table 1. Dados do trabalho

Table 1. Dados do trabalho Título: Desenvolvimento de geradores de aplicação configuráveis por linguagens de padrões Aluno: Edison Kicho Shimabukuro Junior Orientador: Prof. Dr. Paulo Cesar Masiero Co-Orientadora: Prof a. Dr. Rosana

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Exame de Qualificação para o Doutorado

Exame de Qualificação para o Doutorado Universidade Federal do Rio de Janeiro Instituto Alberto Luiz Coimbra de Pós-Graduação e Pesquisa de Engenharia Programa de Engenharia de Sistemas e Computação Exame de Qualificação para o Doutorado EVOLMANAGER:

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Nos artigos anteriores apresentamos. Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio

Nos artigos anteriores apresentamos. Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio Vinicius Lourenço de Sousa vinicius.lourenco.sousa@gmail.com Atua no ramo de desenvolvimento de software há mais de

Leia mais

MODELAGEM DE PROCESSOS

MODELAGEM DE PROCESSOS MODELAGEM DE PROCESSOS a a a PRODUZIDO POR CARLOS PORTELA csp3@cin.ufpe.br AGENDA Definição Objetivos e Vantagens Linguagens de Modelagem BPMN SPEM Ferramentas Considerações Finais Referências 2 DEFINIÇÃO:

Leia mais

Reuso. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior

Reuso. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Reuso Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Reutilização de Software Na maioria das áreas de engenharia de software, sistemas são desenvolvidos

Leia mais

Suporte à Engenharia Reversa para o ambiente SEA

Suporte à Engenharia Reversa para o ambiente SEA Otavio Pereira Suporte à Engenharia Reversa para o ambiente SEA Orientador: Ricardo Pereira e Silva Universidade Federal de Santa Catarina - UFSC Departamento de Informática e Estatística - INE Florianópolis

Leia mais

Transformando Modelos da MDA com o apoio de Componentes de Software

Transformando Modelos da MDA com o apoio de Componentes de Software Transformando Modelos da MDA com o apoio de Componentes de Software Fapesp-PIPE Autores: Marco Antonio Pereira Antonio Francisco do Prado Mauro Biajiz Valdirene Fontanette Daniel Lucrédio Campinas-SP,

Leia mais

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO Contribuições do MDA para o desenvolvimento de software Anna Carla Mohr Verner Helder Eugenio dos Santos Puia Florianópolis,

Leia mais

Introdução à Engenharia de Software

Introdução à Engenharia de Software Introdução à Engenharia de Software Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Imagem Clássica Objetivo da aula Depois desta aula você terá uma visão sobre o que é a engenharia

Leia mais

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o

Leia mais

A Linguagem de Modelagem Unificada (UML)

A Linguagem de Modelagem Unificada (UML) Aécio Costa A Linguagem de Modelagem Unificada (UML) Percebeu-se a necessidade de um padrão para a modelagem de sistemas, que fosse aceito e utilizado amplamente. Surge a UML (Unified Modeling Language)

Leia mais

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

Ontologia Aplicada ao Desenvolvimento de Sistemas de Informação sob o Paradigma da Computação em Nuvem

Ontologia Aplicada ao Desenvolvimento de Sistemas de Informação sob o Paradigma da Computação em Nuvem Ontologia Aplicada ao Desenvolvimento de Sistemas de Informação sob o Paradigma da Computação em Nuvem Luiz Cláudio Hogrefe Orientador: Prof. Roberto Heinzle, Doutor Roteiro Introdução Fundamentação teórica

Leia mais

Spider-PM: Uma Ferramenta de Apoio à Modelagem de Processos de Software

Spider-PM: Uma Ferramenta de Apoio à Modelagem de Processos de Software Spider-PM: Uma Ferramenta de Apoio à Modelagem de Processos de Software Renan Sales Barros 1, Sandro Ronaldo Bezerra Oliveira 1 1 Faculdade de Computação Instituto de Ciências Exatas e Naturais (ICEN)

Leia mais

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil Elicitação de Requisitos a partir de Modelos de Processos de Negócio e Modelos Organizacionais: Uma pesquisa para definição de técnicas baseadas em heurísticas Marcos A. B. de Oliveira 1, Sérgio R. C.

Leia mais

Proposta de abordagem de desenvolvimento de software orientado a modelos para empresas

Proposta de abordagem de desenvolvimento de software orientado a modelos para empresas Proposta de abordagem de desenvolvimento de software orientado a modelos para empresas Tânia Eiko Eishima 1, Jandira Guenka Palma 1 1 Departamento de Computação Universidade Estadual de Londrina (UEL)

Leia mais

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA CAMPUS AVANÇADO DE ARACATI PROJETO DE PESQUISA

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA CAMPUS AVANÇADO DE ARACATI PROJETO DE PESQUISA INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA CAMPUS AVANÇADO DE ARACATI PROJETO DE PESQUISA IMPLEMENTAÇÃO DE SOLUÇÃO PARA AUTOMATIZAR O DESENVOLVIMENTO DE SOFTWARE UTILIZANDO A LINGUAGEM C#.NET

Leia mais

Introdução à Plataforma Eclipse. Leandro Daflon daflon@les.inf.puc-rio.br

Introdução à Plataforma Eclipse. Leandro Daflon daflon@les.inf.puc-rio.br Introdução à Plataforma Eclipse Leandro Daflon daflon@les.inf.puc-rio.br Agenda Introdução Arquitetura da Plataforma Componentes da Plataforma JDT PDE Visão Geral do Projeto Eclipse.org 2 Introdução O

Leia mais

Viabilidade de Construção de Software com MDD e MDA

Viabilidade de Construção de Software com MDD e MDA Viabilidade de Construção de Software com MDD e MDA André Sandri Ciência da Computação Centro Universitário La Salle (UNILASALLE) Av. Victor Barreto, 2288 92.010-000 Canoas RS Brazil andresandri@hotmail.com

Leia mais

1/26/2009. Baseadas em http://www.voelter.de/services/mdsdtutorial.html. Experiência pessoal/profissional/acadêmica

1/26/2009. Baseadas em http://www.voelter.de/services/mdsdtutorial.html. Experiência pessoal/profissional/acadêmica Baseadas em http://www.voelter.de/services/mdsdtutorial.html Experiência pessoal/profissional/acadêmica 1 Metamodelo UML Meu Metamodelo Meu processo de negócios Meu processo de negócios Stereotypes Perfis

Leia mais

Desenvolvimento de software orientado a características e dirigido por modelos

Desenvolvimento de software orientado a características e dirigido por modelos Desenvolvimento de software orientado a características e dirigido por modelos Universidade Federal de Uberlândia Rodrigo Reis Pereira Prof. Dr. Marcelo Almeida Maia Agenda Motivação Introdução Modelagem

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de software AULA NÚMERO: 08 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir conceitos relacionados a modelos e especificações. Nesta aula

Leia mais

No artigo anterior explicamos. Desenvolvimento de Software Dirigido por Caso de Uso. Parte II: Especificando Caso de Uso

No artigo anterior explicamos. Desenvolvimento de Software Dirigido por Caso de Uso. Parte II: Especificando Caso de Uso Desenvolvimento de Software Dirigido por Caso de Uso Parte II: Especificando Caso de Uso Vinicius Lourenço de Sousa viniciuslsousa@gmail.com Atua no ramo de desenvolvimento de software há mais de 10 anos,

Leia mais

Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Programa de Pós-Graduação em Desenvolvimento de Sistemas para Web

Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Programa de Pós-Graduação em Desenvolvimento de Sistemas para Web Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Programa de Pós-Graduação em Desenvolvimento de Sistemas para Web } Com o forte crescimento do comércio eletrônico por

Leia mais

PRD Tecnologia de Gestão Ltda. Julho/2008

PRD Tecnologia de Gestão Ltda. Julho/2008 O Processo de Desenvolvimento Telescope Julho/2008 Página 1 Sumário Introdução...3 O desenvolvimento de software tradicional...3 O problema da produtividade...3 O problema da portabilidade...6 O problema

Leia mais

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software O que é software? Software e Engenharia de Software Programas de computador Entidade abstrata. Ferramentas (mecanismos) pelas quais: exploramos os recursos do hardware. executamos determinadas tarefas

Leia mais

Especificação de um Sistema Gerenciador de Workflow de Acordo com a Abordagem de Desenvolvimento Baseado em Componentes

Especificação de um Sistema Gerenciador de Workflow de Acordo com a Abordagem de Desenvolvimento Baseado em Componentes Especificação de um Sistema Gerenciador de Workflow de Acordo com a Abordagem de Desenvolvimento Baseado em Componentes Edson Alves de Oliveira Junior 1, Itana Maria de Souza Gimenes 1 1 Departamento de

Leia mais

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS Élysson Mendes Rezende Bacharelando em Sistemas de Informação Bolsista de Iniciação Científica

Leia mais

Odyssey-MDA: Uma Ferramenta para Transformações de Modelos UML

Odyssey-MDA: Uma Ferramenta para Transformações de Modelos UML Odyssey-MDA: Uma Ferramenta para Transformações de Modelos UML Natanael E. N. Maia, Ana Paula B. Blois, Cláudia M. Werner COPPE/UFRJ Programa de Engenharia de Sistemas e Computação Caixa Postal 68.511

Leia mais

Qualidade de Software no Contexto Organizacional: Arquitetura Corporativa. Atila Belloquim Gnosis IT Knowledge Solutions

Qualidade de Software no Contexto Organizacional: Arquitetura Corporativa. Atila Belloquim Gnosis IT Knowledge Solutions Qualidade de Software no Contexto Organizacional: Arquitetura Corporativa Atila Belloquim Gnosis IT Knowledge Solutions TI e Negócio 10 entre 10 CIOs hoje estão preocupados com: Alinhar TI ao Negócio;

Leia mais

Transforms: Um Ambiente de Apoio a Modelagem e Execução de Processos de Software Dirigido por Modelos

Transforms: Um Ambiente de Apoio a Modelagem e Execução de Processos de Software Dirigido por Modelos Transforms: Um Ambiente de Apoio a Modelagem e Execução de Processos de Software Dirigido por Modelos Bruno C. da Silva 1,2, Ana Patrícia F. Magalhães 2, Rita Suzana P. Maciel 3, Narciso Martins 2, Leandro

Leia mais

OSCAR BRANCO DENIS DESENVOLVIMENTO BASEADO EM MODELOS: DA TEORIA À PRÁTICA

OSCAR BRANCO DENIS DESENVOLVIMENTO BASEADO EM MODELOS: DA TEORIA À PRÁTICA CENTRO UNIVERSITÁRIO EURÍPIDES DE MARÍLIA - UNIVEM TRABALHO DE CONCLUSÃO DE CURSO OSCAR BRANCO DENIS DESENVOLVIMENTO BASEADO EM MODELOS: DA TEORIA À PRÁTICA MARÍLIA 2007 1 OSCAR BRANCO DENIS DESENVOLVIMENTO

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 3 - MODELAGEM DE SISTEMAS ORIENTADA A OBJETOS COM UML 1. INTRODUÇÃO A partir de 1980, diversos métodos de desenvolvimento de sistemas surgiram para apoiar o paradigma orientado a objetos com uma

Leia mais

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Itana M. S. Gimenes 1 itana@din.uem.br Fabrício R. Lazilha 2 fabricio@cesumar.br Edson A. O. Junior

Leia mais

Model-Driven Engineering Geração de modelos de software e especificações usando a plataforma IBM

Model-Driven Engineering Geração de modelos de software e especificações usando a plataforma IBM Model-Driven Engineering Geração de modelos de software e especificações usando a plataforma IBM Luiz Esmiralha IBM Eduardo Chiote IBM Quem somos Luiz Esmiralha Arquiteto de Aplicações / IBM 15 anos exp.

Leia mais

WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML

WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML Carlos Henrique Pereira WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML Florianópolis - SC 2007 / 2 Resumo O objetivo deste trabalho é especificar

Leia mais

PROFILE EM UML PARA MODELAGEM SIMPLIFICADA DE INTERFACES GRÁFICAS EM APLICATIVOS

PROFILE EM UML PARA MODELAGEM SIMPLIFICADA DE INTERFACES GRÁFICAS EM APLICATIVOS PROFILE EM UML PARA MODELAGEM SIMPLIFICADA DE INTERFACES GRÁFICAS EM APLICATIVOS André Sandri Prof. Me. Carlos Michel Betemps UNILASALLE - www.unilasalle.com.br 30 de junho de 2006 Curso de Ciências da

Leia mais

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1.

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1. Modelos de Sistema Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1 Objetivos Explicar por que o contexto de um sistema deve ser modelado como parte do processo de RE Descrever

Leia mais

MDA - resumo (OMG - Model Driven Architecture) Prof. Rossano Pablo Pinto Março/2012 v0.1 Março/2013 v0.2. Rossano Pablo Pinto - março/2013 1

MDA - resumo (OMG - Model Driven Architecture) Prof. Rossano Pablo Pinto Março/2012 v0.1 Março/2013 v0.2. Rossano Pablo Pinto - março/2013 1 MDA - resumo (OMG - Model Driven Architecture) Prof. Rossano Pablo Pinto Março/2012 v0.1 Março/2013 v0.2 Rossano Pablo Pinto - março/2013 1 PARTE 1 O processo de desenvolvimento MDA Rossano Pablo Pinto

Leia mais

Introdução a INGENIAS:

Introdução a INGENIAS: Universidade do Estado do Rio Grande do Norte UERN Universidade Federal Rural do Semi-Árido UFERSA Mestrado em Ciência da Computação MCC Disciplina: Engenharia de Software Orientada a Agentes Professores:

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

Leia mais

MRedPN tt : Metodologia para Redesenho de Processos de Negócios com Transferência Tecnológica - Versão 1.1

MRedPN tt : Metodologia para Redesenho de Processos de Negócios com Transferência Tecnológica - Versão 1.1 MRedPN tt : Metodologia para Redesenho de Processos de Negócios com Transferência Tecnológica - Versão 1.1 Prof. Dr. Jorge Henrique Cabral Fernandes (jhcf@cic.unb.br) Departamento de Ciência da Computação

Leia mais

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Tópicos Motivação e Objetivos LP e SOA Processo ADESE

Leia mais

CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE

CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE Tathiana da Silva Barrére Antonio Francisco do Prado Vitor César Bonafe E-mail: (tathiana,prado,bonafe)@dc.ufscar.br

Leia mais

GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código

GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código Igor Steinmacher 1, Éderson Fernando Amorim 1, Flávio Luiz Schiavoni 1, Elisa Hatsue Moriya Huzita 1 1 Departamento de Informática

Leia mais

Planejamento da disciplina: Modelagem de processos de negócio

Planejamento da disciplina: Modelagem de processos de negócio UNIVERSIDADE FEDERAL DE MINAS GERAIS / INSTITUTO DE CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Planejamento da disciplina: Modelagem de processos de negócio Professor: Clarindo Isaías Pereira

Leia mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

MC302A Modelagem de Sistemas com UML. Prof. Fernando Vanini vanini@ic.unicamp.br

MC302A Modelagem de Sistemas com UML. Prof. Fernando Vanini vanini@ic.unicamp.br MC302A Modelagem de Sistemas com UML Prof. Fernando Vanini vanini@ic.unicamp.br Modelamento de Sistemas e Orientação a Objetos O paradigma de Orientação a Objetos oferece um conjunto de características

Leia mais

Palavras-chave: Desenvolvimento Baseado em Componentes (DBC), Transformação de Software, framework e ObjectPascal.

Palavras-chave: Desenvolvimento Baseado em Componentes (DBC), Transformação de Software, framework e ObjectPascal. Construção e Reutilização de de Software do Domínio de Cardiologia João L C Moraes, Daniel Lucrédio, Adriano A Bossonaro, Dr Rubens Tofano, Prof Dr Antonio F Prado DC/UFSCar - Departamento de Computação

Leia mais

ORDEM DE SERVIÇO OS 003/DINFO/2013 16/09/2013

ORDEM DE SERVIÇO OS 003/DINFO/2013 16/09/2013 A DIRETORIA DE INFORMÁTICA DINFO DA UNIVERSIDADE DO ESTADO DO RIO DE JANEIRO -UERJ, no uso de suas atribuições legais, estabelece: Art. 1º: Para fins de normatização do Desenvolvimento Tecnológico na UERJ

Leia mais

Linguagem Específica de Domínio para Programação de Robôs

Linguagem Específica de Domínio para Programação de Robôs Linguagem Específica de Domínio para Programação de Robôs François Jumes, Luiz Claudio Rossafa Honda Curso de Bacharelado em Sistemas de Informação Departamento de Informática e Estatística Universidade

Leia mais

Modelando Arquiteturas de Aplicativos da WEB com UML

Modelando Arquiteturas de Aplicativos da WEB com UML Modelando Arquiteturas de Aplicativos da WEB com UML Jim Conallen Rational Software White Paper TP 157, 6/99 Uma versão deste material aparece na edição de outubro de 1999 (volume 42, número 10) de Communications

Leia mais

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES w w w. i d e a l o g i c. c o m. b r INDICE 1.APRESENTAÇÃO 2.ESPECIFICAÇÃO DOS RECURSOS DO SOFTWARE SAXES 2.1. Funcionalidades comuns a outras ferramentas similares 2.2. Funcionalidades próprias do software

Leia mais

Uma proposta de um processo prático para apoiar o reuso de software

Uma proposta de um processo prático para apoiar o reuso de software Uma proposta de um processo prático para apoiar o reuso de software Rosangela Kronig (UNIP) rkronig.mes.engprod@unip.br Ivanir Costa (UNIP) icosta@unip.br Mauro Spínola (UNIP) mspinola@unip.br Resumo A

Leia mais

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

2 Auto-sintonia de Bancos de Dados e Agentes de Software

2 Auto-sintonia de Bancos de Dados e Agentes de Software 2 Auto-sintonia de Bancos de Dados e Agentes de Software A uso da abordagem de agentes de software 1 pode trazer benefícios a áreas de aplicação em que é necessário construir sistemas autônomos, ou seja,

Leia mais

Ferramenta para Geração de Código a partir da Especialização do Diagrama de Classes

Ferramenta para Geração de Código a partir da Especialização do Diagrama de Classes Ferramenta para Geração de Código a partir da Especialização do Diagrama de Classes Alexandro Deschamps (Ápice) alexandro@apicesoft.com Everaldo Artur Grahl (FURB/DSC) egrahl@furb.br Resumo. Uma das grandes

Leia mais

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

! Introdução.  Motivação para Processos de Software. ! Processo Unificado (USDP)  Definições  RUP x USDP  Características do Processo Unificado Agenda! Introdução " Motivação para Processos de Software! (USDP) " Definições " RUP x USDP " Características do! Descrição detalhada do! Processos Derivados! Templates simplificados! Conclusões 2 Processo

Leia mais

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com REVISÃO ENGENHARIA DO SOFTWARE Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Software Sequencia de Instruções a serem seguidas ou executadas Dados e rotinas desenvolvidos por computadores Programas

Leia mais

Questionário. A ferramenta auxilia na alocação de Não (0) x x x. Satisfatório (5) complexidade de um caso de uso? de uso (72) Sim (10)

Questionário. A ferramenta auxilia na alocação de Não (0) x x x. Satisfatório (5) complexidade de um caso de uso? de uso (72) Sim (10) Questionário Nível Avaliado Gerador de plano de teste Gerador de dados Função/característica do produto Gestão dos dados do plano de teste (51) Perguntas Pontuação Selenium BadBoy Canoo A ferramenta auilia

Leia mais

CES-32 e CE-230 Qualidade, Confiabilidade e Segurança de Software. Tendências, Perspectivas e Ferramentas de Qualidade em Engenharia de Software (4)

CES-32 e CE-230 Qualidade, Confiabilidade e Segurança de Software. Tendências, Perspectivas e Ferramentas de Qualidade em Engenharia de Software (4) CURSO de GRADUAÇÃO e de PÓS-GRADUAÇÃO do ITA 2º SEMESTRE 2002 CES-32 e CE-230 Qualidade, Confiabilidade e Segurança de Software Eng. Osvandre Alves Martins e Prof. Dr. Adilson Marques da Cunha Tendências,

Leia mais

Um processo para construção de software mais transparente

Um processo para construção de software mais transparente Um processo para construção de software mais transparente Eduardo Almentero 1, and Julio Cesar Sampaio do Prado Leite 1 1 Pontifícia Universidade Católica do Rio de Janeiro, PUC - Rio, Brasil {ealmentero,

Leia mais

SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25

SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25 SUMÁRIO LISTA DE FIGURAS LISTA DE TABELAS LISTA DE SIGLAS E ABREVIATURAS Pág. CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25 2.1 A tecnologia de orientação a objetos 25 2.1.1 Projeto de software

Leia mais

Diretrizes para criação de um padrão de desenvolvimento de sistemas de informação baseados em cots

Diretrizes para criação de um padrão de desenvolvimento de sistemas de informação baseados em cots Diretrizes para criação de um padrão de desenvolvimento de sistemas de informação baseados em cots Roosewelt Sanie Da Silva¹ 1 Ciência da Computação Universidade Presidente Antônio Carlos (UNIPAC) Rodovia

Leia mais

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ ModeloPlanoProjeto_2007_04_24 SIGECO07_PlanoProjeto_2007_09_23 Página

Leia mais

Administração de Banco de Dados

Administração de Banco de Dados Administração de Banco de Dados Professora conteudista: Cida Atum Sumário Administração de Banco de Dados Unidade I 1 INTRODUÇÃO A BANCO DE DADOS...1 1.1 Histórico...1 1.2 Definições...2 1.3 Importância

Leia mais

UMA ARQUITETURA BASEADA EM MODELOS - MDA. helderpb@hotmail.com, {bruno.schulze, neuman.souza, a.roberto.m}@gmail.com

UMA ARQUITETURA BASEADA EM MODELOS - MDA. helderpb@hotmail.com, {bruno.schulze, neuman.souza, a.roberto.m}@gmail.com UMA ARQUITETURA BASEADA EM MODELOS - MDA Hélder Pereira Borges 1,2, José Neuman de Souza 2, Bruno Schulze 3, and Antonio Roberto Mury 3 1 Federal Institute of Education, Science and Technology of Maranhão,

Leia mais

Automação do Processo de Instalação de Softwares

Automação do Processo de Instalação de Softwares Automação do Processo de Instalação de Softwares Aislan Nogueira Diogo Avelino João Rafael Azevedo Milene Moreira Companhia Siderúrgica Nacional - CSN RESUMO Este artigo tem como finalidade apresentar

Leia mais

Transformação de um Modelo de Empresa em Requisitos de Software

Transformação de um Modelo de Empresa em Requisitos de Software Transformação de um Modelo de Empresa em Requisitos de Software Fábio Levy Siqueira 1 and Paulo Sérgio Muniz Silva 2 1 Programa de Educação Continuada da Poli-USP, São Paulo, Brazil 2 Escola Politécnica

Leia mais

Sistemas de Informação e Programação II Odorico Machado Mendizabal

Sistemas de Informação e Programação II Odorico Machado Mendizabal Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011 Processo de Desenvolvimento de Software Objetivos

Leia mais

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com)

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com) ARQUITETURA DE SISTEMAS Cleviton Monteiro (cleviton@gmail.com) Roteiro Definição Documento de arquitetura Modelos de representação da arquitetura Estilos arquiteturais Arquitetura de sistemas web Arquitetura

Leia mais

COBIT (CONTROL OBJECTIVES FOR INFORMATION AND RELATED TECHNOLOGY)

COBIT (CONTROL OBJECTIVES FOR INFORMATION AND RELATED TECHNOLOGY) Universidade Federal de Santa Catarina Departamento de Informática e Estatística INE Curso: Sistemas de Informação Disciplina: Projetos I Professor: Renato Cislaghi Aluno: Fausto Vetter Orientadora: Maria

Leia mais

Desenvolvimento de uma Plataforma Gráfica para a Descrição de Modelos de Sistemas Ambientais

Desenvolvimento de uma Plataforma Gráfica para a Descrição de Modelos de Sistemas Ambientais Desenvolvimento de uma Plataforma Gráfica para a Descrição de Modelos de Sistemas Ambientais Tiago F. M. Lima 1,2, Tiago G. S. Carneiro 2, Sérgio D. Faria 3 1 Programa de Pós-Graduação em Análise e Modelagem

Leia mais

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS Lilian R. M. Paiva, Luciene C. Oliveira, Mariana D. Justino, Mateus S. Silva, Mylene L. Rodrigues Engenharia de Computação - Universidade de Uberaba (UNIUBE)

Leia mais

Semântica para Sharepoint. Busca semântica utilizando ontologias

Semântica para Sharepoint. Busca semântica utilizando ontologias Semântica para Sharepoint Busca semântica utilizando ontologias Índice 1 Introdução... 2 2 Arquitetura... 3 3 Componentes do Produto... 4 3.1 OntoBroker... 4 3.2 OntoStudio... 4 3.3 SemanticCore para SharePoint...

Leia mais

3 OOHDM e SHDM 3.1. OOHDM

3 OOHDM e SHDM 3.1. OOHDM 32 3 OOHDM e SHDM Com a disseminação em massa, desde a década de 80, de ambientes hipertexto e hipermídia, principalmente a Web, foi identificada a necessidade de elaborar métodos que estruturassem de

Leia mais

Documento de Arquitetura

Documento de Arquitetura Documento de Arquitetura A2MEPonto - SISTEMA DE PONTO ELETRÔNICO A2MEPonto - SISTEMA DE PONTO ELETRÔNICO #1 Pág. 1 de 11 HISTÓRICO DE REVISÕES Data Versão Descrição Autor 28/10/2010 1 Elaboração do documento

Leia mais

Se observarmos nos diferentes livros. Planejamento de Testes a partir de Casos de Uso

Se observarmos nos diferentes livros. Planejamento de Testes a partir de Casos de Uso Planejamento de Testes a partir de Casos de Uso Arilo Cláudio Dias Neto ariloclaudio@gmail.com É Bacharel em Ciência da Computação formado na Universidade Federal do Amazonas, Mestre em Engenharia de Sistemas

Leia mais

Modelagem de Processos. Prof.: Fernando Ascani

Modelagem de Processos. Prof.: Fernando Ascani Modelagem de Processos Prof.: Fernando Ascani Bibliografia UML Guia de consulta rápida Douglas Marcos da Silva Editora: Novatec UML Guia do usuário Grady Booch James Rumbaugh Ivair Jacobson Editora: Campus

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

Leia mais

Frameworks. Pasteur Ottoni de Miranda Junior

Frameworks. Pasteur Ottoni de Miranda Junior Frameworks Pasteur Ottoni de Miranda Junior 1-Definição Apesar do avanço das técnicas de desenvolvimento de software, a construção de software ainda é um processo extremamente complexo.a reutilização tem

Leia mais

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Processos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Objetivos Apresentar modelos de processos de software Descrever três modelos genéricos de processo e quando

Leia mais

DESENVOLVIMENTO AUTOMÁTICO DE APLICAÇÕES E PLATAFORMAS DE TRABALHO EM NUVENS COMPUTACIONAIS

DESENVOLVIMENTO AUTOMÁTICO DE APLICAÇÕES E PLATAFORMAS DE TRABALHO EM NUVENS COMPUTACIONAIS DESENVOLVIMENTO AUTOMÁTICO DE APLICAÇÕES E PLATAFORMAS DE TRABALHO EM NUVENS COMPUTACIONAIS Hélder Pereira Borges 1,2, José Neuman de Souza 2, Bruno Schulze 3, and Antonio Roberto Mury 3 1 Federal Institute

Leia mais

2 Trabalhos Relacionados

2 Trabalhos Relacionados 2 Trabalhos Relacionados Os trabalhos relacionados podem ser classificados em três categorias: abordagens baseadas em metamodelos para a definição de formalismos, uso de metamodelos em editores de diagrama

Leia mais

Engenharia de Software I: Análise e Projeto de Software Usando UML

Engenharia de Software I: Análise e Projeto de Software Usando UML Engenharia de Software I: Análise e Projeto de Software Usando UML Capítulo 1 Processo de Desenvolvimento de Software Metodologia de Desenvolvimento de Software Uma metodologia é um conjunto de métodos,

Leia mais

Palavras-Chaves: engenharia de requisitos, modelagem, UML.

Palavras-Chaves: engenharia de requisitos, modelagem, UML. APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE

Leia mais

Model Checking of Statecharts using Automatic White Box Test Generation

Model Checking of Statecharts using Automatic White Box Test Generation Model Checking of Statecharts using Automatic White Box Test Generation Um artigo de: Doron Drusinsky (Cupertino, CA) Apresentado por: Charles-Edouard Winandy Disciplina: CSE310-4 Engenharia de Software

Leia mais

Especificação de Sistemas de Tempo-Real utilizando Orientação a Objetos

Especificação de Sistemas de Tempo-Real utilizando Orientação a Objetos Especificação de Sistemas de Tempo-Real utilizando Orientação a Objetos Marco Aurélio Wehrmeister mawehrmeister@inf.ufrgs.br Roteiro Introdução Orientação a Objetos UML Real-Time UML Estudo de Caso: Automação

Leia mais

Processo Unificado (RUP)

Processo Unificado (RUP) Fases do Desenvolvimento Processo Unificado (RUP) Ulf Bergmann ulf@ime.eb.br Domínio do Problema Objetos Objetos do do Mundo Mundo real real Modelo Semântico Domínio da Solução Aplicação Interface Serviços

Leia mais