UNIVERSIDADE FEDERAL DE GOIÁS – UFG

CAMPUS CATALÃO – CaC

DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO – DCC

Bacharelado em Ciência da Computação

Projeto Final de Curso

Verificação e Refinamento de Requisitos em Árvore deCaracterísticas usando Linhas de Produtos de

Requisitos e Redes de Petri

Autor: Carla Ferreira Fernandes

Orientador: Liliane do Nascimento Vale

Catalão - 2012

Carla Ferreira Fernandes

Verificação e Refinamento de Requisitos em Árvore de Características

usando Linhas de Produtos de Requisitos e Redes de Petri

Monografia apresentada ao Curso deBacharelado em Ciência da Computação da

Universidade Federal de Goiás – Campus Catalãocomo requisito parcial para obtenção do título de

Bacharel em Ciência da Computação

Área de Concentração: Engenharia de SoftwareOrientador: Liliane do Nascimento Vale

Catalão - 2012

Ferreira, Carla Fernandes

Verificação e Refinamento de Requisitos em Árvore de Características

usando Linhas de Produtos de Requisitos e Redes de Petri/Carla Ferreira

Fernandes- Catalão - 2012

Número de paginas: 74

Projeto Final de Curso (Bacharelado) Universidade Federal de Goiás, CampusCatalão, Curso de Bacharelado em Ciência da Computação, 2012.

Palavras-Chave: 1. Redes de Petri. 2. Árvore de Caracteristicas. 3. Lógica Modal

Carla Ferreira Fernandes

Verificação e Refinamento de Requisitos em Árvore de Características

usando Linhas de Produtos de Requisitos e Redes de Petri

Monografia apresentada e aprovada em dePela Banca Examinadora constituída pelos professores.

Liliane do Nascimento Vale – Presidente da Banca

Vaston Gonçalves da Costa

Valquíria Aparecida Rosa Duarte

Aos meus pais Arlete e Écioque com muito orgulho formam a primeira filha.

AGRADECIMENTOS

Considerando esta monografia como resultado de uma caminhada que não começouna UFG, agradecer pode não ser tarefa fácil, nem justa. Para não correr o risco dainjustiça, agradeço de antemão a todos que de alguma forma passaram pela minha vida econtribuíram para a construção de quem sou hoje. E agradeço, particularmente, algumaspessoas que tiveram contribuição direta para a construção deste trabalho.

Primeiramente a Deus por ter me dado o dom da vida, por me guiar, dar forças esabedoria para concluir mais esta grandiosa etapa. Agradeço também aos meus pais, Écioe Arlete, por acreditarem em mim, por nunca terem medido esforços para me proporcionaruma boa base de estudos e por nunca terem me deixado desistir, como quis tantas vezes.Eles são responsáveis por cada sucesso obtido e cada degrau avançado na minha vida.

Aos meus amigos, em especial Elaine, Laisa e Nélio que me apoiaram, incentivaram eestiveram ao meu lado, concedendo-me coragem, força e sorrisos em todos os momentos.

A minha orientadora, Liliane, pela paciência, sabedoria e por ter acreditado em mim.Pela direção que me deu, pela sua competência, e conhecimento que me conduziram àconclusão deste trabalho. Pela palavra mágica em que me disse no momento certo: “Vocêé capaz ”. Sem esquecer do professor Vaston pelo amparo e fervorosa tentativa em memotivar ao citar Chico Xavier: “Crê em ti mesmo, age e verás os resultados. Quando teesforças, a vida também se esforça para te ajudar ”. Este, que, sempre que pôde, ajudou-me com todos os pormenores na construção deste. São frases singelas, mas que fizeramtoda a diferença na minha vida. E eis aqui o resultado, serei eternamente grata.

A todos os outros professores que passaram pela minha formação acadêmica.Vocês todos serão lembrados e referenciados como integrantes fundamentais de uma

das mais significantes etapas de minha vida.Obrigada seus lindos ♥ !

Retém a instrução e não a largues:

guarda-a, porque ela é a tua vida

Provérbios 4:13

RESUMO

Um dos problemas na construção de software advém da fase de identificação e elici-tação de requisitos. Muitas vezes os usuários e/ou clientes do software a ser construído,não compreendem bem os requisitos e funcionalidades essenciais que o sistema deveriaconter. Desta forma, repassam informações inconsistentes ao especialista, o que torna aconstrução mais difícil provocando o re-trabalho. Muitas técnicas de elicitação de requi-sitos se baseiam em informações textuais e por meio da linguagem natural, promovendoproblemas de interpretação ou ainda empregando casos de uso que são pobres em deta-lhes. De acordo com esta realidade, este trabalho propõe o uso da metodologia de Árvorede Características como parte do processo de eliticação dos requisitos. É uma técnicaque conta com a intensa participação do usuário e/ou cliente. Em seguida será realizadoum refinamento na Árvore de Características para eliminar problemas de ambigüidadee omissão de informações que são comuns em requisitos textuais. Para o processo, seráutilizado o conceito de Linhas de Produto de Software o qual abrange a gerência de vari-abilidade e similaridade de características de software, que resultará na árvore final. Daversão final da Árvore de Características, uma Linha de Produtos de Requisitos é obtida.Neste momento, serão feitas instâncias de características para a geração de produtos.Para a formalização desses produtos, a simulação e execução de diferentes cenários seráapresentada utilizando as Redes de Petri Ordinária e Colorida com expressões da Lógicamodal denominada de Rede de Petri com Modalidades, para avaliação de restrições nastransições da Rede de Petri e também para validação e garantia da corretude do modelo.

Palavras-Chaves: Redes de Petri, Árvore de Caracteristicas, Lógica Modal

ABSTRACT

One of the problems in the construction of software comes from the identificationphase and requirements elicitation. Many times users and/or customers of the softwarewill be built, do not fully understand the requirements and essential functionalities thatthe system should contain. Thus, inconsistent information are passed to the specialist,which makes construction more difficult causing rework. Many techniques of requirementselicitation based on textual information and through natural language, promoting pro-blems of interpretation or employing use cases that is lacking in detail. According to thisfact, this paper proposes the use of the methodology Tree features as part of the pro-cess requirements elicitation. It is a technique that has the intense user and/or customerparticipation. Then there will be a refinement on tree features to eliminate problems ofambiguity and omission of information that is common in textual requirements.For theprocess, will be used the concept of Software Product Lines which covers the managementof variability and similarity of softwares’ features, resulting in the final tree. The finalversion of the Feature Tree, a Requirements Product Line is obtained. At this point, willbe done instances of features for the generation of products. For the formalization of theseproducts, simulation and implementation of different scenarios will be presented using theOrdinary Petri Nets and Colored with expressions of modal logic called with Petri Netwith Modalities, for the evaluation of restrictions in the transitions of Petri Nets and alsofor validation and ensure the correctness of the model.

Keywords: Petri Nets, Features Tree, Modal Logic

Sumário

1 Introdução 14

2 Análise de Requisitos 17

2.1 Engenharia de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.1 Como Identificar Requisitos . . . . . . . . . . . . . . . . . . . . . . 182.1.2 Elicitação e Modelagem de Requisitos . . . . . . . . . . . . . . . . . 19

2.2 Árvore de Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3 Linhas de Produtos de Software no contexto de Requisitos . . . . . . . . . 23

2.3.1 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3.2 Gerenciamento de Características . . . . . . . . . . . . . . . . . . . 26

2.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 Lógica Modal e Redes de Petri 29

3.1 A Lógica Modal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2 Formulação de Kripke para Lógica Modal . . . . . . . . . . . . . . . . . . . 303.3 A formalização da linguagem . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4 Semântica e teoria de modelo . . . . . . . . . . . . . . . . . . . . . . . . . 323.5 Redes de Petri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.5.1 Definições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.5.2 Tipos de Rotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.6 Rede de Petri Ordinária . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.7 Rede de Petri Colorida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.8 Rede de Petri com Modalidade . . . . . . . . . . . . . . . . . . . . . . . . 463.9 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4 Estudo de Caso 50

4.1 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2 Estudo de caso: Extração de Funções e Características de um Forno Elétrico 524.3 Simulação e execução através das Redes de Petri . . . . . . . . . . . . . . . 564.4 Especificação lógica para Redes de Petri . . . . . . . . . . . . . . . . . . . 59

4.4.1 Rede de Petri com Modalidade . . . . . . . . . . . . . . . . . . . . 594.4.2 Considerações a respeito de Redes de Petri com Modalidade . . . . 61

4.5 GRequisitos - Gerenciamento das variabilidades . . . . . . . . . . . . . . . 62

5 Conclusão e Trabalhos Futuros 69

Referências 72

Lista de Figuras

2.1 Processo de elicitação e análise de requisitos [Sommerville, 2009] . . . . . . 192.2 Metamodelo de uma árvore de características para um forno elétrico . . . . 232.3 Atividades do desenvolvimento de LPS. [Northrop e Clements, 2005] . . . . 252.4 Modelo de Caracteristicas de um Carro . . . . . . . . . . . . . . . . . . . . 26

3.1 Representação do modelo M . . . . . . . . . . . . . . . . . . . . . . . . . 333.2 |=M

w12(p→ q) em M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3 Representação gráfica dos elementos básicos de uma RdP [Peterson, 1981] . 363.4 Representação das Condições de uma RdP . . . . . . . . . . . . . . . . . . 373.5 Representação do Disparo das Transições . . . . . . . . . . . . . . . . . . . 373.6 Exemplo de RdP Reiniciável e k-limitada . . . . . . . . . . . . . . . . . . . 393.7 Exemplo de Deadlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.8 Exemplo de conflito em uma RdP . . . . . . . . . . . . . . . . . . . . . . . 403.9 Exemplo de Paralelismo em uma RdP . . . . . . . . . . . . . . . . . . . . . 413.10 Exemplo de Disparo sequencial em uma RdP . . . . . . . . . . . . . . . . . 413.11 Exemplo de Concorrência em uma RdP . . . . . . . . . . . . . . . . . . . . 413.12 Rede de Petri Ordinária . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.13 Transformação de uma RdP Ordinária (Figura a) para uma rede Colorida

(Figura b).[e Barros, 1996] . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.14 Modelo de RdPcM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.15 Modelo de RdPcM antes do disparo da transição . . . . . . . . . . . . . . . 473.16 Modelo de RdPcM após o disparo da transição . . . . . . . . . . . . . . . . 48

4.1 Árvore de Características de um Sistema de Forno Elétrico . . . . . . . . . 534.2 Árvore de Características Refinada . . . . . . . . . . . . . . . . . . . . . . 554.3 RdP Ordinária correspondente ao Algoritmo 4.1 . . . . . . . . . . . . . . 574.4 Rede de Petri com Modalidades . . . . . . . . . . . . . . . . . . . . . . . . 594.5 RdPcM após o disparo da transição t5 . . . . . . . . . . . . . . . . . . . . 604.6 RdPcM após o disparo da transição t6 . . . . . . . . . . . . . . . . . . . . 614.7 RdPcM após o disparo da transição t8 . . . . . . . . . . . . . . . . . . . . 614.8 RdPcM após o disparo da transição t10 . . . . . . . . . . . . . . . . . . . . 61

12

4.9 RdPcM após o disparo da transição t12 . . . . . . . . . . . . . . . . . . . . 614.10 Página Inicial do GRequisitos . . . . . . . . . . . . . . . . . . . . . . . . . 634.11 Menu “Sobre” do GRequisitos . . . . . . . . . . . . . . . . . . . . . . . . . 634.12 Menu “Cadastrar” do GRequisitos . . . . . . . . . . . . . . . . . . . . . . 644.13 Menu “Entrar” do GRequisitos . . . . . . . . . . . . . . . . . . . . . . . . 644.14 Página inicial ao logar no sistema . . . . . . . . . . . . . . . . . . . . . . . 654.15 Tela de inserção de novas características . . . . . . . . . . . . . . . . . . . 654.16 Modo de exibição da característica adicionada . . . . . . . . . . . . . . . . 654.17 Novo campo ao inserir Características Opcionais ou Alternativas . . . . . 664.18 Tela para selecionar características . . . . . . . . . . . . . . . . . . . . . . 674.19 Gerando o Relatório das características selecionadas. . . . . . . . . . . . . 68

Lista de Algoritmos

4.1 Trecho da descrição textual da função “Cozinhar” do sistema . . . . . . . . 57

Lista de Siglas

FDD Feature Driven Development

LM Logica Modal

LPR Linhas de Produtos de Requisitos

LPS Linhas de Produtos de Software

RdP Rede de Petri

RdPC Rede de Petri Colorida

RdPcM Rede de Petri com Modalidade

Capítulo 1

Introdução

Um dos problemas que comumente ocorre na fase de elicitação de requisitos é queos usuários finais do software ou clientes, em sua maioria, repassam requisitos e fun-cionalidades incompletos para o desenvolvedor. Isso torna a construção mais difícil e,consequentemente, dispendiosa [Sommerville, 2009].

Desta forma, os analistas de sistemas tem procurado o melhor modo de elicitar requi-sitos funcionais 1 e dentre algumas técnicas que podem ser aplicadas, tem-se entrevistas,formulários e casos de uso. Entretanto, tais técnicas não são eficientes para a interpre-tação dos especialistas uma vez que, em sua maioria se baseiam em informações textuaispor meio da linguagem natural. Isto muitas vezes causa problemas de interpretação ou oemprego de casos de uso pobres em detalhes.

Uma metodologia que ajuda a fase de elicitação de requisitos é baseada em árvorecaracterísticas. Esta metodologia, advinda de Engenharia de Requisitos, visa melhor re-presentar a elicitação de requisitos que o sistema deverá possuir e tem como característicaa intensa participação do usuário e/ou cliente [Oliveira e Souza, 2011].

A árvore de característica construída durante o processo de elicitação de requisitos,deve ser submetida a um refinamento para remover possíveis ambiguidades na interpreta-ção dos requisitos, extraindo requisitos inconsistentes e/ou incompletos. Tal refinamentose processa em uma Linha de Produto de Software no contexto de Requisitos. Ao final doprocesso é gerada um árvore de característica final (uma Linha de Produto de Requisitos),oriunda do processo de gerência de variabilidades, com requisitos funcionais reduzidos ecompletos.

Contudo, a mera construção de uma árvore de características para elicitar requisitosnão é ainda suficiente para se garantir a correta execução do sistema. Uma ferramentaque se mostra apta a este propósito é a Rede de Petri, tanto a Colorida (alto nível) quantoa Ordinária (baixo nível).

1Entende-se por requisito funcional como uma característica do sistema ou a descrição de algo que osistema seja capaz de realizar para atingir os seus objetivos.

14

A utilização da Rede de Petri para a fomalização dos requisitos se deve ao fato destaser uma poderosa técnica de modelagem na representação de processos, permitindo aexibição de concorrência, paralelismo, sincronização, não-determinismo e exclusão mútua.Além de possuírem técnicas que possibilitam a verificação, correção, execução e simulaçãodo modelo, especialmente pelo motivo de transportar em suas fichas valores que serãomanipulados ao longo da rede por meio do disparo de transições.

Entretanto, quando se fala de formalismo de especificação, Redes de Petri tem o usobem menos disseminado que aqueles advindos do campo lógico. Pode-se citar a LógicaModal, que possui características de especificação formal mais amplamente difundidas econsolidadas que as Redes de Petri. Indo desde a descrição dos formalismos, passandopela modelagem e por fim pela avaliação automática dos mesmos.

Redes de Petri podem ser classificadas como um formalismo operacional, onde a des-crição do sistema obedece um modelo abstrato cujo comportamento é simulado. Dife-rentemente de um paradigma lógico, onde as propriedades do sistema são identificadaspor fórmulas de uma linguagem lógica e seu comportamento é analisado usando certaspropriedades.

Em busca de ferramentas que descrevem não só o comportamento, mas também aspropriedades de sistemas concorrentes surgiram trabalhos que agregam às redes de Pe-tri uma linguagem de especificação lógica, utilizando das mais variadas lógicas, sejaproposicional, seja de predicados ou com modalidades. Das duas primeiras pode-secitar os trabalhos de Almeida e Haeusler [Almeida e Haeusler, 1999] e os de Engberg[Engberg e Winskel, 1990]. Já no que envolve lógica modal tem-se os trabalhos de Clem-per [Clempner e Medel, 2007] e o Haddad [El Hog-Benzina et al., 2010].

Neste trabalho será apresentado um modelo híbrido de Redes de Petri, que combinaelementos comportamentais da Rede de Petri Colorida e da Lógica Modal. O objetivoé formalizar, através de restrições e modalidades, cenários de execução de um produtoinstanciado da Linha de Produto de Requisito final. Por fim, será apresentado o softwareGRequisitos, que auxiliará na gerência das variabilidades e similaridades.

Para melhor compreensão do temas abordados, o presente trabalho será dividido daseguinte forma: no Capítulo 2 serão apresentados os conceitos básicos de Engenharia deRequisitos, tais como técnicas de elicitação de requisitos (Árvore de Características) eLinhas de Produtos de Software no contexto de Requisitos.

O Capítulo 3 introduzirá a noção de Lógica Modal, bem como sua semântica. EsteCapítulo também compreende conceitos de Redes de Petri, suas definições, vantagens epropriedades.

No Capítulo 4 será apresentado um Estudo de Caso de um sistema de Forno Elétrico,o qual é um produto instanciado da Linha de Produto de Requisitos, onde este serámodelado utilizando Redes de Petri Ordinária e Rede de Petri Colorida com expressões

15

da Lógica Modal - originando as Redes de Petri com Modalidade.Por fim, a Conclusão e Trabalhos Futuros farão parte do Capítulo 5.

16

Capítulo 2

Análise de Requisitos

Neste capítulo serão discutidos sobre conceitos fundamentais para a compreensão dotrabalho proposto, relativos a Engenharia de Requisitos bem como as Linhas de Produtosde Requisitos (LPR) que é derivada dos conceitos de Linhas de Produtos de Software.

2.1 Engenharia de Requisitos

Para o desenvolvimento de um software bem sucedido, é essencial ter uma compreensãocompleta a respeito dos requisitos que este software deverá conter. Não importa quão bemimplementado o software seja, um programa mal analisado e com requisitos incompletosaborrecerá o cliente e trará conseqüências ao desenvolvedor. Não é vantajoso projetare construir um sistema que seja elegante mas que não resolve o problema, ou seja, nãoatende as necessidades do cliente. Por esta razão, é importante entender e utilizar técnicasque facilitam o entendimento sobre o que o cliente deseja ter em seu sistema.

A análise de requisitos é a primeira atividade técnica para a elaboração de um sistema.Para [Sommerville, 2009] engenharia de requisitos é o processo de descobrir, analisar,documentar e verificar serviços e restrições. Mais precisamente, está relacionada com adefinição do que o sistema deve fazer, suas propriedades emergentes, desejáveis, essenciaise também às restrições operacionais. Deve descrever de modo claro, sem ambigüidades,conciso e consistente todos os aspectos significativos do sistema proposto. Para Fischer[Fischer, 2001] dentro da Engenharia de Requisitos há 4 etapas:

• Extração de requisitos: equivale a agrupar as informações a fim de verificar oque o cliente ou usuário está solicitando;

• Especificação: é um documento formal que registra todas as informações obtidasna extração (ou elicitação) de requisitos. É quando ocorre o maior esforço de análisee o comportamento do software começa a ser entendido no contexto do ambienteem que ele estará inserido;

17

• Verificação: é a etapa que assegura a consistência dos dados, evitando conflitosentre requisitos, e;

• Validação: assegura que o documento descreve com precisão o sistema que o clientedeseja.

Ao final dessas etapas, é gerado um documento de Requisitos de Software onde estãocontidos todas as definições e especificações do sistema.

Existem dois tipos de requisitos: funcionais e não-funcionais. Conforme proposto por[Sommerville, 2009], um requisito é tratado como funcional quando descreve um serviço oufunção que o sistema deve realizar. Paralelamente, pode haver requisitos não-funcionais,que são restrições impostas tanto ao sistema quanto ao seu desenvolvimento, tais comoconfiabilidade, tempo de resposta e espaço de armazenamento.

2.1.1 Como Identificar Requisitos

Técnicas especiais podem ser utilizadas para idenfiticar a completeza dos requisitosfornecidos pelos usuário. Existem ferramentas capazes de resolver, com eficiência, manei-ras de lidar com todas as faces de análise de requisitos enquanto algumas não são muitoeficientes. Segundo [Sommerville, 2009] são elas:

• Rápida protopipação: trabalha com dois dos maiores problemas da análise, avalidação dos requisitos e sua representação de forma compreensível aos diferentesleitores. Trata-se de uma técnica que permite por meio da elaboração das telasdo sistema, por exemplo, trazer uma versão mais abrangente do software, o quepossibilita uma interação maior do cliente.

• Animação: é similar a rápida prototipação. As especificações são executadas comoum filme, porém é um recurso mais pobre, pois não demonstra todos os aspectosdos requisitos.

• Revisões: consiste na releitura dos requisitos na especificação. É um métodosimples, porém eficaz. A desvantagem é o tempo que se leva para reler toda aespecificação, principalmente em se tratando de grandes projetos.

• Prova das propriedades do sistema: mediante provas através do uso de lingua-gens formais, pode-se concluir se o sistema opera ou não corretamente. A desvan-tagem também é o tempo, modelar o mundo real é dispendioso.

Essas técnicas são de suma importância para a construção de um sistema com maiorconfiabilidade, completeza, eficiência e evita o re-trabalho para o desenvolvedor.

18

2.1.2 Elicitação e Modelagem de Requisitos

Elicitar é o ato de tornar explícito, descobrir e obter o máximo de informação para oconhecimento dos requisitos em questão. Compete à elicitação a tarefa de identificar osfatos que compõem os requisitos do sistema, de modo a fornecer o mais correto e completoentendimento do que é exigido do software.

Nesta atividade, os engenheiros de softwares trabalham com os clientes e os usuáriosfinais do sistema para aprender sobre o domínio da aplicação [Sommerville, 2009]. Muitasvezes os usuários não têm uma idéia precisa do sistema requerido por eles e descrevem comdificuldades o conhecimento sobre o domínio do problema. [Sommerville, 2009] apresentaum modelo de processo genérico de elicitação e análise de requisitos e é ilustrado na Figura2.1, onde tal figura também é derivada do modelo de desenvolvimento espiral, definidopor Barry Boehm [Boehm, 1988].

Figura 2.1: Processo de elicitação e análise de requisitos [Sommerville, 2009]

O ciclo do processo começa com a elicitação de requisitos e termina com a documen-tação. O entendimento dos requisitos pelo analista aumenta em cada volta do ciclo. Naetapa de elicitação de requisitos é onde ocorre o processo de interação com os envolvidosno sistema para coletar dados essenciais do sistemas, logo após é realizado o esboço des-tes requisitos. Na etapa de análise de requisitos envolve a organização dos requisitos emconjuntos coerentes. Pode haver problemas na consistência dos requisitos, ocorrendo apresença de requisitos ambíguos e/ou incompletos. A partir daí, é feito a negociação derequisitos do desenvolvedor com o usuário para discutir e priorizar aqueles requisitos quemais objetivam o sistema, com o intuito de eliminar requisitos inconsistentes. E por fim,na etapa de documentação de requisitos, os requisitos serão documentados e colocados napróxima volta do espiral.

19

De acordo com [Castro, 1998], existem técnicas importantes que podem ser utilizadaspara coletar conhecimento sobre os requisitos do usuário, são elas: entrevista, leitura dedocumento, questionários, análise de protocolos, participação ativa dos usuários, cenários,reuso de requisitos e etc. A abordagem mais trivial é a entrevista, porém não é satisfatória,pois envolve fatores que podem atrapalhar o rendimento da coleta, como por exemplo,diferenças culturais entre os envolvidos.

O foco principal deste trabalho é quanto à modelagem dos requisitos. É importanteadotar uma boa técnica de modelagem de forma que dê sustentação para os dados coleta-dos, fazendo com que fiquem corretamente representados para um futuro tratamento. Aescolha das técnicas e seu esquema de integração dependerão do problema, no entanto, umponto importante a ser destacado é o fato de que o analista deverá ter um conhecimentoaceitável sobre tais técnicas e saber identificar onde uma técnica é superior a outra.

Como afirma Booch [Booch et al., 2000], um modelo é uma simplificação da realidade,e modelos são construídos para compreender melhor o sistema que está sendo desenvolvido.Modelos nos dão um molde que nos guia na construção de um sistema e também é umaforma de documentar as decisões tomadas.

Existem muitas técnicas de modelagem de requisitos, sendo as seguintes mais expres-sivas:

• Casos de uso: descreve uma interação entre o usuário e o sistema, resultandoem um diagrama que possui uma sequência de ações interagindo com um ator[Booch et al., 2000];

• Viewpoints: é uma técnica na qual considera aspectos do sistema percebidos por di-ferentes requerentes obtendo uma especificação mais adequada.[Finkelstein et al., 1992];

• Expressão Controlada dos Requisitos – CORE: o sistema a ser construído élimitado em perspectivas ou viewpoints, representando organizações, homens, enti-dades de hardware ou software e processos. [Finkelstein et al., 1992];

• Diagrama de Fluxo de Dados – DFD: descreve o fluxo de informações e astransformações que são aplicadas à medida que os dados se movimentam da entradapara a saída. Pode ser usado em qualquer nível de abstração [Pressman, 2005];

• Processador de Requisitos de Linguagem – RLP: permite o desenvolvimentode linguagens formais para os requisitos de especificação das aplicações garantindoa completeza e consistência dos mesmos. [Silva et al., 2005];

• Metodologia de Engenharia de Requisitos de Software – SREM: é umaferramenta de análise de requisitos automatizada que faz uso de uma linguagem de

20

declaração de requisitos, para descrever elementos, atributos relações e estruturas[Pressman, 2005];

• Volere: é um método completo para obtenção de requisitos, baseado nos casos deuso [Fischer, 2001].

Neste trabalho, será utilizado o conceito de árvore de caracteristicas, o qual trata-se deum modelo gráfico que concentra os requisitos do sistema em vários níveis de abstração,fundamentando-se na metodologia de desenvolvimento guiado por características (FeatureDriven Development – FDD ) [Mathias et al., 2004].

2.2 Árvore de Características

Antes de entender a modelagem da árvore de características é necessário que se entendao conceito de metodologia ágil e FDD. Feature Driven Development (DesenvolvimentoGuiado por Características) é uma metodologia ágil para desenvolvimento e gerenciamentode software, criada em 1997 num grande projeto em Java para o United Overseas Bank,em Singapura. Mas o que são métodos ágeis? Em muitos softwares, o tempo gasto paraprojetar e documentar um sistema era maior que o tempo empregado no desenvolvimento ena realização de testes no mesmo [Sommerville, 2009]. Essa abordagem gerava insatisfaçãodos clientes, o que foi um ponto determinante para que os desenvolvedores propusessemnovos métodos ágeis.

A equipe de desenvolvimento passou a se concentrar somente no software, em vez deseu projeto e documentação, contando com uma abordagem iterativa para especificação,desenvolvimento e entrega de software.

No desenvolvimento guiado por características, é possível representar as capacidadesde especificar a variabilidade de requisitos e suas interdependências através de um modelo.Neste contexto, característica é uma função valorizada pelo cliente que deve ser construídae acoplada ao novo sistema [Oliveira e Souza, 2011]. A árvore de características é utilizadapara descobrir as características que o sistema deverá possuir e é expressa pelo cliente pormeio da linguagem natural.

Conforme [Mathias et al., 2004], a vantagem do uso desta metodologia é o fato deque o desenvolvimento proporciona a geração de software por meio da composição decaracterísticas. Outra vantagem é sua representação gráfica, bastante simples. Em geral,para o usuário final, a representação gráfica é importante, pois ela é um modelo semânticoque descreve as relações estruturais entre as características de um domínio de aplicação,o que facilita a compreensão por parte do usuário final.

O desenvolvedor lida com usuários ou clientes leigos que encontram grandes dificulda-des para expressar objetivamente todas as informações de que são necessárias conhecer,

21

deixando para o desenvolvedor a tarefa de prever e imaginar suas necessidades. Destaforma, o cliente acata todas as sugestões do programador, deixando para apontar proble-mas, questionamentos e inconsistências no futuro, já com o software em desenvolvimento.

Com a utilização do modelo gráfico de árvore de características, a elicitação dos re-quisitos será anotada visualmente no gráfico, o que facilita a comunicação entre am-bos. Entretanto, é importante ressaltar que esse processo de descoberta dos requisitosnão é um processo matemático e há fatores organizacionais, técnicos, sociais envolvidos[Batista e Carvalho, 2003].

As vantagens da utilização dessa abordagem, primeiramente é que pode ser elabo-rada por usuários leigos, possibilitando assim a acessibilidade e participação de qualquerusuário. A organização dos requisitos elicitados se dá por meio de uma árvore. Segundo,por que é um modelo que estimula o design participativo dos usuários e/ou clientes emtodo o processo de desenvolvimento do sistema [Dix et al., 2004]. Isso ajuda a melhorar aqualidade do software final, uma vez que a etapa de elicitação e modelagem de requisitosfica bem apresentada, tornando claro o entendimento do sistema para todos os envolvidos(stakeholders 1)

Na construção desta árvore, o usuário é instigado a detalhar cada vez mais o modelo emvários níveis de abstração, pois a árvore de características tem a vantagem de incentivaro usuário a expor, pormenor, cada um dos requisitos formando assim uma árvore maispróxima de ser completa [Oliveira e Souza, 2011]. Nesse contexto, as características sãoapresentadas de forma estruturada e organizadas hierarquicamente. Para exemplificar ouso de árvores de características, na Figura 2.2 é apresentado um metamodelo de umforno elétrico.

Como se pode perceber na Figura 2.2, a árvore é composta de nós pais, nós cujo asbordas aparecem em negrito e nós filhos. O principal requisito para que um forno elétricoseja assim denominado, é a existência do Kernel Cozinhar. Ao considerar o requisito"Cozinhar", pode surgir variações nas famílias para esta função, e tais variações sãorepresentadas pelos nós inseridos abaixo do nó Cozinhar, tais como assar, tostar e etc.Botões reguladores que estão incluídos na LPS "Forno Elétrico"são os botões de Timere/ou Temperatura, dependendo da família. Assim como também, os fornos elétricos podemou não conter Alarme ou Lâmpada no seu interior.

As características externas de um forno elétrico também possuem inúmeras variações.Contudo, por ser um metamodelo esta árvore não demonstra as variações das caracte-rísticas, apresentando somente o escopo destas. Elas estão sujeitas a sofrerem variaçõesdependendo de cada família de produtos em que está inserida. Tais caracteristicas são

1Stakeholder; do português "a parte interessada". São chamados de stakeholders todos os envolvidosna construção do sistema, desde a análise de requisitos até usuários e/ou clientes finais.

22

Figura 2.2: Metamodelo de uma árvore de características para um forno elétrico

representadas pela segunda coluna do metamodelo da Figura 2.2.Este tipo de modelagem estimula também o pensamento criativo pessoal e a geração

de novas idéias, muito parecida com a técnica de brainstorming 2 . Formular um conjuntode processos simples que podem ser executados por qualquer perfil de usuário em parceriacom o desenvolvedor é o principal foco da modelagem baseada em árvore de características.

Por esta razão, este modelo tem como qualidade fundamental a sua simplicidade.

2.3 Linhas de Produtos de Software no contexto de

Requisitos

No contexto deste trabalho, uma vez que a árvore de características passa por vários ní-veis de abstração, se faz necessário o gerenciamento das características comuns e variáveisque são obtidas durante as abstrações, a fim de obter requisitos consistentes e completos.Sendo assim, a árvore passará por um processo de refinamento a fim de extrair requisitosinconsistentes e/ou incompletos, pois a ocorrência da ambigüidade é possível. [Pressman,2005]. No entanto, é necessário entender os conceitos de completude e consistência de re-quisitos. O conceito de completude significa que nenhum serviço (ou limitação), que sejanecessário no sistema, tenha sido esquecido. Já a consistência, significa que os requisitos

2É uma reunião realizada com os envolvidos no desenvolvimento do sistema, que objetiva recolher omaior número de idéias possíveis, sem restrições. [Osborn, 1962]

23

não devem conter conflitos ou serem contraditórios [Somerville, 2009].Baseado nesta realidade é importante abranger conceitos ligados a este processo de

refinamento bem como aprofundar nos conceitos de Linhas de Produtos de Software (LPS)dentro do contexto de Requisitos, originando as Linhas de Produtos de Requisitos (LPR).

De acordo com [Gomaa, 2005] LPS é um conjunto de sistemas intensivos de soft-ware que possuem características em comum, compartilhadas com outros softwares parasatisfazer necessidades específicas de um ramo do mercado particular e é utilizado inter-nacionalmente como Software Product-Lines.

A idéia da LPS é sugerir o desenvolvimento seqüencial dos produtos, baseado emtarefas repetitivas, executadas sempre pelas mesmas pessoas que dispunham dos recursose materiais que necessitavam. Surge então o conceito de reuso de software justamentepor apresentar menor custo de produção, beneficiando os consumidores com sistemas demaior qualidade e menor custo de manutenção, entrega rápida e entre outras facilidadesque esta técnica apresenta. Para as empresas, o software tem se valorizado cada vez maise para aumentar o retorno sobre investimentos demandados no desenvolvimento destessoftwares, estas vêm promovendo a utilização do reuso.

Para [Sommerville, 2009] todo o sistema da aplicação pode ser reusado por incorpora-ção a outros sistemas sem mudanças. Os componentes, objetos e funções também podemser reusados. Estas podem ser facilmente vinculadas ao código de outras aplicações. Estáclaro que a maior vantagem do reuso é a redução dos custos totais de desenvolvimento.

Uma LPS não é apenas o desenvolvimento de um simples sistema utilizando o reuso,nem apenas uma arquitetura configurável ou a obtenção de um produto simples. É maisdo que isso, envolve estratégia e planejamento do reuso, prevendo os resultados possíveise alcançando ganhos de produtividade para conseguir manter presença no mercado esustentar o crescimento.

Na Figura 2.3 é apresentado as três principais atividades do desenvolvimento de Linhasde Produtos de Software.

Todas as três atividades estão inteiramente inter-relacionadas e são representadas comocírculos em rotação indicando que a saída de uma realimenta a entrada de outra. CoreAsset Development, do português Núcleo de Desenvolvimento de Ativos, é onde estálocalizado os itens reutilizáveis e as limitações dos produtos, tais como documentação,padrões, estilos, requisitos, etc., sendo necessário trabalhar com tais limitações para darinício ao desenvolvimento visando a família de produtos. Na atividade de Management,do português Gerência, requer liderança. O líder deverá ter uma visão ampla do trabalhoa ser desenvolvido, deverá garantir metas e medidas apropriadas a serem tomadas pelaequipe, sustentar a moral e melhorar continuamente a abordagem. Product Development,do português Desenvolvimento de Produtos, como o próprio nome já sugere, é a atividade

24

Figura 2.3: Atividades do desenvolvimento de LPS. [Northrop e Clements, 2005]

responsável pelo desenvolvimento do produto gerando novos núcleos de ativos base.Nas atividades essenciais ilustradas na Figura 2.3, podem ser identificadas as práticas

essenciais que se enquadram em três áreas práticas, representando a coleção de atividadesque uma organização deveria dominar para obter com sucesso uma Linha de Produto deSoftware. São elas:

• Engenharia de Software : atividade responsável pela definição e avaliação daarquitetura, levantamento de custos, engenharia de requisitos, realização de testesentre outros;

• Gestão Técnica: atividade responsável pela definição do escopo do projeto, ge-renciamento da configuração de coleta de dados, planejamento técnico e a gestão deriscos técnicos, e;

• Gestão Organizacional: atividade responsável pela gestão de clientes e interface,financiamento, planejamento e estrutura organizacional, análise de mercado, etc.[Northrop e Clements, 2005];

Na próxima seção, será descrito alguns conceitos fundamentais para o entendimentoda LPS , bem como suas características.

2.3.1 Características

As características ou features são fundamentais para alguma parte interessada da cons-trução do sistema e são utilizadas para capturar funcionalidades comuns ou variáveis entresistemas de uma mesma família de produtos [Czarnecki et al., 2005]. As característicaspodem ser classificadas como sendo de três tipos, são elas:

25

• Obrigatórias: deverão estar disponíveis em toda a família do produto;

• Alternativas: oferece um leque de opções para a seleção de apenas uma. Exemplo:cor de um automóvel;

• Opcionais: podem ou não estar presente em um produto.

Considera-se que as características alternativas só fazem sentido dentro de um agrupa-mento de características. Graficamente, as características são representadas como naFigura 2.4.

Figura 2.4: Modelo de Caracteristicas de um Carro

As características "transmissão" e "potência do cavalo" são obrigatórias, enquanto queo fato de ter "ar condicionado" no veículo é opcional, pode ou não ter. A transmissão deum carro pode ser automática ou manual, sendo estas duas características alternativas.Porém, deve-se atentar ao fato de que algumas caracteristicas necessitam de alguma(s)condição(es) para ser escolhida(s) ou não. Por exemplo, um veículo só pode ter ar condici-onado se possuir uma potência que suporte a sua existência, como por exemplo, potênciado cavalo 〉 100. Esta regra é denominada de regra de composição, na qual estabelececondições para a existência ou não de características, como é o caso do ar condicionado.

2.3.2 Gerenciamento de Características

Antes de iniciar a compreensão do estudo de gerenciamento das características, énecessário abordar a diferença existente entre "requisitos" e "características". Muitosconfundem os dois termos e acabam considerando-as como sendo parte de uma mesma in-terpretação, mas existe diferença. Wiegers [Wiegers, 2003] define os requisitos da seguinteforma:

É a declaração da necessidade de um cliente ou objetivo, ou de uma condiçãoou capacidade que um produto deve possuir para satisfazer tal necessidade ouobjetivo.

26

Robertson [Robertson e Robertson, 2006] diz o sequinte:

Requisitos é alguma coisa que o produto deverá fazer ou alguma qualidade queo produto deverá conter.

Já as características são mais especificas, se referem aos atributos do sistema. Nestecontexto, característica ou feature é um conjunto de requisitos relacionados que permiteao usuário satisfazer suas necessidades ou objetivos de negócio. Sendo assim, o termo"característica" é mais genérico, ou seja, tende a um objetivo de alto nível (abstrato)sendo mais focado nos objetivos de negócio que na implementação.

Os requisitos, ao contrário das características, é mais específico, isto é, descreve o que osistema deve fazer para alcançar seus objetivos, sendo, portanto, mais granular. Refere-seainda às funções específicas do sistema, ou seja, o que vai ser implementado, de fato, nosistema.

O gerenciamento de variabilidades é considerado uma questão chave na LPS. Nestecontexto, uma atividade importante é modelar o que é comum e o que é variável nafamília de produtos de software. Antes de entender como funciona o gerenciamento decaracterísticas, é fundamental que se entenda os conceitos de Variabilidade e Similaridade.

As características comuns ou similares, são aquelas compartilhadas por todas as apli-cações das Linhas de Produtos de Software [Gomaa, 2005].

Dentre os principais aspectos que devem ser gerenciados em uma LPS, estão as diferen-ças entre seus produtos, conhecidas como variabilidades. SegundoWeiss em [Weiss e Lai, 1999],variabilidade é a forma como os membros de uma família de produtos podem se diferenciarentre si. Diferentes versões de um componente possui a mesma interface porém, diferentesimplementações para diferentes membros da LP.

As características a serem gerenciadas, sejam elas aplicadas para adaptação ou al-teração do sistema, podem afetar diretamente na qualidade e/ou no comportamento domesmo. Logo, a linha de produtos de software só irá obter sucesso se for realizado umbom gerenciamento tanto no desenvolvimento da LPS quanto na derivação do produto.

Decisões sobre quais características são comuns e quais são variáveis devem ser to-madas e descritas. Esta etapa será realizada com a ajuda de um software construídoneste trabalho para gerenciar os requisitos, chamado de Grequisitos, sendo descrito maisdetalhadamente no Capítulo 4: Estudo de Caso.

2.4 Considerações Finais

Neste capítulo foram abordados conceitos fundamentais para a elicitação de requi-sitos bem como para a construção da árvore de características e LPS, cujo são temas

27

fundamentais para o entendimento do estudo de caso que será apresentado no Capítulo4.

Foi abordado sobre a dificuldade que analistas encontram ao fazerem a elicitaçãode requisitos, uma vez que o cliente detém de todo o conhecimento do sistema a serconstruído, porém estes não conseguem repassar as informações necessárias de formaconsistente e completa.

Para isso, é adotado a metodologia de Árvore de Características, um mecanismo quepossui uma representação gráfica bastante simples e que é capaz de representar as carac-terísticas do software.

Para o gerenciamento das características ou features, é obtida a LPS, considerada umaetapa de suma importância que será validada através do software GRequisitos.

O próximo capítulo abordará conceitos de Lógica Modal, uma lógica utilizada nestetrabalho para impor restrições às Redes de Petri Coloridas (RdPC). Neste cenário, asRedes de Petri Colorida com expressões da Lógica Modal, são abordadas para formalizara extração de características da LPS por meio da execução de um caso de uso.

28

Capítulo 3

Lógica Modal e Redes de Petri

Neste capítulo serão apresentados elementos essenciais da Lógica Modal(LM), suadefinição e principais características, bem como os principais conceitos de redes de Petri,sempre focados nas abordagens utilizadas para a compreensão deste trabalho.

3.1 A Lógica Modal

Lógica Modal (LM) é o estudo de proposições com qualidades associadas (modos) eas relações lógicas que as proposições compartilham [Chellas, 1980] [Goldblatt, 1995].

As modalidades mais conhecidas são aquelas que envolvem necessidade e possibilidade.Neste trabalho serão adotadas lógicas modais baseadas em modalidades. Um exemplo deproposições modais, são:

• É possível que chova amanhã

• É possível para humanos viajar para Marte.

• Não é possível que: toda pessoa seja mortal, Sócrates seja uma pessoa, e Sócratesnão seja mortal.

• É necessário que ou chova aqui e agora ou não chova aqui e agora.

• Uma proposição p não é possível se e somente se a negação de p seja necessária.

Os operadores é possível que e é necessário que são chamados operadores modais, porque eles especificam uma maneira ou modo no qual o resto da proposição pode ser ditaverdadeira.

Como dito acima, existem outros operadores modais, tais como, “aconteceu uma vez”e “acontecerá uma vez”.

O trato com modalidades envolve julgar como certas proposições modais implicamem outras. Intuitivamente, parece certo crer que a proposição modal “é necessário p”,

29

logicamente implica a proposição modal “é possível p”, mas não vale a volta. Contudo,logicamente falando, intuição não é uma ferramenta apropriada para julgar implicaçõeslógicas, com ou sem modalidades. Existem duas abordagens lógicas que podem ser em-pregadas, a primeira envolve as relações associadas com o modelo empregado (teoria demodelos ) a segunda envolve a derivabilidade de uma forma lógica a partir da outra (teoriada prova).

Historicamente, as discussões sobre lógica modal tiveram início com Aristóteles emDe Interpretatione. Aristóteles percebeu que “necessidade”, implica “possibilidade”, ( semvaler a volta) e também que se pode definir “necessidade”, a partir de “possibilidade”, e viceversa. Os trabalhos em lógica seguiram por receber maiores contribuições com Leibniz aosugerir uma interpretação das fórmulas modais por meio de mundos alcançáveis, contudoas maiores contribuições foram devidas a Lewis e Carnap que finalmente trataram de“necessidade” de forma mais ampla, passando a interpretá-las como sentenças em vez desimples proposições. Lewis apresentou os sistemas de S1 a S5, sendo que S4 e S5 aindaestão em uso [Goldblatt, 1995].

Contudo, o uso de modalidades teve um caracter mais voltado à computação depoisde apresentado um framework para interpretar a semântica em lógicas modais, maisprecisamente àquelas que envolvem necessidade e possibilidade.

Na próxima seção será apresentada a formulação devida a Kripke de lógica modal.

3.2 Formulação de Kripke para Lógica Modal

As inovações em Lógica Modal foram devidas a S. Kripke, sendo que grande parte deseu trabalho já havia sido antecipado por S. Kanger e J. Hintikka. [Goldblatt, 1995]

Kripke introduziu um domínio de mundos possíveis e usou o prefixo “é necessário que”,como um quantificador sobre tais mundos.

Apesar da idéia de interpretar modalidades com o conceito de mundos ser bastanteaceita, desde de Hilbert, a definição de verdade com “necessidade”, ainda precisava de ajus-tes. A concepção de verdade apresentada por Carnap [Carnap, 1966] [Goldblatt, 1995],que incorreu em erros dizia o seguinte:

‘Necessariamente p’ é verdadeira em um mundo w se e somente se p é verda-deira em todos possíveis mundos.

Para não incorrer nos mesmos erros apresentados por Carnap, Kripke apresenta juntocom o domínio de mundos uma relação de acessibilidade entre os mundos. Desta forma,a definição de verdade em lógica modal foi dada por Kripke da seguinte forma:

“Necessariamente p é verdadeiro em um mundo w se e somente se ‘p’ é verda-deiro em qualquer mundo w′ alcançável por w”.

30

Portanto, deve se ter em mente que nem todo mundo é “modalmente”, alcançável apartir de um mundo w. Um mundo w pode alcançar um mundo w′ somente quando todasas proposições verdadeiras em w′ também forem possivelmente verdadeiras em w.

O uso da relação de alcançabilidade em possíveis mundo abriu um novo caminho deestudos em lógica modal, levando seu uso para além do estudo teórico e encontrandoaplicações em outras ciências, em particular em computação [Hughes e Cresswell, 1996].

Nas próximas subseções serão formalizados os conceitos e definições de lógica modal,em detalhes. Contudo, uma explicação superficial pode ser feita inicialmente, para seentender o formalismo por trás da construção de Kripke.

A definição de linguagem, por Kripke, segue o processo indutivo característico da lógicade predicados, a saber, a linguagem contém certas letras proposicionais p, q, r, ... comosentenças atômicas (átomos). Sentenças mais complexas são definidas a partir destastendo a forma ¬ϕ (‘não é o caso que ϕ’), ϕ→ ψ (‘se ϕ, então ψ’ ) e 2ϕ (‘necessariamenteϕ’), onde ϕ e ψ são sentenças (não necessariamente atômicas). Outras sentenças podemser definidas em termos destas sentenças básicas.

Quanto aos modelos, ou interpretações para a linguagem, tem-se que um modelo M

para uma linguagem é definido basicamente pela tripla 〈W,R, V 〉, onde W é um conjuntonão vazio de possíveis mundos, R é a relação de acessibilidade e V uma função de valoraçãoque associa a cada sentença atômica p um conjunto de mundos V (p). Estes modelospermitem definir a noção de verdade, verdade lógica e consequência lógica no contextode teoria de modelos. Enquanto que verdade e verdade lógica representam a semântica,propriedades das sentenças da linguagem, consequència lógica é uma relação modelo-teórica entre sentenças. Uma sentença é dita logicamente verdadeira, ou válida, apenasse for verdadeira em todos os modelos, e é dita ser válida com relação a uma classe C demodelos apenas se for válida em todos os modelos da classe.

Quanto ao tratamento via teoria da prova, lógica modal segue o mesmo caminhoempregado para teoria de modelos, isto é, estendendo os conceito de lógica de predicados.Regras de inferência relacionam certas sentenças com outras, indicando que sentençaspodem ser inferidas de outras. Uma lógica Σ é definida como sendo um conjunto desentenças (que pode conter alguns axiomas) que são fechadas com relação as regras deinferência que definem tal lógica. Um teorema de uma lógica é simplesmente uma sentençade Σ. Uma lógica Σ é dita correta (do inglês Sound) na classe de modelos C se todasentença ϕ que for um teorema de Σ for válida na classe C. Uma lógica Σ é dita completana classe de modelos C se toda sentença que for válida em C for um teorema em Σ.

31

3.3 A formalização da linguagem

Seja Ω um conjunto não vazio, que represente as fórmulas atômicas, i.e., Ω = p1, p2, . . . ,

pn, no caso finito, ou Ω = p1, p2, . . ., no caso infinito [Chellas, 1980].Para cada conjunto Ω se define, por indução, o conjunto de fórmulas baseados em Ω

como o menor conjunto Form(Ω) que satisfaça as seguintes condições:

1. p ∈ Form(Ω), para toda p ∈ Ω,

2. ⊥ ∈ Form(Ω),

3. Se ϕ ∈ Form(Ω), então (¬ϕ) ∈ Form(Ω),

4. Se ϕ, ψ ∈ Form(Ω), então (ϕ→ ψ) ∈ Form(Ω),

5. Se ϕ ∈ Form(Ω), então (2ϕ) ∈ Form(Ω).

A linguagem modal baseada em Ω, denotada por ΛΩ, é, portanto, o conjunto Form(Ω).Em geral, faz-se uso das variáveis ϕ, ψ, η, ω para representar fórmulas em ΛΩ.Se não causar ambigüidades, pode-se eliminar o uso de parênteses. Seguindo as con-

venções, o conectivo → tem precedência sob ¬ e 2, desta forma a fórmula ¬p → q deveser entendida como (¬p)→ q e a fórmula 2p→ q por (2p)→ q. Os conectivos ∧, ∨ e ↔são definidos de forma usual.

Defini-se 3ϕ (‘possivelmente ϕ’) por ¬2¬ϕ. Pode-se eliminar o uso de parentêseslevando em consideração que ↔ domina →, → domina ∧ e ∨, e que os dois últimosdominam ¬, 2 e 3. Desta forma, a fórmula p ∧ 3p → q deve ser interpretada como(p ∧3p)→ q.

Esquemas serão definidos como conjuntos de sentenças com a mesma forma. Porexemplo, o esquema 2ϕ → ϕ é dado pelo conjunto 2ϕ → ϕ | ϕ ∈ ΛΩ. Desta forma,uma instância deste esquema é apenas um membro deste conjunto. Geralmente, os es-quemas são representados por letras maiúsculas, no exemplo acima o esquema 2ϕ → ϕ

é representado pela letra ‘T’, contudo alguns esquemas são rotulados por números, porexemplo, o esquema 2ϕ→ 22ϕ recebe como rótulo o número ‘4’.

3.4 Semântica e teoria de modelo

Um modelo padrão M para um conjunto de fórmulas atômicas Ω deve ser qualquertripla 〈W,R, V 〉 satisfazendo as seguintes condições:

1. W é um conjunto não vazio,

2. R é uma relação binária sob W , i.e., R ⊆ (W ×W ),

32

3. V é uma função que associa a cada p ∈ Ω um subconjunto V (p) de W , i.e., V : Ω→P(W ), onde P(W ) é o conjunto das partes de W .

Exemplo 3.1 Seja Ω = p, q. Então existe um exemplo de um modelo M para Ω. SejaW = w1, w2, w3. Seja R = 〈w1, w2〉, 〈w1, w3〉. Seja V (p) = w1, w2, e V (q) = w2.A figura 3.1 representa o modelo.

p

w1

p, q

w2

w3

Figura 3.1: Representação do modelo M

Definição 3.1 Diz-se que ϕ é verdadeira no mundo w no modelo M (em símbolos: |=Mw

ϕ) se:

1. |=Mw p se, e somente se, w ∈ V (p);

2. |=Mw/ ⊥ (i.e., não é o caso que |=M

w ⊥);

3. |=Mw ¬ϕ se, e somente se, |=M

w/ ϕ;

4. |=Mw ψ → χ se, e somente se, |=M

w/ ψ ou |=Mw χ;

5. |=Mw 2ψ se, e somente se, para todo w′ ∈ W , se wRw′, então |=M

w′ ψ

Diz-se que ϕ é falsa em w em M se, e somente se, |=Mw/ ϕ

Exemplo 3.2 Neste exemplo, será mostrado que uma condição de verdade 2(p→ q) emum mundo w não significa uma condição de verdade de p→ 2q em w.

Para fazer isto, basta descrever um modelo para o conjunto Ω = p, q. O exemplo3.1 atende tal propósito, considerando M e w1 como especificado em tal exemplo.

Para verificar |=Mw1

2(p → q). Por 5 da definição 3.1 tem-se que |=Mw1

2(p → q) se, esomente se, para todo w′ ∈ W , se w1Rw

′, então |=Mw′ (p → q). Como w1Rw2 e w1Rw3,

deve-se verificar w2 e w3 para determinar se p→ q é verdadeiro em ambos.Uma vez que w2 ∈ V (q) segue por 1 da definição 3.1 que |=M

w2(p → q). Ainda, como

w3 /∈ V (p), então |=Mw3/ p, pelo item 1 da definição 3.1. Portanto, |=M

w3(p → q), por 4 da

definição 3.1. Logo, |=Mw1

2(p→ q). Conforme figura 3.2.

33

2(p→ q), p

w1

p, q

w2

w3

Figura 3.2: |=Mw1

2(p→ q) em M

Contudo, ao se verificar |=Mw1p → 2q, constatasse, pelo item 4 da definição 3.1, que

|=Mw1

p → 2q se, e somente se, ou |=Mw1/ p ou |=M

w12q. Isto é, se, e somente se, |=M

w3/ p

ou para todo w′ ∈ W , se w1Rw′, então |=M

w′ q, pelo item 5 da definição 3.1. Mas, noexemplo, w1 ∈ V (p), desta forma |=M

w1p, por 1 da definição 3.1 . Assim não é o caso que

|=Mw1/ p Portanto, resta verificar se para todo w′ ∈ W , se w1Rw

′, então |=Mw′ q. Verificando

o exemplo, tem-se que w1Rw2 e w1Rw3. |=Mw2

q, pois w2 ∈ V (q). Contudo |=Mw3/ q, pois

w3 /∈ V (q). Logo, |=Mw1/ p→ 2q.

A Lógica Modal aliada as Redes de Petri se torna uma poderosa ferramenta de forma-lização da extração de características da LPS, sendo assim, na próxima seção conceitosde Redes de Petri serão abordados, pois ao final do capítulo serão apresentados as Redesde Petri Coloridas com expressõs da Lógica Modal, denominada assim de Rede de Petricom Modalidade (RdPcM) , a fim de impor restrições as transições garantido uma maiorcorretude do funcionamento do sistema.

3.5 Redes de Petri

A Rede de Petri (RdP) é uma ferramenta gráfica e matemática que se encaixa bem anumerosas aplicações em que as noções de eventos e de evoluções simultâneas são impor-tantes [Cardoso e Vallete, 1997]. Dentre essas aplicações pode-se considerar: avaliação dedesempenho, análise e verificação formal em sistemas discretos, protocolos de comunica-ção, sistemas de transporte, gerenciamento de base de dados, sincronização, concorrênciae conflitos de processos, etc.

As RdP devem o seu nome ao trabalho de Carl Adam Petri, que na sua dissertação dedoutorado submetida no ano de 1962, à faculdade de Matemática e Física da UniversidadeTécnica de Darmstadt na Alemanha, apresentou um tipo de grafo bipartido 1 com estados

1Um grafo bipartido é um grafo cujos vértices podem ser divididos em dois conjuntos, nos quais nãohá arestas entre vértices de um mesmo conjunto.

34

associados, com o objtetivo de estudar a comunicação entre autômatos [Murata, 1989].Uma característica importante alcançada por este modelo é a habilidade de represen-

tar processos concorrentes, o que a modelagem em diagramas UML, por exemplo, não faz.Além disso, são destacadas por serem um método formal. Tal formalidade faz tornar possí-vel a obtenção de informações sobre o comportamento do sistema modelado e também au-xilia, inclusive, a detectar eventuais erros presentes na especificação, proporcionando assimum suporte à verificação da corretude do sistema em questão [Cardoso e Vallete, 1997].Portanto, as Rdp não só revelam importantes informações sobre a estrutura e o comporta-mento dinâmico dos sistemas, como também avaliam o sistema sugerindo mudanças e/oumelhorias.

A escolha da RdP como mecanismo de modelagem e formalização dos requisitos nestetrabalho, se deve ao fato desta ser uma poderosa técnica de modelagem na represen-tação de processos, permitindo a exibição de concorrência, paralelismo, sincronização,não-determinismo e exclusão mútua. Além disso, as RdP possibilitam a representaçãomatemática formal e disponibilizam de mecanismos de análises que tornam possíveis ve-rificar a correção do modelo e checar suas propriedades garantindo a segurança do fun-cionamento, além de permitir a simulação e execução do modelo. Outro motivo para autilização deste, é devido a sua forma de representação, que pode ser feita tanto atravésde diagramas visuais que são de fácil entendimento e bastante intuitivos quanto por mo-delos matemáticos, dependendo da complexidade do sistema estudado e do contexto deaplicação [Peterson, 1981]. Por fim, apresentam um bom nível de abstração se comparadocom outros modelos gráficos.

Na próxima seção serão apresentadas as principais definições e propriedades das RdP.

3.5.1 Definições

Segundo [Cardoso e Vallete, 1997] a Rede de Petri, enquanto um modelo formal, podeser abordada de três maneiras diferentes, são elas:

• um grafo com dois tipos de nós e um comportamento dinâmico;

• um conjunto de matrizes de inteiros, onde as linhas representam os lugares e ascolunas representam as transições, descrito por um sistema linear;

• um sistema de regras numa representação do conhecimento aliada as técnicas deInteligência Artificial.

Para o foco deste trabalho, será aprofundado somente na primeira abordagem, pois estamais se aproxima ao objetivo deste. Através desta abordagem, pode-se fazer todas asverificações e ter uma idéia geral do sistema modelado.

35

Definição 3.2 Formalmente, uma rede de Petri é uma quádrupla R = 〈 P, T, Pre, Post〉 onde:

• P é um ponto finito de lugares de dimensão n;

• T é um conjunto finito de transições de dimensão m;

• Pre: P × T → N, onde N é o conjunto dos números naturais. Define o conjuntodos arcos de entrada das transições.

• Post: P × T → N, onde N também é o conjunto dos números naturais. Define oconjunto dos arcos de saída das transições.

Graficamente, uma RdP pode ser representada por um grafo com dois tipos de nós:nós lugares e nós transições. Um arco liga um lugar p a uma transição t. Para Petter-son [Peterson, 1981] a notação gráfica de uma RdP é dada pela composição de quatroelementos básicos:

• Lugar: representado por uma circunferência ou elipse. Equivale a qualquer variávelde estado do sistema, representando tanto uma condição, quanto uma atividade ouaté mesmo uma espera do sistema.

• Transição: representada por uma barra vertical fina ou retangular e são responsáveispela mudança de estado do sistema

• Arco: elemento que interliga lugares a transições e vice-versa.

• Ficha: também conhecidas por marcas ou token,são representadas graficamente porum círculo preto e tem o papel de representar o estado do sistema. Podem mover-seao longo dos lugares, de acordo com as ações executadas

As transições se localizam exatamente entre lugares e é através da sua ação, denomi-nada disparo, que um lugar altera a sua ficha. Na figura 3.3 será ilustrado os elementosde uma RdP.

Figura 3.3: Representação gráfica dos elementos básicos de uma RdP [Peterson, 1981]

36

Definição 3.3 Rede de Petri Marcada: uma Rede de Petri Marcada N é uma dupla N =

〈 R, M 〉, onde R é uma rede de Petri e M é uma marcação inicial dada pela aplicaçãoM: P → N, onde N é o conjunto dos números naturais. A marcação M é a distribuiçãodas fichas nos lugares, denota-se por (N, M0) uma rede de Petri com marcação inicial.

Cada lugar na RdP representa um estado parcial do sistema a ser modelado. Quandoocorre o disparo de uma transição (indicando que uma ação poderá ser executada) aficha passa do estado atual para o próximo estado. Porém, a ação só será efetivada seas condições precedentes forem completamente satisfeitas. Ao final do disparo produziráuma saída que é representado pela pós-condição (Figura 3.4).

Figura 3.4: Representação das Condições de uma RdP

Na Figura 3.5 tem-se a ilustração de um disparo de transição em uma RdP, onde estapossui três lugares e duas transições, representadas pelas letras p e t, respectivamente.O que acontece com as fichas no momento da transição não é movimentação dela peloslugares, e sim a remoção de fichas nos lugares de entrada e a criação de novas fichas noslugares de saída [Ramos e Barros]. Na Figura 3.5 a) a ficha se encontra inicialmente nolugar p1. Com a ficha em p1, a transição t1 é sensibilizada. Desta forma, após o disparode t1, o sistema muda de estado, removendo a ficha de p1 e criando uma nova ficha nolugar p2, como mostra a Figura 3.5 b). Com a ficha em p2, a transição t2 é sensibilizadae após o seu disparo a ficha será removida do lugar p2 e criada em p3, como se pode verna Figura 3.5 c).

Figura 3.5: Representação do Disparo das Transições

37

A quádrupla R = 〈 P, T, Pre, Post 〉 com P = p1, p2, p3 , T = t1, t2 , Pre =

(p1, t1), (p2, t2) e Post = (t1, p2) (t2, p3), representa essa RdP.Com relação a complexidade, as RdP podem ser classificadas em dois tipos [Peterson, 1981]:

• Baixo Nível: Nestas RdP a marcação de cada lugar corresponde a um valor bo-oleano (RdP Ordinária). As fichas utilizadas para marcação da rede representamapenas o seu estado e não possuem um significado específico, a não ser pela estruturaa qual a rede está associada. Um exemplo de rede de baixo nível é a RdP Ordinária,que será discutida com mais detalhes na seção 3.6.

• Alto Nível: As RdP de alto nível permitem uma maior facilidade e simplicidadede especificação. A marcação de um só lugar pode conter muitas informações secomparadas as redes de baixo nível e elas não são iguais entre si. Essas informa-ções podem ser: valores, cores, tipos abstratos de dados, além da representação doestado do sistema. Exemplo de redes de alto nível são: RdP Coloridas, Temporais,Híbridas, Orientadas a Objeto e etc. Essas RdP surgiram da necessidade de mo-delar sistemas não triviais e complementam as RdP Ordinárias adicionando maiorflexibidade, de acordo com o sistema a ser modelado.

Na próxima seção serão apresentadas algumas propriedades das Redes de Petri.

Propriedade das Redes de Petri

As propriedades das RdP encontram-se longamente discutidas em diversas literaturas.Neste trabalho serão discutidas as propriedades com base na literatura de [Cardoso e Vallete, 1997]e [Murata, 1989].

Em [Murata, 1989] as propriedades das RdP são classificadas em comportamentais ouestruturais. As propriedades comportamentais, também conhecidas por dinâmicas e comoo próprio nome sugere estão em constante mudanças durante o funcionamento da redee são essencialmente dependentes da marcação desta. Sendo assim, podemos considerarcomo propriedades comportamentais os seguintes itens:

• Alcançabilidade: Uma marcação é dita alcançável em uma RdP se existir umasequência finita de disparos que conduza a ela a partir da marcação inicial. Logo, setodas as marcações alcançáveis forem decorrentes da inicial, a rede é dita alcançável;

• Limitabilidade: Uma RdP é dita limitada se para cada lugar da rede, a quantidadede marcas não excederá a um inteiro k, para qualquer marcação alcançável a partirde M0. Neste caso, a rede é dita k-limitada, onde k é considerado a capacidademáxima de cada lugar. A Figura 3.6 é limitada, pois observa-se que as fichas noslugares da rede nunca excedem ao inteiro 2, portanto, é uma rede 2-limitada.

38

Figura 3.6: Exemplo de RdP Reiniciável e k-limitada

• Vivacidade: O conceito de vivacidade garante a completa ausência de Deadlock 2

na rede. Uma RdP é dita viva se ela consegue executar todas suas ações (disparos) apartir de qualquer uma das marcações alcançáveis da rede, garantindo a inexistênciade bloqueios no sistema; A Figura 3.7 ilustra um exemplo de deadlock, portanto, éuma rede que não possui a propriedade de vivacidade. Neste caso, a transição t1

não pode ser disparada, pois nem todos os estados de entrada da transição possuemuma ficha, admitindo a possibilidade de um deadlock.

Figura 3.7: Exemplo de Deadlock

• Reversabilidade:Uma RdP é dita reversível se existe uma marcação base que podeser acessada de qualquer outra marcação do conjunto de alcançabilidade da rede;

• Cobertura: Uma marcação M em uma RdP é dita coberta se existir uma marcaçãoM’ em R(M0) tal que M’(p) ≥ M(p) para cada lugar p pertencente a esta rede[Murata, 1989]. Desta forma, uma RdP é coberta se o número de marcas em cada

2[Murata, 1989] Deadlock é uma configuração da rede a qual nenhuma transição está habilitada paradisparar.

39

lugar de M” for maior ou igual ao número de marcas do lugar correspondende deM’, para todos os lugares da rede.

• Persistência: Uma RdP é dita persistente se existem mais de uma transição habi-litada3 em qualquer das marcações na rede. Por sua vez, a execução de um disparode uma delas não desabilita a execução das demais.

• Reiniciabilidade: Uma RdP é reiniciável se é possível voltar à marcação inicial apartir de qualquer marcação alcançável. Na Figura 3.6 é apresentado um exemplode RdP reiniciável. Nesta Rede, é possível chegar a marcação inicial a partir dequalquer sequência de disparo.

• Justiça: Uma RdP é dita justa se o número de vezes que quaisquer duas transiçõessão executadas é finito, enquanto uma transição é executada, a outra não executa.

Nas propriedades estruturais, o foco é voltado somente para a estrutura das redes.Neste caso, são independentes da marcação e não se modificam no decorrer de seu funci-onamento. Exemplo destas propriedades são: vivacidade estrutural, controlabilidade, li-mitabilidade estrutural, conservabilidade, repetibilidade, consitência, justiça B-estrutura.Tais propriedades não serão discutidas por não pertencerem ao foco deste trabalho.

3.5.2 Tipos de Rotas

Sem que o usuário do sistema perceba, ao ser executado, este pode assumir diversassituações tais como, sincronismo, concorrência, paralelismo, conflito e disparo em sequên-cia. Na modelagem através da RdP é possível visualizar e diferenciar cada item citadoacima. Para isso, nesta seção serão discutidos cada um dos tipos de Redes.

• Conflito: o conflito significa que existe duas alternativas para um mesmo lugar, ouseja, a execução de uma transição exclui a execução de outra. (Figura 3.8)

Figura 3.8: Exemplo de conflito em uma RdP

3Uma transição habilitada é aquela cujo cada um dos seus lugares de entrada possuem pelo menosuma quantidade de marcas maior ou igual ao peso dos arcos que conectam os lugares a esta transição[Peterson, 1981].

40

• Paralelismo: a presença de paralelismo na rede indica que duas ou mais atividadespoderão ser executadas ao mesmo tempo, como se pode ver na Figura 3.9.

Figura 3.9: Exemplo de Paralelismo em uma RdP

Os lugares p2 e p3 podem ser executados simultaneamente sem que um tenha queesperar o outro terminar de executar para começar sua execução.

• Disparo em sequência: é o tipo de rede mais simples e comum. O disparo dastransições é feito sequencialmente, ou seja, assim que t1 disparar, t2 já estará apto afazer o próximo disparo, e assim por diante. Na Figura 3.10 é ilustrado este exemplo.

Figura 3.10: Exemplo de Disparo sequencial em uma RdP

• Concorrência: é quando os lugares disputam por uma mesma transição, como émostrado na Figura 3.11

Figura 3.11: Exemplo de Concorrência em uma RdP

As principais redes elucidadas neste trabalho para consolidar a compreensão do es-tudo de caso demonstrado no Capítulo 4 são, em especial, as Redes de Petri Ordinárias,Coloridas e Modais que serão detalhadamente descritas nas próximas seções.

41

3.6 Rede de Petri Ordinária

É uma rede de baixo nível, isto é, suas fichas representam apenas o seu estado. A RdPOrdinária é considerada o modelo mais básico das RdP.

De acordo com Petterson [Peterson, 1981], uma RdP Ordinária marcada, isto é, umarede que possui fichas distribuídas pelos lugares, é um conjunto de lugares, transições,lugares precedentes e lugares decorrentes e marcação inicial da rede, representada pelaquíntupla: R = 〈 P, T, Pre, Post, M0 〉 onde P representa um conjunto finito de lugaresde dimensão N, analogamente T representa as transições de dimensão M, Pre define paracada transição t ∈ T um conjunto de lugares de entrada, Post define para cada transiçãot ∈ T um conjunto de lugares de saída e M0 é a marcação inicial dada pela aplicação: M:P → N.

A representação do número de fichas que pertence a um lugar pode ser descrita daseguinte forma: M(p) ou pX onde x é o número de fichas e p é o lugar.

Na Figura 3.12 tem-se a representação de uma RdP Ordinária. A representação donúmero de fichas desta Figura se dá pela fórmula: M(p1) = 4 ou p1

4. Ainda nestafigura, tem-se três estados e quatro transições que exemplificam o compartilhamento deum conjunto de quatro recursos que são representados pelas fichas contidas em p1, e entreduas atividades que são representadas pelos lugares p2 e p3. Os números vistos sobre osarcos são denominados de pesos.

O disparo de uma transição só poderá ocorrer se cada lugar precendente, ou seja, saido lugar e chega a transição, tiver no mínimo uma ficha. Em outra palavras, a transiçãosó irá acontecer se ela estiver sensibilizada. Em uma RdP Ordinária nenhum tempo éenvolvido.

Figura 3.12: Rede de Petri Ordinária

Matematicamente, a RdP Ordinária da Figura 3.12 pode ser representada da seguinteforma: P = p1, p2, p3 T = t1, t2, t3, t4 Pre(p1,t1) = 3, Pre(p1, t3) = 2, Pre(p2,t2) = 3, Pre(p3, t4) = 2, Post(p1, t2) = 3, Post(p1, t4) = 2, Post(p2, t1) = 3, Post(p3,

42

t3) = 2 M0 = p4

A RdP Ordinária também pode ser representada por uma notação matricial. Nestecaso, as linhas representam os lugares e as colunas representam as transições. Essa notaçãosó poderá ser empregada se a RdP em questão possuir pesos nos arcos [Cardoso e Valette,1997]. A matriz de incidência anterior é definida com base nos elementos de Pre assimcomo a matriz de incidência posterior é definida com base nos elementos de Post, ambascom dimensões n x m.

A notação matricial da Rede da Figura 3.12 é dada por três matrizes: a matriz Pre,Post, e C, onde C é obtida através da fórmula: C = Pre - Post e apresenta informaçõessobre a movimentação das fichas.

Pre =

3 0 2 0

0 3 0 0

0 0 0 2

Post =

0 3 0 2

3 0 0 0

0 0 2 0

A partir das duas matrizes acima, defini-se a matriz de incidência C que fornece o

balanço das fichas na rede quando ocorre o disparo das transições [Cardoso e Valette,1997]:

C =

−3 3 −2 2

3 −3 0 0

0 0 2 −2

Os valores positivos indicam que foram acrescentadas fichas enquanto que nos valores

negativos as fichas foram removidas.Na próxima seção será apresentada a RdP Colorida mais detalhadamente, pois esta

será utilizada no Estudo de Caso apresentado no Capítulo 4 e constitui uma peça funda-mental para o entendimento do estudo.

3.7 Rede de Petri Colorida

As Redes de Petri Coloridas (RdPC) foram idealizadas por Kurt Jensen, pesquisadorda Universidade de Aarhus, na Dinamarca. Seu artigo, do ano de 1981, intitulado ColouredPetri Nets and the Invariant Method foi um trabalho com resultados favoráveis que abriuespaço a uma série de estudos sobre coloração das fichas.

43

A RdPC é uma extensão da RdP Ordinária porém com informações adicionais. Écaracterizada por diferenciar as fichas uma das outras atribuindo-lhes cores, permitindorepresentar diferentes recursos e processos em uma mesma rede. Essa RdP pode serutilizada para modelar sistemas não triviais, logo, faz parte da classe de Redes de altonível.

[Ramos e Oliveira, 2009] realizou uma comparação da RdP Colorida com a RdP Or-dinária e percebeu algumas características e vantagens que merecem ser destacadas. Sãoelas:

• Uma RdPC pode ser reduzida a uma RdP Ordinária, isto é, ela pode ser transfor-mada em uma RdP Ordinária sem perder a equivalência.

• Na prática, a RdPC possui um melhor poder de compactação da rede se comparadoa RdP Ordinária, por isso são mais utilizadas para modelar um sistema complexo.

• Possui uma representação gráfica bastante intuitiva e aparentemente não tem dife-rença da RdP Ordinária.

[Cardoso e Valette, 1997] apresenta uma definição formal para a Rede de Petri Coloridacomo sendo uma sêxtupla dada por:

Nc = 〈 P, T, Cor, Csc, W, M0 〉, onde:

• P é um conjunto finito de lugares;

• T é um conjunto finito de transições;

• Cor é um conjunto finito de cores;

• Csc é a função sub-conjunto de cores que a cada lugar e a cada transiçãoassocia um sub conjunto de Cor (as cores possiveis para este lugar ouestra transição: Csc: P ∪ T → P(Cor));

• W é a função de incidência que equivale nas RdP Ordinárias a C=Post−Pre;

• M0 é a marcação inicial que associa, para cada lugar e para cada corpossivel neste lugar, um número de fichas.

A principal característica desta Rede é a diferenciação das fichas através da atribuiçãode cores, por isso o nome de RdP Colorida. Desta forma, a cada transição e lugar éassociada um conjunto de cores. No caso das transições, as cores indicam as diferentesmaneiras de disparar uma transição.

44

Um exemplo clássico que permite demonstrar o alto poder de compactação das redesColoridas é o problema do jantar dos filósofos4. Na Figura 3.13 mostra bem esta diferença.

O objetivo desta transformação é substituir o conjunto de lugares por um só lu-gar“colorido” através das marcas. As marcas coloridas possibilitam representar cada umdesses lugares através de valores inteiros distintos. A compactação dos lugares implicanecessariamente em uma compactação dos arcos e esta tarefa é concluída por meio daadição de funções aos arcos. Estas funções possibilitam avaliar quais as marcas que serãosubtraídas e quais serão adicionadas aos lugares.

Pode-se observar o que foi explicado anteriormente na função Garfos() da Figura3.13 b). Na Figura 3.13 a) os lugares de cor branca representam os estados “filósofospensando”, os lugares de cor cinza escuro representam os estados “filósofos comendo” e,por fim, os lugares com tom cinza claro representam os garfos. Vale ressaltar que, quantomaior for a quantidade de filósofos mais será possível visualizar a redução significativa dacomplexidade obtida através da utilização da RdPC (Figura 3.13 b)) ao comparar-se coma Rede de Petri Ordinária.

É possivel representar uma mesa com mais filósofos e garfos, bastaria apenas alterar amarcação inicial dos lugares Pensando e Garfos disponíveis e a função Garfos() (Figura3.13 b)). Enquanto que em a) a quantidade de lugares e arcos cresceria na rede na mesmaproporção do crescimento do número de filósofos e garfos.

O conjunto de variáveis que suportam as marcas são declaradas em um escopo glo-bal, pois em diferentes instantes é necessário fazer um novo cálculo para o disparo dastransições e assim é necessário que todas as transições conheçam tais variáveis.

Já nas Redes de Petri Ordinárias não existe o emprego de valores às marcas. O únicocuidado que se deve ter em relação as fichas é a presença ou não da quantidade de marcasnecessárias nos arcos de entrada.

Na RdPC é recomendado a imposição de restrições nos disparos das transições combase nos valores de suas marcas, pois estas podem não ser necessariamente iguais entre si[e Barros, 1996].

É importante ressaltar que a idéia de cores não está relacionada ao pigmento outonalidade, e sim a atribuição de valores diferentes as marcas.

Na próxima seção será apresentada um novo conceito de Rede de Petri, as Redes dePetri com Modalidades, aliadas a Lógica Modal para impor restrições ao disparo dastransições.

4O problema do jantar dos filósofos foi formulado por Dijkstra em 1965 e baseia-se em uma mesacircular onde sentam um determinadeo número de filósofos, no qual cada um possui seu prato e existeapenas um garfo entre dois pratos. Os filósofos podem estar nos estados Comendo, ou Pensando, porémpara comer, o filósofo precisará de dois garfos. O problema ocorrerá quando todos os filósofos pegarem ogarfo da sua direta e esperarem pela liberação do garfo da esquerda para se alimentarem

45

Figura 3.13: Transformação de uma RdP Ordinária (Figura a) para uma rede Colorida(Figura b).[e Barros, 1996]

3.8 Rede de Petri com Modalidade

Conforme descrito por [Clempner e Medel, 2007], estrutura de Kripke está fortementeligada com Redes de Petri, contudo existem diferenças fundamentais. Uma rede de Petrirepresenta sistemas que envolvem tokens como entradas e respondem a estes através deações em forma de transições geridas por uma função. Já uma estrutura de Kripke éobtida apenas pela descrição do sistema, ela exemplifica todas as possíveis situações quepodem ocorrer na realização da ação de um sistema.

Uma forma natural de estender uma Rede de Petri Colorida, seria empregar o conceitode mundos a cada estado, de maneira que as fichas recebam, em vez de cores, átomos. Arelação de alcançabilidade pode ficar a cargo das transições, uma vez que uma função éum caso particular de relação.

O intuito dessa combinação é unir os benefícios das Redes de Petri com as vantagensproporcionadas pelas modalidades. Formalmente, pode se pensar em Redes de Petri comModalidade da maneira descrita a seguir:

• Cada lugar no modelo representa uma atividade do sistema, definindo assim umconjunto de lugares:

L = L1, L2, L3,...Ln

• As transições definem o conjunto:

46

T = T1, T2, T3,...Tn

• Os arcos ligam lugares em transições e transições em lugares.

Um modelo de RdPcM é apresentado pela Figura 3.14:

Figura 3.14: Modelo de RdPcM

As transições possuem um esquema do tipo:

〈 L1, φ 〉 → 〈 ψ, L2 〉, 〈 α, L1 〉

no qual temos que ψ, φ e α são cláusulas. As cláusulas são conjuções literais do tipo:

φ: p ∧ ¬q ∧ rα: ¬p

ψ: q ∧ ¬r

O disparo de uma transição ocorrerá quando a expressão da transição:

〈 L1, φ 〉 → 〈 ψ, L2 〉, 〈 α, L1 〉

é satisfeita, ou seja, se torna verdadeira. Na Figura 3.15 é apresentado um modelo deRdPcM antes do disparo da transição.

Figura 3.15: Modelo de RdPcM antes do disparo da transição

Nota-se que o modelo acima satisfaz a clausula φ, ou seja, 〈 L1, φ 〉, pois dado

φ = p ∧ ¬q ∧ r;

47

temos que, para 〈 L1, φ 〉 ser verdadeiro, a cláusula definida por φ também seja verdadeira,isto é, deve existir no lugar L1 os literais p e r, porém não deve existir q.

Logo, se o antecendente da implicação for verdadeiro, o consequente também será, ouseja, havendo 〈 L1, φ 〉 → 〈 ψ, L2 〉, 〈 α, L1 〉 , e 〈 L1, φ 〉 é verdadeiro, então 〈 ψ,L2 〉, 〈 α, L1 〉 se sucede, como pode ser observado na Figura 3.16.

Figura 3.16: Modelo de RdPcM após o disparo da transição

O símbolo proposicional p é retirado do lugar L1, como é mostrada na cláusula α =

¬p.O próximo passo é a colocação do símbolo proposisional q no lugar L2 e a retirada do

símbolo r, correspondendo a cláusula ψ:

ψ = q ∧ ¬rOs arcos de saída da transição de disparada são α e ψ. Algumas considerações serão

descritas abaixo para uma melhor compreensão da RdPcM.Considerações:

1. A Rede de Petri com Modalidade utiliza linguagem proposicional, não havendoquantificadores ∃ nem ∀, da lógica de predicados.

2. Li pode ser um “mundo possível” da Lógica Modal.

3. As transições modificam os mundos possíveis, atividades ou telas do sistema, de-pendendo do contexto.

3.9 Considerações Finais

Neste capítulo foram apresentados conceitos sobre Lógica Modal para a compreensãodo uso de Redes de Petri com Modalidades. Nota-se que a Lógica consolidada por Kripkenão é tão trivial como se imagina e requer bastante atenção para seu uso. As modalidadesmais conhecidas envolvem possibilidade e necessidade, as quais especificam um modo noqual o resto da preposição poderá ser verdadeira dependendo do mundo em que estarãoinseridas.

48

Posteriormente, conceitos sobre redes de Petri foram abordados. De acordo com exten-sas literaturas baseadas para a fundamentação deste trabalho, a escolha da modelagem desistemas através de redes de Petri pode ser considerada bastante proveitosa, pois muitosautores expõem essa técnica como sendo altamente eficiente. Elas possuem um poder derepresentação bastante elevada, podendo representar desde processos concorrentes até adetecção de erros presentes na especificação do sistema.

As RdP adotadas para um estudo mais profundo neste trabalho foram as Ordinárias,Coloridas e com Modalidades, que serão aplicadas ao estudo de caso apresentado noCapítulo 4.

49

Capítulo 4

Estudo de Caso

Este capítulo empregará na prática os conteúdos abordados nos capítulos anteriores.Conceitos sobre Árvore de características, LPS no contexto de requisitos, Redes de Petrie Lógica Modal serão utilizados no estudo de caso de um “Forno Elétrico”. A próximaseção abordará os trabalhos relacionados e as seções seguintes apresentarão a elaboraçãoe execução do estudo de caso realizado.

4.1 Trabalhos Relacionados

Amodelagem de sistemas tem sido cada vez mais discutida no contexto de formalizaçãode software das mais diversas naturezas. Deste modo, serão apresentados nesta seçãoalguns trabalhos relacionados com este trabalho.

O trabalho de [Oliveira e Souza, 2011] propõe o uso do modelo de árvore de carac-terísticas como forma de elicitação de requisitos, objetivando testar se o emprego destaabordagem poderia ser utilizada por pessoas com pouco conhecimento técnico na área deengenharia de software, porém detentoras do conhecimento pedagógico necessário para aconstrução de uma Comunidade Virtual de Aprendizagem para atender alunos do sextoao nono ano. E em seguida é apresentada a tradução desta árvore para uma rede de PetriColorida com expressões lógicas. A idéia é aplicar todos estes conceitos para o desenvol-vimento e validação de uma Comunidade Virtual de Aprendizagem, voltada para o ensinofundamental.

Em [Maria. et al., 2007] é apresentado uma proposta de modelagem de Objetos deAprendizagem que aplica um mecanismo chamado de LOCPN (Learning Objects pro-duction with Colored Petri Nets) baseada em Rede de Petri Colorida. Neste artigo éapresentado um modelo formal que procura dar suporte e apoio no desenvolvimento desoftware web, no qual é empregado para o melhoramento da qualidade de implementações,bem como a redução do tempo de produção.

O modelo de LOCPN, alguns quesitos merecem ser destacados. Inicialmente, alguns

50

lugares representam telas/janelas (pop-ups ou tradicionais) de implementação de Objetosde Aprendizagens. Em relação as fichas, há uma que merece atenção especial, a fichae, esta, indicará que o controle do fluxo estará em foco (ativo) no momento. A respeitodas transições, deverão ser marcadas com pesos que indicarão as ações sobre os controlesda tela ou uma mudança de foco. A introdução desta nova ferramenta que ajuda nodesenvolvimento de Objetos de Aprendizagem, vem sendo um grande desafio. Porém,muitas vantagens vem sendo constatadas com a sua utilização, tais como aumento daqualidade de implementação, facilidade na construção da documentação e participação deuma equipe pedagógica no início do projeto para apoiar/melhorar as funcionalidades dosistema a ser desenvolvido, já que eles são os possuidores do conhecimento.

Já no contexto de técnicas de modelagem e Lógica Modal, em [Carvalho, 2011] é pro-posto a modelagem de Interfaces de software utilizando árvore de características e LógicaModal para definir uma nova forma de modelar projetos de interface de software. É pro-posto uma comparação do método de modelagem que ela utiliza, o MNLAC (ModelagemNavegacional baseada em Lógica de Árvore Computacional) com outros métodos, usuais,de Engenharia de Software, tais como o OOHDM (Object Oriented Hypermedia DesignMethod) e MoLIC (Modeling Language for Interaction as Conversation). Por fim, MN-LAC é aplicado para a modelagem da Interface de um sistema educativo de apresentaçãode conteúdo, através de uma ferramanta de Captura e Acesso.

O MNLAC aborda a concepção de mundos possíveis da Lógica Modal, denominadosde Telas. Uma Telas constitui um estado da interface do sistema em um determinadomomento da execução. Estabelecido o conjunto de Telas e um conjunto de relações, éaplicado os princípios da dedução Lógica Modal com o objetivo de certificar a satisfaçãode propriedades no sistema

[Carvalho, 2011] ressalta ainda os benefícios da melhoria da usabilidade da interfacedo sistema ao aplicar as técnicas acima, porém, ainda existe o desafio de entender asdificuldades que especialistas encontram ao elaborar o projeto, são elas:

• Dificuldade em entender as tarefas do usuário;

• complexidade relativa às tarefas e aplicações;

• variedade de aspectos e requisitos diferentes, pois as interfaces com o usuário en-volvem questões como design gráfico, documentação, desempenho e etc., o que fazaumentar a complexidade;

• teoria e métodos não são suficientes para resolover o problema;

• dificuldade de criar um projeto iterativo.

51

Contudo, o uso da Lógica Modal como sendo uma linguagem descritiva e de especifica-ção para tratar o formalismo da modelagem de interfaces com o usuário, se torna adequadopossibilitando a verificação de propriedades necessárias para um bom funcionamento dosoftware.

Além disso, foi revisado também o trabalho de [Clempner e Medel, 2007] que apresentaum novo paradigma de modelagem para o desenvolvimento de representação de processode decisão associando para qualquer rede de Petri de Processo de Decisão (DPPN) umaestrutura de Kripke. As principais características deste modelo é a sua capacidade derepresentar e analisar as propriedades do caminho mais curto de um processo de decisão.Neste artigo, os autores fazem uso de Lógica Modal Temporal empregando as modalidadesX (next) unário, U (until) binário e também um operador chamado Lypunov. Este artigodistancia um pouco do foco deste trabalho, porém ele tenta unir a estrutura de Kripke auma rede de Petri, neste caso, a rede de Petri de Processo de Decisão que se assemelhacom parte desta monografia, "casando"a rede de Petri com a Logica Modal.

Em consideração as Redes de Petri Coloridas, o trabalho de [Prata, 2006] propõeelaborar um modelo de avaliação de desempenho operacional em terminais portuários,baseado nas redes de Petri Coloridas, tendo como principal variável de decisão o tempototal de deslocamento das cargas utilizadas em um porto.

Desta forma, [Prata, 2006] abordou o software CPNTools, editor e simulador de Re-des de Petri Coloridas, para implementação, simulação e análise do modelo proposto.Concluiu-se que, as simulações feitas possibilitaram avaliar que o terminal portuário ci-tado não está operando de forma eficiente, no que diz respeito a frota de caminhõesalocada para a movimentação de contêineres. Portanto, pode ser destacada a eficiênciado emprego de Redes de Petri Colorida como técnica de modelagem, simulação e análise.

Além disso, a Lógica Modal também é utilizada para verificação de códigos e algorit-mos. Em [Areces et al., 1998] é proposto o uso da lógica descritiva para projetar sistemas.

4.2 Estudo de caso: Extração de Funções e Caracte-

rísticas de um Forno Elétrico

Por ser um produto que apresenta facilidades em seu uso, o forno elétrico será adotadocomo objeto de estudo de caso favorecendo a didática que será empregada. Um outromotivo importante para a escolha deste, deve-se ao fato de possuir uma série de variaçõesna família1, tornando-se um alvo fácil para o emprego dos conceitos de uma LPS, bemcomo o gerenciamento das variabilidades e similaridades existentes no sistema.

1Um produto pertence a uma mesma família, se compartilha características comuns e gerenciáveis quesatisfaz as exigências de um determinado ramo do mercado [Northrop e Clements, 2005]

52

A primeira atividade a efetuar sobre o objeto de estudo é a elicitação de requisitos. Ousuário fornecerá os requisitos que o sistema de forno elétrico terá através da construçãode uma árvore de cartacterísticas. Neste processo, o usuário deverá expor, pormenor,os detalhes essenciais do sistema. O nível de abstração desta árvore, ainda assim, éconsiderado alto do ponto de vista do especialista, pois a árvore não fornece detalhes deimplementação, apenas características essenciais do sistema a ser construído e que sãovisíveis ao usuário.

Na Figura 4.1 é ilustrado a árvore de característica resultante do processo de elicitação.Observa-se nesta árvore que além das características, o usuário também focou nas funçõesdo sistema, o que não deixa de serem elementos valorizadas por ele.

Figura 4.1: Árvore de Características de um Sistema de Forno Elétrico

O ramo mais a esquerda da árvore de características da Figura 4.1, indica as funciona-lidades que o usuário gostaria de ver em seu sistema. A função "cozinhar" define a famíliado produto, pois qualquer forno elétrico, contendo quaisquer características, tem comometa principal cozinhar um alimento, portanto, esta função é definida como o Kernel da

53

aplicação, isto é, o núcleo do sistema. No entanto, tem-se as variações que podem estarinclusas ou não em um forno, por exemplo, assar, tostar, secar, esterelizar, etc. Por outrolado, o ramo mais a direita aponta as características técnicas.

É importante ressaltar que uma boa técnica de modelagem implica em uma melhorrepresentação dos dados coletados. Realizar esta etapa de maneira satisfatória, ou seja,construir uma árvore de características que cumpre com as necessidades do usuário, éimprescindível para o claro desenvolvimento e entendimento do sistema solicitado.

Contudo, ao concluir esta etapa, é necessário que a árvore de características criadaseja submetida a um refinamento, com o intuito de remover possíveis ambiguidades nainterpretação dos requisitos. Neste estágio, a árvore de características será traduzida emuma LPS e novas características serão acrescentadas pelo especialista.

A idéia é especificar ainda mais as informações obtidas, até então, do sistema a serrepresentado. Deste modo, ao aplicar o refinamento a árvore de características será con-vertida para uma LPR. De acordo com os conceitos da LPS, explorados no Capítulo 2, éincorporado também a gerência de variabilidade e similaridade das características extraí-das, o que torna possível a obtenção de requisitos completos e consistentes. A Figura 4.2elucida o refinamento da árvore de características apresentada anteriormente pela Figura4.1.

Na árvore de características refinada (Figura 4.2), são acrescidas novas características.Estas, foram inseridas com o propósito de gerenciar as variabilidades e similaridades, mos-trando ao usuário que, além das características que ele forneceu, existem outras passíveisde gerenciamento, permitindo um leque maior de seleção que poderá ser constituída aosistema final.

Nota-se que, diferentemente da árvore de característica inicial, as arestas da árvorerefinada possuem significados. No ramo mais a esquerda da árvore, o qual incluem asfunções do forno elétrico, as características “assar”, “tostar”, “grelhar”, “secar”, “descon-gelar” e “esterelizar” passaram a ser opcionais, denotadas pela aresta com um circulonão-preenchido na ponta. Não é um requisito obrigatório, para um forno elétrico, constartodas essas funcionalidades. No entanto, um forno elétrico pode ou não conter todas ouparte dessas funcionalidades, logo, tais características são destacadas por serem optativas.

Ainda no mesmo ramo, as características “alarme” e “lâmpada” também foram clas-sificadas como optativas. Enquanto que “cozinhar” e “botão regulador” são obrigatórias.Incorporado ao “botão regulador” ainda encontra-se as características “power on/off”, “tem-peratura” classificadas como mandatórias e “timer” como opcional. Caso o forno elétricopossua o botão regulador “timer”, obrigatoriamente deverá vir acompanhado da regula-gem do tempo, que varia de 0 a 120 minutos, o mesmo se aplica para o termostato datemperatura, variando entre 50 a 300C.

54

Figura 4.2: Árvore de Características Refinada

55

No ramo à direita da árvore, encontram-se as características técnicas. Observe que,cada uma das características técnicas foram acrescidas de requisitos que podem variar,representadas pela aresta com um arco entre elas, indicando serem características alter-nativas, isto é, o usuário poderá optar por apenas uma característica dentre as opçõesexistentes.

Após construir a árvore de características refinada, o próximo passo é realizar a si-mulação e execução através das Redes de Petri Ordinária e Colorida e com Modalidade(Seção 4.3). Posteriormente, será feito o gerenciamento das variabilidades e similarida-des do sistema de forno elétrico. O objetivo é combinar o refinamento com tal gerênciapara evitar, ou no mínimo amenizar, os problemas de ambiguidade e conflito de requisi-tos, classificando as características como mandatória, opcional ou alternativa (Seção 4.4).Isto será realizado através do software GRequisitos, desenvolvido para tal gerenciamento.Este, é executado online, via web e foi implementado na linguagem Ruby.

4.3 Simulação e execução através das Redes de Petri

A mera construção de uma árvore de características para elicitar requisitos e o empregodo gerenciamento das variabilidades, não é suficiente para garantir a correta execução dosistema. Para atender a este propósito, será empregado as Redes de Petri Ordinária e comModalidade, para simular e executar as funções do forno elétrico, verificando formalmentese o sistema funciona corretamente. A RdPcM, auxiliará na introdução de restrições àstransições da RdP, a fim de estabelecer uma correta execução das funções.

Por representar o núcleo do sistema, a função escolhida para simular neste trabalho éa função “Cozinhar”, considerada uma das mais importantes.

Para auxiliar na elaboração das descrições textuais da função “Cozinhar”, é apresentadoum template que permite descrever um algoritmo da função. Esta descrição leva emconsideração o relatório gerado pelo GRequisitos, obedecendo as características que ousuário selecionou para representar seu forno elétrico (ver Algoritmo 4.1).

O Algoritmo 4.1 descreve, detalhadamente, o comportamento do sistema ao iniciar afunção “Cozinhar”. A construção deste algoritmo facilitará a criação da Rede de Petri,uma vez que as transições, representadas por t, são bem definidas.

A utilização das Redes de Petri para formalização dos requisitos deve-se ao fato depermitir a modelagem na representação dos processos, permitindo uma avaliação crite-riosa do desempenho e comportamento do sistema modelado. Com isto, o uso da RdPpossibilita a detecção de eventuais erros presentes na especificação garantindo a corretudedo sistema em questão.

Desta forma, para simular a execução da função escolhida, a RdP Ordinária corres-pondente ao Algoritmo 4.1, pode ser observada na Figura 4.3.

56

Algoritmo 4.1 Trecho da descrição textual da função “Cozinhar” do sistemaNome do Caso de Uso: Cozinhar

Categoria de reuso: Kernel

Resumo: Usuário insere o alimento no forno e o forno cozinha o alimento

Pré-Condição: Forno pré-aquecido

Descrição:

1. Usuário abre a tampa (t1), coloca a comida no forno (t2), fecha a tampa (t3)

2. Alimento pronto pra ser cozido (t4)

3. Usuário ajusta o botão de temperatura (t5)

4. Sistema acende a luz que indica seu funcionamento (t6)

5. Sistema verifica o tempo em que atinge a temperatura desejada (t7)

6. Sistema apaga a luz (t8)

7. Usuário define o tempo de cozimento (t9)

8. Sistema inicia contagem do tempo definido (t10)

9. Sistema inicia cozimento do alimento (t11)

10. Sistema desliga automaticamente ao acabar o tempo solicitado (t12)

11. Usuário abre a tampa (t13), remove a comida do forno (t14), fecha a tampa (t15)

Figura 4.3: RdP Ordinária correspondente ao Algoritmo 4.1

A sequência dos disparos para a execução desta Rede de Petri, serão apresentados aseguir. A marcação inicial (ficha que está associada ao lugar p1) sensibiliza a transição t1,que não possui pré-condição. O disparo de t1 indica que a tampa foi aberta pelo usuário.Após o disparo de t1, um novo estado é produzido no lugar, criando uma nova ficha emp2.

Com uma ficha no lugar p2, a transição t2 é sensibilizada. O disparo de t2 indica que acomida foi colocada no forno. Após o disparo de t2, um novo estado é produzido, criando

57

uma nova ficha em p3.Com uma ficha no lugar p3, a transição t3 é sensibilizada. O disparo de t3 indica que

a tampa do forno é fechada. Após o disparo de t3, um novo estado é produzido, criandouma nova ficha em p4.

Com uma ficha no lugar p4, a transição t4 é sensibilizada. O disparo de t4 indicaque o alimento está pronto para ser cozido. Após o disparo de t4, dois novos estadossão produzidos, ocorrendo o paralelismo. Agora há 2 fichas, uma em p5 e outra em p7,indicando que as transições t5 e t6, (usuário regula botão de temperatura e sistema acendea luz que indica seu funcionamento, respectivamente) acontecem concorrentemente.

Até que o sistema inicie o cozimento do alimento, haverá a concorrência das transiçõese estados. Após o disparo de t5, um novo estado é produzido, criando uma nova fichaem p6. Da mesma forma, após o disparo de t6 um novo estado é produzido, criando umanova ficha em p8.

Com uma ficha no lugar de p6, a transição t7 é sensibilizada. O disparo de t7 indicaque o sistema está verificando o tempo em que atinge a temperatura desejada. Após odisparo de t7, um novo estado é produzido, criando uma nova ficha em p9.

Com uma ficha no lugar p9, as transições t7 e t8 são sensibilizadas, mas somente atransição t8, que indica se a temperatura desejada foi alcançada, é satisfeita. Após odisparo de t8 um novo estado é produzido, criando uma nova ficha em p10.

Com uma ficha no lugar p10 e no lugar p8, a transição t9 é sensibilizada. O disparode t9 indica que o usuário definirá o tempo de cozimento do alimento. Após o disparo det9, um novo estado é produzido, criando uma nova ficha em p11.

Com uma ficha no lugar p11, a transição t10 é sensibilizada. O disparo de t10 indicaque o botão de timer do sistema está rolando até chegar ao ponto inicial. Após o disparode t10, um novo estado é produzido, criando uma nova ficha em p12.

Com uma ficha no lugar p12, a transição t11 é sensibilizada. O disparo de t11 indicaque o alimento está sendo cozido. Após o disparo de t11, um novo estado é produzido,criando uma nova ficha em p13.

Com uma ficha no lugar p13, a transição t12 é sensibilizada. O disparo de t12 indicaque o tempo solicitado foi alcançado. Após o disparo de t12, um novo estado é produzido,criando uma nova ficha em p14.

Com uma ficha no lugar p14, a transição t13 é sensibilizada. O disparo de t13 indicaque o usuário abriu a tampa. Após o disparo de t13, um novo estado é produzido, criandouma nova ficha em p15.

Com uma ficha no lugar p15, a transição t14 é sensibilizada. O disparo de t14 indica queo usuário remove a comida do forno. Após o disparo de t14, um novo estado é produzido,criando uma nova ficha em p16.

Com uma ficha no lugar p16, a transição t15 é sensibilizada. O disparo de t15 indica

58

que o usuário fecha a tampa do forno. Após o disparo de t15, um novo estado é produzido,criando uma nova ficha no último estado, p17. Assim encerra sua execução.

4.4 Especificação lógica para Redes de Petri

Acrescentar um paradigma lógico à Redes de Petri implica em ganhos de formalismo,além do operacional já oferecido. Isto é, a inserção de um paradigma lógico incrementaráo poder de validação e verificação da Rede de Petri.

Nesta seção serão discutidos o emprego de tais paradigmas, apontando vantagens edesvantagens de cada um e as pesquisas que subsidiam os apontamentos apresentados. Oprimeiro a ser tratado envolve o uso de lógica modal. Em seguida serão apresentados, atítulo de ilustração, uma abordagem sem modalidades empregando lógica proposicional ecáluculo de sequentes.

4.4.1 Rede de Petri com Modalidade

A sequência da execução dos disparos da RdPcM é análoga a Rede de Petri Ordinária(ver Figura 4.3), porém inclui expressões da Lógica Modal com o propósito de estabelecerrestrições comportamentais às transições da RdPM.

Na Figura 4.4 é ilustrado a Rede de Petri Colorida com expressões da Lógica Modal,denominada de Rede de Petri com Modalidade.

Figura 4.4: Rede de Petri com Modalidades

As transições da RdPcM somente serão disparadas após satisfazerem as condiçõesestabelecidas através de fórmulas da Lógica Modal. Tais restrições são representadas porExp e possuem a seguinte semântica:

59

• Exp1: Necessariamente a tampa será fechada, então, usuário regulará o botão detemperatura. Sendo k = “tampa fechada” e L = “botão de temperatura regulado”,temos: 2k → k ∧ L

• Exp2: Necessariamente o botão de temperatura será regulado, então, a luz irá apa-gar. Sendo: M = “botão de temperatura regulado” e N = “luz apagada”, temos: 2M→ M ∧ N

• Exp3: Necessariamente a temperatura desejada será alcançada, então, a luz iráapagar. Sendo: P = “temperatura desejada” e Q = “luz apagada”, temos: 2P → P∧ Q

• Exp4: Necessariamente o timer será definido, então, o botão será rolado até o pontoinicial. Sendo: R = “timer será definido” e S = “botão rolado”, temos: 2R→ R ∧ S

• Exp5: Necessariamente o tempo solicitado será atingido, então, o sistema desligará.Sendo: T = “tempo solicitado” e U = “sistema desligado”, temos: 2T → T ∧ U.

Para uma melhor observação da Figura 4.4, na Figura 4.5 tem-se uma ampliação daRdPcM exatamente onde está localizada a primeira expressão(Exp1), isto é, a primeirarestrição da rede.

Figura 4.5: RdPcM após o disparo da transição t5

Neste momento, os lugares são considerados como mundos na Lógica Modal e as tran-sições representam a alcançabilidade. De acordo com as regras supracitadas no Capítulo3, mais precisamente na seção 3.2, 2K é verdadeira em um mundo p5 se e somente se k éverdadeiro em qualquer mundo alcançável por p5. Deste modo, para que 2K seja verda-deiro, K ∧ L no mundo p6 deverão ser verdadeiros, em outras palavras, necessariamente atampa será fechada se tampa fechada e botão de temperatura regulado forem verdadeiros.Logo, a condição é satisfeita e a transição será disparada, como é mostrado na Figura 4.5.

De forma análoga, acontece com os disparos das transições das Figuras 4.6, 4.7, 4.8,4.9 abaixo.

60

.png

Figura 4.6: RdPcM após o disparo datransição t6

Figura 4.7: RdPcM após o disparo datransição t8

Figura 4.8: RdPcM após o disparo datransição t10

Figura 4.9: RdPcM após o disparo datransição t12

4.4.2 Considerações a respeito de Redes de Petri comModalidade

Como se percebe no Estudo de Caso no que se refere ao emprego da RdPcM, o meroemprego de modalidades não agrega grande valor lógico a Rede de Petri. Uma vez queos únicos axiomas empregados se enquadram no esquema 2A → A ∧ B, este pode serdesconsiderado na abstração, ficando apenas a análise proposicional das fórmulas presentesem cada estado. Isto mostra que agregar modalidades não se apresenta de forma trivial,como alertado em [Clempner e Medel, 2007].

Contudo, tal estudo realizado, apresenta uma abordagem mais natural. Que seria oemprego de lógica proposicional (podendo se estender a lógica de predicados) aos mundose às transições. Ainda, pode se pensar em atribuir conceitos de modalidade temporal(Lógica Temporal) aos estados e transições.

Da primeira abordagem pode-se citar o trabalho de [Almeida e Haeusler, 1999] emque se mostra o emprego de um sistema dedutivo proposicional baseado em Cálculo deSequentes.2

A segunda abordagem, pode-se citar o trabalho de [Clempner e Medel, 2007] em queas modalidades empregadas são representadas por Next (próximo) e Until (até que) jun-

2Cálculo de Sequentes é um sistema dedutivo a La Frege, muito empregado em provadores automáticosde teoremas que, possui como único axioma fórmulas da forma A ⇒ A e um conjunto de regras deinferência baseadas em sequentes. Mais detalhes podem ser encontrados em [van Dalen, 2004].

61

tamente com um operador de Lyapunov3.A abordagem apresenta a característica de ser implementável por um checador de

Modelos (Model Cheking) e pode ser generalizada para vários sistemas. Contudo, taltrabalho ainda não foi empregado para sistemas em Linhas de Produto de Software, o quesugere um trabalho futuro de pesquisa.

Quanto ao trabalho de [Almeida e Haeusler, 1999], em que os autores tiveram a pre-ocupação de verificar a consistência e completude do sistema, pode se empregar o uso dosistema dedutivo a la Frege apresentado para extrair conceitos e propriedades da rede dePetri. O sistema emprega marcadores às fórmulas para indicar de que mundo (estado)tal fórmula teve origem, seja por construção, seja por agregação. As regras de inferênciadevem levar em conta todas estas nuances, o que leva o sistema a possuir 23 regras deinferência. Apesar de não ter sido evidenciado em tal trabalho, crê-se que um provadorautomático de teoremas baseado nas regras apresentadas seja factível.

4.5 GRequisitos - Gerenciamento das variabilidades

Concluído a etapa de execução das Redes de Petri Ordinária e Modal, nesta últimaetapa o usuário estará apto a instanciar produtos, isto é, através do GRequisitos o usuáriopoderá escolher quais funções e características ele gostaria de ver no seu produto, gerando,ao final, um modelo de forno elétrico da série X, por exemplo.

Este processo se dará da seguinte forma:

1. O especialista irá inserir todas as características apresentadas na árvore refinada,classificando-as em mandatórias, opcionais e alternativas e ainda diferenciando-asem comum ou variável;

2. Posterior às inserções das características, o usuário estará apto a instanciar o pro-duto, escolhendo as características que melhor satisfaçam suas necessidades;

3. Ao final, um relatório das características selecionadas será gerado.

Para entrar no site do GRequisitos, basta digitar “grequisitos.heroku.com”. O heroku éum serviço de hospedagem de site que se destaca por ser uma plataforma de computaçãona nuvem como serviço, denotado pela sigla PaaS (Plataform as a Service). Atualmentesuporta seis linguagens: Ruby, Java, Node.js, Scala, Clojure e Phyton. Foi fundado poruma equipe de engenheiros que pensavam que desenvolver aplicativos para web era muitocomplicado. É um desenvolvimento ágil cujo o foco é 100% no código.

3por entender que tal abordagem foge ao escopo do trabalho, recomenda-se que mais detalhes sobretal operador seja pesquisada em [Kalman e Bertram, 1960]

62

Para entender todas as funcionalidades do GRequisitos, na Figura 4.10 é ilustrado apágina inicial do mesmo.

Figura 4.10: Página Inicial do GRequisitos

Ao clicar em “Sobre” uma breve descrição do sistema é mostrado (ver Figura 4.11).

Figura 4.11: Menu “Sobre” do GRequisitos

Para utilizar o GRequisitos é necessário que o usuário cadastre uma senha. Para isso,basta clicar em “Cadastrar”. Nesse menu, o “Nome”, “Email” e “Senha” são exigidos dousuário para que o cadastro seja realizado com sucesso (ver Figura 4.12).

63

Figura 4.12: Menu “Cadastrar” do GRequisitos

Após realizar o cadastro, o usuário estará apto para logar no sistema (ver Figura 4.13)

Figura 4.13: Menu “Entrar” do GRequisitos

Logado no sistema, incialmente com o login do administrador, o especialista irá inserirtodas as características elicitadas e mais aquelas que foram refinadas e acrescentadas naárvore de característica refinada. Na Figura 4.14 é mostrado a primeira página ao logarno sistema.

Nesta tela, tem-se os sub-menus: “Selecionar características” e “Nova característica”.A princípio, não existe nenhuma característica a ser selecionada. Logo, o primeiro passo éadicionar uma nova característica. A Figura 4.15 mostra o modo como é feito a inserção.

Inicialmente, no campo “Nome” coloca-se o nome da característica em questão, poste-riormente, escolhe-se o tipo em que ela se enquadra(comum ou variável), classifique-a emmandatória, opcional ou alternativa e, por fim, dê uma breve descrição da característica.Clique em “Cadastrar” para que a característica inserida seja armazenada.

64

Figura 4.14: Página inicial ao logar no sistema

Figura 4.15: Tela de inserção de novas características

Figura 4.16: Modo de exibição da característica adicionada

Ao cadastrar uma característica, a tela irá exibi-la como mostrado na Figura 4.16.

Note que, ao classificar uma característica como “alternativa” ou “opcional”, um campoa mais será adicionado ao sistema. Isto, significa que ela será considerada como nó filho,ou seja, sempre virão integradas a uma característica mandatória (nó Pai), pois os filhossão as variações existentes no sistema (ver Figura 4.17).

Logo, ao adicionar uma característica com estas classificações, fica a cargo do especi-

65

alista indicar qual o nó pai (também chamado de mandatória) deste filho. Esta distinçãoajudará na clareza do relatório final.

Figura 4.17: Novo campo ao inserir Características Opcionais ou Alternativas

Dado que todas as características foram incorporadas ao sistema pelo especialista, ousuário estará autorizado a fazer logon e selecionar as características que melhor definemo sistema de forno elétrico que ele necessita. Esta etapa é ilustrada na Figura 4.18. Aofinal desta tela, há um botão “Gerar Relatorio”.

E, por fim, após a seleção das características, o usuário gerará um relatório das ca-racterísticas selecionadas, obtendo assim, a instância de um forno elétrico da série X (verFigura 4.19).

A (Figura 4.19) exibi parcialmente a LPR. Porém, é possível se ter uma noção decomo é gerado tal relatório. As características recuadas a direita, correspondem as carac-terísticas filhas,ou seja, aquelas que são marcadas como opcionais ou alternativas e cujoo nó acima é o pai (característica mandatória) .

66

Figura 4.18: Tela para selecionar características

67

Figura 4.19: Gerando o Relatório das características selecionadas.

68

Capítulo 5

Conclusão e Trabalhos Futuros

Neste trabalho foi apresentado como a extração de requisitos pode acontecer de modoeficiente e formal. Inicialmente, foi utilizado a árvore de características como método deelicitação de requisitos para o estudo de caso do sistema de forno elétrico. O uso destaárvore facilita a obtenção do conhecimento necessário para o desenvolvimento do sistema,e, ainda, constitui-se em um modelo simples e bastante intuitivo. Destaca-se também porpermitir ser elaborada por usuários leigos em computação, onde estes, deverão ser capazesde expor, pormenor, as necessidades do sistema em questão sem ter que frustrar-se comdefinições técnicas.

A validação da árvore de característica foi realizada por [Oliveira e Souza, 2011] aplicando-a para usuários com pouco ou nenhum conhecimento em informática, comprovando, assim,a facilidade de compreensão desta.

As Linhas de Produtos de Software com foco nos requisitos, foi empregada na árvore decaracterísticas a fim de diferenciar requisitos mandatórios, alternativos e opcionais, o quecontribuiu para eliminação de requisitos ambíguos, inconsistentes e/ou duplicados. Paraisto, a árvore de característica construída foi submetida a um refinamento, acresentando-lhe características variáveis.

As características acrescentadas serviram para fornecer um leque maior de opçõesao usuário do sistema final, permitindo-lhe que optasse pela característica que mais seaproximasse para a satisfação de suas necessidades.

Uma vez que o produto da LPR é instanciado pelo usuário, é essencial que se garantaa correta execução do sistema. Para este propósito, o emprego das Redes de Petri Ordi-nária e com Modalidade tornaram-se indispensáveis. O algoritmo de descrição textual dacaracterística “Cozinhar” do forno elétrico, apresentado na seção 4.3, permitiu de modoclaro e objetivo, a visualização de como ocorre a descrição de uma variável do sistema.

Tal descrição, auxiliou na construção das Redes de Petri Ordinária e Colorida, uma vezque as transições foram bem definidas. Estas redes foram empregadas para possibilitar asimulação e execução, de modo formal, do requisito “Cozinhar” em questão.

69

Finalmente, posterior a simulação e execução das Redes de Petri Ordinária e Colorida,procurou-se garantir a corretude da execução por meio de um paradigma lógico. Nesteintento, tentou-se o emprego de propriedades da Lógica Modal para estabelecer restriçõesàs transições da RdP, originando, deste modo, a Rede de Petri com Modalidades.

Na RdPcM, expressões da Lógica Modal foram aplicadas às transições com intuito deestabelecer tais condições para seu disparo. Ao safisfazer a condição imposta, a transição aqual esteve associada a alguma expressão Lógica, foi disparada. Desta forma, pretendeu-segarantir a segurança do correto funcionamento do sistema modelado.

O emprego de modalidades, como um simples adendo às Redes de Petri, não apre-sentou o poder esperado de representação. Contudo, uma vez que tal monografia podeser empregada para desenvolvimento de trabalhos futuros, achou-se por bem documentartodo o trabalho envolvido em sua construção.

Ressalta-se, entretanto, que a busca por formalizar Redes de Petri abriu horizontes depesquisas atraentes tanto para estudos teóricos quanto aplicados. Teóricos, por envolve-rem assuntos de lógica matemática e Redes de Petri e práticos por permitir a aplicação emuma área tão carente de formalismos de verificação e validação que é Linhas de Produtosde Software, particularmente no que envolve elicitação de Requisitos.

Para auxiliar na etapa de gerenciamento de variabilidade, o software GRequisitos foidesenvolvido com o objetivo de permitir que o usuário instancie o produto. Através destesoftware, o especialista irá inserir as características que foram extraídas do usuário e maisaquelas que foram refinadas. Após esta inserção, o usuário estará apto a selecionar ascaracterísticas que melhor se encaixam às suas necessidades. Ao final, um relatório comas características selecionadas é gerado.

Durante a construção deste trabalho, viu-se necessário a possibilidade de otimizar eestender certos aspectos que poderão vir a contribuir para pesquisas futuras. Para tanto,como proposta de trabalhos futuros pode-se destacar:

• Construção protótipo para validar o modelo de Rede de Petri Ordinária, permitindoassim, a simulação de diferentes cenários de interface;

• Adapatar a abordagem com lógica temporal à árvore de característica em Linha deProdutos de Software.

• Verificar a viabiliade de construção de provadores baseados no sistema dedutivo de[Almeida e Haeusler, 1999] empregando tal abordagem no processo de elicitação derequisitos.

• Desenvolvimento de uma formalização matemática para a árvore de características.Dessa forma, a modelagem utilizando árvores de características poderá alimentar arede de Petri de forma automática;

70

• Automatização do processo de construção de uma árvore de característica. Imple-mentação de um software que auxilie usuários leigos a fazerem a correta utilizaçãoe preenchimento das árvores de características, fornecendo um meio gráfico para acriação, edição e impressão destas;

71

Referências

Almeida, E. S. e Haeusler, E. H. (1999). Proving properties in ordinary petri nets usingLoRes logical language. Petri Nets Newsletter, 57:23–36.

Batista, E. A. e Carvalho, A. M. B. R. (2003). Uma taxonomia facetada para técnicas deelicitação de requisitos. In Martins, L. E. G. e Franch, X., editors, WER, pages 48–62.

Boehm, B. W. (1988). A spiral model of software development and enhancement. Com-puter, 21:61–72.

Booch, G., Rumbaugh, J., e Jacobson, I. (2000). UML: guia do usuário. Rio de Janeiro:Campus. Tradução por: Fábio Freitas.

Cardoso, J. e Vallete, R. (1997). Redes de Petri. Editora da UFSC, Florianópolis.

Carnap, R. (1966). Introduction to semantics, and Formalization of logic. Harvard Uni-versity Press.

Carvalho, D. O. (2011). Mnlac: Uma proposta de modelagem de fluxo de navegação ba-seada em lógica modal. Dissertação de mestrado., Universidade Federal de Uberlândia- UFU, Uberlândia, MG.

Castro, J. (1998). Disponivel em: http://www.cin.ufpe.br/~if119/aulas/cap3.PDF.Acessado em: 23/12/2012.

Chellas, B. (1980). Modal logic: an introduction. Cambridge Univ Pr.

Clempner, J. e Medel, J. (2007). A simple modal logic approach to decision process. InProceedings of the 9th WSEAS international conference on Mathematical and computa-tional methods in science and engineering, MACMESE’07, pages 34–38, Stevens Point,Wisconsin, USA. World Scientific and Engineering Academy and Society (WSEAS).

Czarnecki, K., Helsen, S., e Ulrich, E. (2005). Formalizing cardinality-based featuremodels and their specialization. Software Process: Improvement and Practice, 10:7 –29.

Dix, A., Finaly, J., Abowd, G., e Beale, R. (2004). Human-Computer Interaction. PrenticeHall Europe.

e Barros, J. P. M. P. R. (1996). Cppnets: uma classe de redes de petri de alto-nível:implementação de um sistema de suporte à sua aplicação e análise. Dissertação demestrado, Faculdade de Ciências e Tecnologia, Portugal, Lisboa.

72

El Hog-Benzina, D., Haddad, S., e Hennicker, R. (2010). Process refinement and asynchro-nous composition with modalities. In Sidorova, N. e Serebrenik, A., editors, Proceedingsof the 2nd International Workshop on Abstractions for Petri Nets and Other Models ofConcurrency (APNOC’10), Braga, Portugal.

Engberg, U. e Winskel, G. (1990). Petri nets as a model of linear logic. In CAAP - 90,volume 431, Copenhagen. Springer Lecture Notes in Computer Science.

Finkelstein, L., Huang, J., Finkelstein, A., e Nuseibeh, B. (1992). Using software speci-fication methods for measurement instrument systems: Part 1: Structured methods.Measurement, 10(2):79 – 86.

Fischer, M. (2001). Estudo de requisitos para um software educativo de apoio ao ensinoda introdução a computação. Dissertação de mestrado, Instituto de Matemática eEstatística. Universidade de São Paulo.

Goldblatt, R. (1995). Logics of time and computation, volume 60. Center for the Studyof Language and Information.

Gomaa, H. (2005). Designing Produtc Lines with UML: From Use Cases to Pattern-BasedArchitectures. Addison-Wesley.

Hughes, G. e Cresswell, M. (1996). A new introduction to modal logic. Burns & Oates.

Kalman, R. E. e Bertram, J. E. (1960). Control system analysis and design via the ?secondmethod? of lyapunov. Transactions of the ASME Journal of Basic Engineering, 82:371–393.

Maria., S., Gomes, D. G., Barroso, G. C., de Souza, C. T., de Castro Filho, J. A., Pequeno,M. C., e Andrade., R. M. C. (2007). Locpn: Redes de petri coloridas na produção deobjetos de aprendizagem. Revista Brasileira de Informática na Educação, 15(3):39–52.

Mathias, de Oliveira, T. C., e de Lucena, C. J. (2004). A framework instantiation approachbased on the Features Model. Journal of Systems and Software, 73(2):333–349.

Murata, T. (1989). Petri nets: properties, analysis and applications. Proceedings of theIEEE, 77.

Northrop, L. e Clements, P. (2005). Software Product Lines. Carnegie Engineering Insti-tute, Pittsburgh, PA.

73

Oliveira, C. C. e Souza, J. N. (2011). Árvore de características e rede de petri coloridacom expressõs da lógica proposicional: Propostas de modelagem de requisitos e fluxode navegação. Dissertação de mestrado, Universidade Federal de Uberlândia.

Osborn, A., F. (1962). O poder criador da mente: Princípios e processos do pensamentocriador e do Brainstorming. Ibrasa.

Peterson, J. L. (1981). Petri Net Theory and the Modeling of Systems. Prentice HallPTR, Upper Saddle River, NJ, USA.

Prata, B. A. (2006). Avaliação de desempenho operacional de terminais portuários decarga utilizada: Uma aplicação das redes de petri coloridas. Fortaleza - Ce.

Pressman, R. (2005). Engenharia de Software. McGraw Hill Interamericana do Brasil.

Ramos, E. e Oliveira, J. (2009). Especificação e verificação formal de um modelo de sti-pblpor redes de petri coloridas. Revista Brasileira de Informática na Educação, 17(3).

Robertson, S. e Robertson, J. (2006). Mastering the requirements Process. Pearson Edu-cation, Boston, MA.

Silva, S. M. A., Bonim, M. R., e Paludo, M. A. (2005). Levantamento de requisitossegundo o método volere. Disponível em: http://publica.fesppr.br/index.php/

rnti/\%20article/viewFile/v1n1ART2/86. Acessado em: 25/11/2011.

Sommerville, I. (2009). Engenharia de Software. São Paulo: Pearson Assison-Wesley.

van Dalen, D. (2004). Logic and structure. Springer Verlag.

Weiss, D. M. e Lai, C. T. R. (1999). Software product-line engineering: a family-basedsoftware development process. Addison-Wesley Longman Publishing Co., Inc., Boston,MA, USA.

Wiegers, K. E. (2003). Software requirements: practical techniques for gathering andmanaging requirements throughout the product development cycle. Microsoft Press.

74