PROCEDA Um Processo para Construo e Verificao Semntica de Domnios em uma Linha de Produtos de Software

Jaguaraci Batista Silva Departamento de Cincia da Computao / Laboratrio de Sistemas Distribudos Universidade Federal da Bahia Campus de Ondina, CEP: 40170-110, Salvador-BA, Brasil
jaguarac@ufba.Br

Resumo. A falta de um processo que norteie a construo e verificao semntica de um domnio de aplicao um dos principais temas de pesquisa e vrias metodologias tentam contornar esse problema. Um outro agravante a prpria evoluo natural e aproximaes com tecnologias recentes (e.g. ontologia, arquitetura orientada modelos e programao orientada aspectos) torna-se indispensvel rever essas atividades para diminuir os erros e evitar re-trabalho. O PROCEDA contribui nesse mbito, por apresentar um conjunto de atividades e tcnicas para verificao semntica de domnios. Abstract. The lack of process that aims to get application building and semantic verification of domain is a top research theme and several methodologies try to solve it. Another trouble is the self natural evolution and actual technologies approaches (e.g. ontology, model-driven architecture and aspect-oriented programming) become indispensable to review theses activities to decrease faults and reworks. The PROCEDA method presents a set of activities and techniques for semantic verification of domains. .
Keywords: Process, Ontology, Application Domain, Semantic Verification.

1 Introduo
H tempos pessoas envolvidas com a fabricao de software vem criando conscincia de que para a satisfao dos clientes necessrio construir produtos com qualidade, porm no basta ter uma boa qualidade, se no for economicamente vivel (Travassos et al, 2002). A engenharia de domnio, bem como, outras tcnicas (e.g. padres de projeto, desenvolvimento baseado em componentes, composio adaptativa, programao orientada a aspectos) visam a reutilizao e est entre as tcnicas mais relevantes para que se possa construir um software em menor tempo, maior confiabilidade e tendo como conseqncia

um menor custo. Segundo (Travassos et al, 2002), o enfoque de linha de produto pode ser visto como uma forma de organizao dessas tcnicas. Durante a construo de uma linha de produtos preciso ter um processo consiso para construir e verificar os pontos de variabilidade do domnio e a falta de um conjunto detalhado de atividades para apoiar esse processo um dos principais problemas enfrentados hoje em dia. Em um trabalho anterior (Silva e Saba, 2008), foi proposta a criao de um processo de integrao de componentes com base no CMMI e uma metodologia de Business Process Management, que mescla a padronizao de documentos, diagramas e representao de atividades do junto com tcnicas de modelagem de requisitos baseadas em casos de usos. Aproveitando essa padronizao foi criada uma aproximao com ontologias para mesclar ao conjunto de atividades a criao e verificao formal de um domnio de aplicao. Na seo 2 apresentado os conceitos bsicos de uma linha de produtos de software, bem como, a identificao de um domnio e seus pontos de variabilidade. Na seo 3 apresentado o processo PROCEDA que incorpora a criao e verificao formal dos requisitos do domnio usando ontologias e na seo 4 um estudo de caso para testar a sua aplicao durante a construo de um domnio para um sistema de abastecimento de fornos industriais. Por fim, apresentada a concluso deste trabalho.

2 O Processo de Criao de Uma Linha de Produtos de Software

Uma famlia de produtos de software um conjunto de produtos de software com caractersticas suficientemente similares para permitir a definio de uma infra-estrutura comum de estruturao dos itens que compe os produtos e a parametrizao das diferenas entre os produtos (Travassos et al, 2002). Uma famlia de produtos para sistemas de acompanhamento da produo de indstrias, por exemplo, tem uma arquitetura comum e um domnio especfico, porm os tipos de produtos produzidos podem variar, o que tornaria necessria a especializao do software para atender as especificidades de malha industrial. Uma linha de produto de software envolve um conjunto de aplicaes similares dentro de um domnio que podem ser desenvolvidas a partir de uma arquitetura genrica comum, a arquitetura da linha de produto, e um conjunto de componentes que povoam a arquitetura (Travassos et al, 2002). O objetivo identificar os aspectos comuns e as diferenas entre os artefatos durante todo o processo de desenvolvimento, assim, os pontos de deciso em que devem ser adaptados os componentes para gerao de produtos especficos, devem ser identificados atravs de pontos de variabilidade ou pontos em que as caractersticas dos produtos podem variar.

2.1 Aspectos bsicos

As trs atividades essenciais da construo de uma linha de produto so: o desenvolvimento do ncleo de artefatos, o desenvolvimento do produto e o gerenciamento da linha de produto (Clements et al, 2001). Essas trs atividades esto intrinsecamente relacionadas de tal forma que a alterao em uma delas implica em analisar o impacto nas demais. importante notar que o

desenvolvimento do ncleo de artefatos baseado em uma famlia de produtos faz a reutilizao de artefatos para a linha de produtos previsvel. Segundo (Clements et al, 2001), a atividade de desenvolvimento do ncleo de artefatos tem sido chamada de engenharia de domnio e a atividade de desenvolvimento do produto tem sido chamada de engenharia de aplicao. Em (Weiss et al,1999) incorporado o conceito de engenharia de domnio e engenharia de aplicao. Em sua abordagem, uma famlia de produtos tambm conhecida pelo termo domnio. O processo de desenvolvimento de uma linha de produto de software pode ser visto como dois modelos de ciclo de vida (Travassos et al, 2002), conforme mostra a Figura 1.

Figura 1. O processo de desenvolvimento de uma linha de produto (Travassos et al, 2002).

O primeiro modelo de ciclo de vida representa o desenvolvimento do ncleo de artefatos ou engenharia de domnio. Esta etapa composta pela anlise de domnio, desenvolvimento da arquitetura e desenvolvimento de componentes

reutilizveis. Este ciclo produz um modelo de domnio, uma arquitetura, um conjunto de componentes reutilizveis e geradores de software para a linha de produtos. Um dos conceitos mais importantes na de linha de produto de software o de variabilidade. Este conceito ser explorado e definido na seo seguinte.

2.2 Variabilidade
Para formar uma linha de produto necessrio representar as variaes que podem ocorrer em cada artefato que faz parte desta. Produtos em uma linha de produto existem simultaneamente e podem se diferenciar em termos de comportamento (conjunto de aes), atributos de qualidade, plataforma, configurao fsica, fatores de escala, entre muitos outros (Clements et al, 2001). Variaes so diferenas tangveis entre produtos que podem ser reveladas e distribudas entre os artefatos da linha de produto, sejam eles a arquitetura, os componentes, as interfaces entre componentes ou as conexes entre componentes (Travassos et al, 2002). As variaes podem aparecer em qualquer fase do ciclo de desenvolvimento de uma linha de produtos, a comear na fase de anlise de requisitos. A variao mais conhecida em construo de sistemas a existncia de vrias implementaes para uma mesma especificao. A expresso de uma variao pode ser obtida pela introduo de parmetros instanciveis em tempo de construo associados a componentes, subsistemas ou coleo de subsistemas a partir dos quais um produto pode ser configurado atribuindo-se um conjunto de valores a esses parmetros (Clements et al, 2001). Um tipo de variao simples de ser representado a escolha de componentes diferentes para uma mesma arquitetura. Assim, produtos podem ter maior ou menor capacidade, ou caractersticas diferentes dependendo do tipo de componente escolhido para a arquitetura (Travassos et al, 2002). Em orientao a objetos, as variaes podem ser representadas, em nvel de projeto, atravs de especializaes de classes. A integrao dos componentes de uma arquitetura de linha de produtos tem tambm um papel fundamental. A instanciao de todas as variaes possveis deve ser consistente e ter um valor semntico que faa sentido para o produto desejado. Existem vrios mecanismos para tratamento de variabilidade. Por tratamento de variabilidade entende-se desde o momento de reconhecimento de um ponto de variao at o mapeamento do ponto para uma instncia de variao. Um dos conceitos mais importantes, quando se aborda a variabilidade no software, em particular no processo de desenvolvimento, corresponde ao momento em que se seleciona uma das variantes do ponto de variabilidade, ou seja, o momento em que o ponto de variabilidade fechado (momento usualmente designado por binding time). Esta ao significa, normalmente, que a partir desse momento o software executar a opo selecionada para o ponto de variabilidade, ou seja, esse local do software deixa de ser um ponto de variabilidade. possvel selecionar uma opo de um ponto de variabilidade em diversas fases do processo de desenvolvimento: derivao da arquitetura do produto (aplicao),

compilao, ligao dinmica de bibliotecas (linking) e execuo. Bragana (Bragana et al, 2007) baseia-se nas ltimas trs fases, porque estas dizem respeito a tcnicas que podem ser utilizadas nas linguagens de programao e ambientes de desenvolvimento mais comuns. No obstante, possvel conceber outros momentos de binding como, por exemplo, o tempo de depurao. Relativamente s tcnicas de implementao de variabilidade, muito til fazer a distino entre tcnicas em que o binding time se realiza antes do momento da distribuio das tcnicas nas quais o binding time aps a distribuio do software (Bragana et al, 2007). Esta distino muito importante porque define uma linha que separe o ciclo de vida tradicional de desenvolvimento do software onde possvel mudar quase tudo da instalao e execuo do software no cliente e, no qual a mudana e a variabilidade so quase impossveis de introduzir. Segundo (Bragana et al, 2007), as tcnicas de implementao de variabilidade com o uso de binding time antes da distribuio, usadas vulgarmente pela indstria, tm por base (Gurp, 2003): pr-processamento do cdigo de fonte (e.g. diretivas do pr-processador), diretivas do editor de bibliotecas dinmicas (e.g. ligaes de objetos e/ou bibliotecas diversas), parmetros de incio de programas (e.g. templates), herana e composio de cdigo. Tambm de acordo com (Bragana et al, 2007), as tcnicas de composio de cdigo (e.g. Programao Adaptvel, Programao Orientada a Assunto e Programao Intencional) so resultados de investigaes recentes desenvolvidas nos meios acadmicos e, como tal, na grande maioria dos casos, ainda no so adotadas pela indstria.

2.2.1 Engenharia de domnio e gesto da variabilidade

Para aumentar o reuso de diversas aplicaes de uma linha de produtos, as mesmas devem compartilhar as mesmas caractersticas, conforme explicado na introduo do captulo. Isso geralmente s ocorre quando os sub-sistemas tem um domnio de aplicao em comum. A engenharia de domnio um processo que visa identificar, representar e implementar artefatos reutilizveis de um domnio (Bragana et al, 2007). A engenharia de domnio fornece mtodos e tcnicas adequados para suportar o desenvolvimento de artefatos reutilizveis, como arquiteturas de software, modelos de desenho e componentes de software. Figura 2 apresenta as interaes possveis entre a engenharia de domnio e a engenharia de aplicao. Os artefatos produzidos pela engenharia de domnio podem ser reutilizados na engenharia de aplicao. As setas com sentido da engenharia de aplicao para a engenharia de domnio demonstram que a engenharia de aplicao pode fornecer entradas para a engenharia de domnio, usualmente sob a forma de conhecimento do domnio em causa. Cada nova aplicao que construda dentro do domnio ganhar da reutilizao dos artefatos do domnio e fornecer conhecimento para refinar os mesmos artefatos do domnio ou para construir novos artefatos. Os artefatos resultantes do processo de engenharia de domnio consistem nos componentes comuns que so reutilizados nas aplicaes e tambm nos componentes que implementam os pontos de variabilidade e que so usados apenas em algumas aplicaes.

Uma vez que o domnio esteja definido, o processo de engenharia de domnio se decompe em trs etapas segundo (Barreto, 2005): anlise, projeto e implementao do domnio. A anlise de domnio visa identificar os pontos comuns e as variaes entre os programas do domnio. O ponto central da anlise de domnio na viso de Barreto (Barreto, 2005) a separao entre os pontos comuns (commonalities) e as variaes (variabilities) existentes nas polticas.

Figura 2. Engenharia de domnio vs. Engenharia de aplicao (Bragana et al, 2007.

O objetivo identificar o mximo de pontos comuns a fim de reutiliz-los de maneira sistemtica no desenvolvimento de novas polticas. O projeto de domnio utiliza uma linguagem para a representao de conjuntos de abstraes de sintaxes concretas e semnticas. Quando da implementao do domnio, utilizada uma linguagem de programao capaz de executar as aes, sendo uma implementao concreta das abstraes projetadas na etapa anterior.

3 Construo de Domnios para uma Linha de Produtos usando o PROCEDA

O PROCEDA centrado em casos de uso e pode ser incorporado a qualquer modelo de processo de software existente como: Rational Unified Process (RUP) (Booch et al, 1999), Extreme Program (XP) (Extreme Program, 2008) e nas metodologias geis (Agile Modeling, 2008). Foi dividido em 3 partes contemplando um conjunto de atividades desde a anlise de requisitos at a verificao do domnio. As representaes das atividades esto agrupadas em trs processos principais, chamados de macro processos em (Silva e Saba, 2008): modelagem do domnio, verificao e extrao das regras de negcios e transformao do domnio conceitual em um modelo para uma plataforma especfica.

3.1.1 Modelagem do domnio de uma aplicao

A Figura 3 apresenta a construo do modelo de domnio da aplicao que a primeira etapa do processo. A primeira atividade, capturar os requisitos da aplicao, visa a identificao dos pontos de variabilidade da linha de produtos. Essas variaes podem ser a definio da arquitetura, os componentes e as suas interfaces de integrao, configurao fsica, atributos de funcionalidade entre outros. No processo proposto pode ser utilizada qualquer tcnica adequada para coleta de informaes, a exemplo das tcnicas: Join Application Developer (JAD) (Wood et al, 1995), anlise estruturada (Yourdon, 1992) e particionamento e agregao estruturais na anlise orientada a objetos (Reinoso et al, 1994). Durante ou aps a coleta de informaes, pois depende do modelo de processo utilizado, possvel criar os casos de uso e o domnio conceitual da aplicao de maneira incremental. Sendo necessrio identificar, os requisitos funcionais e nofuncionais. Os requisitos funcionais representam a viso dos usurios ou stakeholders quando do uso do sistema atravs de alguma interface ou tela, enquanto que os no-funcionais devem atender a critrios para o funcionamento correto do sistema (e. g. segurana, persistncia e integrao com outros softwares).

Figura 3. Modelagem do Domnio da Aplicao.

A atividade de criao dos casos de uso visa representar tudo o que o usurio pode fazer no sistema e tem o objetivo de mostrar, atravs da linguagem UML (Booch et al, 1999), o entendimento do desenvolvedor sobre as funcionalidades do sistema para os stakeholders. A atividade de criao do domnio conceitual da aplicao guiada pelo processo de construo de um diagrama de classes UML, devendo ser encontradas as informaes sobre a definio de classes, seus atributos e relaes e as descries das regras de negcio.

3.1.2 Formalizao do Domnio e Extrao das Regras de Negcios

A segunda etapa, representada na Figura 4, prope o uso da ontologia para formalizar os conceitos do domnio da aplicao (Silva e Pezzin, 2006). Inicia-se pelo processo de construo de uma ontologia de acordo com os requisitos do domnio da aplicao: a definio de conceitos, seus atributos ou propriedades, as relaes entre os conceitos e os axiomas que iro representar as regras de negcio descritas na etapa anterior. A gerao do arquivo OWL (Ontology Web Language) se faz necessria para que se possa fazer inferncias sobre a satisfao dos conceitos definidos para o domnio da aplicao, seguindo os passos propostos em (Silva e Pezzin, 2007), onde foi definida uma arquitetura para a verificao formal de domnio de aplicao. O prximo passo a identificao das regras de negcio antes da gerao de um modelo independente de plataforma (PIM).

Figura 4. Formalizao do Domnio e Extrao das Regras de Negcio.

Essa atividade possibilita a separao de interesses ortogonais da aplicao, pois esses interesses esto misturados entre os mtodos de classes dificultando uma futura manuteno do software. Com essa abordagem, ser possvel implementar os interesses em forma de aspectos criando composies de modelos especficos de plataforma (PSMs) (Silva e Barreto, 2008).

3.1.3 Transformao do PIM em PSM e Implementao das Regras de Negcio usando AOP

Figura 5. Transformao do PIM em PSM e Implementao das Regras usando AOP.

A Figura 5 apresenta a ltima etapa do processo. O modelo independente de plataforma criado a partir de uma ontologia, deve ser uma instncia do metamodelo MOF e poder utilizar algum perfil da UML como o ODM (Ontology Definition Metamodel) para a criao de modelos a partir de ontologias ou a criao de um perfil prprio. A sua implementao uma demonstrao de uma das principais vantagens da criao de modelos usando a MDA, que a gerao e o intercmbio de modelos usando a linguagem XML. A prxima atividade, transformao do PIM para o PSM, contm a definio do conjunto de classes, atributos e relacionamentos que sero gerados para uma plataforma especfica. Ainda nesta atividade devero ser criadas as regras para a transformao do modelo PIM criando uma instncia para uma plataforma especfica. De acordo com os requisitos no-funcionais ou desejos dos stakeholders definidos na primeira etapa do processo.

4 Estudo de Caso Construo e Verificao de um Domnio para um Sistema de Abastecimento de Fornos Industriais
A proposta do estudo de caso utilizar o PROCEDA para a construo de um domnio para um sistema de abastecimento de fornos industriais real. A primeira atividade durante a criao de um sistema a construo dos cenrios ou casos de uso do sistema. Os casos de uso visa representar tudo o que o usurio pode relizar em um sistema e tem o objetivo de mostrar, atravs da linguagem UML (Booch et al, 1999), o entendimento sobre as funcionalidades do sistema a ser construdo com base em uma ontologia de domnio. O processo de construo da

ontologia baseia-se nas informaes do diagrama conceitual do domnio da aplicao e na descrio textual dos casos de uso (Tabela 1).
Tabela 1. Descrio Textual do Caso de Uso Realizar Carga no Forno.
Nome do Caso de Uso: Realizar carga no forno

UC#: 001 ltima Atualizao: 10/03/2008

Responsvel: Operador

1. Descrio O objetivo deste caso de uso realizar o abastecimento de fornos com os insumos necessrios para a produo de ligas. Ele tem como ator principal o operador. 2. Fluxo Principal Fluxo: Carga realizada com sucesso: 1. 2. 3. 4. Operador entra com informao de usurio e senha de acesso ao sistema. Operador escolhe o forno para produo de uma liga de ferro. Operador seleciona os insumos necessrios para fabricao, indicando o silo de armazenamento e digita as quantidades. Operador confirma a ao de carga.

3. Fluxos Complementares 1. Operador verifica a carga dos insumos atravs do relatrio de abastecimento, ver caso de uso Gerar relatrio de abastecimento.

4. Regras de Negcio 1. 2. 3. 4. 5. 6. 5. Excees 1.a Administrador tenta abastecer os fornos. 1.a O operador digita nome e/ou senha invlido(s). 2.a. O operador escolhe o forno que no est habilitado para produo. 2.b. O operador escolhe o produto que no est sendo produzido no forno selecionado. 3.a. O operador escolhe os insumos que no pertence a receita do produto que est sendo produzido no Para cada forno, produzido um nico tipo de produto. Quando do carregamento do forno, o mesmo no deve aceitar um insumo que no seja parte da receita do seu produto. Os insumos devem ser carregados com suas respectivas unidades, ex: Kg, m3. O administrador no pode carregar o forno, apenas o operador. Cada forno est residente em uma unidade de fabricao. No momento da carga do forno, o usurio deve ser identificado.

forno.

6. Pr-Condies

produto.

Haver um cadastro de fornos, de insumos, de produtos, de silos e receita para produo de um O operador deve ter sido identificado no sistema para realizar as cargas dos insumos. Escolher um forno, um produto e os insumos contidos na receita para a produo do produto.

7. Ps-Condies

O sistema dever registrar o log das transaes de carga do forno. O sistema deve registrar as informaes de data, hora, insumo, operador, silo e forno quando da carga dos fornos.

O modelo de casos de uso exemplificado na Tabela 1 foi baseado na proposta de Jacobson (Jacobson et al 1992), a qual considera esse item o centro do processo

de desenvolvimento de software. Porm outras abordagens, considerando especificamente os modelos de casos de uso, encontradas nas literaturas fornecem algumas diretrizes que ajudam a sua construo, mas elas no so escritas de uma forma procedimental tal que a experincia e a subjetividade do projetista interfiram o mnimo possvel. Por isso, foi incorporada a tcnica de leitura TUCCA (Technique for Use Case model construction and Constructionbased requirements document Analysis) (Belgano et al, 2005), que tem o objetivo principal de auxiliar a construo de casos de uso, fornecendo procedimentos mais sistemticos que direcionem a modelagem e permitam que o modelo construdo no apresente tanta variao se desenvolvido por pessoas diferentes.

Figura 6. Domnio Conceitual da Aplicao.

De acordo com (Barreto, 2005), a engenharia de domnio de uma aplicao visa suportar a automao, e foca na anlise do domnio conceitual da aplicao para extrair o mximo de informao dos experts do domnio. A partir das informaes contidas nas descries dos casos de uso e documento de requisitos do sistema (Tabela 1), foi construdo o domnio conceitual da aplicao, apresentado na Figura 6. A utilizao da linguagem UML para representao dos conceitos e seus relacionamentos apenas ilustrativa. Neste trabalho, o processo utilizado a criao de uma ontologia de domnio transformado-a em um modelo UML, aps a verificao dos seus conceitos. Durante a construo da ontologia do sistema de abastecimento foram criados: os conceitos, que so as classes representadas no modelo de domnio; as propriedades dos conceitos que representam os seus atributos; os axiomas que so as regras de negcio encontradas nos casos de usos. Todos os elementos encontrados e usados na criao da ontologia esto na Tabela 2.

Tabela 2. Elementos da ontologia de domnio.

Classes Usurio Propriedades Nome Senha Matrcula Online Operador Nome Senha Administrador Nome Senha Forno Descrio Produto Fbrica Receita 1- Para cada forno, produzido um carregado nico tipo de produto. operador. por um um usurio Carrega um forno um usurio Axiomas Relacionamentos

2- Quando do carregamento do forno, o Produz um produto. mesmo no deve aceitar um insumo que no seja parte da receita do seu Utiliza uma receita. produto. 3- Os insumos devem ser carregados com suas respectivas unidades, ex: Kg, m3. 4 - O administrador no pode abastecer o forno, apenas o operador. 5 - Cada forno est residente em uma unidade de fabricao. 6 - No momento da carga do forno, o usurio deve ser identificado.

Produto

Descrio Receita Forno

Possui uma receita. produzido em um forno.

Receita

Descrio Insumos Produto

1 Uma receita insumo.

possui ao menos 1 possuda por um produto. Possui insumos

Silo

Nmero Insumo

1- Um silo s pode armazenar um tipo Armazena um insumo. de insumo. armazenado em um silo. Est contido em uma receita.

Insumo

Descrio Unidade Quantidade Receita

A construo da ontologia fornece uma capacidade de verificao formal de um modelo independente de plataforma. Uma vez que as ferramentas UML so construdas baseadas no metamodelo UML (OMG, 2003) e no possuem capacidade de inferir os conceitos contidos nos diagramas de classes a um reasoner (e.g. Racer). Para a construo do software de abastecimento de fornos foram verificados os conceitos com relao a sua herana, no caso dos conceitos operador e administrador serem subconceitos de usurio. Os relacionamentos entre os conceitos descritos na Tabela 1 e a satisfatibilidade dos conceitos, uma das atividades principais deste trabalho. Deste modo, a verificao formal ir

garantir que o modelo independente de plataforma adere aos requisitos funcionais do software.

Figura 7. Ontologia criada no editor de ontologias Protg.

A Figura 7 mostra a criao da ontologia de domnio na ferramenta de edio de ontologia protg (Protg, 2008). A esquerda foram criados os conceitos baseados nas informaes dos elementos contidos na Tabela 2. Para a criao de uma ontologia, segundo (Santos et al, 2005) preciso primeiro definir os indivduos. Neste trabalho os objetos da vida real, mostrados em fotos e coletados em documentos ajudaram na obteno das informaes sobre os indivduos. As caractersticas de cada indivduo formam os seus atributos ou propriedades. No editor de ontologia, as propriedades formam os relacionamentos entre os conceitos, onde cada propriedade deve ter o domnio e a sua abrangncia (Santos et al, 2005). Entre os tipos de propriedades que podem ser criadas no protg, as propriedades funcionais e inversamente funcionais podem representar claramente os relacionamentos entre as classes do domnio (Tabela 2). possvel notar as propriedades criadas no editor de ontologias que significam os relacionamentos entre os conceitos do domnio na Figura 6. Tambm foram criados os inversos (e.g. Operador carrega forno, forno carregado pelo operador). Embora o protg seja o editor mais utilizado para a construo de um modelo de domnio baseado em classes e objetos (indivduos), ainda preciso definir os comportamentos em um modelo UML, pois esses no fazem parte de uma ontologia. Alm das propriedades objetos j comentadas, as propriedades de tipos de dados podem representar os atributos das classes (Tabela 2).

Figura 8. Propriedades da Ontologia.

Aps a criao da ontologia, feita a identificao dos pontos de variabilidade do domnio. Em Bragana (Bragana, 2007) foram apresentadas diversas tcnicas para capturar e representar os pontos de variabilidade e reus-los em linhas de produtos de software (e.g. RSEB, FODA, CODA e OCA). Estas tcnicas no apresentam a relao da captura e a representao de pontos de variabilidades dentro de um domnio conceitual construdo a partir de uma ontologia, mais ajudam na definio dos que seriam os pontos de variabilidade encontrados tanto dentro do domnio conceitual quanto fora dele. Para a representao dos pontos de variabilidade externos em uma linha de produtos de software, salutar a criao de diversas arquiteturas, de acordo com a proposta e requisitos do software. No caso do sistema de abastecimento de fornos, vrios pontos de variabilidade externos so pragmticos (e.g. tipo de hardware CLP, utilizao de drivers, bibliotecas, APIs entre outros) e por delimitao de espao e tempo no foram abordados nessa dissertao. A criao dos pontos de variabilidade internos ao domnio podem ser representados pelos conceitos e sub-conceitos, as propriedades dos tipos objetos e dados e as restries que representam as regras de negcio. Neste caso, todos os pontos devero variar de acordo com o modelo especfico de plataforma. A verificao formal do domnio da aplicao utiliza a Description Logic ou Lgica de Descries. A proposta deste mtodo como uma representao do conhecimento a possibilidade de se utilizar sistemas de raciocnio (Santos et al, 2005) para inferir sobre um dado conhecimento. O sistema de raciocnio ou

reasoner utilizado neste trabalho foi o Racer (Haarslev et al, 2004). O Racer implementa o clculo SHIQ (Horrocks et al, 1999), um mtodo de tableux para Lgica de Descrio. A lgica SHIQ composta de conceito atmico, conceito universal, conceito base, negao atmica, interseo de conceitos, quantificao universal, quantificao existencial limitada, negao, restrio de nmeros, regras hierrquicas, regras de inverso e regras de transitividade. Essas regras facilitam a verificao dos conceitos criados no editor de ontologia. A criao de instncias permite a verificao da checagem de inconsistncias durante a criao de um conceito. A Figura 9 exibe um exemplo de um ABox para o TBox insumo, onde duas instncias foram criadas. Se o motor de inferncia permite a criao da instncia ento o conceito insumo est satisfeito. Logo, todo o processo de verificao formal comeou pela criao de instncias de todos os conceitos do domnio da aplicao. Para a verificao das inconsistncias.

Figura 9. A Criao de Instncias para Verificao Formal dos Conceitos.

A criao de instncias tambm pode servir para provar que os conceitos e seus relacionamentos esto corretos. Na Figura 9 possvel notar a criao das instncias Cromita e Cromo, que so dois tipos de insumos usados na fabricao de uma liga. Neste exemplo foram criados dois conceitos: insumo e receita, onde um insumo est contido em uma receita de um produto. Alm das verificaes de instncias, possvel verificar as restries que formam as regras de negcio (Tabela 2). A linguagem axiomtica PAL (Protg Axiomatic Language), permite a insero de restries e axiomas que incidem sobre as classes e instncias de uma ou mais ontologias (Noy et al, 2000). As regras transcritas da Tabela 2 para a linguagem PAL podem ser vistas na Tabela 3.

Durante a construo das restries so feitas associaes das propriedades e valores que podem ser um conceito ou um dado. De acordo com os tipos de restries suportados. Quando da verificao das regras, aplicado o mtodo de tableux (Horrocks et al, 1999). Para inici-lo criado um ABox genrico. Nele so aplicadas as regras referentes a lgica SHIQ para tentar obter um novo ABox at quando no se pode aplicar mais alguma regra. As regras que faziam aluso a algum tipo de cardinalidade foram representadas usando os smbolos pertinentes (e.g. min ou >=, max ou <= e exactly ou =). Regras que semanticamente revelam uma forte referncia aos conceitos encontrados no domnio foram separadas com base nas propriedades objeto. Assim, foram criadas todas as restries necessrias entre os relacionamentos dos conceitos. Tabela 3. Regras de negcio transcritas para a Protg Axiomatic Language.
Regras PAL 1- Para cada forno, produzido um nico tipo de Possui_um_Forno min 1 produto. 2- Quando do carregamento do forno, o mesmo Produz_um_Produto exactly 1 no deve aceitar um insumo que no seja parte da Possui_uma_Receita exactly 1 receita do seu produto. Possui_uma_Receita only Receita 3- Os insumos devem ser carregados com suas Possui_uma_Unidade exactly 1 respectivas unidades, ex: Kg, m3. 4 - O administrador no pode abastecer o forno, E_Carregado_por_Operador only Operador apenas o operador. Not (Carrega_Forno some Forno) 5 - Cada forno est residente em uma unidade de Possui_um_Forno max 1 fabricao. 6 - No momento da carga do forno, o usurio deve A regra 4 j contempla o requisito. ser identificado. 7 Uma receita possui ao menos 1 insumo. Possui_Insumos some Insumo E_Armazenado_no_Silo max 1 8- Um silo s pode armazenar um tipo de insumo.

Na Tabela 3 tambm so exibidas restries do tipo some ou alguns valores de e only apenas valores de que so quantificadores existenciais. Com o uso do protg, a utilizao desse tipo de lgica para formalizao dos conceitos tornouse fcil. ocultada toda a complexidade para escrever as provas formais de conceitos proposta na lgica SHIQ (Horrocks et al, 1999) que utilizada no motor de inferncias Racer (Haarslev et al, 2004).

5 Concluso
Com o aumento da exigncia na fabricao de software, vem crescendo a conscincia da satisfao dos clientes e a necessidade da construo de produtos com qualidade e com o menor custo. A engenharia de domnio, bem como, outras tcnicas visam a reutilizao para agilizar a construo do software, com maior confiabilidade e tendo como conseqncia um menor custo. O enfoque de linha de

produto pode ser visto como uma forma de organizao dessas tcnicas, onde o seu ponto mais importante a anlise dos pontos de variabilidade para o reuso de domnios de aplicao. A modelagem de um domnio de aplicao com uma aproximao ontologia, permite utilizar-se de mecanismos para abstrair paradigmas (e.g. POO, POA, POM). Algumas linhas de produtos de software j esto utilizando a criao de modelos em nveis de abstraes diferentes para facilitar a manuteno de domnios conceituais de aplicao e a gerao automtica destes em plataformas especficas (Silva e Pezzin, 2006). Isso porque a semntica de um domnio especfico de aplicao muda constantemente, principalmente em funo dos requisitos de software estabelecidos pelos stakeholders em diferentes empresas. Construir um software, usando modelos de processos mais uma tentativa de diminuir o tempo total de produo, porm no o bastante. A ontologia, neste caso, pode representar melhor um conceito, e utilizando a MDA (Silva e Barreto, 2008), gerar modelos corretos para plataformas especficas. Os axiomas contidos no arquivo OWL, que representam as regras de negcio do domnio conceitual da aplicao formalizado, podem ser separados e implementados em um modelo especfico de plataforma usando a MDA e uma linguagem de programao orientada a aspectos (Silva e Barreto, 2008). Em um outro trabalho tambm foi proposta a ferramenta OWLtoAspectJ (Silva, 2008) para tratar a transformao automtica de regras de negcio em aspectos utilizando um modelo especfico de plataforma com base na extenso da UML e composio de modelos para execuo das regras de negcio em runtime.

6 Referncias
Agile Modeling (2008). Agile Modeling. http://www.agilemodeling.com. Maro. Barreto, L. P.. (2005) Engenharia de Domnio aplicada ao Desenvolvimento Robusto e Eficiente de Sistemas Operacionais. In: Simpsio Brasileiro de Engenharia de Software, Uberlndia. Belgano, A., Fabbri, S.. (2005) TUCCA: Tcnica de Leitura para apoiar a Construo de Modelos de Casos de Uso e a Anlise de Documentos de Requisitos. Simpsio Brasileio de Engenharia de Software SBES, Uberlndia, 2005. Booch, G., Jacobson, I., Rumbaugh, J (1999). Unified Modeling Language Users Guide. Addison-Wesley. Bragana, A. Methodological Approaches and Techniques for Model Driven Development of Software Product Lines. Tese de Doutorado, Universidade do Minho, Portugal, 2007, P.15-65. Clements, P., Northrop, L. (2001) Software Product Lines: Practices and Patterns, SEI Series in Software Engineering, Addison-Wesley. 563 p..

Extreme Program (2008). Extreme Program. http://extremeprogramming.org. Acessado em maro de 2008. Gimenes, I. M. ; Travassos, G. H.. (2002) O enfoque de Linha de Produto para Desenvolvimento de Software. In: Sociedade Brasileira de Computao; Ingrid Jansch Porto. (Org.). XXI JAI - Livro Texto. Florianopolis: Sociedade Brasileira de Computao, v. 2, p. 1-32. Gurp, J.v.. (2003) On the Design & Preservation of Software Systems, PhD dissertation, Computer Science Department, University of Groningen, Groningen. Haarslev, V., Muller, R.. Racers User Guide and Reference Manual 1.7.19, 2004. Horrocks, I., Sattler, U., Tobies, S.. Reasoning with Individuals for the Description Logics SHIQ. Proc. of the 17th Int. Conf. on Automated Deduction (CADE 2000), volume 1831 of Lecture Notes in Computer Science, pages 482496. Springer, 2000. Jacobson, I, et al. Object-Oriented Software Engineering A Use Case Driven Approach. Addison-Wesley Publish Company, 1992. MDR."Metadata Repository".http://mdr.netbeans.org/. Acessado em maro de 2008. Mellor, J. Stephen et al (2003). MDA Destilada: Princpios da Arquitetura Orientada por Modelos. Editora Cincia Moderna Ltda., p. 15-169. Noy, N., Fergerson, R., Musen., M. 2000. The knowledge model of Protege-2000: Combining interoperability and flexibility. 2th International Conference on Knowledge Engineering and Knowledge Management (EKAW'2000), Juan-lesPins, France. OMG. Software Process Engineering Metamodel Management Group. Janeiro de 2005, Verso 1.1. Specification. Object

OMG. Object Management Group (2003). Ontology Definition Metamodel Third Revised Submission to OMG/ RFP ad/2003-03-40. Reinoso, G. B., Heuser, C. A.. Particionamento e Agregao Estruturais na Anlise Orientada a Objetos. Publicado como Trabalho Individual III, T.I. n 412, CPGCC-UFRGS, Porto Alegre (Brasil), 1994. Ribeiro, M.. Raciocnio em Lgica de Descries. Universidade Federal da Bahia, http://twiki.im.ufba.br/bin/view/Residencia/Cursos, Abril, 2005. Santos, D. A., Vieira, Renata, Santana, M. R., Silva, D. M.. (2005) Web Semntica: Ontologias, Lgica de Descries e Inferncias. In: Cesar Augusto Camillo Teixeira; Eduardo Barrre; Iran Calixto Abro. (Org.). Web e Multimdia: Desafios e Solues. 1 ed. Porto Alegre: SBC, v. 1, p. 127-165. Silva, J. B., Pezzin J. (2006). Usando Ontologias na Construo de Modelos MDA (Model-driven Architecture). IX Frum de Tecnologia e XVI Seminrio Regional de Informtica 2006, Santo ngelo.

Silva, J. B., Pezzin J. (2007). The formal verification of an application conceptual models using MDA and OWL. World Congress on Engineering and Computer Science WCECS 2007, San Francisco. Silva, J. B., Saba, H. (2008). Modelagem das reas de Processo do CMMI usando uma metodologia de BPM e notaes do SPEM. 34 Congresso Infobrasil TI & Telecom 2008, Fortaleza. Silva, J. B., Barreto, L.P.. (2008). Separao e Validao de Regras de Negcio MDA Atravs de Ontologias e Orientao Aspectos. Simpsio Brasileiro de Componentes, Arquitetura e Reuso de Software 2008, Porto Alegre. Silva, J. B.. (2008). OWLtoASPECTJ: Uma Ferramenta para Transformao de Regras Conceituais de Domnio em Aspectos. Seminrio de Pesquisa em Ontologia no Brasil 2008, Niteri. Sun. Sun Microsystems (2008). Java Technology. http://www.java.sun.com. Abril. Weiss, D., et al.. (1999) Software Product-Line Engineering: a family-based software development process. (S.l): Ed. Addison Wesley. 426 p. Wood, J. Silver,D.. "Joint Application Development". 2 Edio, John Wiley & Sons Inc, ISBN 0-47104-299-4, 1995. Yourdon, E. "Anlise Estruturada Moderna", ELSEVIER, ISBN 8570016158,1992.