SBSI 2015 Anais Minicursos

of 38 /38

description

Anais do SBSI 2015

Transcript of SBSI 2015 Anais Minicursos

  • XI Simposio Brasileiro de Sistemas de Informacao

    Sistemas de Informacao:A Visao Sociotecnica da Computacao

    26 a 29 de Maio de 2015Goiania - GO - Brasil

    ANAIS

    Minicursos SBSI 2015

    Vol. 4

  • Publicado por:Instituto de Informatica (INF)Universidade Federal de Goias (UFG)http://www.inf.ufg.br/sbsi2015

    Creditos:Capa: Ascom/UFGDiagramacao: Sergio Teixeira de Carvalho, Gustavo Teodoro Laureano.

  • Dados Internacionais de Catalogao na Publicao (CIP) GPT/BC/UFG

    S612a

    Simpsio Brasileiro de Sistemas de Informao (20. : 2015 : Goinia, GO) Anais [do] XX Simpsio Brasileiro de Sistemas de Informao [recurso eletrnico] / coordenao do Comit de Programa: Sean Wolfgand Matsui Siqueira, Srgio Teixeira de Carvalho ; coordena- o geral: Vincius Sebba Patto, Valdemar Vicente Graciano Neto ; realizao: UFG/Instituto de Informtica ; promoo: Sociedade Brasileira de Computao. Goinia : UFG, Instituto de Informti- ca, 2015.

    Tema central: Sistemas de informao: uma viso sociotcnica da computao. Contedo: v.1. Trilhas tcnicas. v.2. Workshop de iniciao cientfica em sistemas de informao (II WICSI). v.3. Workshop de teses e dissertaes em sistemas de informao (VIII WTDSI). v.4. Minicursos. Disponvel em:

    1. Sistemas de recuperao da informao Congressos. 2. Tecnologia Servios de informao Congressos. 3. Internet na administrao pblica Congressos. I. Siqueira, Sean Wolfgand Matsui . II. Carvalho, Srgio Teixeira de. III. Patto,Vincius Sebba. IV. Graciano Neto, Valdemar Vicente. V. Universidade Federal de Gois. Instituto de Informtica. VI. Sociedade Brasileira de Com-putao. VII. Ttulo. VIII. Ttulo: Sistemas de informao: uma viso sociotcnica da computao.

    CDU: 004.65

  • XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    II WICSIMinicursos do XI Simposio Brasileiro de Sistemas de InformacaoSistemas de Informacao: A Visao Sociotecnica da Computacao26 a 29 de Maio de 2015Goiania, Goias, Brasil.

    Comites

    Coordenacao Geral do SBSI 2015:Vincius Sebba Pato (UFG)Valdemar Vicente Graciano Neto (UFG)

    Coordenacao do Comite de Programa de Minicursos do SBSI 2015:Clodis Boscarioli (UNIOESTE)Gustavo Teodoro Laureano (UFG)

    Comite do Programa Cientfico:Adolfo Duran (UFB)Alexandre Cidral (UNIVILLE)Carla Merkle Westphall (UFSC)Carla Geovana do Nascimento Macario (EMBRAPA)Carlos Eduardo Santos Pires (UFCG)Celia Ghedini Ralha (UnB)Claudia Cappelli (UNIRIO)Clodis Boscarioli (UNIOESTE)Cristiano Maciel (UFMT)Daniel dos Santos Kaster (UEL)Daniela Barreiro Claro (UFBA)Debora Paiva (UFMS)Denis Silva da Silveira (UFPE)Elvis Fusco (UNIVEM)Fatima de Lourdes dos Santos Nunes Marques (USP)Fernando Braz (IFC)Flavia Maria Santoro (UNIRIO)Flavio Soares Correa da Silva (USP)Geiza M. Hamazaki da Silva (UNIRIO)Glauco Carneiro (UNIFACS)Gustavo Teodoro Laureano (UFG)Jose Maria David (UFJF)Juliano Lopes de Oliveira (UFG)Las do Nascimento Salvador (UFBA)Leonardo Azevedo (UNIRIO)Leticia Mara Peres (UFPR)Luciano Antonio Digiampietri (USP)Lucineia Heloisa Thom (UFRGS)Marcelo Fantinato (USP)Marcos Chaim (USP)Maria Istela Cagnin (UFMS)Marcio Barros (UNIRIO)Morganna Diniz (UNIRIO)Patrcia Vilain (UFSC)

    iv

  • XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    Regina Maria Maciel Braga (UFJF)Rejane Frozza (UNISC)Rita Suzana Pitangueira Maciel (UFBA)Roberto Pereira (UNICAMP)Sidney Lucena (UNIRIO)Thais Vasconcelos Batista (UFRN)

    v

  • XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    vi

  • XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    RealizacaoINF/UFG Instituto de Informatica/ Universidade Federal de Goias

    PromocaoSociedade Brasileira de Computacao (SBC)

    ApoioSECTEC-GO Secretaria de Ciencia, Tecnologia e Inovacao do Estado de Goias

    Patrocnio InstitucionalFAPEG Fundacao de Amparo a` Pesquisa do Estado de GoiasCAPES Coordenacao de Aperfeicoamento de Pessoal de Nvel Superior

    vii

  • XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    viii

  • XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    Apresentacao

    Os Minicursos do Simposio Brasileiro de Sistemas de Informacao (SBSI) visam propiciar a experiencia e

    discussao de assuntos de amplo interesse da comunidade de Sistemas de Informacao a partir de cursos

    de curta duracao de uma forma pratica e didatica. Nesta decima primeira edicao do SBSI, o SBSI 2015,

    estao disponveis quatro minicursos, onde os participantes terao a oportunidade de aprender ou aper-

    feicoar seus conhecimentos sobre modelagem de negocio, criacao de starups, padroes e ferramentas no

    desenvolvimento de software para Web semantica e gestao de processos de negocios. Agradecemos a todos

    pelas propostas submetidas; os membros do comite de programa e avaliadores pelo esforco em prol das

    revisoes e pelos comentarios construtivos aos trabalhos; a organizacao geral do evento pelas orientacoes

    e suporte oferecido. Esperamos que o evento seja proveitoso para todos.

    Goiania, 26 de maio de 2015.

    Clodis Boscarioli (UNIOEST) e Gustavo Teodoro Laureano (UFG)

    Coordenadores dos Minicursos do SBSI 2015

    ix

  • XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    Biografia dos Coordenadores do Comite de Programa do SBSI 2015

    Clodis Boscarioli e Professor Adjunto na Universidade Esta-dual do Oeste do Parana, Campus de Cascavel, onde atua desde oano de 2000, no Curso de Ciencia da Computacao. Docente e ori-entador no Programa de Mestrado em Ensino da Universidade Es-tadual do Oeste do Parana, Campus de Foz do Iguacu. Possui gra-duacao em Informatica e especializacao em Ciencia da Computacaopela Universidade Estadual de Ponta Grossa (1996 e 1999, respec-tivamente). E Mestre em Informatica pela Universidade Federal doParana (2002). Doutor em Engenharia Eletrica pela Universidade deSao Paulo (2008), e tambem especialista em Formulacao e Gestaode Polticas Publicas pela Escola de Governo do Parana em parceriacom a Universidade Estadual do Oeste do Parana (2008). E tutordo Grupo PETComp (Programa de Educacao Tutorial em Cienciada Computacao) aprovado pela Sesu/MEC em 2010. Suas areas de

    interesse envolvem, de forma multidisciplinar, Banco de Dados, Interacao Humano-computador, Apren-dizado Computacional, Data Mining, Sistemas de Informacao e Tecnologias Assistivas no Processo deEnsino-Aprendizagem, alem de questoes relacionadas ao Ensino de Computacao. Lder do GIA (Grupode Inteligencia Aplicada) da UNIOESTE e pesquisador colaborador no ICONE-EPUSP. Mais informacoespodem ser obtidas em http://lattes.cnpq.br/2844207318576160.

    Gustavo Teodoro Laureano possui Doutorado e Mestradopelo programa de Engenharia Eletrica da Universidade de SaoPaulo/Escola de Engenharia de Sao Carlos (EESC/USP) na area deProcessamento de Sinais e Instrumentacao e graduacao em Engenha-ria da Computacao pela Pontifcia Universidade Catolica de Goias(PUC-GO). Atualmente e professor do Instituto de Informatica daUniversidade Federal de Goias (INF/UFG). Tem interesse em En-genharia Eletrica/Computacao, com enfase em Processamento deSinais e Visao Computacional, atuando principalmente nos seguin-tes temas: Processamento Digital de Sinais, Processamento Digi-tal de Imagens, Visao Estereo, Calibracao de Cameras e Reco-nhecimento de Padroes. Mais informacoes podem ser obtidas emhttp://lattes.cnpq.br/4418446095942420.

    x

  • XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    MinicursosSessao de Minicursos 13

    13 Criando Startups: Metodos, Processos, Tecnicas e FerramentasRicardo Batista Rodrigues (UFPE)Carlo Marcelo R. da Silva (UFPE)Vinicius Cardoso Garcia (UFPE)Silvio R. L. Meira (UFPE)

    18 Modelagem de Negocio e Derivacao de Requisites com UMLRaul Sidnei Wazlawick (UFSC)

    25 Padroes, ferramentas e boas praticas no desenvolvimento de software para Web SemanticaErnesto Fonseca Veiga (UFG)Marcio V. Oliveira Sena (UFG)Renato de Freitas Bulcao-Neto (UFG)

    32 Social BPM: Processos de Negocio, Colaboracao e Tecnologia SocialRenata Mendes de Araujo (UNIRIO)Andrea Magalhaes Magdaleno (UNIRIO)

    Indice Remissivo 37

    xi

  • XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    xii

  • Alternative Title: Creating Startups: Methods, Processes, Techniques and Tools

    XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    13

  • XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    14

  • XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    15

  • XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    16

  • XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    17

  • Modelagem de Negcio e Derivao de Requisitos com UML

    Raul Sidnei Wazlawick UFSC-CTC-INE

    88040-900 Florianpolis, SC +55(48) 3721-4713

    [email protected]

    RESUMO Este minicurso apresenta uma viso prtica da disciplina Modelagem de Negcio do Processo Unificado (UP) com o uso da Linguagem de Modelagem Unificada (UML). Inicialmente so apresentados os casos de uso de negcio e tcnicas para identifica-los. Em seguida o detalhamento do modelo de negcio feito com diagramas de atividades de negcio e diagramas de mquina de estado para objetos de negcio. Finalmente apresentam-se tcnicas sistemticas para derivar requisitos (casos de uso de alto nvel) a partir dos modelos de negcio. Este minicurso baseia-se nos captulos 2 e 3 do livro Anlise e Design Orientados a Objetos para Sistemas de Informao [1]. Palavras-chave Modelagem de Negcio, Requisitos, Casos de Uso. ABSTRACT This lecture presents a practical approach for the discipline business modeling of the Unified Process (UP) using the Unified Modeling Language (UML). Initially, we present business use cases and a technique to identify them. In the following, the business model is detailed by using business activities and business objects machine state diagrams. Finally, we present systematic techniques to derive requirements (high-level use cases) from the business model. This lecture is based on Chapters 2 and 3 of the book Object-Oriented Analysis and Design for Information Systems [1].

    Categories and Subject Descriptors D.2.1 [Software Engineering]: Requirements/Specifications Elicitation methods.

    General Terms Documentation, Design, Human Factors, Verification.

    Keywords Business Modeling, Requirements, Use Cases.

    1. INTRODUO A fase de concepo do UP consiste em um perodo de tempo no qual os analistas esto procurando obter informaes sobre o negcio a ser automatizado ou reestruturado. Assume-se que o conhecimento que os analistas tm sobre o negcio mnimo e que a interao com os interessados ser intensa. Usualmente, antes de comear a descobrir e analisar os requisitos do sistema, necessrio entender os objetivos da organizao-alvo. Esta viso pode ser obtida pela disciplina do UP chamada modelagem de negcio. A modelagem de negcio uma atividade que suporta a descoberta dos requisitos de sistema porque ajuda a equipe a perceber o contexto mais amplo do negcio no qual o futuro sistema vai operar. Uma vez que o negcio tenha sido razoavelmente entendido e modelado, a anlise de requisitos pode comear. Embora existam vrias abordagens para representar requisitos, este minicurso apresenta uma tcnica baseada em casos de uso de sistema. O caso de uso de sistema um processo individual que identificado a partir das atividades de sistema. Casos de uso de sistema de alto nvel (ou resumidos) representam os requisitos funcionais de mais alto nvel de um sistema. As anotaes nesses casos de uso representam os requisitos no funcionais, ou seja, as restries e as qualidades relacionadas quelas funes. Os requisitos suplementares so requisitos no funcionais que se aplicam ao sistema como um todo no apenas s funes individuais. Eles podem ser representados no documento de especificaes suplementares. A seo 2 apresenta o conceito de caso de uso de negcio e as sees 3 e 4 tratam do detalhamento deste modelo que conseguido com diagramas de atividades de negcio e diagramas de mquina de estados para objetos de negcio, respectivamente. A seo 5 introduz o conceito e casos de uso de sistema e a seo 6 mostra como derivar tais casos de uso a partir do modelo de negcio. A seo 7 mostra como o modelo conceitual preliminar tambm pode ser usado como ferramenta para identificar casos de uso de sistema. A seo 8 discute aspectos relacionados a requisitos de software, especificamente relacionando esses aspectos com os modelos de casos de uso. A seo 9 apresenta as consideraes finais.

    2. CASOS DE USO DE NEGCIO Jacobson [2] apresenta detalhadamente tcnicas para modelagem de negcios com casos de uso de negcio. Em geral, em modelos de negcio, existem entidades (pessoas ou empresas) externas

    Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SBSI 2015, May 2629, 2015, Goinia, Gois, Brazil. Copyright SBC 2015.

    Alternative Title: Business Modeling and Requirements Derivation with UML

    XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    18

  • organizao-alvo, chamadas atores de negcio, e entidades internas chamadas trabalhadores de negcio. Casos de uso de negcio so os processos realizados por esses atores e trabalhadores que permitem que eles atinjam algumas das metas de negcio da organizao. O modelo de caso de uso de negcio considera a organizao inteira como um sistema, e os atores podem ser pessoas, sistemas ou outras organizaes que criam ou mantm relacionamentos de negcios com ela [3]. A quantidade de casos de uso de negcio que sero identificados pode ser relativamente pequena. Um processo de negcio um processo de longo termo que realizado pela empresa; pode-se pensar, por exemplo, em vender produtos, conduzir o marketing, fornecer servios, resolver problemas dos consumidores etc. Cada processo deste tipo pode contribuir para um objetivo de negcio da empresa. Durante a modelagem e o negcio, h dois tipos de atores que podem ser referenciados:

    Atores de negcio: pessoas, organizaes ou mesmo sistemas que executam algumas atividades pertencentes ao processo, mas que no so parte da empresa-alvo. Ou seja, eles no esto sob o controle da organizao. Atores de negcio poderiam ser, por exemplo, clientes, fornecedores, auditores externos, empresas parceiras ou mesmo outros sistemas automatizados com os quais a empresa deve interagir.

    Trabalhadores de negcio: pessoas, organizaes ou mesmo sistemas que realizam atividades que pertencem ao processo e que so parte da empresa-alvo. Poderiam ser os funcionrios da empresa, seus departamentos ou mesmo sistemas de software existentes que pertencem empresa. Eles so usualmente distinguidos dos atores de negcio pelo esteretipo .

    A associao dos casos de uso de negcio com as principais metas de negcio da empresa ajuda a identificar o escopo do sistema, isto , as atividades que sero efetivamente automatizadas no projeto que est sendo iniciado. No exemplo da Figura 1, todos os casos de uso so candidatos a automatizao com diferentes nveis de prioridade. Entretanto, a empresa pode estar interessada apenas em implementar compras e vendas neste momento, deixando o marketing e os servios ao consumidor para um segundo projeto. Nem todo papel de trabalhador de negcio ser usualmente automatizado. Isso depender do escopo do projeto a ser definido. Uma das vantagens de fazer o diagrama de casos de uso de negcio, ento, ajudar na visualizao e na tomada de deciso sobre automatizao. Com o diagrama, possvel visualizar o que deve ficar dentro e fora do escopo de automatizao, dependendo dos objetivos do projeto. O prximo passo na direo da anlise de requisitos o estudo detalhado dos casos de uso de negcio que sero automatizados. O nvel de preciso e detalhe depende dos objetivos do projeto.

    3. ATIVIDADES DE NEGCIO O diagrama de atividades da UML uma opo muito popular para estudar os detalhes de um caso de uso de negcio. Com este diagrama, podem ser especificadas as diferentes atividades realizadas pelos atores e trabalhadores de negcio na direo da meta geral do caso de uso que est sendo informatizado.

    Alternativamente, a Business Process Model and Notation1 (BPMN)2 pode ser usada no lugar dos diagramas de atividade da UML. Porm, a notao UML mais simples e o objetivo aqui no produzir modelos altamente detalhados do negcio da empresa, mas colecionar informaes que possam ajudar a derivar requisitos de alto nvel para futuros sistemas informatizados.

    Figura 1. Exemplo de modelo de casos de uso de negcio. importante lembrar que o objetivo da modelagem de negcio, no contexto da anlise de sistemas, usualmente vislumbrar uma viso geral do negcio, e no efetuar uma especificao detalhada de seus processos. Assim, na maioria dos casos, o objetivo da equipe concentrar-se na descoberta de informaes sobre o negcio, e no na especificao formal do funcionamento do negcio como se este fosse uma mquina. O diagrama de atividades da UML em muitas coisas similar a um fluxograma. Existem atividades sequencialmente ligadas. Pontos de deciso e repetio podem ser usados e mesmo paralelismo pode ser expresso nesses diagramas. Um exemplo pode ser visto na Figura 2, a qual detalha o caso de uso de negcio Vender livros da Figura 1. Mais tarde, os analistas devem examinar em detalhe cada uma das atividades que devem ser realizadas. Se uma dada atividade pertence ao escopo do sistema que vai ser implementado, ento ela ser alvo de uma anlise mais detalhada. Outras opes para detalhar um diagrama de casos de uso de negcio so os diagramas de sequncia e de comunicao da UML. Entretanto, esses diagramas so usados para representar envio de mensagens entre seus elementos. Nem sempre natural encontrar nomes para rotular essas mensagens no caso de um processo de negcio, e nomes genricos como enviar dados e verificar resultado acabam sendo (mal) escolhidos no final. Assim, o diagrama de atividades a escolha mais natural para descrever o que acontece no mundo real, dentro de uma organizao de pessoas.

    1 Anteriormente conhecida como Business Process Modeling

    Notation. 2 Disponvel em: .

    XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    19

  • 4. ASPECTOS DE NEGCIO DEPENDENTES DE ESTADOS Alm dos casos de uso de negcio, que podem ser detalhados por diagramas de atividades, pode ser importante entender outros aspectos de um negcio que nem sempre aparecem claramente nesses diagramas, tais como alguns objetos-chave de negcio que mudam de estado durante seu ciclo de vida.

    Figura 2. Exemplo de diagrama de atividades de negcio. Assim, outro diagrama UML que ajuda a equipe a entender o negcio o diagrama de mquina de estados. Assim como o diagrama de atividades, trata-se de um diagrama comportamental, mas, em vez de modelar atividades em processos, ele representa um conjunto de estados nos quais um ator ou entidade pode estar em um determinado instante. Como um exemplo de como este diagrama pode ser til durante a anlise do negcio, pode-se imaginar que uma equipe est interessada em entender o ciclo de vida de um livro em uma livraria; examinar os diferentes estados de um objeto-chave de negcio pode reduzir o risco de subestimar a complexidade dos requisitos do sistema (ver Figura 3). Quais elementos de negcio merecem a produo de um diagrama de mquina de estados ou de atividade? Salvo melhor juzo, no recomendvel preparar um diagrama para qualquer elemento de negcio porque, se isso for feito, a fase de concepo poder levar muito tempo para ser concluda, e sua objetividade ser prejudicada. O que usualmente necessrio neste ponto um modelo para alguns elementos-chave, de forma que o comportamento seja mais bem compreendido e que seus requisitos possam ser derivados depois. Uma pista para identificar esses elementos-chave perguntar quais so os objetos de negcio. No caso de uma livraria, so os livros, no caso de um hotel, as hospedagens, no caso de um tribunal, os processos, e assim por diante. Assim, esses so os elementos-chave que devem ser modelados em maior detalhe para ajudar a entender o negcio. Qual diagrama deve ser usado atividade ou mquina de estados? Um diagrama de atividades til quando est modelando pessoas, organizaes ou sistemas fazendo coisas. No entanto, um diagrama de mquina de estados til quando uma nica entidade passa por diferentes estados nos quais ela no est

    necessariamente fazendo coisas. Alm disso, o diagrama de atividades usualmente detalha um caso de uso de negcio (ou seja, um processo como vender, comprar, verificar etc.), enquanto o diagrama de mquina de estados usualmente est associado a um objeto de negcio (como livros, pessoas, pedidos etc.).

    Figura 3. Um exemplo de diagrama de mquina de estados para um objeto de negcio. A modelagem de negcio no consiste, entretanto, apenas em construir diagramas. O propsito dos diagramas ajudar a entender o contexto e os requisitos iniciais de um projeto e um sistema. Modelagem de negcio uma das atividades-chave que ajudam a equipe a identificar e se preparar para riscos de projeto. Outras atividades de mitigao de riscos podem tambm ser realizadas durante a concepo, tais como prova de conceito, workshops, prototipao, testes preliminares etc. Qualquer estratgia que ajude a entender o quadro mais amplo e identificar os maiores riscos e complexidades de um projeto so vlidos.

    5. CASOS DE USO DE SISTEMA Casos de uso de sistema diferem dos casos de uso de negcio em alguns aspectos. Por exemplo, atores de negcio podem gastar dias ou mesmo semanas realizando um caso de uso de negcio, enquanto um caso de uso de sistema frequentemente realizado em um perodo de tempo bem mais curto, usualmente em minutos, com um ou poucos atores interagindo com um sistema e obtendo um resultado completo e consistente para pelo menos uma de suas metas. Adicionalmente, casos de uso de sistema devem ser realizados sem interrupes enquanto casos de uso de negcio no tm restries a este respeito. Outra diferena fundamental que o caso de uso de negcio usualmente realizado por vrios atores humanos, enquanto o caso de uso de sistema normalmente realizado por poucos atores humanos (muitas vezes apenas um). O fato que se um caso de uso de sistema vai ser realizado por mais de um ator humano, ento eles devem estar interagindo ao mesmo tempo com o sistema, e esta no a situao mais comum. Usualmente, cada ator humano acessa o sistema no horrio de sua melhor convenincia, verificando os dados e realizando as aes necessrias. Isso leva a uma sequncia de casos de uso de sistema e no a um nico caso de uso, porque um caso de uso de sistema no pode ser interrompido. O diagrama de casos de uso um diagrama UML bastante popular, mas tambm frequentemente mal compreendido. usual ver esses diagramas com dezenas de casos de uso e tambm com alguns de seus fragmentos acoplados. Entretanto, durante a concepo, mais importante saber quais so os principais processos do sistema e no o seu detalhamento. Assim, no se

    XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    20

  • recomenda a presena desses fragmentos no diagrama, nem o uso das associaes include e extend entre casos de uso (as quais, algumas vezes, revelam parte da estrutura interna dos casos de uso). Usualmente, ainda no h informao suficiente para descobrir todos os fragmentos neste momento. Por que deveriam apenas alguns fragmentos dos casos de uso ser mostrados e outros no? Melhor no mostrar nenhum durante a fase de Concepo. Isso evita que o diagrama acabe ficando com um nmero grande de elipses, o que prejudicaria sua compreenso. Assim, deve haver um critrio preciso para decidir quais casos de uso devem ser mantidos no diagrama para evitar, de um lado, um nmero grande de processos excessivamente detalhados, e, por outro lado, um nmero muito pequeno de processos, o que poderia fazer com que caractersticas importantes do sistema no aparecessem. A regra consiste em considerar como caso de uso apenas aqueles processos que podem ser executados isoladamente. Processos parciais que devem necessariamente ser executados durante outros processos no devem ser representados no diagrama de casos de uso de sistema. Os nomes dos casos de uso devem ser escolhidos com cuidado, porque neste estgio eles vo resumir informaes crticas sobre o sistema e escolhas erradas podem dificultar que os interessados tenham uma compreenso comum sobre a real inteno dos atores e trabalhadores de negcio. Blain3 apresenta algumas das melhores prticas coletadas de vrias fontes. Segundo ele, bons nomes de casos de uso:

    Refletem objetivos do usurio. Nomes tais como Acessar sistema ou Abrir janela principal devem ser evitados, porque eles refletem tecnologia e no um objetivo de negcio.

    So os mais curtos possveis. Embora algumas pessoas possam propor que o nome de um caso de uso no deva ter mais do que duas ou trs palavras (ou qualquer outro nmero), no vivel definir um limite como esse, porque existe o risco de perder a clareza sobre o objetivo de negcio se o nome for curto demais.

    Tm verbos significativos. Um verbo no significativo um que no deixa claro qual o objetivo que o caso de uso realiza; por exemplo, o que um caso de uso como Processar pedido realiza? Que resultado ele produz? J um nome como Separar produtos para entrega seria mais significativo neste caso.

    Tm voz ativa. Como na escrita em geral, a voz ativa prefervel voz passiva. Pagar pedido melhor do que O pedido pago.

    Esto no infinitivo. O infinitivo indica o que o usurio est tentando fazer. Usar o tempo verbal no passado ou no futuro pode ser confuso e desnecessrio.

    No identificam o ator. Como os casos de uso so ligados aos atores, seus nomes no fazem parte do nome dos casos de uso.

    So consistentes. As mesmas convenes de regra de nomeao devem ser aplicadas a todo o projeto ou grupo de projetos.

    3 Disponvel em: .

    Probasco [4] tambm insiste que o significado de um nome de caso de uso deve ser preciso. Por exemplo, Leilo um bom nome para um caso de uso? No seria melhor usar um verbo como em Executar leilo? O verbo executar provavelmente seria a escolha de um programador, mas ele provavelmente no teria nenhum significado para um leiloeiro (o leilo vai ser colocado no paredo e fuzilado?). Neste caso, a ideia seria conversar com um especialista de domnio e obter um nome melhor. No entanto, mesmo o nome Leiloar no suficientemente claro. Vai ser leiloado um nico item ou um lote de itens? Ou ainda simplesmente um participante do leilo dando um lance? Neste caso, nomes como Leiloar lote de itens, Leiloar item ou Apresentar lance seriam mais claros.

    6. DERIVANDO CASOS DE USO DE SISTEMA A PARTIR DE UM MODELO DE NEGCIO Para descobrir casos de uso e atores de sistema, a equipe pode examinar o diagrama de casos de uso de negcio com a fronteira de automao definida (escopo de automao). Primeiramente, os atores que esto realmente interessados nos processos a serem automatizados devem ser identificados. Eles so os atores de negcio que interagem com casos de uso de negcio que estejam dentro do escopo de automao, e os trabalhadores de negcio que interagem com tais casos de uso mas que no estejam eles prprios dentro do escopo de automatizao. Trabalhadores de negcio cujas funes sero parcial ou totalmente automatizadas pelo sistema sero importantes fontes de informao, porque saber como eles realizam seus deveres atualmente pode ser crucial para entender como o sistema deve funcionar. Mais do que isso, saber como eles realmente executam seu trabalho pode ser valioso porque algumas vezes a prtica diferente do que est escrito nos livros de procedimento. Outra fonte de requisitos so os atores de negcio que se tornaro atores de sistema. Entretanto, eles nem sempre estaro disponveis para eliciao de requisitos e, nesse caso, eles devem ser substitudos por especialistas de domnio. Por exemplo, pode no ser possvel entrevistar o cliente de uma loja que ainda no exista. Assim, algum que entenda do negcio e possa explicar como se espera que ele funcione ser uma pessoa chave para obter os requisitos corretos. Uma vez que os atores de sistema tenham sido identificados a partir dos casos de uso de negcio, ser possvel observar os diagramas de atividade e de mquina de estados que foram produzidos durante a modelagem de negcio para verificar quais atividades realizadas por estes podem ser consideradas como casos de uso de sistema. Para identificar casos de uso de sistema nos diagramas de atividade como o da Figura 2, algumas consideraes devem ser feitas. As atividades conectadas por um fluxo devem ocorrer de forma imediata ou podem ocorrer em momentos diferentes? Elas devem ocorrer em uma nica sesso de uso do sistema ou elas podem ser realizadas em momentos diferentes? A resposta depender da forma como o negcio organizado, isto , depender das regras de negcio. Se a empresa decidir, por exemplo, que um pedido s recebido depois que o pagamento feito, ento essas atividades formam um nico caso de uso. Entretanto, se a empresa decidir que possvel registrar um pedido (salvar carrinho de compras) e pagar por ele em outro dia, ento existem dois casos de uso distintos.

    XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    21

  • As atividades selecionadas so completas e consistentes? Por exemplo, Enviar livros uma boa descrio para a atividade realizada pela editora? Pode-se descobrir que a editora vai receber um pedido e que ento vai enviar os livros em estoque. Entretanto, o pagamento na relao entre empresas normalmente no feito imediatamente uma fatura gerada e paga pela livraria em um prazo predefinido (por exemplo, 30 dias aps a compra). Assim, essa atividade deveria ser complementada com mais detalhes. O diagrama de mquina de estados como o apresentado na Figura 3, tambm particularmente til em termos dos casos de uso de sistema que precisam ser analisados. Cada mudana de estado em um livro (principal objeto de negcio) deve ser feita por algum, e este algum um ator que executa o caso de uso. Assim, a partir das transies daquele diagrama, um novo conjunto de casos de uso de sistema pode ser descoberto, conforme mostrado na Figura 4. Uma das decises mais difceis do analista resolver qual o tamanho de seus casos de uso: muitos casos de uso pequenos ou poucos casos de uso grandes? As prximas subsees apresentam alguns critrios para ajudar a escolher a melhor granularidade para casos de uso de sistema.

    Figura 4. Casos de uso que podem ser derivados a partir do diagrama de mquina de estados da Figura 2. 6.1 Sesso Indivisvel Um bom caso de uso deve ser realizado em uma sesso indivisvel de uso do sistema4. Isso significa que ele deveria iniciar e terminar sem sofrer interrupo. Por exemplo, o registro de um pedido poderia ocorrer durante uma nica sesso de uso do sistema, envolvendo a identificao de um cliente, a seleo de livros, a visualizao de preos, o pagamento, a seleo de endereo para

    4 Esta ideia segue a definio de um EBP (Elementary Business

    Process Processo Elementar de Negcio) de Larman [5]. A definio de um EBP vem da rea de engenharia de processo de negcio: uma tarefa realizada por uma pessoa em um lugar em um tempo em resposta a um evento de negcio, a qual adiciona um valor mensurvel ao negcio e deixa os dados em um estado consistente.

    entrega etc. Cada um desses aspectos um requisito funcional do sistema. 6.2 Interativo Um caso de uso deve ser interativo, o que significa que deve existir um ator para interagir com o sistema. Processos internos do sistema no so casos de uso, no importa quo complexos sejam. No entanto, uma simples consulta sobre a informao pode ser um caso de uso se ela for feita por um ator. 6.3 Resultado Consistente Um caso de uso deve produzir um resultado consistente, seja uma entrada completa ou transformao em uma pea de informao, ou simplesmente uma consulta na qual informao relevante passada para o usurio. Um caso de uso no pode deixar a informao inconsistente ao seu final. Por exemplo, o registro de um pedido no pode ser concludo sem que o comprador e os livros que ele deseja tenham sido identificados, caso contrrio, a informao sobre o pedido estar incompleta em relao s regras do negcio; a livraria no pode reiniciar o pedido ou cobrar por ele sem saber quem o comprador e quais so os livros solicitados. 6.4 Essencial Dois estilos para escrita de casos de uso podem ser identificados:

    Casos de uso essenciais, que no mencionam tecnologia de interface.

    Casos de uso concretos (ou reais), que so especificamente escritos para uma dada tecnologia de interface.

    Durante a eliciao e a anlise de requisitos, casos de uso de sistema so considerados requisitos, no design. um erro comum incluir entre estes casos de uso aes que so puramente relacionadas com alguma tecnologia de interface (como Abrir janela principal, Imprimir relatrio ou Login). Ambler [6] aponta que modelos essenciais so mais flexveis, deixando mais opes em aberto, e que so mais capazes de acomodar mudanas na tecnologia. Ele tambm afirma que os modelos essenciais so mais robustos do que as representaes concretas porque eles mais provavelmente permanecero vlidos caso haja alguma mudana na tecnologia de implementao. Assim, casos de uso essenciais devem ser considerados a melhor opo durante a fase de eliciao de requisitos, embora detalhes ou opes tecnolgicas possam ser anotados para permitir anlise de esforo e gerenciamento de risco. 6.5 Alto Nvel Durante a concepo, casos de uso so usualmente resumidos ou de alto nvel, o que significa que sua descrio se d apenas pelo seu nome ou em alguns casos por uma ou duas frases. Entretanto, esta no a nica forma pela qual um caso de uso pode ser descrito. Mais tarde, eles sero expandidos para conter mais detalhes sobre os requisitos. 7. MODELO CONCEITUAL PRELIMINAR O modelo conceitual preliminar construdo durante a fase de concepo e consiste de um diagrama que representa as principais unidades de informao do sistema. Ainda no necessrio representar atributos. Embora as associaes possam aparecer no modelo, ainda no necessrio tambm detalhar suas caractersticas.

    XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    22

  • Com a anlise do diagrama de casos de uso de sistema, vrios conceitos importantes podem ser descobertos. Esses conceitos so representados como classes no modelo conceitual preliminar: eles representam a estrutura da informao que ser gerenciada pelo sistema. Ao mesmo tempo, um analista que observe o modelo conceitual poder perceber se o diagrama de casos de uso suficientemente completo. Essa verificao usualmente ocorre quando novas entidades so identificadas em um processo de negcio e se torna necessrio que elas sejam de alguma forma registradas pelo sistema. Existe ainda mais uma utilidade prtica importante para o modelo conceitual preliminar. Entre os conceitos mostrados, a maior parte so elementos de informao criados ou alterados no contexto dos casos de uso j identificados. Entretanto, alguns destes conceitos no so nem criados nem alterados nestes casos de uso e isso significa que alguns casos de uso ainda podem estar faltando. Este o caso especialmente com as classes Livro, Editora e Cliente na Figura 5. Esses conceitos podem ser considerados como CRUD, porque eles permitem as quatro operaes clssicas: Create, Retrieve, Update e Delete5. Se elas vo ser adicionadas ao diagrama, em vez de represent-las individualmente, ser melhor representar as quatro operaes como um nico caso de uso CRUD, que estereotipado com .

    Figura 5. Um exemplo de modelo conceitual preliminar. 8. REQUISITOS A eliciao e a anlise de requisitos consistem em uma parte significativa da fase de concepo. A equipe pode e deve usar todas as fontes disponveis para identificar requisitos (especialistas, usurios, documentos, interfaces, literatura etc.) e, para cada fonte, um conjunto de funes que o sistema deve realizar pode ser identificado. No entanto, durante a eliciao de requisitos, o analista pode encontrar regras de negcio ou restries sobre como as funes devem ser realizadas pelo sistema. Por exemplo, uma regra de negcio poderia estabelecer que a livraria apenas enviasse livros aps a confirmao do pagamento. Este tipo de regra um 5 Inserir, consultar, atualizar e remover, respectivamente.

    requisito no funcional que pode ser registrado como uma anotao ou comentrio no prprio caso de uso, para que possa ser lembrada e verificada quando o caso de uso for expandido. O tempo usado para eliciao de requisitos deve ser gasto com descoberta, no com inveno. Durante este perodo, a equipe de analistas, com os clientes, usurios e outros interessados, deve tentar listar a maioria das capacidades e restries sem preocupao em detalh-las. Detalhes sobre requisitos sero convenientemente acomodados nas prximas iteraes. Deve ficar claro tambm que requisitos so algo que o cliente pediu, e no algo que a equipe projeta. Alguns analistas podem confundir coleta de requisitos isto , a memria das demandas do cliente com um design de sistema preliminar. O analista deve procurar os requisitos que correspondem s necessidades e objetivos do cliente em termos de informao. Requisitos suplementares so todo tipo de restries ou qualidades relacionadas ao sistema como um todo e no apenas a funes individuais. Por exemplo, um requisito suplementar pode estabelecer que o sistema deve ser compatvel com um determinado banco de dados legado, ou ser implementado com uma determinada linguagem de programao, ou, ainda, seguir um determinado design de interface (look and feel). Deve-se tomar cuidado com a definio dos requisitos no funcionais e suplementares. Um requisito como o sistema deve ser fcil de usar no suficientemente claro. Seria melhor dizer que um usurio novo deve ser capaz de completar as tarefas sem erro na primeira tentativa. Isso d uma ideia mais precisa sobre o que deve ser projetado para atender ao requisito. Requisitos no funcionais e suplementares tambm podem ser identificados em diferentes grupos, tais como, por exemplo, interface, implementao, desempenho, tolerncia a falhas etc. O objetivo de fazer tais distines est em permitir uma organizao mais adequada. Embora a maioria dos praticantes do UP possa escolher o sistema de classificao FURPS+ [7], para organizar requisitos suplementares, uma fonte mais atualizada para a classificao de tais requisitos por grupos de qualidade a norma ISO/IEC 250106. A Tabela 1 mostra as subcaractersticas e algumas questes geradoras de requisitos para a caracterstica confiabilidade do modelo de qualidade da norma. Em sua verso completa a norma apresenta 13 caractersticas e 42 subcaractersticas e a verso completa da tabela pode ser encontrada em [1]. Embora a lista de subcaractersticas seja extensa, a equipe deve ter em mente que ela apenas uma classificao para melhorar a sua capacidade de identificar requisitos que sejam realmente importantes. No h necessidade de se procurar por requisitos inexistentes, por exemplo, estabelecendo requisitos complicados de empacotamento para um cliente que no se importa com a forma como o software ser empacotado. Tambm no recomendvel perder muito tempo discutindo se um dado requisito pertence a este tipo ou quele. Mais importante do que decidir a qual tipo o requisito pertence saber que ele existe: longas discusses sobre classificao de requisitos no adicionam conhecimento significativo ao projeto.

    6 Disponvel em:

    .

    XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    23

  • Tabela 1. Classificao de requisitos suplementares baseada na ISO/IEC 25010:2011 e questes geradoras de requisitos.

    Caracterstica 25010

    Subcaracterstica 25010

    Questes geradoras de requisitos

    Confiabilidade (reliability)

    Maturidade

    Algum cuidado especial deve ser tomado para evitar que o sistema apresente defeitos durante seu uso? Partes crticas do sistema devem ser definidas por especificao formal? Quais a intensidade e o tipo de testes que devem ser realizados para assegurar que o sistema esteja livre de defeitos?

    Disponibilidade

    Qual o grau de disponibilidade requerido para o sistema? Quantos acessos simultneos devem ser suportados? Quantas horas por dia? Quantos dias por ano?

    Tolerncia a falhas

    Como o sistema deve reagir no caso de anomalias externamente provocadas, tais como falha de comunicao?

    Recuperabilidade

    O sistema deve ser recuperar automaticamente no caso de desastre? Sob que circunstncias dados perdidos e processos abortados devem ser recuperados?

    9. CONSIDERAES FINAIS O objetivo da fase de Concepo do UP construir uma viso geral do sistema e do seu contexto e planejar o desenvolvimento futuro. As principais ferramentas de modelagem para a disciplina de requisitos nesta fase so os casos de uso de alto nvel e o modelo conceitual preliminar. A modelagem de negcio com seus casos de uso de negcio, diagramas de atividades e mquina de estados tambm pode ser necessria com maior ou menor intensidade para permitir a compreenso do contexto do negcio e uma melhor derivao de requisitos para o desenvolvimento do sistema correto. Embora a cultura de orientao a objetos tenha mais de 40 anos de existncia, ainda h empresas que acham difcil desenvolver software de boa qualidade. As tcnicas descritas aqui foram

    aplicadas com sucesso pelo autor em muitos projetos de desenvolvimento e software em empresas, bem como em projetos de pesquisa em universidades. Em geral ainda existem muitas dvidas entre profissionais do desenvolvimento de software sobre a verdadeira utilidade de diagramas como casos de uso e os demais diagramas citados neste trabalho. Este minicurso, aqui resumido, procura sanar boa parte dessas dvidas, apresentando como principais contribuies uma compreenso mais clara sobre as diferenas entre casos de uso de negcio e de sistema, introduzindo duas ferramentas diagramas de atividades e de mquina de estados os quais permitem refinar o modelo de negcio, bem como uma estratgia sistemtica para derivar casos de uso de sistema, e portanto, requisitos, a partir desses modelos. O trabalho ainda associa claramente casos de uso de sistema com requisitos funcionais e anotaes de casos de uso com requisitos no funcionais, tais como regras de negcio e requisitos de qualidade. 10. REFERNCIAS [1] Wazlawick, R. S. (2015). Anlise e Design Orientados a

    Objetos para Sistemas de Informao: Modelagem com UML, OCL e IFML. 3 edio, Elsevier, (Also published in English as Object-Oriented Analysis and Design for Information Systems: Modeling with UML, OCL and IFML. Morgan Kaufman, 2014.)

    [2] Jacobson, I. (1994). The Object Advantage: Business process reengineering with object technology. Addison-Wesley.

    [3] Kroll, P., & Kruchten, P. (2003). The Rational Unified Process Made Easy: A practicioners guide to RUP. Addison Wesley.

    [4] Probasco, L. (2001). What makes a good Use Case Name? The Rational Edge. March.

    [5] Larman, C. (2004). Applying UML and Patterns: An introduction to object-oriented analysis and design and the unified process. 3rd ed., Prentice-Hall.

    [6] Ambler, S. W. (2000). Web Services Programming Tips and Tricks: Modeling essential use cases. Disponvel em: . Acesso em 31 de agosto de 2013.

    [7] Grady, R. (1992). Practical Software Metrics for Project Management and Process Improvement. Prentice-Hall

    XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    24

  • Padres, ferramentas e boas prticas no desenvolvimento de software para Web Semntica

    Ernesto Fonseca Veiga Instituto de Informtica

    Universidade Federal de Gois Goinia-GO

    [email protected]

    Mrcio V. Oliveira Sena Instituto de Informtica

    Universidade Federal de Gois Goinia-GO

    [email protected]

    Renato de Freitas Bulco-Neto Instituto de Informtica

    Universidade Federal de Gois Goinia-GO

    [email protected]

    RESUMO A Web Semntica um esforo internacional para representar dados em formatos adequados para processamento, integrao e raciocnio automatizados. As aplicaes atuais incluem busca melhorada, colaborao, composio automtica de servios e agentes inteligentes, tudo enriquecido com tecnologias da Web Semntica. Nesse contexto, este minicurso apresenta, com foco prtico, o uso conjunto de ferramentas, padres e boas prticas na construo de software para Web Semntica, alm de dois prottipos desenvolvidos pelos autores. Como resultado, visa-se capacitar desenvolvedores a construir aplicaes que armazenem, consultem e infiram dados com semntica explcita.

    Palavras-Chave Web Semntica; W3C; Apache Jena; Pellet; boas prticas. ABSTRACT The core of the Semantic Web includes proper data representation towards automated processing, integration and reasoning. Current applications provide improved search, collaboration, automatic composition of services, and intelligent agents; all these functionalities enriched with Semantic Web technologies. For that reason, this short course presents the combined use of standards, tools and best practices for the development of Semantic Web systems in general, and two prototypes developed by the authors in particular. As a result, it is expected that attendants be able to develop applications handling data with explicit semantics.

    Categories and Subject Descriptors I.2.4 [Knowledge Representation Formalisms and Methods]: Representation languages.

    General Terms Design; Languages; Standardization; Experimentation.

    Keywords Semantic Web; W3C; Apache Jena; Pellet; best practices.

    1. INTRODUO A Web Semntica uma Web de dados descritos e interligados de maneira a se estabelecer um contexto ou semntica que adere a uma linguagem e regras gramaticais bem definidas [5]. Para atingir esse propsito, foram criadas especificaes para representar informao na Web de forma padronizada, bem como foram desenvolvidos frameworks [1], processadores de consultas [4] e mquinas de inferncia [8] com suporte a tais especificaes. Nesse contexto, este minicurso apresenta, com enfoque prtico, o uso conjunto de ferramentas, especificaes e boas prticas no desenvolvimento de software para Web Semntica. Inicialmente, so abordadas a importncia de se associar semntica a coisas acessveis pela Web, bem como as diferenas entre a Web Semntica e a Web atual [11]. Em seguida, as principais especificaes da arquitetura da Web Semntica so exploradas, como aquelas para representao estrutural [18] e semntica [19,23] de informao. O objetivo no detalhar cada padro, mas sim descrever o papel de cada especificao na Web Semntica e mostrar como essas especificaes funcionam em conjunto. Em paralelo, ser tambm demonstrado o uso de ferramentas [1,2,3,4,8,12,14,21] que permitem a modelagem de informao e a programao de aplicaes com cada padro W3C. Por fim, duas aplicaes-prottipo desenvolvidas pelos autores sero tambm trabalhadas junto com os alunos, como reforo do uso integrado das especificaes e ferramentas supracitadas, aliadas a discusses sobre boas prticas de construo de aplicaes para Web Semntica [11]. Como principal resultado, espera-se capacitar desenvolvedores a construir uma aplicao com as capacidades de armazenamento, consulta e inferncia de dados com semntica explcita. Este artigo est assim organizado: a arquitetura da Web Semntica e seus principais padres so apresentados na Seo 2; a Seo 3 descreve um estudo de caso com aplicaes-prottipo; boas prticas de desenvolvimento para Web Semntica so discutidas na Seo 4; e a Seo 5 apresenta consideraes finais.

    Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SBSI 2015, May 2629, 2015, Goinia, Gois, Brazil. Copyright SBC 2015.

    Alternative Title: Standards, tools and best practices in software development for Semantic Web

    XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    25

  • 2. ARQUITETURA DA WEB SEMNTICA Esta seo descreve especificaes da arquitetura em camadas da Web Semntica da Figura 1, especialmente aqueles padres para representao de identificao nica [13], sintaxe [15], estrutura [18], consulta [22] e de semntica [19,23] de informao.

    Figura 1. Arquitetura em camadas da Web Semntica [11]

    2.1 Padro URI / IRI Uma URI (Uniform Resource Identifier) corresponde a uma cadeia de caracteres, com uma sintaxe particular, para identificar unicamente um recurso na Web. Entende-se por recurso qualquer poro de contedo, seja uma pgina de texto, um clipe de vdeo ou de udio, um programa, ou uma imagem. Atualmente, as URIs so definidas como IRIs (Internationalized Resource Identifier) [13], em funo de seus caracteres seguirem o padro internacional Unicode de codificao de caracteres. A sintaxe de uma IRI definida na RFC 3987 composta de:

    Nome do protocolo ou mecanismo de acesso :// Domnio ou autoridade sobre o recurso Caminho de acesso ao recurso Recurso em si (pode haver fragmento do recurso)

    A forma mais comum de IRI o endereo de uma pgina Web, que corresponde a um tipo de IRI conhecido como URL (Uniform Resource Locator), que usa o protocolo http://. So tambm exemplos de IRIs os endereos de correio eletrnico (mailto://), bem como os de acesso a arquivos via protocolos file:// e ftp://. O principal papel do padro IRI na Web Semntica fornecer uma codificao universal para nome e localizao de recursos, pois cada recurso na Web identificado unicamente por meio de sua IRI. Seguem exemplos de IRIs: mailto://[email protected], http://www.inf.ufg.br/~renato, que identificam os recursos email e pgina pessoal de uma pessoa, embora essa mesma pessoa possa ter outras IRIs de email e de pgina pessoal associadas a ela. 2.2 Trade XML A linguagem de marcao XML (Extensible Markup Language) [16], alm de extensvel, flexvel, pois permite ao usurio definir suas prprias tags, na ordem desejada e da maneira como quer que sejam processadas ou apresentadas. Todo documento XML representado em memria como uma rvore de elementos (e atributos, se cabvel), e obedece s seguintes regras de sintaxe:

    sendo uma rvore, possui uma nica raiz, sem ciclos; cada n (exceto o raiz) tem um nico pai; elementos devem ter uma tag de fechamento; tags dos elementos so sensveis caixa; a ordem do aninhamento dos elementos importante; aordem dos atributos no importa; e valores dos atributos devem estar entre aspas.

    Documentos que seguem essas regras de sintaxe da linguagem XML so denominados bem formados (do ingls well-formed). Segundo a especificao da linguagem XML [16], qualquer software que processa contedo na sintaxe XML deve interromper o processamento desse contedo, caso um erro de sintaxe seja detectado. Por ter que lidar com esse pequeno e bem definido conjunto de regras de sintaxe, um software de processamento de contedo XML (ou parser XML) simples, rpido e mantm a compatibilidade com outros softwares do mesmo tipo. O principal papel do padro XML na Web Semntica fornecer suas regras de sintaxe para a construo de outras especificaes da arquitetura citada, como RDF [18], RDFS [19] e OWL [23]. Entretanto, a flexibilidade permitida pela linguagem XML, de que qualquer pessoa, organizao ou software possa especificar suas prprias tags para descrever contedo, pode resultar em duplicaes ou conflitos de nomes de tags. Considere a situao em que um parser XML deve analisar e combinar dois documentos XML que utilizam uma mesma tag : em um documento, o significado dessa tag mesa, e possui elementos que descrevem seu nome, altura e largura; j no outro documento, a semntica da tag tabela, e possui elementos que descrevem suas linhas e colunas. Esse conflito de nomes iguais, mesmo em documentos diferentes, precisa ser resolvido, pois o parser XML no saber resolver essas diferenas em funo dos diferentes elementos de em cada documento. Para resolver esse conflito, ambos os documentos devem fazer uso dos espaos de nomes XML (do ingls XML namespaces) [17], que funcionam como um repositrio no qual se define a sintaxe e a estrutura de elementos e atributos de documentos XML. Para isso, deve-se associar um espao de nomes a uma IRI, e a esse espao de nomes atribuir um prefixo (ou alias). Na prtica, essa associao realizada por meio da sintaxe xmlns: prefixo=" IRI". Tomando o exemplo dado nesta seo, as tags desses documentos seriam diferenciadas ao associar a cada uma de suas tags os espaos de nomes nos quais foram definidos os elementos descritos por essas tags. Por exemplo, em um documento, a tag poderia ser identificada por abcd:table, onde abcd o prefixo do espao de nomes xmlns:abcd="http://example.org/". J no outro documento, a tag homnima poderia ser identificada por xyzw:table, onde xyzw o prefixo de um outro espao de nomes, no caso, xmlns:xyzw="http://sample.org/". Dessa maneira, um parser XML no interrompe o processamento de contedo que contenha tags homnimas em funo das definies de espaos de nomes associados a essas tags. Nesse interim, os espaos de nomes XML tm grande importncia para integrao e compartilhamento de dados na Web Semntica, pois previnem colises de nomes de recursos do ponto de vista sinttico, previnem ambiguidades do ponto de vista semntico e garantem a unicidade dos recursos de uma declarao em escala global, segundo seus nomes e respectivos espaos de nomes.

    XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    26

  • O terceiro elemento que forma a trade XML a especificao esquema XML (do ingls XML Schema), uma linguagem para a definio da estrutura [24] de documentos XML (ordem, encadeamento e cardinalidade de elementos, e obrigatoriedade de elementos e atributos), bem como dos tipos de dados [25] armazenados em cada elemento ou atributo. Ou seja, um esquema XML um documento que especifica as regras gramaticas de validao de um ou mais documentos XML. Embora no seja obrigatria a sua adoo, existem situaes em que definir a estrutura de documentos XML relevante, principalmente em intercmbio eletrnico de dados. Documentos oriundos de diferentes fontes, mas que descrevem o mesmo tipo de contedo, devem seguir as mesmas regras de formao, sendo assim considerados vlidos segundo o seu esquema XML. Poderia haver problemas de intercmbio de dados, por exemplo, caso uma sequncia de elementos em um documento XML fosse alterada, ou se um elemento considerado obrigatrio inexistisse. A linguagem esquema XML define tambm um rico mecanismo de tipagem de dados, que inclui a representao de dados numricos (ex.: decimal, float, double, integer, byte), cadeias de caracteres (ex.: string), lgicos (boolean), binrios (hexBinary e base64Binary), temporais (time, date, duration e datetime), de calendrio gregoriano (ex.: gYear, gMonth, gDay), dentre outros. Em virtude de esquemas XML serem escritos na sintaxe XML, o seu aprendizado facilitado, e qualquer editor / parser XML pode ser utilizado para editar / analisar a sua sintaxe. Alm disso, esquemas XML so extensveis e reusveis, sendo de extrema importncia para a interoperabilidade sinttica de dados XML entre programas comunicantes. O principal papel do esquema XML para a Web Semntica o de fornecer um conjunto sofisticado e padronizado de tipos de dados para a descrio de contedo, usado por outras especificaes da arquitetura citada, como RDF [18] e OWL [23]. 2.3 Padro RDF Embora a linguagem XML seja a lngua franca para intercmbio de dados na Web, h caractersticas que a tornam invivel para intercmbio de dados na Web Semntica [11]:

    a dificuldade de se determinar exatamente o significado da hierarquia entre as tags, bem como dos dados que formam o contedo dessas tags;

    o fato de uma mesma informao poder ser representada de mltiplas maneiras dada a estrutura de rvore de documentos XML. Por exemplo, a declarao "Renato leciona Engenharia de Software" pode ser representada sob as seguintes formas descritas na Figura 2:

    Figura 2. Maneiras diferentes de representar a mesma

    informao usando apenas as regras de formao da XML

    Portanto, a Web Semntica demanda um modelo de dados que possa representar qualquer informao que se deseje expressar de maneira universal, legvel por mquinas e fcil para integrar dados de fontes diferentes. Nesse interim, surge o modelo de dados RDF (Resource Description Framework) [18], a especificao padro do Consrcio W3 para intercmbio de dados na Web Semntica. O modelo de dados RDF baseado em triplas (sujeito, predicado, objeto), que podem ser mapeadas diretamente para grafos dirigidos, nas quais:

    o sujeito representa uma IRI de um recurso; o predicado pode representar uma IRI de uma

    propriedade de um recurso, ou uma IRI de um relacionamento entre dois recursos; e

    o objeto pode representar um valor literal (quando se liga ao sujeito por meio de um predicado-propriedade), ou uma IRI de um recurso (quando se liga ao sujeito por meio de uma propriedade-relacionamento).

    A declarao exibida na Figura 2 de trs formas diferentes em XML estruturada em uma tripla RDF, tal como na Figura 3.

    http://.../.../Renatohttp://.../leciona http:///Engenharia

    de Software Figura 3. Representao genrica segundo o modelo de triplas

    RDF para as declaraes XML exibidas na Figura 2 Perceba na Figura 3 que sujeito, predicado e objeto possuem IRIs de protocolo de acesso http://. Neste caso, a propriedade leciona relaciona os recursos Renato e Engenharia de Software. Um caso em que a propriedade uma caracterstica do recurso e o objeto um literal, se fosse necessrio descrever a idade do recurso, algo como (http://.../.../Renato, http://.../idade, "40"). Convenciona-se, na notao de grafos RDF, a representao de ovais para IRIs de sujeitos e objetos; retngulos, para objetos do tipo literal; e setas, para IRIs de predicados. As arestas (setas) so sempre dirigidas do sujeito para o objeto da declarao; da, tanto o sujeito quanto o objeto so vrtices do grafo de uma declarao. Ressalta-se tambm que todos os predicados descritos em RDF so binrios, ligando sempre um sujeito a um objeto. Conclui-se, pois, que o modelo de dados RDF voltado para a estruturao e o intercmbio universal de dados, e no para a exibio de dados. Chama-se ateno tambm ao fato de que mesmo que grafos RDF sejam fceis de visualizar, entender e programar, deve existir uma representao desses grafos para facilitar ainda mais o processamento e o intercmbio de dados entre aplicaes. Ou seja, necessita-se de sintaxes de serializao de dados RDF. Dentre as vrias sintaxes para serializar triplas RDF, destaca-se a serializao Turtle (Terse RDF Triple Language) [20]. Trata-se de uma sintaxe que permite que um grafo RDF seja escrito sob uma forma textual compacta, simples de aprender e compatvel com os padres IRI, espaos de nomes XML e esquema XML. O exemplo a seguir ilustra uma representao em Turtle para a declarao da Figura 3, acrescida da propriedade idade do recurso Renato. 1 @prefix : . 2 @prefix acm: . 3 @prefix xsd: . 4 :Renato :leciona acm:EngenhariaDeSoftware ; 5 :idade "40"^^xsd:positiveInteger .

    XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    27

  • A linha 1 associa um prefixo vazio IRI que delimita o espao de nomes nos quais os recursos Renato e leciona foram definidos. A linha 2 faz o mesmo com o recurso Engenharia de Software, cujo espao de nomes associado ao prefixo acm:. A linha 3 associa o prefixo xsd: IRI do espao de nomes padro em que os tipos de dados do esquema XML esto definidos. A linha 4 corresponde declarao de que "Renato leciona Engenharia de Software", enquanto que a linha 5 atribui ao sujeito Renato o predicado idade com objeto de valor 40, a ser interpretado como um nmero inteiro positivo, segundo a especificao do esquema XML. A seguir so apresentadas as principais regras de sintaxe da linguagem Turtle para fins de serializao de triplas RDF:

    A declarao do prefixo de um espao de nomes deve ser feito por meio da clusula @prefix;

    Todas as IRIs devem vir entre os smbolos < e >; Espaos em branco e quebras de linha so ignorados; Todas as triplas devem finalizar com ponto final; Valores literais devem vir entre aspas duplas; O tipo de dado do esquema XML de um valor literal

    deve ser atribudo por meio do smbolo ^^; Triplas com mesmo sujeito podem ser agrupadas por

    meio do ponto e vrgula; Triplas com os mesmos sujeito e predicado podem ser

    agrupadas por meio de vrgula. Para facilitar no minicurso o aprendizado do modelo de triplas RDF, de sua visualizao como grafo e da sintaxe de serializao Turtle, sero utilizadas ferramentas [12,21], com nfase API Java para programao de modelos RDF [2] do Apache Jena, com a qual pode-se: criar triplas RDF e escrev-las em diferentes sintaxes de serializao (inclusive em Turtle); controlar prefixos e respectivos espaos de nomes XML; navegar, consultar e aplicar operaes de conjuntos sobre triplas RDF; e manipular literais e associ-los a tipos de dados do esquema XML. Em seguida, ser trabalhado no minicurso o componente TDB [3] do Apache Jena para armazenamento persistente de triplas RDF. Os exemplos apresentados no minicurso sero trechos de cdigo desenvolvidos pelos autores, ou exemplos da documentao do Apache Jena. 2.4 Linguagem de consulta SPARQL Como complemento aos esforos de padronizao do RDF, o Consrcio W3 trabalhava na criao de uma linguagem padro para a escrita de consultas sobre triplas, i.e. segundo o modelo de dados RDF (sujeito, predicado, objeto): a linguagem SPARQL (SPARQL Protocol And RDF Query Language) [22]. A linguagem SPARQL permite quatro formas de consulta a triplas RDF, cada qual com sua devida finalidade [9]. Embora essas quatro formas sejam exploradas, na teoria e na prtica, no minicurso, um enfoque maior ser dado forma SELECT. Essa forma de consulta ser usada a seguir para explicar as regras da sintaxe da linguagem SPARQL. 1 PREFIX rdf: 2 PREFIX ex: 3 SELECT ?person ?name 4 WHERE { 5 ?person rdf:type ex:Person . 6 ?person ex:name ?name 7 } As linhas 1 e 2 descrevem prefixos, por meio da clusula PREFIX, dos espaos de nomes XML utilizados na consulta, no

    caso, rdf: e ex:. A clusula SELECT, na linha 3, identifica uma ou mais variveis nas quais devam ser armazenados os valores de retorno da consulta, no caso, ?person e ?name. Destaque para a clusula WHERE, nas linhas 4 a 7, que descreve um padro de grafo (do ingls pattern graph) sob a forma de uma conjuno lgica de triplas RDF escritas em Turtle. Esse padro de grafo (ou subgrafo) representa a informao que dever ser buscada na fonte de dados RDF em questo. Para isso, um processador de consultas SPARQL visa identificar um casamento de triplas (do ingls triple matching), i.e. localizar triplas do subgrafo que combinam estrutural e/ou lexicamente com triplas da fonte de dados. No exemplo anterior, deseja-se o identificador (IRI de sujeito) e o nome (objeto literal) de um recurso do tipo Pessoa. Os valores encontrados para ?person e ?name na fonte de dados que "casam" com a posio dessas variveis no subgrafo (sujeito e objeto, respectivamente) sero retornados nessas variveis de consulta da clusula SELECT. Caso haja nenhum "casamento" entre o subgrafo e as triplas da fonte de dados, o retorno da consulta nulo. apresentado a seguir um possvel retorno consulta SELECT supracitada: person name "Renato Bulco Neto" "Mrcio V. O. Sena" "Ernesto F. Veiga" Assim como em SQL, h clusulas da SPARQL que alteram o resultado de uma consulta, podendo inclusive melhor-lo quanto a preciso e desempenho. Nesse contexto, sero apresentados exemplos de consultas que fazem uso das clusulas FILTER, OPTIONAL e ORDER BY, bem como de expresses sobre agrupamentos via GROUP BY, como HAVING, SUM, AVG, etc. Em seguida, sero discutidos a teoria e exemplos prticos das outras 3 formas de consulta da linguagem SPARQL [9]:

    ASK: til para saber se um dado subgrafo existe na fonte de dados; o resultado da consulta um booleano;

    CONSTRUCT: sua principal diferena para o SELECT que o resultado da consulta um novo grafo, e no uma ligao de valores a variveis de consulta;

    DESCRIBE: til quando se deseja saber "tudo" sobre um determinado recurso em uma fonte de dados.

    Ao longo do minicurso, todos os exemplos de consultas com as clusulas SELECT, ASK, CONSTRUCT e DESCRIBE faro uso do processador de consultas ARQ [4] do Apache Jena. 2.5 Linguagens de ontologia RDFS e OWL2 Embora fornea um modelo universal para expressar declaraes sobre recursos, o padro RDF tem limitaes: ele no fornece uma linguagem para modelagem dos recursos que descreve, nem capaz de representar a semntica desses recursos. Por exemplo, considerando a tripla da Figura 3, no se sabe se Renato objeto de uma classe Pessoa, se Engenharia de Software objeto de uma classe Disciplina, ou mesmo a que objetos a propriedade leciona pode relacionar-se. Para tratar essas limitaes do padro RDF, o Consrcio W3 criou a linguagem RDF Schema (ou RDFS) [19]. A linguagem RDFS uma extenso do RDF por meio da qual possvel construir simples ontologias, que so uma especificao formal de um modelo abstrato de um domnio de conhecimento [10]. Uma das vantagens de se utilizar uma ontologia que ela permite que aplicaes deduzam novas informaes com base na semntica expressa pelo vocabulrio da ontologia. Nesse contexto, RDFS fornece um vocabulrio que permite:

    XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    28

  • modelar recursos como classes ou membros de classes; especificar hierarquias de classes e de propriedades; declarar a que classe de recursos pertence uma dada

    propriedade; e determinar quais os valores (outro recurso ou um literal)

    que uma propriedade pode assumir. A ttulo de ilustrao, segue um trecho de ontologia RDFS, escrita em Turtle, que modela os conceitos da declarao da Figura 3. 1 @prefix acm: . 2 @prefix foaf: . 3 foaf:Pessoa a rdfs:Class . 4 acm:Disciplina a rdfs:Class . 5 acm:leciona a rdfs:Property ; 6 rdfs:domain foaf:Pessoa ; 7 rdfs:range acm:Disciplina . A linha 3 define que o conceito Pessoa, definido no espao de nomes XML de prefixo foaf:, uma classe de indivduos. O mesmo acontece na linha 4, i.e. o conceito Disciplina modelado tambm como uma classe. Nas linhas 5 a 7, o conceito leciona representado como uma propriedade, vinculada a indivduos da classe Pessoa, e indivduos da classe Disciplina como valores possveis dessa propriedadade. Dessa maneira, ao aplicar a semntica dessa ontologia com a declarao da Figura 3, faz-se com que uma aplicao possa deduzir, dentre outras coisas, que "Renato um indivduo da classe Pessoa, e que Engenharia de Software um indivduo da classe Disciplina". Embora expresse a semntica de conceitos e, com base nesta, permitir que aplicaes possam fazer inferncias, RDFS simples para construir ontologias com maior expressividade e, por consequncia, com maior complexidade lgica. Para cobrir essa lacuna, foi criada a linguagem OWL, que est na 2a verso [23]. Ao fazer uso das especificaes IRI, XML, RDF e RDFS, a OWL2 a linguagem padro para construo de ontologias para a Web Semntica [11,23]. Para isso, em acrscimo ao vocabulrio da RDFS, a OWL2, por exemplo, classifica as propriedades como atributos ou relaces: s do tipo atributo, associam-se os tipos de dados definidos no esquema XML; e s do tipo relao, pode-se classific-las quanto a suas caractersticas lgicas, como relaes transitivas, simtricas, reflexivas, inversas, funcionais, etc. Ainda em comparao RDFS, a linguagem OWL2 oferece:

    suporte a restries sobre valores e cardinalidades de propriedades, como o uso de quantificaes universal e existencial e cardinalidades exata, mnima e mxima;

    suporte modelagem de classes disjuntas, i.e. aquelas cujos indivduos no podem ser de ambas as classes;

    construtores para criar classes segundo a teoria de conjuntos, bem como para declarar equivalncia entre classes, propriedades e indivduos.

    Como um simples exemplo da expressividade e da capacidade de inferncia da linguagem OWL2, acrescenta-se ontologia RDFS, exibida neste texto, as linhas 8 e 9 a seguir, que declaram, na sintaxe Turtle, duas propriedades: ministra e ehLecionadaPor. 8 acm:ministra owl:equivalentProperty acm:leciona. 9 acm:ehLecionadaPor owl:inverseOf acm:leciona . Com o uso do espao de nomes owl:, essa ontologia para a ser tratada como do tipo OWL2. A relao leciona declarada como equivalente relao ministra: ou seja, estar-se afirmando que sujeitos e objetos que leciona interliga, devero ser tambm por ministra. A relao ehLecionadaPor declarada como inversa da

    relao leciona: ou seja, sujeitos e objetos que leciona interliga sero invertidos na declarao da relao ehLecionadaPor. Ao aplicar a semntica desses constutores OWL2 declarao da Figura 3, uma aplicao poder inferir, alm das dedues obtidas pela semntica da RDFS, que "Renato ministra Engenharia de Software que, por sua vez, lecionada por Renato". Simples exemplos de ontologias como esse sero apresentados nesta seo do minicurso, com foco na semntica dos principais construtores do padro OWL2. Depois, ser visto como integrar ontologias escritas em OWL2 a uma aplicao Java, utilizando o componente schemagen do Apache Jena [1]. Por fim, ser mostrado como programar uma aplicao para que a mesma deduza novas informaes a partir das informaes conhecidas de um determinado domnio e de uma ontologia sobre esse domnio. Para isso, ser explorada a integrao da API de inferncia do Apache Jena [1] com a mquina de inferncia Pellet [8]. Para visualizao de ontologias, utilizar-se- a clssica ferramenta para edio de ontologias, chamada Protg [14].

    3. DESENVOLVIMENTO DE APLICAES Para fins de demonstrao da aplicao dos conceitos vistos ao longo do minicurso, bem como das prticas trabalhadas sobre cada conceito, sero apresentadas duas aplicaes-prottipo, criadas em conjunto com alunos de graduao e ps-graduao do Instituto de Informtica da UFG. Para cada aplicao, descrever-se-o o propsito, o processo de desenvolvimento e detalhes do uso integrado das especificaes e ferramentas apresentadas ao longo do minicurso.

    3.1 Sugerir revisores para artigos cientficos O fator motivacional para o desenvolvimento desta aplicao advm da dificuldade de se encontrar revisores para artigos cientficos, caso no seja conhecido um pesquisador especialista na rea de conhecimento abordada por cada artigo. A soluo encontrada inclui: o uso de uma ontologia que modela as reas de conhecimento da Cincia da Computao; a criao explcita de um perfil para cada especialista, associando a este as reas de conhecimento de seu domnio; a atribuio explcita de reas de conhecimento a cada artigo cientfico a ser distribudo; e, por fim, a deduo automtica de que especialistas deveriam ser revisores de determinados artigos cientficos, em funo das reas de conhecimento envolvidas, nem sempre equivalentes, mas com algum grau de associao (ex.: subrea, interseco de contedo). Duas ontologias foram utilizadas no desenvolvimento desta aplicao: a ontologia ACM CS, desenvolvida pelos autores com base na Classificao ACM das reas de conhecimento da Cincia da Computao (http://www.acm.org/about/class/1998/); e a ontologia FOAF (Friend Of A Friend) [6], que descreve perfis de pessoas para serem utilizados em redes sociais.

    3.2 Socializar pessoas com interesses comuns O desenvolvimento de uma aplicao para socializao automtica de pessoas advm do fato de muitas pessoas se socializarem com quem conhecem, mas que muitas vezes no guardam interesses em comum como, por exemplo, pessoas que possuem interesse nas mesmas reas de conhecimento. A soluo desenvolvida inclui: o uso da mesma ontologia citada para reas de conhecimento da Cincia da Computao; a criao explcita de um perfil para cada pessoa, associando a esta as reas

    XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    29

  • de conhecimento de seu interesse; e, por fim, a criao automtica de grupos, integrando pessoas, em funo das reas de conhecimento de seus interesses, reas nem sempre equivalentes, mas que guardam algum tipo de relao (ex.: hierarquia de subreas, ou uma interseco de contedo). Para desenvolver esta aplicao foram utilizadas trs ontologias: a ACM CS, a FOAF e a ontologia Relationship [7] que, como o prprio nome indica, fornece um vocabulrio para a descrio de relacionamentos entre pessoas, como amizade, parentesco, etc.

    4. BOAS PRTICAS Esta seo traz discusses sobre boas prticas de desenvolvimento de aplicaes para Web Semntica [11].

    4.1 Gerenciamento de IRIs Quer seja ao desenvolver aplicaes que produzem dados RDF, quer seja ao construir ontologias, a gerao de IRIs deve garantir que sejam nicas, consistentes e resolveis. Uma forma comum de garantir a unicidade das IRIs a de usar uma nica IRI para definir o espao de nomes de cada ontologia criada, ou para servir de base para a gerao de IRIs por meio de uma aplicao que produz dados RDF. H uma tcnica chamada espaamento de datas, na qual se insere na IRI a data em que um documento de ontologia foi criado ou publicado, o que pode reduzir a probabilidade de coliso de IRIs. A garantia de consistncia de IRIs diz respeito ao fato de que operaes sobre recursos, quais sejam, no devem modificar suas IRIs. H tcnicas para garantir consistncia e unicidade de IRIs, e todas devem assegurar que IRIs sejam geradas com base nas caractersticas dos dados (ex.: URL do BD) que identificam unicamente o recurso ao longo do seu ciclo de vida. A resolubilidade de uma IRI advm do fato de que a IRI do espao de nomes de uma ontologia ou de um documento RDF deve ser acessvel na Web Semntica. Dessa maneira, um usurio ou uma aplicao pode recuperar o documento RDF que descreve um recurso. A questo de resolubilidade de IRIs, segundo [11], um assunto nem sempre fcil ou prtico de se implementar.

    4.2 Especificao de unidades de medida Uma limitao de RDF e de OWL que ambos no oferecem suporte direto para unidades de medida de valores literais (ex.: quilogramas e libras para peso de uma pessoa). Uma tcnica que permitem modelar literais com unidades de medida padro uma na qual usa-se propriedades e tipos de dados com unidades especficas para criar uma verso nica de cada propriedade ou tipo de dado para a qual se tem uma unidade de medica. Seguem alguns exemplos de aplicao dessa tcnica:

    uma propriedade de representao de comprimento seria lenght-feet (em ps), ou lenght-meter (em metros); para representao de idade, age-years (anos de idade);

    um tipo de dado que representa valores de ponto flutuante seria float-feet (ps como ponto flutuante); como valores inteiros, int-years (anos como inteiros).

    O problema de se usar essa tcnica que ela cria informao redundante em ontologias, o que pode tornar difcil o seu reso, ou mesmo as inferncia sobre as mesmas. Alm disso, nem todos os frameworks existentes suportam tipos de dados customizados.

    4.3 Representao de relacionamentos n-rios Em RDF e em OWL os predicados so binrios: um predicado liga um nico sujeito a um nico objeto. Porm, h situaes em que necessrio representar relacionamentos n-rios, i.e. onde um indivduo tem mltiplos valores para multiplas propriedades, tomadas em conjunto. A geolocalizao de um objeto um exemplo clssico de relacionamento n-rio: ela representada por um valor combinado de latitude e longitude. A melhor forma de modelar geolocalizao introduzir um objeto intermedirio que age como um container para os valores de latitude e longitude, como a seguir: associam-se as coordenadas de localizao de uma pessoa por meio do recurso ex:coordinate. ex:Renato ex:hasCoordinate ex:coordinate. ex:coordinate ex:hasLatitude "38.88965" ; ex:hasLongitude "-77.03536" . Usar este tipo de representao simplifica as consultas e no usar o objeto intermedirio pode fazer com que diferentes pares de valor de latitude e longitude sejam atribudos a uma pessoa, sem que haja uma ideia da temporalidade desses valores combinados.

    5. CONSIDERAES FINAIS A Web Semntica um esforo internacional para representar dados em formatos adequados para processamento, integrao e raciocnio automatizados. Aplicaes atuais apresentam uma srie de recursos com tecnologias da Web Semntica, como as redes sociais, que utilizam ontologias para perfis de usurios, e as wikis semnticas, que associam aos conceitos descritos seus respectivos significados descritos em ontologias [11]. Soma-se a isso os esforos contnuos do Consrcio W3 na evoluo de padres, como RDF, OWL e SPARQL, em resposta ao uso intenso dessas especificaes pelas comunidades de pesquisadores e desenvolvedores [9]. O surgimento de pequenas empresas aliado ao crescimento de grandes empresas de software para Web Semntica tem proporcionado esse cenrio de intenso desenvolvimento. Somam-se ainda uma srie de projetos open-source na rea e inmeras iniciativas de pesquisa evidenciadas por conferncias na Europa, nos EUA e tambm no Brasil. nesse contexto que a comunidade brasileira de pesquisa em Web Semntica enxerga o Simpsio Brasileiro de Sistemas de Informao (SBSI) como um importante veculo de divulgao de suas pesquisas, com relao direta a tpicos de interesse do evento, atraindo no somente pesquisadores, mas tambm profissionais da indstria de software regional e nacional. Este minicurso vem de encontro a essa crescente demanda com uma abordagem prtica e integrada de ferramentas, padres e boas prticas da Web Semntica, com o intuito principal de capacitar seus participantes a construrem aplicaes que armazenem, consultem e deduzam informao com semntica explcita.

    6. REFERNCIAS [1] Apache Software Foundation. 2015. Apache Jena - A free

    and open source Java framework for building Semantic Web and Linked Data applications. http://jena.apache.org.

    [2] Apache Software Foundation. 2015. Apache Jena RDF API. https://jena.apache.org/tutorials/rdf_api.html.

    [3] Apache Software Foundation. 2015. Apache Jena TDB. http://jena.apache.org/documentation/tdb/.

    XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    30

  • [4] Apache Software Foundation. 2015. ARQ - A SPARQL Processor for Jena. jena.apache.org/documentation/query.

    [5] Berners-Lee, T., Hendler, J, and Lassila, O. 2001. The Semantic Web. Scientific American. 284, 5, 29-37.

    [6] Brickley, D.; Miller, L. 2014. FOAF Vocabulary Specification 0.99. http://xmlns.com/foaf/spec/.

    [7] Davis, I; Vitello Jr, E. 2010. Relationship: A vocabulary for describing relationships between people. http://vocab.org/relationship/.

    [8] Complexible Inc. 2015. Pellet: An open source OWL DL reasoner for Java. https://github.com/Complexible/pellet.

    [9] DuCharme, B. 2013. Learning SPARQL: Querying and Updating with SPARQL 1.1. O'Reilly Media; 2nd edition.

    [10] Gruber, T. 1993. A translation approach to portable ontology specifications. Knowledge Acquisition. 5, 2. 199-220.

    [11] Hebeler, J., Dean, M.; Fisher, M. 2009. Semantic Web Programming. John Wiley & Sons. 2nd edition.

    [12] Humfrey, N. Easy RDF - A PHP library designed to make it easy to consume and produce RDF. http://www.easyrdf.org/.

    [13] Internet Engineering Task Force. 2005. RFC 3987. http://tools.ietf.org/html/rfc3987.

    [14] Stanford Center for Biomedical Informatics Research. 2014. Protg: A free, open-source ontology editor and framework for building intelligent systems. http://protege.stanford.edu/.

    [15] W3C. 2013. W3C Data Activity Building the Web of Data. http://www.w3.org/2013/data/.

    [16] W3C. 2008. Extensible Markup Language (XML) 1.0 (Fifth Edition). http://www.w3.org/TR/xml/.

    [17] W3C. 2006. Namespaces in XML 1.1 (Second Edition). http://www.w3.org/TR/xml-names11.

    [18] W3C. 2014. RDF 1.1 Concepts and Abstract Syntax. http://www.w3.org/TR/rdf11-concepts/.

    [19] W3C. 2014. RDF Schema 1.1. http://www.w3.org/TR/rdf-schema/.

    [20] W3C. 2014. RDF 1.1 Turtle: Terse RDF Triple Language. http://www.w3.org/TR/turtle/.

    [21] W3C. 2006. RDF Validation Service. http://www.w3.org/RDF/Validator/.

    [22] W3C. 2013. SPARQL 1.1 Query Language. http://www.w3.org/TR/sparql11-query/.

    [23] W3C. 2012. OWL 2 Web Ontology Language Primer (Second Edition). http://www.w3.org/TR/owl2-primer/.

    [24] W3C. 2012. XML Schema Definition Language (XSD) 1.1 Part 1: Structures. http://www.w3.org/TR/xmlschema11-1/.

    [25] W3C. 2012. XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. http://www.w3.org/TR/xmlschema11-2/.

    BIOGRAFIAS RESUMIDAS DOS AUTORES Ernesto Fonseca Veiga Bacharel em Informtica pelo Instituto Federal de Educao, Cincia e Tecnologia de Gois (IFG) em 2013, desde 2014 aluno de mestrado do Instituto de Informtica da Universidade Federal de Gois (INF-UFG). Sua pesquisa envolve modelagem semntica de dados coletados de sensores, que envolve o uso de todas as especificaes, ferramentas e boas prticas descritas neste minicurso. Em 2014, foi auxiliar de ensino em disciplina de graduao no INF-UFG, cujo ttulo Engenharia de Software para Web Semntica. Mrcio Vincius Oliveira Sena Bacharel em Sistemas de Informao pelo INF-UFG em 2012, desde 2014 aluno de mestrado nesse instituto. Sua pesquisa envolve qualidade de informaes de contexto representadas por ontologias, que tambm requer conhecimentos das especificaes, ferramentas e boas prticas discutidas ao longo deste minicurso. Desde 2011, desenvolvedor de interfaces de sistemas Web no Laboratrio de Tecnologia da Informao e Mdias Educacionais (LabTIME) da UFG. Prof. Dr. Renato de Freitas Bulco Neto Doutor em Cincia da Computao e Matemtica Computacional pelo Instituto de Cincias Matemticas e de Computao da Universidade de So Paulo (ICMC-USP) em 2006, desde 2010 professor DE do INF-UFG. Orientador do Programa de Ps-Graduao em Cincia da Computao dessa instituio, suas reas de pesquisa incluem Computao Sensvel a Contexto, Engenharia de Software e Web Semntica, esta ltima sendo um dos eixos de sua tese de doutorado. Desde ento, tem ministrado cursos e disciplinas nesse tema para alunos de graduao e de ps-graduao.

    XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    31

  • Social BPM: Processos de Negcio, Colaborao e Tecnologia Social

    Renata Mendes de Araujo Programa de Ps-Graduao em Informtica (PPGI) Ncleo de Pesquisa e Inovao em CiberDemocracia

    (CiberDem) UNIRIO Rio de Janeiro RJ Brasil [email protected]

    Andra Magalhes Magdaleno Programa de Ps-Graduao em Informtica (PPGI) Ncleo de Pesquisa e Inovao em CiberDemocracia

    (CiberDem) UNIRIO Rio de Janeiro RJ Brasil Dheka Consultoria em TI & Gesto

    www.dheka.com.br [email protected]

    RESUMO Este artigo detalha o contedo deste minicurso do SBSI. O objetivo apresentar ao pblico-alvo do evento, o conceito, possibilidades, vantagens e desafios das tecnologias de apoio colaborao em processos de negcio, conhecida atualmente no mercado como Social BPM.

    Palavras-Chave Gesto de processos de negcio, social BPM, colaborao, tecnologia social, software social. ABSTRACT This article details the content of this mini course of SBSI. The goal is to present to the target audience of the event, the concept, possibilities, benefits and challenges of collaboration support technologies in business processes, currently known in the market as Social BPM.

    Categories and Subject Descriptors H.4.0 [Information Systems Applications]: General.

    General Terms Management, Design, Human Factors.

    Keywords Business process management, social BPM, collaboration, social technology, social software.

    1. INTRODUO A sociedade digital e em rede uma realidade. Estamos vivendo em um mundo cada vez mais conectado e aberto, que abre novas

    oportunidades tanto para as organizaes inovarem em seus negcios, como para clientes adquirirem mais autonomia e satisfao no uso de servios. Segundo o Critical Friends [10]: Em um contexto socioambiental, que se tornar cada vez mais complexo nas prximas dcadas, as corporaes e as organizaes da sociedade tero de se abrir muito mais alm do que imaginam atualmente, a fim de solucionar os novos problemas com os quais vo se confrontar no futuro. Don Tappscott [38] afirma que a revoluo tecnolgica est mudando o mundo e que os 4 princpios para lidar com este novo mundo aberto so: colaborao, transparncia, compartilhamento e emponderamento (empowernment) de clientes e funcionrios. A realidade da sociedade e do trabalho em rede indica tambm que uma nova gerao de profissionais nativos digitais desponta no mercado, altamente capacitados no uso de tecnologias e dispositivos de comunicao social, redes e mdias sociais. Os negcios e as organizaes s se mantero competitivos se souberem administrar seus processos neste novo cenrio, conectado e aberto. Ao mesmo tempo, o ambiente interno das organizaes atuais precisar acompanhar a capacidade de interao e colaborao via tecnologia de seus profissionais, de forma a garantir a execuo de seus processos de trabalho/negcio com tarefas mais complexas, menos burocrticas, com mais autonomia e qualidade e conectada ao ambiente externo. Neste cenrio, as tecnologias sociais vm ganhando espao frente s abordagens tradicionais de Gesto de Processos de Negcio (do ingls Business Process Management - BPM), cujo foco tem sido nos processos estruturados e altamente repetitivos. Assim, muitas vezes, as iniciativas de BPM encontravam dificuldades em ambientes que requeriam diversidade e menos previsibilidade no contexto de execuo de processos [31]. As tecnologias sociais tm justamente o potencial de se encaixar nas tecnologias tradicionais de BPM e cobrir o gap da colaborao, inovao e co-participao. Assim, a pesquisa e o mercado na rea de BPM, tm evoludo para propor e desenvolver produtos e mtodos para o apoio colaborao nas iniciativas de gesto de processos de negcio organizacionais. Esta introduo visou motivar a audincia deste minicurso mostrando porque relevante conhecer o potencial da tecnologia de Social BPM e avali-la quanto ao uso em seus contextos de trabalho ou pesquisa. O principal objetivo discutir como as

    Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SBSI 2015, May 2629, 2015, Goinia, Gois, Brazil. Copyright SBC 2015.

    Alternative Title: Social BPM: Business Processes, Collaboration and Social Technology

    XI Simposio Brasileiro de Sistemas de Informacao, Goiania - GO, 26 a 29 de Maio de 2015.

    32

  • tecnologias colaborativas se encaixam no ciclo de BPM, avaliando seus potenciais benefcios e desafios. O restante deste artigo est organizado da seguinte forma: a Seo 2 apresenta uma breve fundamentao terica sobre os conceitos-chave de BPM e colaborao. A Seo Err