Um Estudo Comparativo de Ontologias de Processo de Software

2. Um Estudo Comparativo de Ontologias de Processo de Software Marcelo José SiqueiraCoutinho de Almeida Prog. de Pós-Graduação em Informática – Cin/UFPE Doutorado em Computação Inteligente – 2008.2 mjsca@cin.ufpe.br

3. Agenda • Introdução • Motivação • Objetivos • Conceitos Básicos de Ontologias • SPO • CMMI-SW • Comparações • Conclusões • Referências

4. Conhecimentoé o entendimento de uma área de um determinado assunto. (Durkin, 1994). Conhecimento inclui conceitos e fatos sobre um determinado assunto, assim como as relações entre esses conceitos e os mecanismos sobre como combiná-los para resolver problemas naquela área (Gazevic et al., 2006).

5. Introdução • Nos últimos anos, ontologias vêm sendo utilizadas nos mais diferentes tipos de aplicações: • Bancos de Dados (Integração de Esquemas) • Redes de Computadores (Gerência de Redes) • Sistemas Distribuídos (Web Services Semânticos). • Engenharia de Software (Especificação de Requisitos, Análise e Projeto, etc.)

6. Motivação • Ontologias podem contribuir com a Qualidade dos Processos de Software: • Construção de um modelosemânticoque acompanhe todo o ciclo de vida do software durante o desenvolvimento ou que represente formalmente os processos da organização. • Implantação de programas de qualidade fornecendo um vocabuláriocomum entre especialistas e entre estes e os demais usuários da organização. • Integração de diferentes modelos de qualidade de software.

7. Objetivos • Analisar e compreender como as ontologias podem ser utilizadas no contexto da Qualidade de Processos de Software, bem como poder elencar quais são suas possíveis vantagens e desvantagens.

8. Abordagem • Coletar e examinar alguns trabalhos abordados nas referências: • Soydan e Kokar, 2006 • Liao et al., 2005 • Estabelecer comparações • Apresentar conclusões

9. Ontologia • É a ciência do ser (Aristóteles). • É a especificação formal e explícita de uma conceitualização compartilhada (Gruber, 1993). • Define as classes, propriedades, relacionamentos, funções e axiomas de um determinado domínio (Gomés-Pérez et al., 2006).

10. Exemplo de umaOntologia • Ambiente de Ensino: atributos INF011 Data: 11/11/08 Assunto: Java URL: ... Disc01 Instância de Disciplina Aula Instância de INF012 tem Turma Instância de dá Comparece à Nome: Manoel Mat: 111 Formação: CC atributos Professor matriculaem Aluno01 Nome: João Mat: 1000 CRE: 7.0 Aluno Instância de ensina Instância de É um atributos Aluno02 Prof01 Orienta dor Instância de Nome: José Mat: 2000 CRE: 8.0 Orienta

11. Exemplo de umaOntologia • Axioma • Uma propriedade que é assumida como verdadeira em um dado domínio e momento. • Exemplos: • Um corpo não pode estar em dois lugares no mesmo instante. • Para se criar uma turma é preciso que pelo menos cinco alunos se matriculem nela. • Linguagens de Representação do Conhecimento são utilizadas para representar o conjunto de axiomas: • Linguagens Clássicas de Primeira Ordem • Linguagem de Descrição Lógica (OWL, LOOM) • Linguagens de Restrição (OCL / UML)

12. Utilidade de umaOntologia • Ajudar as pessoas a compreender melhor uma certa área de conhecimento (Reforço); • Ajudar as pessoas a atingir um consenso no seu entendimento sobre uma área de entendimento (Comunicação); • Ajudar outras pessoas a compreender uma certa área de conhecimento (Aprenzidado).

13. Visão de um SBC Agentes Interface de Acesso (Queries) RACIOCÍNIO AUTOMÁTICO Base de Conhecimento (ex. Ontologia) Sistema Especialista

14. Engenharia de Ontologias • Conjunto de atividades relacionadas com: • O processo de desenvolvimento de ontologias. • O ciclo de vida da ontologia • Ferramentas e linguagens que apóiam seu desenvolvimento e uso

15. Engenharia de Ontologias • Metodologias • Cyc • TOVE • Methontology • 101 • OntoAgile • RapidOWL

16. Engenharia de Ontologias • Ferramentas • JENA (Hewllet-Packard) • Pellet • OKBC • Protégé (Stanford University)

17. Ontologias e Web Semântica

18. UmaOntologia de Qualidade de Software Katia Duarte e Ricardo Falbo Departamento de Computação Universidade Federal do Espírito Santo, Brasil.

19. UmaOntologia de Qualidade de Software • Desenvolvido por (Duarte e Falbo, 2002) • Motivação: • Programas de qualidade são compostos por uma grande quantidade de conceitos, termos, relações, regras, etc. • Não existe consenso em torno da terminologia utilizada, o que prejudica a definição de um programa de qualidade.

20. UmaOntologia de Qualidade de Software • Desenvolvimento: • Modelo construído usando LINGO (LINGuagem Gráfica para descrever Ontologias) (Falbo, 1998) • Dicionário de Termos • Axiomas em Linguagem de Primeira Ordem • Integração com uma ontologia de processos de software

21. UmaOntologia de Qualidade de Software • Questões de Competência: • Qual é a natureza de uma característica de qualidade? • Que características de qualidade são relevantes para um dado artefato, atividade ou processo? • Como uma característica de qualidade pode ser medida? • Que métricas podem ser usadas para quantificar uma dada característica?

22. UmaOntologia de Qualidade de Software • Aspectos fundamentais identificados: • Características de qualidade: Natureza e Estrutura (questões 1 e 2) • Qualidade: Como Medir (questões 3 e 4)

23. UmaOntologia de Qualidade de Software • Aspecto 1: Características de qualidade: Natureza e Estrutura

24. UmaOntologia de Qualidade de Software • Aspecto 1: Características de qualidade: Natureza e Estrutura Dicionário de Termos: Ontologia de Qualidade.

25. UmaOntologia de Qualidade de Software Dicionário de Termos: Ontologia de Processo.

26. UmaOntologia de Qualidade de Software • Aspecto 1: Características de Qualidade: Natureza e Estrutura • Axiomas: cq: característica de qualidade. subcarq:subcaracterística de qualidade carqdirm: característica de qualidade indiretamente mensurável

27. UmaOntologia de Qualidade de Software • Aspecto 2 : Como Medir

28. UmaOntologia de Qualidade de Software

29. UmaOntologia de Qualidade de Software • Usos da Ontologia: • Desenvolvimento de uma ferramenta que disponibiliza um tutorial sobre Qualidade de Software. • Ferramenta CASE de apoio ao planejamento e controle da qualidade de sistemas Orientado a Objetos.

30. Comentários • LINGO não apresenta qualquer diferencial semântico em relação às diferentes linguagens de modelagens existentes (p. ex. UML). • Baixa expressividade com usuários de UML • Falta de comprometimento com padrões de qualidade tais como CMMI ou ISO/IEC 15504. • Necessidade ser estendido.

31. Software ProcessOntology Li Liao, Yuzhong Qu e Hareton K. L. Leung Dept. of Computer and Engineering Southest University, China.

32. SPO (Software Process Ontology) • Abordagem baseada em ontologias para expressar processos de software em um nível conceitual. • Características: • Semântica rica • Estensibilidade • Reusabilidade • Baixo custo

33. Motivação • Atualmente existem inúmeros modelos de processos de software: • ISO/IEC 15504 • BOOTSTRAP • CMMI • Trillium

34. Motivação • Problema: • Descrição formal dos modelos de processos • Quase todos os modelos de processos existentes são empíricos ou descritivos: ausência de uma descrição formal e rigorosa • Avaliação dos processos por meio de checklist • Ambigüidade, instabilidade,subjetividade excessiva e imprecisão (Conradi e Fuggeta, 2002) • Solução: • Ontologias podem eliminar confusão conceitual e terminológica, e fornecer uma representação especializada do vocabulário • Conceitos e termos unificados permitem compartilhamento do conhecimento e o torna mais claro

35. Motivação • Problema: • Compatibilidade e Transformabilidade • Fundamentais para as organizações de software • Compatibilidade entre os diferentes modelos de processos correntes e os resultados das avaliações (Lopez, 2001) • Solução: • Criação de ontologias para os processos correntes e utilização de técnicas de alinhamento torna desnecessária a realização de ajustes nos modelos. • As ontologias permitem que os resultados das avaliações para diferentes processos sejam comparados.

36. Arquitetura Abstrata Atividade ISO/IEC 15504 Prática CUS.3.BP4 “Capturar todos os requisitos e todas mudanças de requisitos” Atividade CMMI Prática REQM.SP.1.3-1 Extensão

37. Taxonomia dos Componentesdos Modelos

38. Comparação: CMMI e ISO/IEC 15504

39. Gráfico RDF da SPO Organization ProcessCategory hasProcess belongToCategory Practice owl:Thing Process processAttribute hasPractice 1+ rdfs:SubclassOf includePratice rdfs:SubclassOf rdfs:SubclassOf CompositeProcess BasicPractice AtomicPractice BasicProcess 1+ includeProcess rdfs:SubclassOf ... AP1 APn

40. Gráfico RDF da CMMI-Onto Organization ProcessCategory hasProcess belongToCategory Practice owl:Thing Process processAttribute hasPractice 1+ rdfs:SubclassOf includePratice rdfs:SubclassOf rdfs:SubclassOf CompositeProcess BasicPractice AtomicPractice BasicProcess 1+ includeProcess rdfs:SubclassOf rdfs:SubclassOf rdfs:SubclassOf rdfs:SubclassOf APn ... REQM ... CM REQM.SG1 ... CM.SG3 REQM1.SP1.1-1 ... CM1.SP1.1-1 AP1

41. Uso das Ontologias • Uso da Ontologia • Ferramenta baseada em Web para avaliação de processos • Disponível em http://www.cse.seu.edu.cn:8080/spo/index.jsp

42. Comentários • Trabalho aborda dois dos principais modelos de avaliação (CMMI e ISO/IEC 15504): • Favorece utilização • Utiliza linguagens de Representação do Conhecimento bastante conhecidas (padrões W3C): RDF e OWL: • Favorece aceitação e utilização por diversas ferramentas. • Não foi possível identificar detalhes a respeito da valiação da ontologia e do SBC.

43. CMMI-SW Ontology Golkhan Halit Soydan and Mieczyslaw M. Kokar Departament of Eletrical and Computer Engineering Northeastern University, USA.

44. Introdução • Desenvolvimento de um SBC de apoio à preparação de empresas para o processo de avaliação do CMMI. • Baseado em ontologias. • Inicialmente apenas para tratar o CMMI-SW. • Capaz de responder a perguntas tais como: • Observado-se os processos atuais, a organização se encontra em que nível de maturidade? • Quais são os pontos que devem ser atendidos para que a organização atinja um determinado nível CMMI?

45. Motivação • Complexidade do modelo CMMI-SW • Grande quantidade de conceitos interrelacionados de muitas formas. • Mesmo para especialistas, checar todo o processo é um processo muito tedioso. • Modelos podem sofrer alterações • P. ex.: um novo tipo de prática é aceito pela indústria ou um novo objetivo é identificado como necessário para satisfazer uma área de processo específica. • Especialistas precisariam ser retreinados a fim de dominar as novas práticas e as organizações se readaptarem às mudanças. • Pessoas estão propensas a erros • Ferramentas não são propensas a erros, são mais rápidas e apresentam um custo menos para serem utilizadas.

46. RepresentaçãoGráfica

47. Nível de Topo <owl:Classrdf:ID="Maturity_Level_5"> <owl:equivalentClass> <owl:Class> (…) <owl:Restriction> <owl:someValuesFrom> <owl:Classrdf:about="#Decision_Analysis_and_Resolution"/> </owl:someValuesFrom> <owl:onProperty> <owl:ObjectPropertyrdf:about="#consistsOf"/> </owl:onProperty> </owl:Restriction> <owl:Restriction> <owl:someValuesFromrdf:resource="#Integrated_Project_Management"/> <owl:onProperty> <owl:ObjectPropertyrdf:about="#consistsOf"/> </owl:onProperty> </owl:Restriction> </owl:intersectionOf> </owl:Class> <owl:Class> <owl:intersectionOfrdf:parseType="Collection"> <owl:Restriction> <owl:someValuesFrom> <owl:Classrdf:about="#Organizational_Process_Definition"/> </owl:someValuesFrom> <owl:onProperty> <owl:ObjectPropertyrdf:about="#consistsOf"/> </owl:onProperty> </owl:Restriction>

48. NívelSecundário

49. Relacionamento entre Subclasses

50. ValidaçãodaOntologia • Realização de vários casos de teste usando dados realistas: • Resultados de avaliações do SEI Appraisal Program • Standard CMMI Appraisal Method for Process Improvement (SCAMP-ISM) • Conjuntos de dados de 15 organizações diferentes. • Para uma organização nível 5 foram criadas pelo menos 249 instâncias (nível 4: 231, nível 3: 213; nível 2: 93). • Várias ferramentas foram usadas: • ConsVISor (consistência), BaseVISor, Pellet e Racer (raciocinadores).