Concepts and Values Mário Tomás Catarina Rodrigues André Rodrigues 20/05/09.

Apresentação em tema: "Concepts and Values Mário Tomás Catarina Rodrigues André Rodrigues 20/05/09."— Transcrição da apresentação:

1 Concepts and Values Mário Tomás Catarina Rodrigues André Rodrigues 20/05/09

2 1-Investigating the Role of Soft Issues in the RE Process Autores do artigo: Sarah Thew Alistar Sutcliffe 2

3 1-Investigating the Role of Soft Issues in the RE Process Politicas Sentimentos das Pessoas Problemas no processo RE Taxonomia de Utilizadores: -Valores -Motivações -Emoções 3

4 1-Investigating the Role of Soft Issues in the RE Process -Método trabalha a partir das emoções dos stakeholders Fase de Análise. Valores: Relacionados com crenças e atitudes Influenciam eventos motivações personalidade Respostas e reacções resultam acçõessentimentos Respostas emocionais Valores + Emoções Ajudam a interpretar Requisitos e a prever as suas acções e respostas. 4

5 1-Investigating the Role of Soft Issues in the RE Process Conceitos: -Confiança -Moral/Ética -Estético -Segurança -Sociabilidade - Criatividade/Inova ção Características das pessoas: (Relacionadas às motivações) -Introvertido/Extrovertido -Sensível/Intuitivo -Thinking/feeling -Judging/perceiving Taxonomia : Crenças e Atitudes 5

6 1-Investigating the Role of Soft Issues in the RE Process 6

7 Motivações : É uma boa base para ajudar a organizar configurações e adaptações de Software Emoções : Boas para analisar a aceitação do projecto Detectadas -Linguagem Corporal -Tonalidade da voz -Expressões faciais 7

8 1-Investigating the Role of Soft Issues in the RE Process Emoções : 8

9 1-Investigating the Role of Soft Issues in the RE Process Como Usar : Questionários? Entrevistas? Técnicas Etnográficas? Cenários? Storyboards? Avaliação de protótipos? 9

10 1-Investigating the Role of Soft Issues in the RE Process 10

11 1-Investigating the Role of Soft Issues in the RE Process Conclusões: Autor pretende, que esta metodologia seja um complemento às existentes análises de requisitos não funcionais. O Autor pretende testar esta teoria em casos práticos, via case studies com participantes da indústria. 11

12 2-Value-driven Service Matching Autores do artigo: Jaap Gordijn Sybren de Kinderen Roel Wieringa 12

13 Introdução 2-Value-driven Service Matching VoiceOver IP Internet Access... E-Services Economia FamilyComunication Organização: Serviços estruturados por catálogos 13

14 2-Value-driven Service Matching Consequências Positivas/Benefícios para Cliente E-services QualidadesFunções 14

15 2-Value-driven Service Matching Problema/Necessidade Consequências Relacionar necessidades com serviços Serviços Prioridades Consequências adicionais 15

16 Consequências Durante a elaboração necessidade/desejo/procura podem ser encontradas restrições que se aplicam às consequências desejadas. Por exemplo: uma consequência C1 pode excluir C2 se querer C1 implica não querer C2, uma consequência C1 depende de C2 se C1 só pode existir se C2 existir, etc. 2-Value-driven ServiceMatching 16

17 Restrições: S1 relação de suporte com S2; S1 exclui S2; Etc. 2-Value-driven Service Matching Benefícios Catálogo de serviços Relacionar necessidades com serviços Consequências realizar Agregação de serviços 17

18 2-Value-driven Service Matching Catálogo de serviços do KPN 18

19 3- Revisiting the Core Ontology and Problem in Requeirements Engineering Autores do artigo: Ivan J.Jureta John Mylopoulos Stéphane Faulkner 19

20 3- Revisiting the Core Ontology and Problem in Requeirements Engineering -Zave and Jackson estabeleceram uma ontologia para RE, e é usada para formular problemas de requisitos. -Esta ontologia está incompleta. Não considera todos os tipos básicos de requisitos que os stakeholders transmitem: DesejosIntençõesAtitudesCrenças Formulação de ontologia que capture estes elementos. 20

21 3- Revisiting the Core Ontology and Problem in Requeirements Engineering Introdução Na metodologia de Zave and Jackson: -Resolver um problema de requisitos é K, S | - R S – Especificação K – Assunção de domínio R- Requisito Problemas: 1-Um deles é não permite os requisitos não funcionais 2-Uma especificação não pode ser melhor do que outra. 3-Não incorpora noções como a dos não funcionais e preferências 21

22 3- Revisiting the Core Ontology and Problem in Requeirements Engineering Stakeholders comunicam informação ao Eng.. de software no processo de RE. Classifica Informação Eng. SW -Requisitos -Outros 22

23 3- Revisiting the Core Ontology and Problem in Requeirements Engineering Tipos de Discurso: -Assertivos -Directivos -Comissivos – Commissives -Expressivos -Declarativos -Declarativos representativos DesejosIntençõesAtitudesCrenças Capturar e distinguir entre à medida que são comunicados 23

24 3- Revisiting the Core Ontology and Problem in Requeirements Engineering DOLCE ontologia funcional Boa para sobre linguagem natural e senso comum, foi definida para reflectir noções que depende da percepção, impressões culturais e convenções sociais dos humanos. Quatro categorias: -Endurant, Perdurant, Quality, Abstract. 24

25 3- Revisiting the Core Ontology and Problem in Requeirements Engineering Ontologia: Desejos levam a requisitos Crenças levam às assunções de domínio Intenções levam a especificações Conteúdo do tipo: -Assertivo, declarativo ou representativo declarativo discurso que passa para o eng. SW é uma (B) Crença Directivo, passa desejos Commisive, passa intenção Expressiva, atitudes. 25

26 3- Revisiting the Core Ontology and Problem in Requeirements Engineering Ontologia: Requisitos Funcionais: Na Ontologia, são Objectivos. (Goals) Requisitos Não Funcionais: Na Ontologia, são restrições de qualidade (Quality Constraint) Softgoals: Na Ontologia, são softgoals, são requisitos não funcionais abstractos (eg. Conveniência, segurança..) 26

27 3- Revisiting the Core Ontology and Problem in Requeirements Engineering Conclusão -A especificação não é só a satisfação de requisitos. -Mas sim, a que está mais perto de os satisfazer, e aos opcionais (Goal, Softgoal, Quality Constraint, Domain Assumption.. ), e que tem valores mais elevados nas atitudes dos stakeholders. 27

28 4- Info Cases Como integrar Uses Cases e Modelos de Domínio Autores do artigo: Michel H.Fortuna Cláudia M.L. Werner Marcos R.S. Borges 28

29 Info Cases Introdução Use Case Domain Model Modelar um Sistema: Info Cases 29

30 Info Cases Motivação Difícil obter: Domain Model A partir de Use Case Model Porquê? -Falta de preocupação -Difícil obter os elementos essenciais -A partir de um Use case podem-se obter vários DM diferentes entre si. 30

31 Info Cases Ideia Base: Apresentar um modelo que suprima estas falhas. A solução é apresentada em 2 passos: 1.a captura sistemática de elementos DM, enquanto se modela com os Use Cases; 1.uma descrição mais precisa desses elementos dentro da descrição de Use Cases; 31

32 Info Cases Modelo integrador; Usa as características do Use Case, dando maior detalhe à troca de mensagens; Uma descrição detalhada da troca de mensagens entre actores e Use Cases providencia elementos para obter uma parte do DM; Modelo Info Cases 32

33 Info Cases O Info Case usa uma interface infor- macional para descrever os fluxos (troca de mensagens); Os fluxos são representados pelas setas:->(input),<-(output); Fluxos Compostos Items Simples Items Compostos 33

34 Info Cases Composição do Modelo de Info Cases: -Interface que representa os Fluxos -Dicionário, para elementos dos fluxos 34

35 Info Cases Rule 1(classes) – Cada identificador gerado produz uma classe (Ex: Order(IC1),Item(IC5) e Table(Ic7)); Rule 2(associations) – associações são indicadas pela ocorrência de mais do que um identificador na interface informacional.(Ex: o par ); Rule 3(atributte determination) – se um elemento não identificador está presente num fluxo de um IC e é necessário num outro IC, deve ser considerado; Rule 4(constructors) – Cada identificador produz um construtor para cada classe que identifica; Especialização – algumas regras para obter o DM 35

36 Info Cases Conclusões: Vantagens Permite uma maior aproximação entre os Use Cases e os DM; Traz uma maior consistência na modelação das diferentes views sobre um sistema; Possibilidade de resolver ou reduzir as inconsistências entre Domain Models obtidos por diferentes modeladores; 36

37 Info Cases Conclusões Desvantagens Aumenta a complexidade na modelação do sistema; A existência de elementos redudantes num fluxo pode levar a uma especialização errada; 37

38 Comparação 38

39 Uma nova Ontologia, mais completa que já lida com crenças, desejos, intenções e atitudes. Suporta requisitos funcionais e não funcionais e tem novas formas para analisar a satisfação de um problema de RE. Comparação Paper1: Investigating the Role of Soft Issues in the RE Process Paper2: Value-driven Service Matching Paper3: Revisiting the Core Ontology and Problem in Requeirements Engineering Paper4: Info Cases Metodologia para de (Valores, Motivações, Emoções) capturados na Análise, gerar Requisitos Funcionais e não Funcionais. Modelo para a especificação de catálogos de serviços. Uma forma de apresentar serviços para que o cliente escolha de acordo com as suas necessidades. Extensão ao Modelo de Use Cases, para produzir um Domain Model mais automático, e integrado com os Use Cases. 39

40 Comparação O Paper 1 e 3, fornecem especificações completas de elementos que podem ser usados nas fases posteriores de produção de software. O Paper 4, contribui com um modelo de use cases e Domain model para as fases posteriores. 40

41 Comparação ? 41 Mário Tomás Catarina Rodrigues André Rodrigues