Supporting Use Case Based Requirements Engineering David Marques Filipe Garcês Ricardo Cruz

Conteúdos Contexto Motivação Estado da arte Principais resultados Conclusões Contexto Motivação Estado da arte Principais resultados Conclusões ERSS

Contexto - Informações Autor: Stéphane S. Somé Ano: 2005 Publicação: Information and software technology 48 (2006) Autor: Stéphane S. Somé Ano: 2005 Publicação: Information and software technology 48 (2006) ERSS3

Contexto - Temas Engenharia de requisitos Linguagem Natural UML Modelo de domínio Casos de uso Modelo de estados Prototipagem Engenharia de requisitos Linguagem Natural UML Modelo de domínio Casos de uso Modelo de estados Prototipagem ERSS4

Motivação Engenharia de requisitos é uma tarefa critica Casos de Uso e UML com grande aceitação Processo manual Processo informal Engenharia de requisitos é uma tarefa critica Casos de Uso e UML com grande aceitação Processo manual Processo informal ERSS5

Motivação Simulação por prototipagem é um processo custoso Verificação tardia entre requisitos e especificação pretendida Verificação de consistência entre casos de uso é difícil Verificação do comportamento global é quase impossível Simulação por prototipagem é um processo custoso Verificação tardia entre requisitos e especificação pretendida Verificação de consistência entre casos de uso é difícil Verificação do comportamento global é quase impossível ERSS6

Estado da arte Linguagem natural para descrição de casos de uso Trabalhos efectuados por: Rolland & Ben Achour Fantechi Cockburn Padrões de linguagem Evitar erros e ambiguidades Linguagem natural para descrição de casos de uso Trabalhos efectuados por: Rolland & Ben Achour Fantechi Cockburn Padrões de linguagem Evitar erros e ambiguidades ERSS7

Estado da arte Composição de cenários Caso de uso é composto por um ou mais cenários Representados de forma gráfica (diagramas de sequência,…) Play-in/Play-out (Harel and Marelly) Composição de cenários Caso de uso é composto por um ou mais cenários Representados de forma gráfica (diagramas de sequência,…) Play-in/Play-out (Harel and Marelly) ERSS8

Estado da arte Vista do sistema em Grey box/ Black box UML: diagramas de classes, de casos de uso, de estados REST (Requirements Engineering with Scenario Tool) Vista do sistema em Grey box/ Black box UML: diagramas de classes, de casos de uso, de estados REST (Requirements Engineering with Scenario Tool) ERSS9

Nova aproximação Processo formal Processo automático Apoiado por uma ferramenta: UCEd Clarificação dos requisitos Processo formal Processo automático Apoiado por uma ferramenta: UCEd Clarificação dos requisitos ERSS10

Sintaxe abstracta dos casos de uso Sintaxe baseado no template de Cockburn Dois tipos de casos de uso: normal e extensos Cada caso de uso é um tuplo com titulo, passos, alternativas, pré- condição e pos-condição Definição completa e não ambigua. Sintaxe baseado no template de Cockburn Dois tipos de casos de uso: normal e extensos Cada caso de uso é um tuplo com titulo, passos, alternativas, pré- condição e pos-condição Definição completa e não ambigua ERSS11

Sintaxe abstracta dos casos de uso ERSS12

Linguagem natural Casos de uso definidos por dois componentes básicos: operações e condições Gramática inglesa para definir a sua descrição textual Módulo de Edição de casos de uso no UCEd Verificação automática da sintaxe Casos de uso definidos por dois componentes básicos: operações e condições Gramática inglesa para definir a sua descrição textual Módulo de Edição de casos de uso no UCEd Verificação automática da sintaxe ERSS13

Linguagem natural ERSS14

Modelo de domínio Extensão do diagrama de classes UML Serve de dicionário Define os conceitos do sistema e as suas relações Cada conceito é definido por: Valores possíveis Operações possíveis Extensão do diagrama de classes UML Serve de dicionário Define os conceitos do sistema e as suas relações Cada conceito é definido por: Valores possíveis Operações possíveis ERSS15

Modelo de domínio Integrado no UCEd Possibilidade de criação manual do modelo ou Criação automática a partir dos casos de uso Verificação constante da consistência entre casos de uso e modelo de domínio Integrado no UCEd Possibilidade de criação manual do modelo ou Criação automática a partir dos casos de uso Verificação constante da consistência entre casos de uso e modelo de domínio ERSS16

Modelo de estados Geração feito por um algoritmo Gera todos os cenários possíveis Pode conter sequências inválidas UCEd integra os casos de uso e o modelo de domínio e gera o modelo de estados Geração feito por um algoritmo Gera todos os cenários possíveis Pode conter sequências inválidas UCEd integra os casos de uso e o modelo de domínio e gera o modelo de estados ERSS17

Simulação UCEd possui um módulo de simulação Validação feita pelo modelo de estados gerado Simulação pode ser feita muito cedo Possibilidade de ver o comportamento global do sistema Interface gráfica UCEd possui um módulo de simulação Validação feita pelo modelo de estados gerado Simulação pode ser feita muito cedo Possibilidade de ver o comportamento global do sistema Interface gráfica ERSS18

Simulação ERSS19

Nova aproximação Nova aproximação ao processo de engenharia de requisitos ERSS20

Conclusões Formalização do processo de engenharia de requisitos Visão unificada dos requisitos Aplicação simples que integra todos os passos Verificação automática de erros Formalização do processo de engenharia de requisitos Visão unificada dos requisitos Aplicação simples que integra todos os passos Verificação automática de erros ERSS21

Futuro Introdução de notações personalizadas nos casos de uso Suporte para requisitos não-funcionais Integração da OCL (Object Constraint Language) Transição da fase de requisitos para fase de desenho (Casos de uso para cenários) Introdução de notações personalizadas nos casos de uso Suporte para requisitos não-funcionais Integração da OCL (Object Constraint Language) Transição da fase de requisitos para fase de desenho (Casos de uso para cenários) ERSS22

Questões Modelo de estados é util sendo que sequências inválidas têm de ser removidas manualmente? Poderá usar-se esta solução em qualquer contexto? Como proceder num ambiente em que não o inglês? Formalização do processo não torna o processo muito restrictivo? Modelo de estados é util sendo que sequências inválidas têm de ser removidas manualmente? Poderá usar-se esta solução em qualquer contexto? Como proceder num ambiente em que não o inglês? Formalização do processo não torna o processo muito restrictivo? ERSS23