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.