Palestra Roel Wieringa - Design Science

Design Science é orientada a solução enquanto a ciência natural é orientada a problemas.

O ciclo da engenharia:

Investigação do problema -> Design do tratamento -> Validação do design -> Implementação do tratamento -> evolução da implementação


A primeira fase envolve a investigação quanto aos objetivos e aos fenômenos envolvidos.

Na segunda o design da interação entre o artefato e o contexto.

Na terceira a validação quanto ao atendimento aos critérios e a efetividade.

Na quarta ocorre a aplicação prática.

Na última fase a evolução da implementação.

Design Science aplica o ciclo da engenharia para  projetar um artefato para aprimorar questões do contexto do problema de forma  a fornecer informações e artefatos sobre o problema.

O ciclo empírico:

Investigação do conhecimento sobre o problema -> Design da pesquisa -> Validação do Design -> Execução da Pesquisa -> Evolução

A primeira fase envolve a investigação quanto aos objetivos e aos fenômenos envolvidos.

Na segunda o design da interação entre o artefato e o contexto.

Na terceira a validação quanto ao atendimento aos critérios e a efetividade.

Na quarta ocorre a aplicação prática.

Na última fase a evolução da implementação.

O ciclo empírico é aplicado de forma a fornecer conhecimento e para responder questões sobre um artefato em um contexto.

Aula 9: Mapeamento entre Tropos + AORML

Contexto:
Antes de Propor um sistema organizacional deve-se analisar quais componentes estão presentes. Para resolver essas questões sobre a organização e dar um diagnóstico pode-se utilizar o tropos como ferramenta de gestão do conhecimento. É importante ser realista em relação a veracidade das informações em relação a empresa e suas características.

Integração de Ferramentas:

Devido a limitação do tropos foi necessário integra-lo com o AORML. A combinação foi feito com as técnicas de MDD. Dessa forma os modelos foram integrados mantendo a rastreabilidade.

Problema Não Solução (CIM)

Independente de Plataforma (PIM)

Modelo Específico de Plataforma (PSM)

A proposta de mapeamento baseado em MDD:

Através do mapeamento foi possível conseguir perceber coisas que seriam inviáveis como o fato de que uma delegação gera um compromisso. A tabela de conversão tornou possível gerar o diagrama de agentes.

Aula 8: Continuação da análise I* e análise de modelos

Dependência : Ocorrem relações com mesma função (construct overload)

Dependência foi dividido em :

dependência: Definida por uma relação formal entre atores.

Delegação: definida por relação material que depende de um relator para ocorrer.

Open Dependency 

Ator -> hard goal -> ator

Close Dependency                   |

                                                |   A forma como atingir o objetivo

Ator -> tarefa -> ator               |

A distinção sintática de delegação e dependência se dá com a seta preenchida e vazia respectivamente.

Conclusão sobre análise I*:

A análise completa dos elementos e relações levou a uma nova semântica para as representações sintática de I* baseando-se em razões ontológicas. Busca-se agora fazer experimento para comprovar eficácia.

Analisando os exemplos propostos pela comunidade I* verificou-se vários anti-padrões como elementos do mesmo tipo em decomposições e problemas de orientação quanto as regras de utilização. 

Aula 7 : Continuação Ontologia I*

I*

O I* apresenta alguns problemas quanto a sua aplicação direta na indústria devido a falta de ferramentas e conceitos que variam de acordo com a implementação. Isso já foi provado empiricamente. O I* provê um guideline para orientar a sua utilização, mas diversas das demonstrações não são apoiadas teoricamente. Por exemplo, não existe justificativa para não relacionar tarefa com soft goal.

O metadmodelo do I* facilita o entendimento esclarecendo algumas regras nas não resolve todos os problemas de semântica. Perguntas como: O que é uma tarefa? Qual a diferença entra soft e hard goal. Surgem então as ontologias para o I*.

OntoIStarML e OntoIStar

O OntoIStarML busca um isomorfismo com o metamodelo usando o modelo de referência UFO. Para isso são feitas extensões da UFO. Para poder extender UFO é preciso buscar soluções na filosofia e áreas afim para encaixar corretamente os novos conceitos e evitar os overloads, e ambiguidades.

Decomposições

Or-Decomposition

Para que o Goal 0 seja alcançado, ao menos um dos que estão ligados a ele tem de ter sido alcançado.

Logo: Goal 0 <-> Goal 1 v Goal 2 v Goal 3

And-Decomposition

Para que o Goal 0 seja alcançado, todos que estão ligados a ele tem de ter sido alcançado.

Logo Goal 0 <-> Goal 1 /\ Goal 2 /\ Goal 3

Means-end

São associações que relacionam objetivos (Goal 0) com tarefas ou artefatos (Tarefa e Artefact).

Em resumo, Means-End relacionam coisas de tipos diferentes e Decomposition decompõe coisas de mesmo tipo.

Tabela de relacionamento Means-End x Decomposition

A tabela mostra as conclusões chegadas pelo estudo.

Aula 6: Aplicação de Ontologias em Engenharia de Software

ODE: Ambiente de desenvolvimento para processos de software baseado em ontologias. Eram ferramentas isoladas que foram integradas e posteriormente foi migrado pra web e agora está na fase de integração com outras ferramentas.
A ferramenta possibilita dentre outras funcionalidades alocar recursos, atividades e a gerência de projetos.


Projeto da Gleice: O trabalho em questão visava a integração com o dotProject (Ambiente de Gerência de Projeto) que é um software livre. Essa ferramenta cobre alguns aspectos que ainda não existiam no ODE como cronogramas. Primeiramente, o trabalho visava uma integração com o alocaODE, porém foi ampliado para outros módulos do ODE.

Desenvolvimento:

Foi realizado uma integração semântica entre as ferramentas visando a minimização dos conflitos. Para isso foi utilizado o processo OBA-SI desenvolvido por (Calhau, 2011). Tal processo foi fundamental para integração pois serviu como guia para a integração semântica desejada.

Com base no SPOPL que é uma core ontology para processos de software foi então desenvolvido a ontologia de processos que envolvesse a criação do cronograma no ODE.

Mapeamento vertical: Para realizar o mapeamento vertical foi feito a engenharia reversa do dotProject. Assim foi possível o mapeamento e posteriormente conseguiu-se chegar ao modelo de integração e ao mapeamento horizontal entre o modelo e as ferramentas.

Foram ignorados os aspectos que não eram implementados pelo dotProject e também houveram limitações tecnológicas para o mediador que integrou as ferramentas. Como resultado foi possível vizualisar o cronograma  no ODE.

Quinta Aula

Quinta aula - Análise I* Framework

O I* foi desenvolvido para modelar aspectos da engenharia de requisitos baseada em objetivos. Seu uso foi aproveitado em outras áreas como na área de requisitos de segurança e sistemas que verificam conformidade com as leis.

O I* compreende os seguintes conceitos:

Entidades
       Ator
      Objetivo - Hard Goal (critério)/ Soft Goal (não funcional)
      Tarefa - (passo a passo para objetivo)
      Recurso - (objetivo físico ou informação)

Relações
      Dependência - interação entre atores
      Decomposição - Decompor objetivos
      Meio - fim - Entidades diferentes
      Contribuição - Determinar o efeito de um objetivo em outro por exemplo nota > 7 contribui para             aprovação

tarefa x decomposição de objetivo - depende do contexto e do que se deseja modelar.


I* não define precedência porque não é aplicada pra processos e sim em níveis mais estratégicos.

Diagramas

Dependência estratégica:

Dependência entre atores, exemplo é a dependência entre o gerente e o membro nos dois sentidos para participação em reunião e para marcar reunião respectivamente. Ainda é possível a dependência de um ator em relação a um recurso como por exemplo a dependência de um sistema de calendário compartilhado para verificação de horários livres. Dessa forma contribui-se para os objetivos soft de maximizar grau de participação e minimizar o esforço de agendamento.

Razão estratégica:

Objetivos do ator tarefa ou recurso.

Exemplo:

O ator gerente pode ter objetivo de marcar reunião que se decompõem (AND) em escolher horário e coleta de horários disponíveis. O segundo se decompõem (XOR) na coleta pessoal ou coleta por sistema. A coleta por sistema decompõem-se (AND) em manter agenda e selecionar horários disponíveis. Já a coleta pessoal pode ser por telefone ou por email. Ainda pode-se decompor o objetivo de escolher horário de forma a demonstrar a contribuição dos soft goals e o relacionamento com as tarefas de selecionar data da reunião e de selecionar horário.

Esses diagramas são importantes porque são alternativas documentadas que demonstram o porque de uma certa escolha através de um critério explícitos, ou seja, uma análise de alternativa documentada.

Problema de Interoperabilidade I*

Projetistas da Linguagem => Implementações, Extensões .. etc => Usuário

O que escolher? Como representar conceitos?

Existem conceitos presentes em algumas ferramentas que não estão em outras e conceitos que são utilizados de formas diferente. A conclusão foi criar um consenso entre os conceitos núcleo para que fossem usados de forma uniforme. O propósito é que a linguagem saia da academia e se torne um padrão da indústria.

Existe uma linguagem de intercambio em XML que resolve problemas sintáticos. Logo a ideia era resolver problemas semânticos para propor guias de modelagem. Para isso usou-se ontologias para que ficasse explícito os compromissos ontológicos da linguagem de modelagem. Sabe-se que o contrário de um Ontologia é uma má Ontologia.

UFO-C para mapear os conceitos do I*

Ao mapear de 1-1 os conceitos da ontologia de fundamentação (UFO) para a linguagem de modelagem precisa-se analisar os seguintes problemas:

Contruct Overload - Um conceito da linguagem mapear dois conceitos da ontologia de fundamentação

Construct Redundancy - Dois conceitos da linguagem mapear o mesmo da LF.

Construct Excess - Um conceito da linguagem sem relação

Incompleteness - Um conceito da LF sem relação com o da linguagem.

Então foi feito o mapeamento entre a linguagem e a UFO-C

Um agente foi mapeado como ator, um resource é um object. O object não tem mental moment que pode ser uma crença ou uma intenção. O objetivo (Goal) tem que estar ligado com uma intenção e uma proposição. E ele pode ser Soft ou Hard. O Soft está relacionado a uma situação que impacta na realização ou não de uma crença. Já o Hard altera o mundo quando satisfeito. A tarefa é uma ação realizada por um ator.

Means End

Para solucionar as diferentes aplicações do conceito de Means End foi proposto a diferenciação entre Means End XOR e AND.

Um recurso é meio se em todas instâncias a tarefa tem como parte a participação daquele recurso. Exemplo:
A escada é um recurso essencial para a tarefa de subir escada.

Somente tarefas e recursos podem ser usados como means end. Objetivos já possuem OR e AND na decomposição.

Quarta aula: UFO-C aplicada a Engenharia de Software

Durante a aula, foram tecidos comentários sobre a ontologia de fundamentação para modelagem de domínios sociais da UFO, a UFO-C.

Como forma de estudo, foi proposto a leitura do artigo “Using a Foundational Ontology for Reengineering a Software Process Ontology”, dos autores, Ana C. O. Bringuente, Ricardo A. Falbo, Giancarlo Guizzardi. Este artigo descreve um caso de uso da UFO-C no domínio de Engenharia de Software.

Abaixo segue descrito uma ficha de leitura feita pelo grupo para o artigo.

Referência Completa: “Using a Foundational Ontology for Reengineering a Software Process Ontology”, Ana C. O. Bringuente, Ricardo A. Falbo, Giancarlo Guizzardi, UFES;

Palavras-chave: UFO-C, Engenharia de Software, Software Process Ontology (SPO), reengenharia ontológica;

Resumo

- Foco do artigo

Aplicar a UFO a engenharia de software (Gerência de Projeto e Processos de Desenvolvimento de Software), através de uma reengenharia de conceitos.

- UFO-C

Está porção da UFO pode ser entendida como a ontologia das entidades sociais. Nesta ontologia de fundamentação é possível modelar agentes que tem poder de criar ações, perceber acontecimentos de eventos e possuir intenções próprias.

- SPO: Software Process Ontology (Falbo e Bertollo, 2009)

O trabalho trata de uma reengenharia na proposta do SPO. Sua pretensão é de reestruturá-la, utilizando a UFO-C para isso. Os autores do trabalho apresentam as ontologias iniciais de Falbo e Bertollo e tecem críticas a cerca delas. A partir disso, propõem modificações nestas ontologias, acrescentando conceitos definidos na UFO-C.

Este trabalho defende a ideia de que, utilizando de uma ontologia de fundamentação (UFO-C) que estruture a organização dos conceitos mais primitivos de um domínio social, seja possível evitar possíveis erros de modelagem, ou seja, que utilizando a UFO-C, seria possível verificar a falta de conceitos em uma modelagem (conceitos ocultos), bem como possíveis relacionamentos errôneos.

Principais ideias

• Uso da UFO-C como premissa para modelagem de ontologias cujo domínio seja de estruturas sociais. 
• Utilização de padrões ontológicos para modelagem (uso de ontologias de fundamentação);

Aspectos Positivos

• Demonstrar a possibilidade de se descobrir conceitos não "percebidos" durante a modelagem, apenas utilizando uma ontologia de fundamentação como premissa de modelagem (Design Patterns);
• Demonstrar a aplicabilidade da UFO-C em um domínio real.

Aspectos Negativos

• Faltou demonstrar uma ontologia usando OntoUML, facilitaria a leitura.

Ideias que surgiram com a leitura

• A facilidade que pode se tornar a modelagem, tendo como base os padrões de modelagem ontológica (Design Patterns).