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.