Extração de Visões Centradas em Stakeholders a partir de ... · relacionada ao domínio da...

Extração de Visões Centradas em Stakeholders a partir de

Ontologias: Uma Abordagem MDA†

Elisângela Rêgo1, George Pinto1, Laís Salvador1,

Christina Chavez2, Weber Santos3

1Nucleo Interdepartamental de Pesquisa em Redes de Computadores (NUPERC) Universidade Salvador (UNIFACS)

Caixa Postal 41.950/275 – Salvador – BA – Brasil

2Departamento de Ciência da Computação (DCC) Universidade Federal da Bahia (UFBA)

Salvador, BA – Brasil

3Nexen Tecnologia Salvador, BA – Brasil

{elisangela, george, lais}@unifacs.br, [email protected],

[email protected]

† Este trabalho é parte integrante do projeto “Uma solução de transformação bidirecional de modelos UML e código baseado na abordagem MDA”, financiado pela Fundação de Amparo à Pesquisa do Estado da Bahia (FAPESB)

Abstract. This paper presents an strategy for extracting stakeholder-centered

views from domain ontologies, with the goal of helping the development of

software applications. The proposed approach is part of a MDA (Model-

Driven Architecture) solution and can be used for building domain models

associated to the CIM (Computer Independent Model) layer. An important

contribution of our proposal is the treatment of business rules as first class

elements in several associated models. A Multimedia ontology is used to

illustrate the proposed approach.

Resumo. Este trabalho propõe uma estratégia para extração de visões

centradas em stakeholders a partir de ontologias de domínio, com o objetivo

de auxiliar o desenvolvimento de aplicações. Esta abordagem está inserida

numa solução MDA (Model-Driven Architecture) e fornece subsídios à

construção de modelos de domínio da camada CIM (Computer Independent

Model). Uma contribuição desta proposta é o tratamento das regras de

negócio como elementos de primeira classe nos vários modelos envolvidos.

Uma ontologia de Multimídia é utilizada para ilustrar abordagem proposta.

II Workshop on Ontologies and Metamodeling in Software and Data EngineeringWOMSDE 2007

17

1. Introdução

Uma das atividades mais complexas do processo de Engenharia de Requisitos é a elicitação de requisitos, na qual analistas interagem com diversas fontes de informação –stakeholders, documentação sobre o domínio da aplicação, outros sistemas de informação, etc – para descobrir as principais funções de um sistema e restrições sobre seu funcionamento. Várias dificuldades devem ser contornadas para que, ao final do processo, a especificação do sistema seja válida (isto é, corresponda ao que os clientes realmente desejam), completa e consistente. Nesse contexto, a dificuldade de comunicação entre analistas e stakeholders é um problema clássico a ser tratado [Sommerville, 2007]. Em geral, stakeholders têm conhecimento sobre o negócio e regras associadas, expressam suas demandas usando terminologia específica de domínio e por vezes, não conseguem articular o que desejam, ou expressam necessidades contraditórias. Analistas, por sua vez, têm pouca ou mesmo nenhuma experiência prévia relacionada ao domínio da aplicação e enfrentam o desafio de compreender e organizar os requisitos do sistema, lidando com eventuais inconsistências e conflitos de interesse, e promovendo a integração do novo sistema com sistemas existentes.

Regras de negócio podem ser tratadas como requisitos, ou seja, elas podem ser elicitadas e especificadas em um sistema de software como requisitos do sistema, reutilizando várias técnicas de elicitação existentes [Sommerville, 2007]. Neste trabalho, propomos o uso de ontologias de domínio para elicitação de requisitos e, mais especificamente, de regras de negócio. Uma ontologia de domínio proporciona definição dos conceitos, vocabulário e axiomas familiares aos stakeholders e que podem ser utilizados pelos analistas na definição de um conjunto inicial de regras de negócio. Adicionalmente, ontologias apresentam uma representação simples para um contexto que pode favorecer a comunicação entre analistas e stakeholders e facilitar a compreensão, resolução de conflitos e validação de requisitos. A existência de repositórios de ontologias pode também facilitar o desenvolvimento de novas aplicações em um mesmo domínio.

Entretanto, o uso de ontologias nem sempre é adequado para interação entre todos os tipos de stakeholders. Por exemplo, regras de negócio podem estar representadas através de axiomas e outros elementos que não são necessariamente fáceis de entender e manipular. Além disso, ontologias podem ser grandes e complexas, a depender do domínio associado. A comunicação entre analistas e stakeholders deveria considerar apenas a visão de cada stakeholder sobre o negócio e regras associadas. Desse modo, cada visão deveria corresponder a apenas um subconjunto dos conceitos e axiomas presentes na ontologia.

Neste artigo, apresentamos uma abordagem baseada em ontologias de domínio para apoiar a atividade de elicitação de requisitos e, mais especificamente, a extração de regras de negócio relacionadas a um ou mais stakeholders e suas visões correspondentes. As regras elicitadas serão especificadas de modo a facilitar (i) a comunicação entre analistas e stakeholders, e (ii) a transformação para outros artefatos de projeto e implementação. Assim, as regras de negócio identificadas serão mapeadas para SBVR (Semantics in Business Vocabulary and Rules), um padrão emergente da OMG (Object Modeling Group) para representação de regras de negócio, que deve se tornar parte integrante do padrão MDA (Model Driven Architecture) [Hendryx, 2005].


18

Este trabalho está inserido em um projeto de pesquisa em andamento, cujo foco é Desenvolvimento Dirigido por Modelos, no qual regras de negócio são tratadas como elementos de primeira classe em diversos modelos até a sua implementação em alguma linguagem de programação.

Este trabalho está organizado como se segue. Na seção 2, os conceitos básicos necessários para compreensão de nossa proposta são apresentados. Na seção 3 apresentamos a abordagem proposta. Na seção 4 apresentamos um estudo de caso, onde nossa abordagem é aplicada para extração de visões tendo como base a ontologia de Mutimidia [Guizzardi, 1997]. Na seção 5 é apresentada uma comparação da proposta com trabalhos correlatos. Finamente, na seção 6 apresentamos as conclusões e trabalhos em andamento.

2. Conceitos Básicos

Nesta seção, apresentamos a fundamentação teórica para este trabalho, que inclui alguns conceitos e definições relacionadas a ontologias, regras de negócio, SBVR e MDA.

2.1. Ontologias Uma ontologia é uma especificação formal e explícita de uma conceitualização compartilhada. Nessa definição, formal significa legível para computadores;

especificação explícita diz respeito a conceitos, propriedades, relações, funções, restrições,axiomas, explicitamente definidos; compartilhado quer dizer conhecimento consensual; e conceitualização diz respeito a um modelo abstrato de algum fenômeno do mundo real [Borst, 2002].

A ontologia pode ser classificada sobre diversos aspectos. Utilizaremos a classificação da ontologia proposta em [Guarino, 1998], que está dividida em: i) ontologia genérica, ii) ontologia de domínio, iii) ontologia de tarefa e iv) ontologia de aplicação.

As ontologias genéricas apresentam conceitos bastante gerais, que são independentes de um problema ou domínio particular. As ontologias de domínio e de tarefas descrevem, respectivamente, um vocabulário relacionado a um domínio genérico (como medicina, ou automóveis) ou a uma tarefa genérica ou atividade (como diagnosticar ou vender), especializando-se os termos introduzidos na ontologia genérica. As ontologias de aplicação descrevem conceitos que dependem de um domínio e de uma tarefa, que são freqüentemente especializados das ontologias relacionadas.

2.2. Regras de Negócio

Regras de negócio têm sido largamente utilizadas para a modelagem de bancos de dados e, recentemente, seu uso foi popularizado pelo BRG (Business Rules Group). Nesse contexto, o termo “regra de negócio” recebeu duas definições distintas, uma associada à perspectiva de sistemas de informação (SI) e outra associada à perspectiva de negócio [BRG, 2000]. Na perspectiva de sistemas de informação, uma regra de negócio é uma sentença que define ou restringe algum aspecto do negócio. Segundo a perspectiva de negócio, uma regra de negócio é uma diretriz que interfere na conduta, ação, prática ou procedimento em uma atividade específica dentro de uma organização, como suporte a


19

uma política de negócio. Na perspectiva de SI, uma regra de negócio lida com fatos do sistema armazenados como dados e com restrições sobre modificações nos valores desses fatos [BRG, 2000]. Este trabalho adota esta última definição associada à perspectiva de SI.

2.3. SBVR

O padrão SBVR "Semantics of Business Vocabulary and Business Rules" é o resultado da fusão de padrões ISO, lógica formal, lingüística e a experiência prática dos membros da BRT “Business Rules Team”. Esta especificação da OMG é a primeira a utilizar formalmente linguagem natural na modelagem, provendo uma forma de capturar especificações em linguagem natural e representá-las em lógica formal.

O padrão SBVR é composto por dois vocabulários, um responsável por descrever o vocabulário do negócio, contendo termos e definição dos conceitos, e o outro por descrever as regras de negócio. Dentro da abordagem MDA, ele está posicionado na camada CIM [OMG, 2005b]. Nesse padrão, há duas categorias de regras: estruturais e operativas. Regras estruturais representam necessidades -- são as regras sobre como o negócio é organizado. Regras operativas representam obrigações -- são as regras que governam a conduta da atividade de negócio. Por exemplo, a regra: “It’s necessary that each servidor is owned by exactly one provedor.” é estrutural e “each servidor feeds some terminal if only if that terminal has a contract some provedor.” é operativa.

Em [OMG, 2005b] o vocabulário SBVR utilizado é baseado no inglês estruturado. No entanto essa não é a única opção, podendo-se escrever um outro vocabulário em qualquer outra linguagem para expressar o metamodelo SBVR.

2.4. MDA

A arquitetura dirigida por modelos (Model Driven Architecture ou MDA) é um framework para desenvolvimento de software definido pela OMG, cujo ponto principal está na utilização de modelos e transformações entre eles em um processo de desenvolvimento dirigido por modelos. Aplicações que seguem o padrão MDA promovem uma separação entre a especificação das funcionalidades independentes de plataforma de um sistema, de sua implementação em uma ou mais plataformas específicas [OMG, 2003].

A arquitetura MDA está organizada em três camadas, a saber: i) CIM (Computation Independent Model), ii) PIM (Platform Independent Model) e iii) PSM (Platform Specific Model). A camada CIM corresponde a um modelo conceitual independente de computação; é a representação do sistema considerando-se apenas conceitos do domínio, relações e regras de negócio. A camada CIM contribui para o entendimento do domínio e criação de um vocabulário padrão, além de facilitar a comunicação entre desenvolvedor e cliente. A camada PIM corresponde a um modelo independente de plataforma, com foco nas operações do sistema. Essa independência permite que, a partir da camada PIM, sejam gerados diversos modelos específicos de plataforma ou PSMs. A camada PSM corresponde a um modelo específico de plataforma que combina as informações da camada PIM com detalhes específicos de plataforma.


20

3. Proposta

Nossa proposta consiste em uma estratégia para a extração de regras de negócio relacionadas a um ou mais stakeholders e suas visões correspondentes, com o objetivo de gerar modelos de negócio associados à camada CIM da abordagem MDA (Figura 1). As visões extraídas deverão apresentar o conhecimento de uma ontologia em diferentes níveis de abstração e detalhe para os stakeholders no processo de desenvolvimento do software, além de conter informações adicionais fornecidas pelos próprios stakeholders, baseadas na experiência da execução de suas tarefas. Na seção 3.1 apresentamos as visões de uma ontologia centrada em stakeholders e na seção 3.2 ilustramos os artefatos associados a uma ontologia.

Figura 1. Camadas de Modelagem (adaptada de [Linehan, 2006]).

3.1. Visões de uma Ontologia Centrada em Stakeholders

As visões estão definidas inicialmente para três tipos de stakeholders: i) cliente gerencial ii) cliente operacional e iii) analista de requisitos. A extração e elaboração destas visões é conduzida pela equipe de analista de requisitos. Estas visões são analisadas nas subseções seguintes com maior detalhamento, incluindo uma breve descrição do papel de cada stakeholder, o benefício da utilização de ontologia e o processo de extração das visões.

3.1.1 Visão para o Cliente Gerencial

Neste trabalho, o cliente gerencial é aquele que dirige a empresa ou algum setor da mesma e identifica a necessidade de automatização de tarefas; é o responsável pela solicitação do sistema a ser desenvolvido na estrutura organizacional.

Uma ontologia subsidiará a formação de uma visão macro do negócio - composta por uma ilustração que contempla os principais conceitos e relacionamentos, além da descrição destes conceitos (vocabulário). Ela é obtida através de interações entre os analistas e os diversos representantes da gerência em reuniões utilizando-se uma ontologia, ou parte da mesma.


21

A partir de uma ontologia, são inferidas informações que se encaixam na organização em questão e acrescidos demais conhecimentos relevantes fornecidos pelo cliente gerencial. Caso não haja um consenso com relação ao vocabulário, recomenda-se a utilização de um thesaurus.

3.1.2 Visão para o Cliente Operacional

O cliente operacional é aquele que executa as atividades a serem automatizadas e, por isso, possui o entendimento do negócio. A visão de uma ontologia para o cliente operacional incorpora a anterior, sendo complementada com conceitos e relacionamentos não tratados na visão gerencial. Adicionalmente, um subconjunto de axiomas oriundos da ontologia é transformado em regras de negócio codificadas em linguagem natural.

Com a utilização de uma ontologia, o processo inicial de elicitação de requisitos é facilitado, já que ela aproxima o cliente operacional do analista. Sua utilização permite que o tempo gasto possa ser reduzido, já que parte dos requisitos e das regras de negócio está contemplada na ontologia [Cota e Falbo, 2004].

Além do conhecimento extraído da ontologia, esta visão pode ser enriquecida com novas regras e requisitos informados pelo próprio cliente operacional. A utilização de linguagem natural para inserção de novas regras de negócio é um benefício na elicitação de requisitos, pois é de fácil compreensão por parte dos stakeholders.

Esta visão acrescida do conhecimento do cliente operacional pode ser incorporada na ontologia para criação de uma mais específica. Neste caso, é importante ter-se o cuidado para que essas alterações não causem ambigüidade e/ou inconsistências na ontologia.

Essa elicitação ocorre através de reuniões entre os analistas e o cliente operacional, onde (i) são apresentadas ao cliente operacional, as informações provenientes de uma ontologia e (ii) é solicitado que ele informe quais delas fazem parte da sua realidade, além de pedir-lhe que adicione outras regras que não estão sendo contempladas pela ontologia. Neste momento, faz-se necessária uma revisão do vocabulário e do thesaurus obtido na visão gerencial.

3.1.3 Visão para o Analista

O analista é aquele que tem o conhecimento técnico em engenharia de software e cujo objetivo é tentar mapear os desejos e necessidades dos clientes para o sistema a ser desenvolvido. Cabe a ele capturar e perceber junto aos clientes o que realmente é útil e indispensável.

Esta visão mais técnica apresenta, além do conteúdo das visões anteriores, o modelo de entidades e relacionamentos com os conceitos relativos ao domínio, extraídos da ontologia e enriquecidos com informações fornecidas pelos clientes.

Nesta visão, as regras de negócio levantadas são mapeadas para SBVR (Seção 2). Essa transformação é interessante, pois este padrão está em consonância com a abordagem MDA, um dos eixos da nossa proposta, além de apresentar mapeamentos para outras tecnologias (XMI,OCL etc.) que serão úteis para uma implementação futura desta abordagem.


22

Uma ontologia facilita essa tarefa na medida em que o analista possui um conjunto de informações sobre o domínio do problema, bastando ao cliente selecionar o que é relevante para a aplicação desejada. Resta ao analista a tarefa de levantar o restante dos requisitos e regras não contempladas na ontologia, e validá-los.

A extração desta última visão ocorre no levantamento de requisitos através de reuniões com todos interessados na concepção do novo sistema. Vale ressaltar que esta visão é a integração das visões anteriores ao conhecimento técnico do analista.

3.2. Artefatos Associados a uma Ontologia

A Tabela 1 apresenta uma associação entre fases de projeto, visões de stakeholders, artefatos e o paradigma MDA para o ciclo de vida do novo sistema.

Apesar da forte relação entre este trabalho e a camada CIM, em todos os níveis da MDA os artefatos estão descritos com base no vocabulário da mesma ontologia (caracterizada no nível de domínio), facilitando a rastreabilidade entre conceitos e artefatos de diversas atividades do processo de desenvolvimento.

Tabela 1. Analogia de Fases de Engenharia de Software, Visões de Stakeholders, Artefatos e Nível MDA

Fases Visões de

Stakeholders Artefatos Nível MDA

Ontologia (conceitos, axiomas, cardinalidades e relações)

Nível de domínio

Cliente Gerencial Ilustração da Ontologia, Conceitos (vocabulário)

Cliente Operacional Ilustração da Ontologia, Conceitos (vocabulário), Regras de Negócio (linguagem natural), Requisitos e novas Regras de Negócio

Negócio

Analista Ontologia, Conceitos, Regras de Negócio (SBVR), DER

CIM

Análise Analista Ontologia, Conceitos, DER, Regras de Negócio (OCL), Diagramas UML (análise)

PIM

Projeto Analista Ontologia, Conceitos, DER, Regras de Negócio (OCL), Diagramas UML (projeto)

PSM

4. Estudo de Caso

Nesta seção, apresentamos alguns resultados associados à aplicação da abordagem apresentada na seção 3, tendo como base a ontologia e o domínio modelado em [Guizzardi, 1997].

Um sistema de vídeo sob demanda é um sistema multimídia que permite uma interação entre os usuários e o servidor de vídeo, possibilitando a eles o direito de escolha da programação desejada [Guizzardi, 1997]. Neste estudo de caso é apresentado um tipo de sistema de vídeo sob demanda TVod (True Vod), no qual o usuário tem total controle sobre a exibição do vídeo.


23

4.1. Visão do Cliente Gerencial

Esta visão apresenta uma ilustração do diagrama de conceitos e relações do domínio de gerência de um serviço de VoD (vídeo on demand system). Desta forma é possível verificar de maneira simples uma visão macro do negócio apresentada na figura 2. Num experimento real, recomenda-se que esta ilustração seja construída pelo analista e apresentada ao cliente gerencial.

Um outro benefício de utilização desta ilustração é que a mesma contempla os principais conceitos relacionados ao domínio VoD com os seus significados, tais como: i) Provedor (do Serviço): Entidade que possui servidores e é contratada por terminais. É responsável por manter os Vídeos em seus servidores e por gerenciar usuários que os contratam; ii) Servidor: Armazena os vídeos e os transmite aos terminais; iii) Vídeo: Entidade que representa unicamente um título que compõe o catálogo de um Provedor; iv) Terminal (do Usuário): Entidade que representa o equipamento através do qual o usuário escolhe o Vídeo que irá assistir; v) Central: Entidade que representa uma central telefônica, central de TV a cabo ou uma rede local, associando Servidores e Terminais.

Figura 2 - Visão simplificada de um cenário de VoD [Guizzardi, 1997].

O cliente gerencial valida as necessidades de automatização de alguma tarefa com base na ontologia apresentada pelo analista. Neste sentido, é possível verificar um outro benefício associado: o entendimento consensual domínio do sistema a ser desenvolvido.

4.2. Visão do Cliente Operacional

Na visão do cliente operacional é possível a inserção de novas regras e requisitos em linguagem natural, informados pelo por este stakeholder l (Tabela 2). Os axiomas da ontologia são representados em LINGO (Linguagem Gráfica para descrever Ontologias) [Falbo, 1998] e especificados com teoria dos conjuntos.

Tabela 2 - Regras da Ontologia e Regras em Linguagem Natural

Axiomas da Ontologia Regras Linguagem Natural

∀s:S, t:T alimentação(s,t) ↔ t ∈ ( Im(Im(s,posse),contrato) ∩ Im(Im(s,habitação),cobertura) )

Para um Servidor alimentar um Terminal, ele deve pertencer a um dos Provedores contratados por esse Terminal e o Servidor deve estar conectados à mesma Central que cobre o Terminal.


24

Na Tabela 2, o axioma extraído exibe os termos (alimentação, posse, contrato, habilitação, cobertura) que representam as relações existentes na ontologia, como mostra a Figura 3. Os demais símbolos advêm da teoria de conjuntos, como por exemplo, Im, representa a imagem do conjunto [Guizzardi, 1997]. A Tabela 2 mostra a transformação de um axioma para uma regra de negócio em linguagem natural, legível ao cliente operacional.

Figura 3 - Diagrama conceitos e relações do domínio.

Com base nesses artefatos iniciais, o analista entrevista o cliente operacional para que ele possa enriquecer essa visão com novos requisitos e regras.

4.3. Visão do Analista de Requisitos

Esta visão apresenta o modelo de entidade-relacionamento e as regras de negócio mapeadas em SBVR com os conceitos relativos ao VoD gerados a partir da ontologia. O diagrama de entidade-relacionamento (Figura 4) é derivado a partir da visão anterior. Este apresenta os conceitos básicos referentes ao domínio desejado, sendo desta forma, um modelo mais técnico (conceitual) e independente de plataforma.

Figura 4 – Diagrama Entidade-Relacionamento


25

A Tabela 3 apresenta o mapeamento do axioma exibido na Tabela 2 para SBVR. Este axioma é convertido em uma regra de negócio composta por uma proposição operativa e outra estrutural. Neste estudo de caso a conversão entre um axioma da ontologia para uma regra em SBVR foi realizada manualmente com base no mapeamento existente na especificação do padrão [OMG, 2005b, Cap. 10]. Numa implementação desta abordagem será construído um parser para leitura e análise de axiomas e posterior tradução numa linguagem específica de domínio baseada no padrão SBVR.

Tabela 3 - Regras da Ontologia e Linguagem SBVR

Axiomas Ontologia Linguagem SBVR

∀s:S, t:T alimentação(s,t) ↔ t ∈ ( Im(Im(s,posse),contrato) ∩ Im(Im(s,habitação),cobertura) )

each servidor feeds some terminal if only if that terminal has a contract some provedor and that provedor owns the servidor and that is connected with the central that covers the terminal.

termo: conceito do negócio. Nome: conceito individual. verbo: relação entre os termos. Palavra-chave: palavra reservada da linguagem.

5. Trabalhos Correlatos

A proposta apresentada neste trabalho se alinha com outras propostas de casar MDA com o universo das ontologias, entre elas, destaca-se o trabalho em andamento da OMG chamado ODM (Ontology Definition Metamodel) [OMG, 2005a]. Este padrão tem como objetivo a criação de uma família de metamodelos MOF (Meta Object Facility) para definição de ontologias a ser aplicado na abordagem UML/MDA. Neste padrão, o conceito de ontologia também pode ser usado como subsídio à construção do modelo de domínio na camada CIM.

Na tentativa de integrar o uso de ontologias à abordagem MDA, o foco da nossa proposta é na extração de visões de uma ontologia para a construção do modelo CIM, isto é, como usar uma ontologia para a construção do modelo de domínio com foco nos diferentes stakeholders, enquanto que o padrão ODM – uma proposta, sem dúvida, mais ampla - visa, em última instância, fazer mapeamentos entre os vários metamodelos de ontologias e propor um conjunto de profiles que permitem a modelagem de ontologia através de ferramentas baseadas em UML.

Em sua proposta original, o padrão SBVR [OMG, 2005b] não faz referência a ontologias - a definição dos padrões SBVR e ODM ocorreu em paralelo. Porém, no padrão SBVR é citado que um mapeamento parcial entre SBVR e ODM é possível. Outra questão importante colocada no mesmo documento: “Para as regras de negócio, a lógica monotônica é apenas aplicada a uma pequena fração de requisitos” [OMG, 2005b,pg. 47], onde a lógica monotômica é aquela presente em ontologias. Este ponto é extremamente relevante: o conjunto de regras de negócio pode ser bem maior que o conjunto de axiomas de uma ontologia de domínio. Em função disso, na nossa proposta, os axiomas oriundos de uma ontologia apenas constituem uma bateria inicial de regras de negócio, e caso novas regras sejam inseridas na ontologia em questão, esta adição deve ser validada para que seja mantida a coerência lógica do conjunto de axiomas inicialmente estabelecido.


26

6. Conclusão

Neste artigo apresentamos uma abordagem para extração de conhecimento através do uso de ontologia, com objetivo de facilitar a identificação de requisitos e extração de regras de negócio. As vantagens dessa abordagem são: i) entendimento consensual do domínio, ii) maior legibilidade das regras de negócio através do uso de linguagem natural, iii) suporte à separação de regras de negócio centrada em visões, fornecendo percepções distintas e adequada para cada stakeholder e iv) otimização na construção do modelo de domínio da camada CIM (MDA).

Além dos benefícios para a elicitação de requisitos, o uso de uma ontologia e sua apresentação através de visões, podem auxiliar analistas e stakeholders a resolver conflitos, priorizar, especificar e validar requisitos.

Neste sentido, a extração de visões centradas em stakeholders possibilita que os mesmos complementem o domínio, por menor que sejam seus conhecimentos técnicos. Isso decorre do fato de cada visão da ontologia apresentar um diferente nível de abstração do domínio. É importante observar que a definição dos stakeholders depende da estrutura organizacional. Neste trabalho é sugerida uma definição de papéis que pode ser customizada.

A abordagem aqui apresentada também pode se beneficiar dos repositórios de ontologias existentes nas mais diversas áreas do conhecimento, representando um ganho substancial na fase inicial no processo de engenharia de software.

Esta proposta faz parte de uma solução MDA, cuja implementação encontra-se em andamento. A próxima fase do projeto é a transformação dos modelos CIM para modelos PIM. Neste sentido, uma visão importante é a perspectiva do analista de requisitos, que contém o conjunto completo de artefatos que serão transformados em elementos do modelo PIM. No que diz respeito ao processamento das regras de negócio, será realizado o mapeamento dos axiomas de uma ontologia para o padrão SBVR e deste para a linguagem OCL (Object Constraint Language). Os elementos restantes da visão do analista serão convertidos em diagramas de análise em UML. Um aspecto importante desta implementação é a integração das regras de negócio em OCL com os diagramas UML resultando em modelo independente de plataforma.

7. Referências

Almeida, M.; Bax, M. (2003) “Uma visão geral sobre ontologias: pesquisa sobre definições, tipos, aplicações, métodos de avaliação e de construção”, Ci, Inf. Brasília, v.32, n. 3, p. 7-20, set/dez, http://www.ibict.br/cienciadainformacao/viewarticle.php?id=36, Junho.

Brown, A. (2004) "Model driven architecture: Principles and pratice". Springer-Verlag.

Borst, W. “Construction of engineering ontologies, Graduate School for Information and Knowledge Systems” Disponível em: http://www.ub.utwente.nl/webdocs/inf/1/t0000004.pdf

Business Rules Group – (BRG) (2000). “Defining Business Rules ~ What Are They Really?”, http://www.businessrulesgroup.org/defnbrg.shtml, Junho.


27

Cota, R., Menezes, C.., Falbo, R. (2004). “Modelagem Organizacional Utilizando Ontologias e Padrões de Análise” Memorias de VII Workshop Iberoamericano de Ingeniería de Requisitos y Desarrollo de Ambientes de Software - IDEAS'2004, pp. 56-67, Arequipa, Perú, http://www.inf.ufes.br/%7Efalbo/download/pub/2004-IDEAS-2.pdf, Julho.

Duarte, K., Falbo, R, (2000). “Uma Ontologia de Qualidade de Software”, In: Anais do VII Workshop de Qualidade de Software, João Pessoa – Paraíba. Brasil.

Falbo, R. (1998). “Integração de conhecimento em um ambiente de desenvolvimento de software”, http://www.inf.ufes.br/%7Efalbo/pub.html, Junho.

Guarino, N. (1998). “Formal Ontology and Information System. Intl Conf. on Formal Ontology and Information Systems”, http://www.loa-cnr.it/Papers/FOIS98.pdf, Junho.

Guizzardi, G. (1997). "Hipervisao: a logical architecture for video on demand systems", Final Dissertation, Computer Science Department, Federal Univ. of Espírito Santo.

Hendryx, S. (2005) “Model-Driven Architecture and the Semantics of Business Vocabulary and Business Rules”.

Linehan, M. (2006). “Semantics in model-driven business design”. In Proc. of 2nd Intl Semantic Web Policy Workshop (SWPW’06), http://www.l3s.de/~olmedilla/events/2006/SWPW06/programme/paper_02.pdf, Julho.

Object Modeling Group – OMG (2003). “MDA Guide”, version 1.01, http://www.omg.org/docs/omg/03-06-01.pdf, Junho.

Object Modeling Group – OMG (2005a). “Ontology Definition Metamodel (ODM) Proposal”, http://www.omg.org/docs/ad/05-08-01.pdf, Agosto.

Object Modeling Group – OMG (2005b). “Semantics of Business Vocabulary and Business Rules”, version 8, http:/www.omg.org/docs/bei/05-08-01.pdf, Agosto.

Sommerville, I. (2007). Software Engineering, Addison Wesley, 8th edition.Almeida,

Souza, R.; Alvarenga, L. (2004). “A Web Semântica e suas contribuições para a ciência da informação”. Ci. Inf., Brasília, v. 33, n. 1, p. 132-141, jan./abr, http://www.ibict.br/cienciadainformacao/printarticle.php?id=71&layout=html, Julho.


28

Extração de Visões Centradas em Stakeholders a partir de ... · relacionada ao domínio da...

Documents

Transcript of Extração de Visões Centradas em Stakeholders a partir de ... · relacionada ao domínio da...