GORE e as principais técnicas de especificação 2

GOREe as principais técnicas de

especificação

2

Agenda• Motivação Goal-Oriented Requirements

Engineering (GORE)

• GORE - Especificação de requisitos

– GBRAM

– GRL

– KAOS

3

Motivação GORE

• Métodos tradicionais se preocupam apenas com o que deve ser feito.

• Métodos orientados a metas se preocupam com o “porquê” e “como”.

4

Métodos GORE• Perguntam porque uma certa funcionalidade

é necessária e como ela pode ser implementada.

• Mantém a razão para a funcionalidade do sistema através do conhecimento do porquê.

• Rastreiam diferentes alternativas de implementação e o critério de seleção entre estas alternativas.

5

GORE

• O que é uma meta?

– Existem várias definições na literatura.

– Para contextualizar:

• É um objetivo do sistema sob consideração que deve ser alcançado.

• Formulações de metas se referem a propriedades que pretende-se garantir.

6

Métodos GORE

• Existem métodos GORE para atender as principais atividades da ER.

• A tabela presente em [Kavakli 2003] mostra as principais técnicas divididas por atividades da ER.

7

Métodos GORE

8

GBRAM

9

GBRAM

• GBRAM é a sigla para Goal-Based Requirements Analysis Method.

• É utilizado para identificar, aprimorar, refinar e organizar metas para a especificação de requisitos.

10

GBRAM

• O método é focado em duas perspectivas:

– Análise de Metas

– Evolução de Metas

11

GBRAM

• Antes de conhecermos o método em si, vamos conhecer:

– Terminologia.

– Alguns conceitos chave.

12

GBRAM - Conceitos

• Metas

– São objetivos de alto nível do negócio, organização ou sistema. Capturam as razões que justificam a necessidade do sistema.

• Requisitos

– Especificam como uma meta deve ser cumprida por um sistema proposto.

13

GBRAM - Conceitos

• Operacionalização

– É o processo de definir uma meta suficientemente detalhada de forma que suas sub-metas tenham uma definição operacional.

• Metas de Realização

– São objetivos de alguma corporação ou sistema.

– Exemplo: Alistar estudantes nos cursos antes do início das aulas.

14

GBRAM - Conceitos

• Metas de Manutenção

– São aquelas metas que são satisfeitas enquanto sua condição alvo permanecer verdadeira.

– Tendem a ser operacionalizadas como ações ou restrições que previnem certos estados de serem atingidos.

• Agentes

– São as entidades ou processos que realizam metas dentro de uma organização ou sistema.

15

GBRAM - Conceitos

• Restrições

– São requisitos que devem ser conhecidos para a realização da meta.

– Uma restrição coloca uma condição para a realização da meta.

• Decomposição de Metas

– É o processo de subdivisão de um conjunto de metas em um subconjunto lógico.

– Facilita o entendimento, definição e especificação dos requisitos do sistema.

16

GBRAM - Conceitos

• Cenários

– São descrições comportamentais de um sistema e seu ambiente em situações restritas.

– Exemplificam comportamentos permitindo que necessidades escondidas sejam descobertas.

– São úteis para avaliar alternativas de projeto e validar projetos.

• Obstáculos de Meta

– São comportamentos ou outras metas que bloqueiam a realização de uma determinada meta.

– Abstrair e identificar obstáculos de meta permite considerar os possíveis caminhos para metas falharem e antecipar casos de exceção.

17

• Análise de Metas

– Exploração de documentação

– Organização das metas

– Classificação das metas.

• Evolução de Metas

– Avalia a maneira que as metas mudam em todo o ciclo de vida do método.

GBRAM - Conceitos

18

GBRAM

• Agora vamos conhecer todas as atividades associadas a cada perspectiva.

• Conheceremos as atividades através de um estudo de caso.

19

GBRAM – Estudo de Caso

• Informações– CTTS (Sistema de Gerenciamento de Curso

de Carreiras).

– Reengenharia de negócios para uma base de força aérea (AFB).

– Aproximadamente 155 funcionários da AFB são alistados no treinamento por ano.

20

GBRAM – Análise de Metas

• Identificar metas

– Analisando as informações disponíveis foram encontradas 36 metas.

– Algumas destas metas são:

21

GBRAM – Análise de Metas

• Classificar metas de realização e manutenção

– Existem várias perguntas que ajudam a classificar as metas. Por exemplo:

• “Esta meta denota um estado que foi alcançado ou um estado desejado?” (Realização)

• “A realização desta meta é requerida continuamente?” (Manutenção)

22

GBRAM – Análise de Metas

• Classificar metas de realização e manutenção

– Exemplo: a meta “Dinheiro dos pagadores de taxas gasto eficientemente” deve ser executada de forma contínua.

– Esta meta caracteriza uma condição que deve ser mantida verdadeira.

23

GBRAM – Análise de Metas

• Identificar agentes e stakeholders

– Agentes são identificados para determinar os responsáveis por realizar uma meta em um dado momento.

– Stakeholders são identificados para desenvolver um entendimento dos diferentes pontos de vista envolvidos no sistema para a resolução de conflitos.

24

GBRAM – Análise de Metas

• Identificar agentes e stakeholders

– Uma meta pode ter um ou mais stakeholders associados.

– Exemplo: A meta “Conhecimentos profissionais melhorados” é de interesse do empregado e da AFB.

25

GBRAM – Evolução de Metas

• Reduzir o tamanho do conjunto de metas e clareá-las.

– Existem três abordagens:

• Eliminar metas duplicadas• Refinar metas baseado nas entidades do sistema• Consolidar metas sinônimas

26

GBRAM – Evolução de Metas

• Reduzir o tamanho do conjunto de metas e clareá-las.

– Refinar metas baseado nas entidades do sistema:

• Exemplo: a meta “Processo HRD concluído” deve ser refinada para entendermos tal processo.

• Especificamente neste caso esta meta se transformou em duas: “Vagas disponíveis no curso anunciadas” e “Pessoal qualificado identificado”.

27

GBRAM – Evolução de Metas

• Reduzir o tamanho do conjunto de metas e clareá-las.

– Consolidar metas sinônimas:

• Exemplo de metas similares: “Conhecimentos melhorados” e “Qualificações melhoradas”.

• A meta “Conhecimentos melhorados” representa bem as duas metas.

28

GBRAM – Evolução de Metas

• Reduzir o tamanho do conjunto de metas e clareá-las.

– As metas de realização do CTTS foram afetadas utilizando as técnicas de refinamento mostradas.

– O número de metas de realização diminuiu de 27 para 19.

29

GBRAM – Evolução de Metas

• Usar restrições

– Exemplo: “O curso deve qualificar o empregado para avançar para outro nível”.

– Antes do empregado poder avançar seu nível de certificação ele deve participar de um curso que o qualifique para o avanço.

30

GBRAM – Evolução de Metas

• Usar restrições

– Por causa da restrição, a meta “Cursos que o empregado se qualifica identificados” foi identificada.

31

GBRAM – Evolução de Metas

• Aprimorar e refinar metas

– Relações de dependência

• Maneira de considerar outros possíveis aprimoramentos e refinamentos.

• São definidas através das perguntas:

– “Quais metas são pré-requisito para esta meta?”

– “Quais metas devem seguir esta meta?”.

32

GBRAM – Evolução de Metas

• Identificar obstáculos de metas

– É útil considerar casos específicos que devem ser tratados devido a atividades que impedem a realização da meta.

– Exemplo: “De quais outras metas ou condições esta meta depende?”

33

GBRAM – Evolução de Metas

• Identificar obstáculos de metas

– A realização da meta “Portfolio de carreira disponibilizado” depende da cooperação do surpevisor.

– Caso não exista tal cooperação surge um obstáculo.

34

GBRAM – Evolução de Metas

• Identificar cenários

– A identificação de obstáculos inicia na identificação de caminhos nos quais as metas podem falhar.

– Cenários aprimoram esta informação.

– Cenários são instâncias dos obstáculos.

35

GBRAM – Evolução de Metas

• Identificar cenários

– Exemplo: dado o obstáculo “Sem vagas disponíveis”.

– Através da pergunta “Quais são as circunstâncias sob as quais este obstáculo pode ocorrer?

• “Todos os cursos fechados (vagas preenchidas)”.

• “Curso cancelado”.

36

GBRAM – Evolução de Metas

• Operacionalizar metas

– Informações das metas devem ser traduzidas para uma especificação de requisitos.

– Isto é feito através da consolidação das informações das metas em um conjunto de esquemas de metas.

37

GBRAM – Evolução de Metas

• Operacionalizar metas

– Esquemas de metas especificam os relacionamentos entre metas e agentes em termos de eventos que causam a mudança de estado.

38

GBRAM – Evolução de Metas

• Operacionalizar metas

39

GRL

40

GRL

• GRL é a sigla para Goal-oriented Requirement Language.

• Dá suporte à modelagem e a justificativa de requisitos orientados a metas.

– Própria para requisitos não-funcionais.

41

GRL

• Fornece diversas construções para expressar vários tipos de conceitos que surgem durante o processo de requisitos.

• Existem três principais categorias destes conceitos.

– Elementos intencionais.

– Ligações.

– Atores.

42

GRL

• Suporta avaliação sobre cenários.

– A modelagem de cenários é complementar à de metas.

• Ajuda na identificação de mais metas e cenários importantes.

• Contribui para a completude e precisão dos requisitos.

43

GRL

• Elementos intencionais

– São chamados intencionais por causa da capacidade de responder questões:

• O porquê de comportamentos particulares.

• Aspectos informacionais e estruturais que foram escolhidos para serem incluídos nos requisitos do sistema

– Alternativas existentes.

– O porquê da escolha de uma alternativa em detrimento da outra.

44

GRL

• Elementos intencionais

– Goal

– Task

– Resource

– Softgoal

– Belief

45

GRL

• Elementos intencionais

– Definição de um elemento intencional:

46

GRL – Elementos intencionais

• Meta (Goal)

– É uma condição que os stakeholders gostariam de alcançar.

– Não se especifica como alcançá-la.

• Permite que alternativas possam ser consideradas.

47

GRL – Elementos intencionais

• Meta (Goal)

– Pode-se classificar uma meta como:

• Meta de negócio

– Expressa metas relativas ao negócio ou a algo que a organização quer alcançar.

• Meta de sistema

– Expressa metas que o sistema alvo deve alcançar (geralmente descrevem os requisitos funcionais).

48

GRL – Elementos intencionais

• Meta (Goal)

– É representada graficamente por um retângulo arredondado

– Exemplo: VoiceConnectionBeSetup

• Meta básica para qualquer sistema de telecomunicação.

• Existem várias formas de configurar a conexão de voz.

49

GRL – Elementos intencionais

• Tarefa (Task)

– Especifica uma forma particular de se fazer algo.

– Podem ser vistas como soluções em um sistema alvo.

50

GRL – Elementos intencionais

• Tarefa (Task)

– É representada graficamente por um hexágono.

– Exemplo: MakeVoice-Over-LAN

• É uma forma particular de configurar uma conexão de voz.

51

GRL – Elementos intencionais

• Recurso (Resource)

– É uma entidade física ou informacional.

– Disponibilidade é a principal preocupação.

52

GRL – Elementos intencionais

• Recurso (Resource)

– É representado graficamente por um retângulo.

– Exemplo: LAN Bandwidth

• Largura de banda deve estar disponível na arquitetura voz sobre LAN.

53

GRL – Elementos intencionais

• Meta Flexível (Softgoal)

– É uma condição que o ator gostaria de alcançar.

– Diferente da meta normal.

• Não há um critério bem definido para determinar se a condição foi alcançada.

54

GRL – Elementos intencionais

• Meta Flexível (Softgoal)

– É representada graficamente por uma forma curvilínea irregular.

– Exemplo: Reliability of Router

• A confiança no roteador é uma softgoal que deve ser alcançada durante o projeto de um sistema de telecomunicação.

55

GRL – Elementos intencionais

• Crença (Belief)

– São usadas para representar argumentos de projeto.

– Permitem que características do domínio sejam consideradas e corretamente refletidas dentro de um processo de tomada de decisão.

– Facilita uma posterior revisão, justificativa e mudança do sistema.

56

GRL – Elementos intencionais

• Crença (Belief)

– É representada graficamente por uma elipse.

– Exemplo:

• Este argumento apóia a task VoiceLAN como um redutor de custos.

57

GRL

• Relacionamentos intencionais

– Ligam os elementos intencionais.

• Existem cinco tipos:

– Decomposition

– Means-Ends

– Contribution

– Correlation

– Dependency

58

GRL

• Relacionamentos intencionais

– A definição dos relacionamentos intencionais:

59

GRL – Relacionamentos intencionais

• Means-Ends

– A sentença MEANS-END descreve como as metas são de fato alcançadas.

– Cada tarefa fornecida é um meio alternativo para alcançar a meta.

60

GRL – Relacionamentos intencionais

• Means-Ends

– Exemplo gráfico:

61

GRL – Relacionamentos intencionais

• Decomposition

– É a sentença que permite definir quais outros elementos precisam estar disponíveis para realizar uma tarefa.

• Estes elementos podem ser: tasks, goals, resources ou softgoals.

62

GRL – Relacionamentos intencionais

• Decomposition

– Exemplo gráfico:

63

GRL – Relacionamentos intencionais

• Contribution

– É a sentença que descreve como elementos intencionais contribuem entre si.

– Existem vários tipos: AND, OR, MAKE, BREAK, HELP, HURT, SOME-, SOME+, EQUAL, UNKNOWN.

64

GRL – Relacionamentos intencionais

• Contribution

– Exemplo gráfico:

65

GRL – Atores

• É uma entidade ativa que realiza ações para alcançar metas.

• É representado graficamente por um círculo.

• Exemplo:

66

GRL – Atores

• Opcionalmente pode haver uma fronteira que define o escopo de atuação do ator.

• É representada por um círculo tracejado cinza.

• Exemplo:

67

GRL – Relacionamentos intencionais

• Dependency

– É a sentença que descreve um relacionamento intencional entre dois atores.

68

GRL – Relacionamentos intencionais

• Dependency

– Exemplo gráfico:

• Vários atores e

dependências

69

GRL – Relacionamentos intencionais

• Correlations

– Funciona da mesma forma que Contributions.

– A diferença é que a correlação é um desejo explícito e a contribuição é um efeito colateral.

70

KAOS

71

KAOS

• É uma metodologia.

• Tem o propósito de suportar todo o processo de elaboração de requisitos, a partir das metas de alto nível a serem alcançadas.

• Fornece:

– Linguagem de especificação.

– Método de elaboração.

72

KAOS

• Antes de conhecermos a linguagem e método vamos conhecer:

– Terminologia

– Alguns conceitos

73

KAOS

• Objeto

– É algo de interesse no sistema cujas instâncias podem evoluir de estado.

– São caracterizados por declarações de atributos e constantes.

– Podem ser organizados em hierarquia de herança.

74

KAOS

• Objeto

– Entidade: é um objeto independente.

– Relacionamento: é um objeto dependente de objetos que os ligam.

– Evento: é um objeto instantâneo.

75

KAOS

• Operação

– É uma relação de entrada e saída sobre os objetos.

– Operações quando aplicadas definem transições de estado.

– São caracterizadas por pré-condições, pós-condições e condições de gatilho.

76

KAOS

• Agente

– É um objeto ativo que age como processador para algumas operações.

– Realiza uma operação, quando alocada a ele.

– Monitora e controla um objeto se os estados do objeto são observáveis e controláveis por ele.

– Podem ser humanos, dispositivos, programas, entre outros.

77

KAOS

• Meta

– É um objetivo que o sistema deve satisfazer.

– Captura um conjunto de comportamentos desejados.

78

KAOS

• Meta

– Existem dois tipos de refinamento que relacionam as metas com as sub-metas:

• AND-refinement

– A única condição suficiente para satisfazer a meta é satisfazer todas as sub-metas.

• OR-refinement

– Satisfazer uma das sub-metas é condição suficiente para satisfazer a meta.

79

KAOS

• Meta

– Pode (opcionalmente) ser caracterizada por um atributo de prioridade:

• Especifica se a meta é obrigatória ou opcional.

– São classificadas de acordo com a categoria dos requisitos que irão lidar.

80

KAOS

• Meta

– Metas funcionais resultam em requisitos funcionais.

– Por exemplo: SatisfactionGoals

• São relacionadas com a satisfação das requisições dos agentes.

81

KAOS

• Meta

– Metas não-funcionais resultam em requisitos não-funcionais.

– Por exemplo: AccuracyGoals

• São relacionadas com a manutenção da consistência entre o estado dos objetos no ambiente e o estado de suas representações no software.

82

KAOS

• Meta

– O refinamento da meta termina quando as metas terminais são atingidas.

– Uma meta terminal pode ser formulada em termos de estados controláveis por algum agente individual.

– Um requisito é uma meta terminal designada a um agente no ambiente.

– As metas terminais são operacionalizadas por operações e objetos.

83

KAOS

• Propriedade de domínio

– É uma propriedade sobre os objetos ou operações no ambiente que existe independentemente do sistema a ser construído.

– Incluem leis da física, regulamentos, restrições impostas por agentes ambientais, entre outros.

84

KAOS

• Cenário

– É uma seqüência consistente de domínio das transições de estado controladas por instâncias dos agentes correspondentes.

– Consistência de domínio significa que a operação é aplicada em um estado que satisfaz sua pré-condição de domínio, resultando em um estado que satisfaz sua pós-condição de domínio.

85

KAOS

• Cada construção na linguagem tem uma estrutura genérica de dois níveis:

– Uma camada de rede semântica exterior.

• Declara um conceito, seus atributos e suas várias ligações a outros conceitos.

– Uma camada de declaração interna para definir formalmente o conceito.

86

KAOS

• Exemplo de especificação para um sistema de despacho de ambulância:

87

KAOS

• A primeira parte da declaração:

– Introduz um conceito do tipo Goal: AmbulanceMobilization.

• Declara uma propriedade alvo que deve eventualmente manter, referindo-se a objetos, tais como, Call ou Ambulance.

– Refina a meta de origem AmbulanceIntervention.

• Refinado em sub-metas IncidentFiled, AmbulanceAllocated e AllocatedAmbulanceMobilized.

– E uma definição informal.

88

KAOS

• A segunda parte da declaração (opcional):

– Define a meta em termos formais usando uma lógica temporal de tempo real.

– Os operadores de lógica temporal utilizados são:

89

KAOS – Método de elaboração

90

KAOS – Método de elaboração

• Elaboração de meta

– Elabora a estrutura AND/OR da meta.

• Define metas e suas ligações de refinamento até alcançar as metas designáveis.

• A identificação de metas é realizada geralmente através de uma combinação de processos top-down e bottom-up.

– Metas descendentes são identificadas através de questões “Como?”

– Metas de origem são identificadas através de questões “Porque?”

91

KAOS – Método de elaboração

• Captura dos objetos

– Identifica os objetos envolvidos nas formulações das metas.

• Define suas ligações conceituais.

• Descreve suas propriedades de domínio por constantes.

92

KAOS – Método de elaboração

• Captura das operações

– Identifica transições do estado do objeto que são significantes para as metas.

– As formulações de metas referem aos estados desejados ou proibidos.

• São alcançáveis apenas através de transições de estado.

93

KAOS – Método de elaboração

• Operacionalização

– Deriva:

• As (pré-, pós- e gatilho) condições em operações.

• Constantes em objetos.

94

KAOS – Método de elaboração

• Designação de responsabilidade

– Identificar responsabilidades alternativas para metas terminais.

– Designar as operações para os agentes que podem realizá-las.

– As várias metas terminais se tornam requisitos.

95

Conclusões

• Avanço a engenharia de requisitos orientada a metas.

• Supõe-se que esta abordagem é bastante proveitosa.

• Captura dos requisitos de forma mais eficaz.

• Evita que alguns projetos fracassem.

96

Referências

• [Kavakli 2003] Kavakli, E. and P. Loucopoulos (2003). Goal driven requirements engineering: Evaluation of current methods. 8th CAiSE/IFIP8.1 International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design (EMMSAD'03), Velden, Austria.

• [Annie 1996] Annie, I. A. (1996). Goal-Based Requirements Analysis. Proceedings of the 2nd International Conference on Requirements Engineering (ICRE '96), IEEE Computer Society.

• [Annie 1997] Annie, I. A. (1997). Goal identification and refinement in the specification of software-based information systems, Georgia Institute of Technology.

• [Annie 1998] Annie, I. A. and P. Colin (1998). The use of goals to surface requirements for evolving systems. Proceedings of the 20th international conference on Software engineering. Kyoto, Japan, IEEE Computer Society.

97

Referências

• [GRL 2008] GRL – Goal-Oriented Requirement Language Disponível em: http://www.cs.toronto.edu/km/GRL/.

• [Anne 1993] D. Anne, L. Axel van, and F. Stephen, Goal-directed requirements acquisition. Sci. Comput. Program. 20 (1993) 3-50.

98