O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

Padrões Aplicados a Padrões Aplicados a Engenharia de RequisitosEngenharia de Requisitos

Profº Kleber R. Oliveira

2008

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Padrões na Engenharia de Software

Padrões de Arquitetura

Padrões de implementação

PadrõesOrganizacionais

Padrões de Processos

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Compreensão do Problema

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Fator Crítico de Sucesso

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Epistemologia

AlexanderGamma

Portland Coplien

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Padrões Para Solução de Problema

01

• 1979 – Christopher Alexander – Arquitetura Urbanista;

• 1993 – Erich Gamma et al. – Padrões de Projetos;

• 1996 – Richard Gabriel – Padrões de Arquitetura;

• 1997 – Suzanne & James Robertson – Padrões de Requisitos;

• 2001 – Will Wright – Jogos (SymCity);

• 2002 – Deutsches Elektronen-Synchrotron (DESY) – Padrões de Requisitos (repositórios);

• 2005 - Lasse Harjumaa - Improving the software inspection process with patterns

• 2007 – Stephen Withall - Introduction to Software Requirement Patterns

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Mastering the Requirements Process: Suzanne, James Robertson -1999

Suzanne e James Robertson – Padrões de

Requisitos

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Lasse Harjumaa - Improving the software inspection process with

patterns

Harjumaa, Lasse, Improving the software inspection process with patternsFaculty of Science, Department of Information Processing Science,

University of Oulu, Finland (2005)

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Deutsches Elektronen-Synchrotron (DESY) – Padrões de Requisitos

(repositórios)

Deutsches Elektronen-Synchrotron (DESY). http://repare.desy.deWorking Group on Requirements Engineering Patterns (WGREP)

German Informatics Society (GI)2002-2008

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Stephen Withall - Introduction to Software Requirement Patterns

Stephen Withallwww.withallyourequire.com

Introduction to Software Requirement Patterns -2007

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Mineração dos Padrões

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Construção de Padrões para Requisitos

Alexander “Notes on the Synthesis of form” (1964 – Harvard Press) .

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Observação de Projetos Semelhantes

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Dimensão de Conflitos: forças opostas (segundo Alexander

(1979))

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Definição das Forças

Contém o Requisito ou parte do problema [R] que precisa ser conduzido, as duas Forças contraditórias [F←] e [F→] que caracterizam o problema, a Ação ou método de eliciação [A] que pode contribuir com a Solução [S] resolver o problema ou atender ao requisito. A seguir, a fórmula simplificada da estrutura

Padrão = (R, F←, F→, S, A) ou “se F← mas F→ então S por A para R”

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Extraindo Padrões (Projeto A)

Parte do Problema (A)

“... os usuários deverão utilizar apenas partes do sistema que lhe são atribuídos de acordo com suas funções dentro da sua unidade, com objetivo de padronizar as formas de acessos. Deverá ser flexível aos usuários, pois um funcionário em determinadas ocasiões poderá substituir outro colaborador em horários diferentes...”

(Ação) Técnica de Eliciação Aplicada

Caso de Uso, Observação e Análise de Protocolo.

Solução

Criar um controle de acesso aos usuários com senhas com controle de prioridades de acessos aos usuários que se relacionem as unidades do software.

Tipo de Requisito Funcional

Descrições

id = “usuários”R = “utilizar o sistema”F = “padronizar as formas de acessos”F = “deve ser flexível aos usuários”A = caso de uso; observação; análise de protocolo.S = criar um controle de acesso aos usuários com senhas

Vetor

(id, R, F←, F→,S, A) (usuários, utilizar o sistema, padronizar as formas de acessos, dever ser flexível aos usuários, criar um controle de acesso aos usuários com senhas, [caso de uso, observação e análise de protocolo])

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Extraindo Padrões (Projeto B)

Parte do Problema(B)

“... os operadores deverão ter um controle rigoroso de acesso ao sistema, pois estes terão suas produtividades gerenciadas. Nenhum usuário poderá ter acesso à senha alheia, mas poderá utilizar terminais diferentes de acordo com a ordem de chegada na empresa...”.

Técnica de Eliciação Aplicada

Caso de Uso, Observação e Análise de Protocolo.

Solução Criar um controle de acesso aos usuários com senhas

Tipo de Requisito Funcional

Descrições

id = “operadores/usuário”R = “acesso ao sistema”F = “nenhum usuário poderá ter acesso à senha alheia”F = “poderá utilizar terminais diferentes”A = caso de uso; observação; análise de protocolo.S = criar um controle de acesso aos usuários com senhas

Vetor

(id, R, F←, F→,S, A) (operadores/usuários, acesso ao sistema, nenhum usuário poderá ter acesso à senha alheia, poderá utilizar terminais diferentes, criar um controle de acesso aos usuários com senhas, [caso de uso, observação e análise de protocolo])

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Extraindo Padrões (Projeto C)

Parte do Problema(C)

“... cada usuário terá um perfil para utilização do sistema, onde o software terá que ser customizado de acordo com a função de cada funcionário. Será gerado um controle (log) de acesso, e este será independente do terminal utilizado pelo usuário. Haverá a flexibilidade de um usuário do mesmo nível utilizar os privilégios de outro usuário, quando este estiver ausente e o caso for urgente..”

Técnica de Eliciação Aplicada

Caso de Uso, Observação e Análise de Protocolo.

SoluçãoCriar um controle de acesso aos usuários com senhas individuais uma também genéricas (mantendo o mesmo usuário) que possam ser utilizadas em qualquer terminal.

Tipo de Requisito Funcional

Descrições

id = “usuário”R = “utilização do sistema”F = “customizado de acordo com a função de cada funcionário”F = “flexibilidade de um usuário do mesmo nível utilizar os privilégios de outro usuário”A = caso de uso; observação; análise de protocolo.S = criar um controle de acesso aos usuários com senhas

Vetor

(id, R, F←, F→,S, A) (operadores/usuários, acesso ao sistema, nenhum usuário poderá ter acesso à senha alheia, poderá utilizar terminais diferentes, criar um controle de acesso aos usuários com senhas, [caso de uso, observação e análise de protocolo])

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Extraindo Padrão (Candidato 1)

A.1.1 – Extraindo Padrão Candidato IÉ feita a organização das observações comuns:A = (Id1,R1, F←1, F→1,S1,A1) B = (Id2,R2, F←2, F→2,S1,A1)C = (Id1,R2, F←3, F→3,S2,A1), onde,Id1 = “usuários”.Id2 = “operadores”.R1 = “utilizar o sistema”.R2 = “acesso ao sistema”.[F← 1,2,3 ] = “padronizar as formas de acessos”; “nenhum usuário poderá ter acesso à senha alheia”; “customizado de acordo com a função de cada funcionário”.[F→ 1,2,3 ] = “deve ser flexível aos usuários em geral” ; “poderá utilizar terminais diferentes”; “flexibilidade de um usuário do mesmo nível utilizar os privilégios de outro usuário”.S1 = “criar um controle de acesso aos usuários com senhas”.A1 = [caso de uso; observação; análise de protocolo].

Identificado os padrões descobertos em diferentes padrões pelo processo de eliciação, é feita a filtragem dos elementos comuns e a adição das forças que influenciam o padrão candidato.

P1 = (R2, F← 1,2,3, F→ 1,2,3,S1,A1)

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Leitura do Padrão Candidato 1

“É preciso padronizar os acessos dos usuários ao sistema, permitindo a customização de acordo com a função de cada usuários,

MAS o controle deve ser flexível aos diversos níveis funcionais, podendo ser utilizado em diferentes pontos de acessos,

ENTÃO é preciso criar um controle de acesso aos usuários através de senhas e privilégios,

ELICIADO POR caso de uso; observação; análise de protocolo,

PARA que possibilite o acesso ao sistema de forma segura e eficiente.”.

“É preciso padronizar os acessos dos usuários ao sistema, permitindo a customização de acordo com a função de cada usuários,

MAS o controle deve ser flexível aos diversos níveis funcionais, podendo ser utilizado em diferentes pontos de acessos,

ENTÃO é preciso criar um controle de acesso aos usuários através de senhas e privilégios,

ELICIADO POR caso de uso; observação; análise de protocolo,

PARA que possibilite o acesso ao sistema de forma segura e eficiente.”.

P1 = (R2, F← 1,2,3, F→ 1,2,3, S1, A1)

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Organização dos Padrões

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Descrição do Padrão Candidato 1

•Nome: USER•Contexto: Na identificação dos usuários que terão acesso ao Sistema da Informação.•Problema: Acesso ao sistema.•Forças: “padronizar o controle de acesso”; “nenhum usuário poderá ter acesso à senha alheia”; “customizado de acordo com a função de cada funcionário”; “deve ser flexível aos usuários em geral”; “poderá utilizar em pontos de acessos diferentes”; “flexibilidade à usuários do mesmo nível”.•Método Eliciação: Caso de uso, observação e análise de protocolo.•Solução: Criar um controle de acesso aos usuários com senhas.•Exemplos: Através de casos de usos é feita a identificação dos usuários e os processos organizacionais as quais estes participam. A observação também contribui para eliciar operadores que eventualmente utilizarão o sistema e que de certa maneira influenciam em alguma etapa do processo, e que podem gerar risco no armazenamento dos dados, comprometendo as informações geradas. A análise de protocolo é importante no momento de padronizar o modo de cada usuário utilizar o sistema, e é o método que mais contribui na identificação do problema relacionado a classificação dos usuários que influenciam direta ou indiretamente na operacionalidade dos sistemas. Identificados e classificados os usuários, é possível especificar um controle de acesso que envolva todos os tipos de usuários existentes na organização.

•Nome: USER•Contexto: Na identificação dos usuários que terão acesso ao Sistema da Informação.•Problema: Acesso ao sistema.•Forças: “padronizar o controle de acesso”; “nenhum usuário poderá ter acesso à senha alheia”; “customizado de acordo com a função de cada funcionário”; “deve ser flexível aos usuários em geral”; “poderá utilizar em pontos de acessos diferentes”; “flexibilidade à usuários do mesmo nível”.•Método Eliciação: Caso de uso, observação e análise de protocolo.•Solução: Criar um controle de acesso aos usuários com senhas.•Exemplos: Através de casos de usos é feita a identificação dos usuários e os processos organizacionais as quais estes participam. A observação também contribui para eliciar operadores que eventualmente utilizarão o sistema e que de certa maneira influenciam em alguma etapa do processo, e que podem gerar risco no armazenamento dos dados, comprometendo as informações geradas. A análise de protocolo é importante no momento de padronizar o modo de cada usuário utilizar o sistema, e é o método que mais contribui na identificação do problema relacionado a classificação dos usuários que influenciam direta ou indiretamente na operacionalidade dos sistemas. Identificados e classificados os usuários, é possível especificar um controle de acesso que envolva todos os tipos de usuários existentes na organização.

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Aplicação dos Padrões

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Benefícios dos Padrões

24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

Publicações

OLIVEIRA, Kleber Rocha de; SPINOLA, Mauro de Mesquita.POREI: Patterns-Oriented Requirements Elicitation Integrated – Proposal of a Metamodel Patterns-Oriented for Integration of the Requirement Elicitation Process In: EURO AMERICAN ASSOCIATION ON TELEMATICS AND INFORMATION SYSTEMS - EATIS 2007, Faro/Algarve - Portugual, 14-17 May 2007. (The ACM Digital Library )

http://portal.acm.org/citation.cfm?id=1352694.1352738&coll=portal&dl=ACM&type=series&idx=SERIES11637&part=series&WantType=Proceedings&title=EATIS&CFID=71555655&CFTOKEN=94354131

OLIVEIRA, Kleber Rocha de; SPINOLA, Mauro de Mesquita. POREI: Patterns-Oriented Requirements Elicitation Integrated: Proposta de um Metamodelo Orientado à Padrão para Integração do Processo de Eliciação de Requisitos. In: 6th LATIN AMERICAN CONFERENCE ON PATTERN LANGUAGES OF PROGRAMMING - SugarLoafPLoP 2007, Porto de Galinhas/PE. 23-30 Maio, 2007.

http://sugarloafplop.dsc.upe.br

OLIVEIRA, Kleber Rocha de; SPINOLA, Mauro de Mesquita. PORE Patterns-Oriented Requirements Engineering - Proposta de um Metamodelo Orientado ao Processo de Especificação de Requisitos de Software. In: XIII SIMPÓSIO DE ENGENHARIA DE PRODUÇÃO - SIMPEP, Bauru/SP. 2006.

OLIVEIRA, Kleber Rocha de; SPINOLA, Mauro de Mesquita. Evolução da Gerência das Mudanças de Requisitos de Sistemas da Informação Baseado no PMBOK. In: CONGRESSO INTERNACIONAL DE GESTÃO DA TECNOLOGIA E SISTEMAS DE INFORMAÇÃO, São Paulo. 2º CONTECSI. 2005.

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O? Onde Começar a

Pesquisar ?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

O q

ue é

VIR

TU

ALI

ZA

ÇÃ

O?

Agradecimentos

"The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed

technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done

wrong. No other part is more difficult to rectify later". (F. Brooks, "No Silver Bullet", IEEE Computer, 1987)

kleber.oliveira@poli.usp.br Eu nunca te abandonarei.