Uma das áreas da Engenharia de Software mais desafiadoras de se trabalhar chama-se Engenharia de Requisitos. Tudo isto porque trata-se de uma área bastante subjetiva em termos de aquisição, estruturação e análise de informações o que, de uma certa forma, pode ocasionar ambiguidade. Assim, modelar problemas do mundo real para serem solucionados por sistemas de computação em geral torna-se uma tarefa difícil, uma vez que é preciso verificar qual parcela do mundo real e seus problemas serão tratados e que, muitas vezes, constitui-se uma tarefa árdua quando são problemas de grande complexidade.

O objetivo geral da área de Engenharia de Software é modelar problemas do mundo real para serem tratados por sistemas computacionais por meio da Elicitação de Requisitos. Esse processo consiste em capturar os Requisitos dos clientes que desejam a solução computacional para resolução dos seus problemas. Os Requisitos são características desejadas para o sistema computacional resolver os seus problemas no mundo real. Estes são divididos, no geral, em Requisitos Funcionais - que correspondem as funções que o sistema de software deve executar para solucionar problemas do mundo real - e Requisitos Não Funcionais - que corresponde as estruturas em termos de recursos, ambientes e demais informações referentes a como o sistema de software irá executar suas funções para resolução dos problemas do usuário. É no processo de Elicitação de Requisitos que deve ser verificado o contexto de mundo real onde está alocado o usuário, ambiente dos problemas, características dos problemas, ambiente de execução do sistema de software e demais informações necessárias.

Mesmo diante de um contexto tão subjetivo e informal acerca das informações, existe a necessidade de um certo formalismo que visa modelar o mundo real para o mundo computacional para tratar com objetividade os problemas do mundo real. Assim, surgiu a necessidade de elaborar metodologias, métodos, processos, notações aplicadas dentro do contexto da Engenharia de Requisitos para dar suporte aos Analistas de Requisitos. No mais estas ferramentas CASE (Computer-Aided Software Engineering – Engenharia de Software Assistida por Computação) constituem um auxílio automatizado para Elicitação de Requisitos.

Ferramenta CASE RE-Tools

Uma das ferramentas disponibilizadas no universo web para auxílio na fase de Engenharia de Requisitos chama-se RE-Tools. A RE-Tools constitui-se de um kit de ferramentas, open source, para modelagem de Requisitos em múltiplas notações. Atualmente a ferramenta dá suporte as seguintes notações:

  • NFR Framework: para modelagem de Requisitos Não-Funcionais;
  • I* Framework: para modelagem softwares Orientada a Agentes;
  • KAOS: para modelagem formal de objetivos;
  • Problem Frames: para modelagem de especificações e requisitos de negócios e de sistemas;
  • UML: para modelagem de softwares Orientados a Objetos;
  • BMPN: para modelagem de processos de negócios.

Estas notações podem ser modeladas separadamente ou em conjunto, de forma integrada. Diagramas criado pela ferramenta são representados na memória com base em uma meta-modelo e armazenados em arquivos de texto com base em um formato XML/XMI. Este kit ferramental consiste em um plugin do aplicativo StarUML. A ferramenta RE-Tools em geral da suporte aos processo de modelagem, raciocínio e implementação.

A StarUML é uma ferramenta open source, para modelagem de sistemas de software. A ferramenta da suporte a notações como UML e MDA (Model Driven Architecture – Modelagem Dirigida a Arquitetura. A ferramenta tem suporte a 11 dos diagramas da notação UML, sendo eles: Diagrama de Classes, Objeto, Casos de Uso, Componentes, Implantação, Composição, Sequência, Comunicação, Atividade, Perfil e Máquina de Estados. Atualmente a ferramenta está na versão 2.0 e pode ser obtida no site principal (veja o link no final do artigo). Contudo, esta nova versão da StarUML ainda não possui suporte a plugins por se tratar de uma versão beta e de avaliação. A versão mais estável e que dá suporte a ferramenta RE-Tools é a versão 1.0 (veja o link no final do artigo). A seguir serão abordados brevemente os tipos de notação que são suportados pela RE-Tools.

Modelagem de Requisitos pelo Framework NFR

A RE-Tools suporta o Framework NFR para a modelagem de Requisitos Não Funcionais (NFRs), conforme definido neste em (BRITO; MOREIRA, 2004), com uma extensão para apoiar ambas suposições de mundo abertas e fechadas para satisfação da análise de camadas de objetivos. O framework NFR consiste em uma framework para modelagem de Requisitos Não Funcionais, auxiliando na identificação e especificação destes interesses. Este framework é composto pelo conceito de execução de quatro principais tarefas:

  • Identificação de interesses: fazendo uso de um template para descrição dos Requisitos;
  • Especificação de interesses: onde se especifica os Requisitos fazendo uso da melhor abordagem, identificação das contribuições, identificação de prioridades e identificação de recursos;
  • Identificação dos Requisitos Cruzados;
  • Composição dos Requisitos (BRITO; MOREIRA, 2004).

A ferramenta tem suporte a Gráfico de Interdependência de MetaObjetivos (Softgoal Interdependency Graph - SIG) que modela contas de segurança, junto com as suas definições e medidas de segurança correspondente (Figura 1). Também existe o suporte para o Gráfico de Interdependência de MetaProblemas (Problem Interdependency Graph - PIG) para a modelagem de metaproblemas ou obstáculos para cumprimento dos MetaObjetivos, como mostra a Figura 2.

Figura 1. Ilustração do Gráfico de Interdependência de MetaObjetivos (“RE-Tools: A Multi-notational Requirements Modeling Toolkit”, [s.d.]).

Figura 2. Ilustração do Gráfico de Interdependência de MetaProblemas.

Modelagem de Requisitos pelo Framework I*

O Framework I* trata-se de uma modelagem dirigida a Requisitos no contexto da Engenharia de Software Orientada a Agentes, modelando os stakeholders ou conceitos sociais como atores e suas intenções como metas que, por sua vez, são desempenhadas por atores, o que pode ocorrer diversas cardinalidades como um ator cumpre uma meta ou várias metas, meta cumprida por um ator ou vários atores e várias metas desempenhadas por vários atores. Por isto que o sistema de software é projetado como uma estrutura organizacional de atores que na dependência de atores cumprem as suas metas. Assim, o framework tem como principais objetivos:

  • Obter uma melhor compreensão sobre os relacionamentos da organização;
  • Entender as razões envolvidas nos processos de decisões;
  • Descrever potenciais alternativas do sistema pretendido.

O framework I* é estruturado em dois modelos: modelo de Dependência Estratégica (DE) e modelo de Razão Estratégica (RE). O modelo de Dependência Estratégica é utilizado para descrição das intenções de processos em termos de relacionamentos de dependência entre atores. Já o modelo de Razão Estratégica fornece a descrição estratégica de processos, levando em consideração elementos processuais e análise de metas que deverão ser cumpridas pelos atores. Para mais informações sobre o Framework I* e sobre Engenharia de Software respectivamente, pode-se consultar os posts Introdução a Metodologia TroposeEngenharia de Software Orientada a Agentes.

A ferramenta suporta a modelagem dos diagramas de Dependência Estratégica (DE) e Razão Estratégica (RE) do Framework I*. A seguir, são exemplos de diagramas Dependência Estratégica (Figura 3) e Razão Estratégico Diagramas (Figura 4), respectivamente.

Figura 3. Ilustração de Diagrama de Dependência Estratégia.

Figura 4. Ilustração de Diagrama de Razão Estratégica.

Modelagem de Requisitos pela notação KAOS

A notação KAOS (Knowledge Acquisition in automated Specification - Especificação Automatizada em Aquisição de Conhecimento) é um Método Formal. Estes são métodos utilizados para elaboração de sistemas computacionais dando prioridade a sua coesão, isto porque estes métodos são desenvolvidos a partir de princípios matemáticos o que garantem a sua exatidão na capacidade de expressão das ideias vinculadas ao projeto de software. Estes métodos foram desenvolvidos para auxiliar todas as etapas de desenvolvimento de software, sendo elas:

  • especificação formal para definição de requisitos;
  • refinamento para concepção de projeto;
  • síntese para implementação;
  • prototipagem para a validação
  • e prova para a verificação.
Além disso, o uso de Métodos Formais pode ser aplicado durante todas as etapas de desenvolvimento do software ou somente em algumas etapas ou partes do projeto de desenvolvimento. As principais características desta abordagem são a reutilização de conhecimento de domínio e na aplicação da tecnologia de aprendizagem de máquina. Duas estratégias de aprendizagem foram adaptadas ao contexto de aquisição requisitos: aprendizado por instrução, onde o aluno realiza o processo de aquisição, utilizando meta conhecimento sobre o tipo de conhecimento a ser adquirido, e aprendizado por analogia, onde o aluno obtém conhecimento sobre algum sistema "similar" para mapeá-lo para o sistema que está sendo aprendido. A abordagem geral de KAOS possui três componentes:
  • Um modelo conceitual para a aquisição e estruturação de modelos de requisitos, com uma linguagem de aquisição de conhecimento associada;
  • Um conjunto de estratégias para a elaboração de modelos de requisitos;
  • Um assistente automatizado para fornecer orientação no processo de aquisição de acordo com tais estratégias.

A Figura 5 e a Figura 6 ilustram modelos da notação KAOS. A ferramenta RE-Tools suporta um subconjunto dos conceitos definidos sobre a notação KAOS, com as seguintes extensões:

  • Diferentes ícones para objetivos de "Requisitos" e "Expectativa";
  • Ícones diferentes para as pessoas, hardware, software alvo (software em desenvolvimento), e software externo;
  • Capacidade de vincular MetaObjetivos NFR à elementos do modelo KAOS.

Figura 5. Ilustração do Modelo de Objetivos da notação KAOS.


Figura 6. Ilustração do Modelo de Obstáculos da notação KAOS.

Modelagem de Requisitos pela notação Problem Frames

A abordagem Problem Frames não é considerada um método de desenvolvimento, mas sim considerada como uma perspectiva e um quadro conceitual, modelando uma certa maneira de olhar para um importante grupo de classes de problemas e de estruturação dos processos intelectuais de desenvolvimento de boas soluções. Destina-se a ser usado de várias maneiras:


  • De forma construtiva: para orientar o desenvolvimento de software;
  • Analiticamente: para ajudar a compreensão do desenvolvimento de software;
  • e Metodologicamente: para ajudar na compreensão das abordagens existentes e propostas para Engenharia de Software (JACKSON, 2005).
O Problem Frames é uma abordagem para a decomposição de problemas. Dada uma boa decomposição de um problema em sub-problemas, uma gama de benefícios surgem se o analista for capaz de fornecer uma solução, resolvendo os sub-problemas de forma isolada, e depois, compor as soluções parciais para resultar em um sistema completo. Os benefícios incluem: escalabilidade (devido ao trabalho a nível de sub-problemas mais simples), rastreabilidade (os sub-problemas são mapeados diretamente para suas soluções), e mais fácil quanto à evolução do sistema (alterações ao sub-problemas podem ser resolvidos pela modificação das soluções ou composições correspondente). A Figura 7 ilustra um exemplo do Diagrama de Problemas da notação Problem Frames.

A RE-Tools suporta Problem Frames, como descrito em (LANEY et al., 2004) e (JACKSON, 2005), com as seguintes extensões:

  • Flechas nos enlaces de Interface e Referência de Requisitos para indicar o destino do fenômeno primário;
  • Capacidade de vincular MetaObjetivos NFR para elementos do modelo Problem Frames.

Figura 7.
Ilustração do Diagrama de Problema da notação Problem Frame.

Modelagem de Requisitos pela notação UML

Por padrão, devido a ferramenta StarUML, a ferramenta RE-Tools tem suporte a modelagem de Requisitos pela notação UML. Devido a notação UML ser muito conhecida ela não será descrita neste post. Usando StarUML, o usuário é capaz de modelar todos os diagramas UML suportados pela ferramenta. AFigura 8 ilustra um digrama UML com notações utilizadas na RE-Tools, que estende a notação UML com a capacidade de vincular MetaObjetivos para elementos do modelo UML nos seguintes diagramas, incluindo:

  • Diagrama de Classes;
  • Diagrama de Casos de Uso;
  • Diagrama de Componentes;
  • Diagrama de Implantação.

Figura 8. Ilustração de Diagrama de UML com NFR.

Modelagem de Requisitos pela notação BMPN

A Iniciativa de Gerenciamento de Processos de Negócios (BPMI - Business Process Management Initiative) desenvolveu um padrão chamado Notação Modelagem de Processos de Negócios (BPMN - Business Process Modeling Notation). A especificação BPMN 1.0 foi lançada ao público em Maio de 2004 e representa mais de dois anos de esforço por parte do BPMI Notation Working Group. O principal objetivo do esforço BPMN foi providenciar uma notação que seja facilmente compreensível por todos os usuários de negócios, desde os analistas de negócios que criam os rascunhos iniciais dos processos, para os desenvolvedores técnicos responsáveis pela implementação da tecnologia que irá executar esses processos, e, finalmente, às pessoas de negócios que irão gerenciar e monitorar esses processos. BPMN também contém suporte a um modelo interno que permite a geração de executáveis BPEL4WS. Assim, a BPMN cria uma ponte padronizada para a lacuna entre o desenho de processos de negócios e implementação de processos. Além disso, define um Diagrama de Processos de Negócios (BPD - Business Process Diagram), que é baseado em uma técnica de fluxograma adaptado a para a criação de modelos gráficos de operações de processos de negócios. Um modelo de processo de negócio, então, é uma rede de objetos gráficos, que são atividades (ou seja, trabalho) e os controles de fluxo que definem a ordem de desempenho (WHITE, 2004).

A Figura 9 ilustra um Diagrama BPMN. RE-Tools suporta modelagem de processos de negócio utilizando a notação BPMN. Apoio BPMN está atualmente em fase experimental e ainda não foi totalmente integrado com o pacote principal RE-Tools. A versão atual (v0.1) suporta os seguintes conceitos de modelagem:

  • Pilha de Processos;
  • Tarefa (enviar, receber, usuário, manual, regras de negócio, serviços e Script);
  • Início de Evento (padrão, mensagem, temporizador, erros e Regras de Negócio);
  • Eventos Intermediários (padrão, mensagem, temporizador, erros e Regras de Negócio e enlaces);
  • Finalizar eventos (finalizar e Mensagens);
  • Fluxo de Sequência (Padrão, Condicional);
  • Gateway (exclusivo, inclusivo, baseado em eventos, paralelo, baseado em evento exclusivo, baseado em evento paralelo, complexidade);
  • Armazenamento de dados, Objetos de dados, Associação de dados.

Figura 9. Ilustração de um Digrama BPMN.

Suporte a Raciocínio

A ferramenta RE-Tools faz uso de duas formas de Raciocínio: Raciocínio Qualitativo e Raciocínio Quantitativo. A RE-Tools usa o Raciocínio Qualitativo para avaliar a realização do objetivo em Gráficos de Interdependência de MetaObjetivos (SIG) baseada em Label Propagation Procedure (Propagação de Procedimentos em Camadas), com uma extensão para apoiar tanto modelagem de mundo fechado e os pressupostos de mundo aberto. O Raciocínio Qualitativo foi estendido para suportar todas as quatro notações, incluindo o notação NFR, o Framework I*, Método Formal KAOS e Problem Frames.

A RE-Tools usa o Raciocínio Quantitativo para recomendar uma alternativa desejável para se alcançar um MetaObjetivo. A recomendação alternativa quantitativa baseia-se em seleção com base em pesos.

Instalação e Configuração da ferramenta RE-Tools

A ferramenta RE-Tools só está disponível para plataformas Windows já que a ferramenta StarUML é uma ferramenta de modelagem com suporte somente para Sistemas Operacionais Windows. A ferramenta para download e demais informações sobre RE-Tools estão disponíveis no site (ver link no final do artigo).

O único requisito para instalação da ferramenta RE-Tools é estar instalado no computador a ferramenta StarUML. Primeiro se faz o download e instalação da ferramenta StarUML. Após isto, se faz o download e instalação da ferramenta RE-Tools também obtida no site da ferramenta citado anteriormente.

Espero que tenham gostado de mais um dos meus posts, agradeço a atenção de todos e até a próxima.

Referências

AMBIEL, L. M. B. Tópicos de Engenharia de Software Orientada a Agentes. p. 6, 2010.

JACKSON, M. Problem frames and software engineering. Information and Software Technology, v. 47, n. 14, p. 903 – 912, 2005.

LANEY, R. et al. Composing requirements using problem framesRequirements Engineering Conference, 2004. Proceedings. 12th IEEE International. Anais...set. 2004

RE-Tools: A Multi-notational Requirements Modeling Toolkit. Disponível em: . Acesso em: 16 dez. 2014.

SUPAKKUL, S. et al. An NFR Pattern Approach to Dealing with NFRsRequirements Engineering Conference (RE), 2010 18th IEEE International. Anais...set. 2010

WHITE, S. A. Introduction to BPMN. IBM Cooperation, v. 2, n. 0, p. 0, 2004.

StarUml:http://staruml.io/

Ferramenta ReTools:http://www.utdallas.edu/~supakkul/tools/RE-Tools/download-installation.html

SIG:http://utdallas.edu/~supakkul/NFR-modeling/label%20evaluation%20and%20world%20assumptions/label-propagation.htm