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
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
Natal, RN 2012
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.
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, 2012.
91 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
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.
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.
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, domain-specific 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.
SUMÁRIO
1 INTRODUÇÃO 1
1.1. CONTEXTO E MOTIVAÇÃO 1
1.2. DESAFIOS E PROPOSTA DE SOLUÇÃO 3
1.3. OBJETIVOS 5
1.4. METODOLOGIA 6
1.5. ORGANIZAÇÃO DO TRABALHO 6
2 CONCEITOS E TECNOLOGIAS PARA DESENVOLVIMENTO DIRIGIDO
POR MODELOS 9
2.1. DESENVOLVIMENTO DIRIGIDO A MODELOS 10
2.2. ARQUITETURA DIRIGIDA A MODELOS (MODEL-DRIVEN
ARCHITECTURE) 11
2.3. LINGUAGENS ESPECÍFICAS DE DOMÍNIO (DOMAIN-SPECIFIC
LANGUAGES) 13
2.4. LINHA DE PRODUTO DE SOFTWARE (SOFTWARE PRODUCT LINE) 15
2.5. FÁBRICAS DE SOFTWARE (SOFTWARE FACTORIES) 18
2.6. DISCUSSÃO E CONSIDERAÇÕES 20
3 TRABALHOS RELACIONADOS 23
3.1. USO DE TÉCNICAS DE MDD 23
4 O MODELO DE SEGURANÇA DOS SISTEMAS DE INFORMAÇÃO:
SITUAÇÃO ATUAL 27
4.1. ROLE-BASED ACCESS CONTROL (RBAC) 27
4.2. UM EXEMPLO LIGADO AO DOMÍNIO DE SEGURANÇA EM SISTEMAS
DE INFORMAÇÃO 30
4.2.1. Framework de Controle de Acesso Corporativo 30
4.2.2. Problemas e limitações da solução atual 35
5 CALV3 – UMA DSL VISUAL PARA O DOMÍNIO DE SEGURANÇA DE
SISTEMAS CORPORATIVOS 37
5.1. PREMISSAS 37
5.2. CONCEPÇÃO DA DSL VISUAL CALV3 38
5.2.1. Metodologia de criação 38
5.2.1.1. Tarefas de desenvolvimento 38
5.2.1.2. Selecionando um Workbench para a linguagem 39
5.2.2. Arquitetura da solução CALV3 41
5.2.3. Design da CALV3 43
5.2.4. Sintaxe da CALV3 e Editor visual 51
5.2.5. Validadores semânticos da CALV3 56
5.2.6. Gerador de código e framework da CALV3 59
5.2.6.1. Template de geração de código 60
6 ESTUDO DE CASO - AVALIAÇÃO DA CALV3 65
6.1. MÉTODOS DE AVALIAÇÃO EMPÍRICOS EM ENGENHARIA DE
SOFTWARE 65
6.2. METODOLOGIA 66
6.2.1. Projeto do estudo de caso: Plano e protocolo 67
6.2.2. Coleta e análise dos dados 69
6.2.2.1. Análise das questões 70
6.2.2.2. Ameaças à validade 78
6.2.3. Resultado final 79
7 CONSIDERAÇÕES FINAIS E CONCLUSÕES 83
7.1. CONTRIBUIÇÕES 83
7.2. TRABALHOS FUTUROS 85
7.3. CONCLUSÃO 86
REFERÊNCIAS 87
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 V3...31
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 CALV3 ...41
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 CALV3...50
Figura 17 - Mapeamento entre Perfil e sua classe de sintaxe visual ...51
Figura 19 - Barra de ferramentas da CALV3 ...55
Figura 20 - Janela de propriedades para config. dos elementos de sintaxe visual...55
Figura 21 - Janela de navegação da CALV3 ...56
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 CALV3...59
Figura 25 - Classe CAFramework chamada pelo script de geração de código...61
Figura 26 - Trecho do template T4 ...62
Figura 27 - Programa de carga gerado pelo template com base em um modelo CALV3 ...63
Figura 28 - Empacotamento físico da solução...64
LISTA DE TABELAS
LISTA DE GRÁFICOS
Gráfico 1 – Resultado quantitativo da questão 1 ...70
Gráfico 2 - Resultado quantitativo da questão 2...71
Gráfico 3 - Resultado quantitativo da questão 3...72
Gráfico 4 - Resultado quantitativo da questão 4...73
Gráfico 5 - Resultado quantitativo da questão 5...74
Gráfico 6 - Resultado quantitativo da questão 6...75
Gráfico 7 - Resultado quantitativo da questão 7...76
Gráfico 8 - Resultado quantitativo da questão 8...77
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
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 assunto1. 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.
1.1. 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
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.
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.
1.2. 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, inter-relacionados a este desafio e espera-se que o feedback da indústria possa trazer importantes contribuições nesta área.
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.
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.
1.3. 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;
1.4. 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 6.
1.5. ORGANIZAÇÃO DO TRABALHO
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.
2.1. 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.
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.
2.2. 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.
plataforma, PlatformSpecific 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.
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
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].
2.3. 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.
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 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.
2.4. LINHA DE PRODUTO DE SOFTWARE (SOFTWARE PRODUCT LINE)
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.
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.
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.
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
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.
2.5. FÁBRICAS DE SOFTWARE (SOFTWARE FACTORIES)
(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.
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.
2.6. 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
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.
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.
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.
3.1. 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 meta-modelagem 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.
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 infra-estrutura 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.
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.
3.2. 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.
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.
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 arquitetura2, 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.
4.1. 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
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.
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.
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.
4.2. 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.
4.2.1. Framework de Controle de Acesso Corporativo
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.
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
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).
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.
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.
Figura 9 - Principais atores e atividades realizadas no CA
4.2.2. Problemas e limitações da solução atual
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 multi-ambiente também estaria endereçado, aumentando a produtividade e diminuindo as chances de erro.
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 CALV3.
5.1. 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.
5.2. 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.
5.2.1. 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.
5.2.1.1. 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.
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 6.
5.2.1.2. 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.
