concepts and values mário tomás catarina rodrigues andré rodrigues 20/05/09

Concepts and Values

Mário TomásCatarina RodriguesAndré Rodrigues

20/05/09

1-Investigating the Role of ‘Soft Issues’ in the RE Process

Autores do artigo:Sarah ThewAlistar Sutcliffe

2


Politicas Sentimentos das PessoasProblemas no

processo RE

Taxonomia de Utilizadores:

-Valores-Motivações

-Emoções

3


-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ções sentimentos

Respostas emocionais

Valores + Emoções Ajudam a interpretarRequisitos e a prever as suas acções e respostas.

4


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


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


Emoções:8


Como Usar:

Questionários?

Entrevistas?

Técnicas Etnográficas?

Cenários?

Storyboards?

Avaliação de protótipos?

9


10


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

2-Value-driven Service Matching

Autores do artigo:Jaap GordijnSybren de KinderenRoel Wieringa

12

Introdução


VoiceOver IP

Internet Access

...

E-Services

Economia

FamilyComunication

Organização:

Serviços estruturados por catálogos

13


Consequências Positivas/Benefícios para Cliente

E-services

QualidadesFunções

14


Problema/Necessidade

Consequências

Relacionar necessidades com serviços

Serviços

Prioridades

Consequências adicionais

15

ConsequênciasDurante 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

Restrições:S1 relação de suporte com S2;S1 exclui S2;Etc.


Benefícios

Catálogo de serviços

Relacionar necessidades com serviços

Consequênciasrealizar

Agregação de serviços

17


Catálogo de serviços do KPN18

3- Revisiting the Core Ontology and Problem in Requeirements Engineering

Autores do artigo:Ivan J.JuretaJohn MylopoulosStéphane Faulkner

19


-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:

Desejos Intenções AtitudesCrenças

Formulação de ontologia que capture estes elementos.

20


Introdução

Na metodologia de Zave and Jackson:

-Resolver um problema de requisitos éK, S | - R

S – EspecificaçãoK – Assunção de domínioR- Requisito

Problemas:

1-Um deles é não permite os requisitos não funcionais2-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


Stakeholders comunicam informação ao Eng.. de software no processo de RE.

Classifica Informação

Eng. SW

-Requisitos-Outros

22


Tipos de Discurso:

-Assertivos-Directivos-Comissivos – ‘Commissives’-Expressivos-Declarativos-Declarativos representativos

Desejos Intenções AtitudesCrenças

Capturar e distinguir entre

à medida que são comunicados

23


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


Ontologia:

Desejos levam a requisitosCrenças levam às assunções de domínioIntenções levam a especificações

Conteúdo do tipo:-Assertivo, declarativo ou representativo declarativo discurso que passa para o

eng. SW é uma (B) CrençaDirectivo, passa desejosCommisive, passa intençãoExpressiva, atitudes.

25


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


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

4- Info Cases

Como integrar Uses Cases e

Modelos de Domínio

Autores do artigo:Michel H.FortunaCláudia M.L. WernerMarcos R.S. Borges

28

Info Cases

Introdução

Use Case

Domain Model

Modelar um Sistema:

Info Cases

29

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

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

Info Cases

Modelo integrador;

Usa as características do Use Case, dando maiordetalhe à troca de mensagens;

Uma descrição detalhada da troca de mensagens entreactores e Use Cases providencia elementos para obteruma parte do DM;

Modelo Info Cases32

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

Info Cases

Composição do Modelo de Info Cases:

-Interface que representa os Fluxos

-Dicionário, para elementos dos fluxos

34

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ênciade mais do que um identificador na interface informacional.(Ex:o par <order_id,table_id>);

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 DM35

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

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

Comparação38

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çãoPaper1: 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

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

Comparação

?

41

Mário TomásCatarina RodriguesAndré Rodrigues

concepts and values mário tomás catarina rodrigues andré rodrigues 20/05/09

Documents