TDRRC - Técnica para Documentação e Recuperação de Requisitos no Código-Fonte através do uso de... por Vinicius Miana Bezerra - Versão HTML

ATENÇÃO: Esta é apenas uma visualização em HTML e alguns elementos como links e números de página podem estar incorretos.
Faça o download do livro em PDF, ePub, Kindle para obter uma versão completa.

requisitos através de entrevistas com usuários, uso do software;

Rui (2007) que apresenta uma proposta para refatoração de casos de uso e

um meta-modelo de casos de uso usado para definir estas refatorações;

Schwarz et al. (2008) que apresenta a rastreabilidade de requisitos dentro do

contexto da Evolução de Software;

Sneed (2008) que apresenta um panorama geral da Reengenharia de

Software;

Yang et al. (2006) que apresenta uma técnica para Engenharia Reversa de

requisitos não funcionais;

Yu et al. (2005) que apresenta os tópicos de interesse da Engenharia

Reversa de requisitos.

Com os resultados da pesquisa, foi feita uma Compilação de Dados que sumarizou

as informações pertinentes aos potenciais objetivos deste trabalho.

Introdução

12

Com estes dados, foi realizado o Desenvolvimento da TDRRC e uma técnica

candidata foi detalhada, documentada e avaliada.

Foi feita então uma Análise Crítica, onde a TDRRC foi confrontada com outras

referências para avaliar o seu potencial de atingir o objetivo deste trabalho e trazer

uma contribuição significativa. Enquanto o resultado da análise não foi satisfatório, o

processo foi reiniciado com uma ampliação da Pesquisa Bibliográfica, uma nova

Compilação de Dados, um aprimoramento no Desenvolvimento da TDRRC e uma

nova Análise Crítica.

Uma vez que os resultados da Análise Crítica foram satisfatórios, foi realizado um

Estudo de Caso onde a TDRRC foi aplicada.

Finalmente foi feita uma Análise dos Resultados da aplicação da TDRRC no Estudo

de Caso.

1.5 ESTRUTURA DO TRABALHO

A divisão de capítulos foi feita como da seguinte forma:

O capítulo 1, Introdução, apresenta a introdução a este trabalho com sua motivação,

objetivo, justificativa, metodologia e a estrutura descrita.

O capítulo 2, Representação de Requisitos Funcionais, apresenta as formas mais

usuais de descrever requisitos funcionais, mostra com mais detalhes as técnicas

mais relevantes, e finaliza com a descrição de um meta-modelo para representação

de casos de uso que é usado como exemplo na TDRRC.

O capítulo 3, Gestão de Requisitos de Software, apresenta um processo de gestão

de requisitos, assim como as técnicas para rastreabilidade de requisitos e os

trabalhos na área de engenharia reversa de requisitos. Estes conceitos são

importantes para a integração da técnica dentro de um processo de gestão de

requisitos.

Introdução

13

O capítulo 4, Mecanismo de Anotações, apresenta o funcionamento do mecanismo

de meta-modelagem presente em diversas linguagens de programação modernas e

usa como base a implementação destes mecanismos na linguagem JAVA. Neste

capítulo são discutidas também as outras opções para meta-modelagem e

representação dos requisitos no código-fonte que são comparadas com o

mecanismo de anotações.

O capítulo 5, TDRRC – Técnica para documentação e recuperação de requisitos,

apresenta uma descrição da TDRRC e detalha seus artefatos, suas atividades.

Apresenta, também, exemplos dos artefatos e a aplicação da TDRRC dentro dos

contexto de reengenharia de requisitos, dos métodos ágeis e integrada à gestão de

requisitos.

O capítulo 6, Estudo de Caso, apresenta um estudo de caso, onde a TDRRC foi

aplicada em um ambiente de desenvolvimento ágil e os resultados obtidos.

O capítulo 7, Considerações Finais, apresenta as conclusões, as contribuições e a

discussão de possíveis evoluções deste trabalho.

Representação de Requisitos Funcionais

14

2 REPRESENTAÇÃO DE REQUISITOS FUNCIONAIS

Os requisitos funcionais constituem a maior parte dos requisitos de um sistema

(KOTONYA; SOMMERVILLE, 1998) e os requisitos não funcionais, na maioria dos

casos, não estão ligados diretamente a um trecho de código e sim a características

gerais do sistema, processo de desenvolvimento ou ambiente operacional (CHUNG;

LEITE, 2009).

Este capítulo apresenta as principais representações de requisitos funcionais

encontradas na literatura. A seguir, apresenta com mais detalhes a representação

de requisitos em casos de uso e os métodos formais. Os casos de uso são

apresentados com mais detalhes por serem a forma mais utilizada pelas empresas

para representar os requisitos, pela sua facilidade de uso, pelo tratamento

sistemático das tarefas do usuário e por ser um padrão importante dentro da

indústria de software. Os métodos formais são apresentados com mais detalhes

para permitir um maior entendimento das vantagens e desvantagens da escolha dos

casos de uso que é uma forma de representação não formal. Também neste

capítulo é apresentado um meta-modelo para representação de requisitos funcionais

baseado em casos de uso. Finalmente, são tecidas as considerações finais

sumarizando os conceitos apresentados no capítulo.

2.1 PRINCIPAIS REPRESENTAÇÕES DE REQUISITOS

As representações de requisitos de um sistema correspondem a um conjunto de

especificações, criados, na maioria das vezes, antes da implementação deste

sistema e descrevem aquilo que deveria ser implementado (KOTONYA;

SOMMERVILLE, 1998; ROBERTSON; ROBERTSON, 2006). Estas especificações

são descrições do objetivo dos seus usuários em relação ao sistema, seu

comportamento para atingir este objetivo, as restrições na sua operação, as

informações do domínio da aplicação, propriedades do sistema e atributos, a forma

de utilização, armazenamento, computação, transmissão e atualização dos dados,

Representação de Requisitos Funcionais

15

etc. (LAUESEN, 2002; ROBERTSON; ROBERTSON, 2006; KOTONYA;

SOMMERVILLE, 1998). Dentro do conjunto de requisitos, os requisitos funcionais

são aqueles que especificam o comportamento que o sistema deve ter para ser útil

aos seus usuários e os dados necessários para que esse comportamento seja

obtido (ROBERTSON; ROBERTSON, 2006). Estas especificações correspondem

aos requisitos funcionais e são usualmente descritas através de abstrações, ou seja,

são expressas de uma maneira que seja tecnologicamente neutra para evitar

influenciar o projeto da solução e, idealmente, devem ser uma expressão pura das

necessidades do negócio (ROBERTSON; ROBERTSON, 2006).

Ao descrever a especificação de um requisito, pode-se utilizar diferentes

representações que podem ser mais ou menos adequadas ao tipo de requisito e ao

público-alvo do requisito. Por exemplo, a representação mais adequada ao usuário

final pode não conter informação suficiente, ou não estar organizada da maneira

mais adequada ao desenvolvedor.

Ao escolher a representação de um requisito, devem-se observar as seguintes

características:

Facilidade de verificação pelo usuário: indica a facilidade com que o usuário

final pode entender a representação e, portanto, verificar se o requisito

representado está correto (LAUESEN, 2002);

Facilidade de verificação pelo desenvolvedor: indica a facilidade com que o

desenvolvedor pode entender a representação, verificar se o requisito

representado está correto e entender o que deverá ser implementado

(LAUESEN, 2002);

Precisão da representação: indica o quanto a representação permite avaliar

se o requisito está consistente e correto de forma automatizada (KOTONYA;

SOMMERVILLE, 1998);

Possibilidade da definição do ambiente: indica se a representação permite a

inclusão do contexto de funcionamento do sistema e dos elementos externos

Representação de Requisitos Funcionais

16

com que o sistema interage (KOTONYA; SOMMERVILLE, 1998; LAUESEN,

2002);

Flexibilidade: indica se a representação permite que os requisitos estejam

temporariamente incompletos e que seja adaptável às mudanças que

ocorrem nos requisitos durante a evolução do sistema (KOTONYA;

SOMMERVILLE, 1998);

Facilidade de integrar outras abordagens: as representações devem permitir o

mapeamento de sua estrutura com elementos equivalentes em outras

representações de requisitos, pois, muitas vezes, uma representação pode

ser melhor que outras, dependendo do tipo do requisito. Dado que pode

existir mais do que uma representação do mesmo requisito, é importante

poder relacionar os diferentes modelos (KOTONYA; SOMMERVILLE, 1998);

Facilidade de comunicação: as representações devem permitir que os

requisitos e o seu entendimento sejam comunicados e discutidos (KOTONYA;

SOMMERVILLE, 1998);

Existência de suporte de ferramentas: é importante que existam ferramentas

que auxiliem na representação dos requisitos e auxiliem na avaliação de

inconsistências e incorreções (KOTONYA; SOMMERVILLE, 1998).

Várias representações de requisitos foram utilizadas e experimentadas e a

importância de criar representações padronizadas de requisitos foi sendo percebida

com a evolução da indústria de software e com o surgimento da Engenharia de

Requisitos como uma disciplina. Ao padronizar a representação de um requisito,

tornou-se possível avaliá-la quanto às caraterísticas descritas anteriormente e

facilitou-se o trabalho do responsável pela especificação de um sistema ao definir

uma forma de representar as informações coletadas, muitas vezes acompanhada

com um método para a coleta destas informações (LAUESEN, 2002; ROBERTSON;

ROBERTSON, 2006).

Representação de Requisitos Funcionais

17

A seguir, estão listadas, as principais representações de requisitos que foram sendo

utilizadas ao longo dos anos (LAUESEN, 2002):

Diagrama de contexto: especifica o ambiente em que se encontra o software

e os elementos externos (usuários e sistemas) com os quais ele interage. O

diagrama de contexto representa todo o sistema como um único processo e

constitui o diagrama de nível mais alto da análise estruturada (YOURDON,

1991). Este diagrama é útil para definição do escopo do sistema e permite

especificar as interfaces do sistema;

Lista de eventos: também utilizada pela análise estruturada, especifica uma

lista dos estímulos que ocorrem no ambiente externo e que o software deve

ser capaz de tratar (YOURDON, 1991). É de grande importância para o

desenvolvedor, pois lista todos os eventos que devem ser tratados pelo

software e serve para verificar se os tratamentos destes eventos foram

implementados. Tem como principal desvantagem o fato de alguns eventos

não terem significado do ponto de vista do usuário e envolver decisões de

projeto, trazendo dificuldade em ser verificada pelo usuário final;

Descrição de Funções: especifica em formato textual o que o software deve

ser capaz de fazer. É bastante atrativa aos usuários finais que conseguem

verificar se o software faz aquilo que ele deseja. Do ponto de vista do

desenvolvedor, facilita o seu trabalho, pois muitas vezes as funções

especificadas são facilmente traduzidas em funções do software. Quando a

elaboração é mal conduzida, pode levar à criação de um número grande e

desnecessário de funções, pois a existência de uma função não garante que

um objetivo de negócio seja atingido. Quando fora de um contexto, a lista de

funções não leva em consideração os objetivos de negócio do sistema, os

quais podem acabar por ser negligenciados;

Telas e protótipos: especificam a interface visual do software através de

imagens, descrições ou animações e o comportamento dos elementos da

interface visual. São bastante atrativas ao usuário final e aos

Representação de Requisitos Funcionais

18

desenvolvedores, pois são fáceis de serem verificadas. O uso desta

representação deve ser apoiado por uma outra representação que define o

escopo do sistema. Sem isso, os usuários tendem, com a visualização das

telas e protótipos, desejar novos requisitos que não faziam parte do escopo

inicial, o que pode levar a um custo maior do que foi orçado;

Descrição de tarefas: especifica as tarefas do usuário através de um texto

contendo, tipicamente, o nome da tarefa, o objetivo da tarefa, os eventos que

acionam esta tarefa, as pré-condições para a execução da tarefa, os passos

envolvidos na execução da tarefa e possíveis variações nesta execução. A

especificação de um sistema através de tarefas é fácil de ser verificada pelo

usuário e pelo desenvolvedor, assim como permite especificar variações e

complexidade da tarefa. Tem como principal desvantagem, a dificuldade

apresentada pelos desenvolvedores em projetar o software a partir da

descrição de uma tarefa, pois o mapeamento não é direto. Um outro problema

é que nem toda função de um sistema é uma tarefa de usuário;

Funções definidas a partir de descrições de tarefas: a representação por

funções pode ser bastante atrativa aos desenvolvedores, já que muitas vezes

pode ser mapeada facilmente em funções do software. Por outro lado, a

descrição de tarefas é mais amigável ao usuário, pois descreve as tarefas

que este quer realizar usando o software. A representação de funções

definidas a partir de descrições de tarefas mescla estas duas representações

buscando inicialmente descrever as tarefas e depois descrever as funções

que participam na execução de cada tarefa. Ao contrário da simples descrição

de funções, nesta representação é necessário que todas as funções

necessárias para a execução de todas as tarefas do usuário sejam definidas;

Tarefas e Suporte: especificam as tarefas como na descrição de tarefas e

também um texto sobre o possível suporte para a implementação desejada

para cada um dos passos da tarefa. Esta forma de representação é indicada

quando se deseja especificar detalhes de implementação nos requisitos. A

Representação de Requisitos Funcionais

19

representação é fácil de ser verificada pelo usuário e pelo desenvolvedor e

permite especificar variações e complexidade da tarefa. Para especificar

requisitos que não consistem de tarefas, esta representação enfrenta os

mesmos problemas de todas as outras baseadas em tarefas e, além disso, é

mais trabalhosa que a simples descrição de tarefas;

Cenários: especificam um caso ilustrando uma ou mais tarefas do usuário e

serve para ajudá-lo a compreender melhor os requisitos. Não se tratam

propriamente de uma representação de requisitos, mas permite visualizar os

requisitos já documentados;

Lista de Tarefas Boas: apresenta a mesma característica da descrição de

tarefas. No entanto, ao invés de especificar tarefas sem nenhum critério, inclui

somente as tarefas que atendam as seguintes condições:

Fechada: A tarefa fechada é aquela que finaliza atingindo um objetivo

significativo para o usuário;

Sessão Agrupada: é uma a sessão de trabalho que contém um

conjunto de pequenas tarefas fechadas e que são desempenhadas

juntas em uma mesma atividade;

Sem especificar implementação: as tarefas não devem detalhar como a

implementação deve ser feita, pois isto é trabalho dos

desenvolvedores.

Ao seguir estas condições para selecionar as tarefas a serem descritas, evita-

se especificar uma série de tarefas que pouco agregam ao entendimento do

sistema;

Tarefas de Alto-Nível: trata-se da descrição de tarefas de negócio, ao invés

de tarefas de usuário. Raramente são usadas para especificação de

requisitos;

Representação de Requisitos Funcionais

20

Casos de Uso: especifica uma série de atividades e suas variações que um

sistema deve executar, a partir de uma solicitação de um usuário,

denominado ator. É a forma de especificação de requisitos mais usada

atualmente e faz parte da UML e do processo unificado (KOBRYN, 1999;

KRUCHTEN et al., 2002);

Tarefas com Dados: descrevem as tarefas, os dados visíveis ao usuário

necessários para a execução dos passos da tarefa e as especificações de

telas que seriam capazes de apresentar esta informação. Esta representação

especifica apenas os dados que o usuário vê, pois a especificação da

organização dos dados é deixada para o projeto e implementação do sistema.

Da mesma forma, as especificações de telas descrevem apenas que

informação e controles devem estar contidos na tela. Esta representação é

fácil de se verificar pelo usuário e pelo desenvolvedor, e permite a

rastreabilidade dos requisitos na implementação;

Modelos de Fluxo de Dados: faz parte da análise estruturada e, através de

um diagrama, descreve o fluxo de dados de um sistema através dos

processos que transformam os seus dados de entrada em dados de saída

(PRESSMAN, 2009; YOURDON, 1991). Foram amplamente usados antes da

difusão das técnicas orientadas a objetos. Sua principal fraqueza é não servir

para descrever tarefas do usuário com muitas variações;

Padrões de produto usados como requisitos: ao invés de definir requisitos,

declara-se que o software deve ser aderente a um certo padrão de produto

reconhecido pela indústria. É um tipo de requisito muito importante, mas traz

uma falsa sensação de segurança ao transferir a responsabilidade pelo

requisito para a organização responsável pelo padrão. Deve ser usado em

conjunto com outro tipo de especificação, para garantir que as necessidades

do usuário sejam atendidas e, ao mesmo tempo, a solução esteja de acordo

com padrões da indústria;

Representação de Requisitos Funcionais

21

Métodos formais: diferente de todas as formas descritas anteriormente,

métodos formais especificam os requisitos de forma precisa não havendo

margem para dúvidas. A precisão vem do uso de formalismos matemáticos

para a especificação dos requisitos. Por outro lado, são difíceis de serem

compreendidos e validados pelo usuário e por muitos dos desenvolvedores.

Das representações citadas nesta seção, os Casos de Uso se destacam por

oferecer uma forma sistemática de elicitar requisitos através das tarefas realizadas

por cada tipo de usuário (ator), por fornecerem suporte a variações nas tarefas dos

usuários (através de fluxos alternativos) e serem fáceis de entender tanto por

usuários quanto por desenvolvedores. Estas características levaram os Casos de

Uso a fazerem parte da UML, um padrão consagrado pela indústria e pela OMG, e a

se tornarem a forma mais utilizada e de aplicação mais ampla na indústria de

software para representar requisitos (LAUESEN, 2002; BOOCH et al., 1999;

KOBRYN et al., 1999; JACOBSON et al., 1999). Por estes motivos, os Casos de Uso

serão detalhados na próxima seção.

2.2 CASOS DE USO

Os Casos de Uso são usados para especificar o que um novo software deve fazer

ou o que um software já existente faz (AMBLER, 2000, BOOCH et al., 1999). Para

fazer esta especificação, as funções do software são definidas a partir de interações

entre o usuário ou outros sistemas e o software. Essas interações são chamadas

Caso de Uso e devem representar uma transação do negócio (JACOBSON et al.,

1999). Neste contexto, o sistema é visto como uma caixa-preta que provê Casos de

Uso, que são formas como o sistema pode ser usado (ERIKSSON et al., 1998,

ENGELS et al., 2000).

A visão geral do software é provida por um modelo de Casos de Uso, onde são

apresentados todos os Casos de Uso do software, a relação entre eles e os atores

que participam de cada Caso de Uso (BOOCH et al., 1999; JACOBSON et al.,

1999). Um ator representa um papel desempenhado por um grupo de usuários que

Representação de Requisitos Funcionais

22

tem um certo objetivo ao interagir com o software. Um Caso de Uso descreve

possíveis comportamentos do software através de cenários. O cenário principal é o

caso de sucesso, ou seja, aquele em que tudo transcorre conforme o esperado e

deve corresponder à grande maioria das transações. Os outros cenários apresentam

situações em que alguma barreira ou dificuldade pode provocar comportamentos

específicos no software ou até mesmo impedir a realização da transação. O

comportamento de um software em um cenário de um Caso de Uso é descrito por

uma sequência de atividades que devem se realizar a partir de um evento ou

estímulo realizado por um ator (MEDVIDOVIC et al., 2002; KRUCHTEN et al., 2002).

Ao organizar os requisitos de um software baseado em transações de negócio, que

são claramente reconhecíveis e validáveis por desenvolvedores e usuários, os

Casos de Uso facilitam a identificação, a elicitação e o acompanhamento da

evolução dos requisitos durante todo o ciclo de vida do projeto e do software (RUI,

2007).

Ao se desenvolver um projeto orientado por Casos de Uso, como propõe o processo

unificado2, estes passam a orientar a especificação, modelagem e programação das

transações de negócio, e com isso, servem como base para rastreabilidade entre

todas as etapas do projeto e servir de apoio na manutenção e evolução do software

(RUI, 2003; 2007).

O modelo de Casos de Uso é constituído por Diagramas de Caso de Uso e por uma

especificação ou descrição do Caso de Uso. Os Diagramas de Caso de Uso são

parte da UML e a figura 2 apresenta um diagrama de casos de uso seguindo o

padrão UML (BOOCH et al., 1999).

2O Processo Unificado é um processo de desenvolvimento de software iterativo e incremental

bastante utilizado pela indústria no desenvolvimento de sistemas orientados a objeto.

index-37_1.jpg

Representação de Requisitos Funcionais

23

Figura 2 – Exemplo de Caso de Uso

Como pode ser visto, o software tem o ator “Cliente” que participa do caso de uso

“Ver Pedido”. Além do relacionamento entre o ator e o caso de uso, os diagramas

UML de casos de uso permitem relacionar casos de uso entre si. Os

relacionamentos permitidos pela UML entre casos de uso são:

<<include>>: permite a inclusão de um Caso de Uso em outro e deve ser

usado quando existe no sistema um conjunto de passos comuns a vários

casos de uso. Cria-se um Caso de Uso com estes passos comuns e, depois,

usa-se o relacionamento <<include>> para referenciar os Casos de Uso

incluídos, evitando reescrever os passos;

<<extend>>: permite a extensão de um Caso de Uso e deve ser utilizado

quando se deseja acrescentar um comportamento no Caso de Uso estendido

em determinadas condições. A extensão é usada para definir a partir de um

Caso de Uso base, um comportamento opcional que o software pode ter, mas

que não é obrigatório para atingir o objetivo do Caso de Uso;

herança: permite a criação de um Caso de Uso genérico que tem

comportamento, requisitos, restrições e suposições comuns a vários Casos

de Uso. Os Casos de Uso específicos herdam as características do Caso de

Uso genérico e descrevem aquilo que eles tem de diferente.

Estes relacionamentos permitem uma reutilização de Casos de Uso e, com isso,

aumentam a produtividade na especificação de sistemas.

A especificação ou descrição do Caso de Uso é, tipicamente, realizada na forma

textual, mas pode ser feita também através de diagramas de sequência, atividade ou

Representação de Requisitos Funcionais

24

interação (ERIKSSON et al., 1997). Não existe uma forma rígida para especificar um

Caso de Uso, mas espera-se que esta especificação contenha os atores, o evento

que dá início ao Caso de Uso, as pré-condições, a sequência de atividades que

devem ocorrer e as pós-condições. Usualmente define-se um padrão para esta

especificação dentro de um projeto onde decide-se o que vai ser feito através de

uma descrição textual e o que vai ser feito através de diagramas (BOOCH et al.,

1999; JACOBSON et al., 1999).

Este padrão garante uma certa uniformidade na descrição de um Caso de Uso, e

pode deixá-lo mais preciso, dependendo do grau de formalismo desejado. Esta

flexibilidade no grau de formalismo é também um dos fatores do sucesso dos Casos

de Uso (RUI, 2003; 2007). A precisão que pode ser oferecida pelos Casos de Uso é

suficiente para a maioria dos projetos, mas não alcança a precisão dada quando se

aplicam formalismos matemáticos. Nos poucos projetos que a precisão da

especificação dos requisitos é o atributo mais importante, a alternativa são os

métodos formais e por este motivo, eles serão detalhados na próxima seção.

2.3 MÉTODOS FORMAIS

Os métodos formais surgem da ideia de que um software é construído baseado em

um pequeno número de conceitos, capazes de especificar, desenvolver e verificar

sistemas através de uma sintaxe matematicamente formal (KOTONYA;

SOMMERVILLE, 1998; HARRY, 1997; CLARK, 1996). Os métodos formais

surgiram como uma resposta à seguintes limitações encontradas na representação

de requisitos em linguagem natural (HARRY, 1997):

Interpretação: ao contrário da linguagem natural, os métodos formais não

estão sujeitos a ambiguidade, pois descrevem o funcionamento do sistema

usando uma formulação matematicamente precisa;

Processamento da especificação: por possuir uma sintaxe bem definida, as

representações em métodos formais podem ser processadas por programas

Representação de Requisitos Funcionais

25

de computador que podem fazer simplificações, validações de maneira

automática.

Um método é considerado formal, se tem uma base matemática sólida, tipicamente

dada por uma linguagem de especificação formal. Esta base provê meios de definir,

de maneira precisa, conceitos como consistência, integridade, especificação,

implementação e correção. Com isso, o método formal provê meios de provar que

uma especificação é implementável, que o sistema está correto e quais

propriedades o sistema tem, sem a necessidade de implementá-lo (CLARK, 1996).

Uma linguagem de especificação formal é composta de três componentes principais

<Syn, Sem, Sat> (KOTONYA; SOMMERVILLE, 1998; CLARK, 1996):

Sintaxe (Syn): define o domínio sintático da linguagem e é derivada de uma

teoria de notações e cálculo de predicados;

Semântica (Sem): define o domínio semântico da linguagem que vai ser

usado para descrever o sistema;

Relações (Sat): define regras que indicam os objetos que satisfazem

propriamente a especificação.

Uma linguagem formal pode ser categorizada como construtiva, em que um modelo

matemático do sistema é criado, ou comportamental, em que o sistema é descrito a

partir de suas propriedades, entradas e saídas e tratado como uma caixa-preta.

Dessas categorias, foram criadas um grande número de estilos de especificações,

linguagens e métodos formais, todos tendo como fundamento a matemática discreta

(CLARK, 1996; HARRY, 1997). Estes estilos foram classificados por Harry (1997) da

forma apresentada na figura 3.

index-40_1.png

Representação de Requisitos Funcionais

26

Figura 3 – Estilos das Linguagens Formais (HARRY, 1997)

Nas linguagens baseadas em modelos, o sistema é representado por um modelo

matemático abstrato e suas funções são expressas utilizando coleções de tipos de

dados. Eles podem fazer esta definição explicitamente ou implicitamente ou

combinando estes dois estilos. Na definição implícita, descreve-se qual o resultado

das funções, sem descrever como a função é executada. Na definição explícita,

descreve-se como a função é executada de maneira imperativa ou declarativa. Ao

usar o estilo imperativo, que é o mesmo utilizado na maioria das linguagens de

programação, descreve-se a especificação através de ações que atuam sobre

variáveis. Ao usar o estilo declarativo, descreve-se as manipulações de dados

através de equações ou relações. Neste grupo, encontra-se o estilo funcional, em

que se define o sistema a partir de funções e o estilo lógico, em que se usam

predicados lógicos. Alguns exemplos de linguagens baseadas em modelos são Z,

VDM, ML, Miranda e Haskell (CLARK, 1996; HARRY, 1997).

Nas linguagens baseadas em propriedades, o sistema é definido indiretamente a

partir de uma série de axiomas que definem propriedades que o sistema deve

satisfazer. Predicados de primeira ordem são usados para definir pré-condições e

pós-condições das funções em termos de axiomas. Se estes axiomas são descritos

utilizando equações, então o estilo é chamado de algébrico. Entre as linguagens

com capacidade de suportar o estilo algébrico se encontram: Larch, OBJ3, CSP,

CCS e LOTOS (CLARK, 1996; HARRY, 1997).

Representação de Requisitos Funcionais

27

Os métodos formais tem as seguintes desvantagens em relação a outras formas de

especificação (KOTONYA; SOMMERVILLE, 1998; CLARK, 1996):

São focados principalmente em funções e dados, sendo difícil utilizá-los para

aspectos comportamentais de um problema;

O uso dos métodos formais garante que os requisitos estão corretos, mas não

garante que eles sejam implementados corretamente;

Métodos formais são difíceis de serem compreendidos pelo usuário final e por

muitos desenvolvedores.

Devido ao alto custo das ferramentas necessárias para sua utilização, os métodos

formais são geralmente usados apenas no desenvolvimento de sistemas de alta-

confiabilidade, no qual há alta probabilidade das falhas conduzirem para a perda da

vida ou sério prejuízo (CLARK, 1996).

2.4 UM META-MODELO DE CASOS DE USO

Um meta-modelo é um modelo que especifica a sintaxe de uma linguagem de

modelagem (BORONAT; MESEGUER, 2008). Um meta-modelo de requisitos

especifica uma sintaxe para representação de requisitos. Esta sintaxe pode ser

definida com diferentes níveis de detalhes, permitindo que a representação do

requisito tenha uma estrutura mais ou menos rígida dependendo do objetivo a ser

atingido com o modelo. Um meta-modelo de Casos de Uso é um modelo que

especifica uma estrutura capaz de descrever um Caso de Uso (RUI, 2007).

Rui (2007) desenvolveu um meta-modelo para casos de uso que formaliza a

estrutura de Casos de Uso sem se preocupar com formalismos semânticos. Este

meta-modelo foi criado com o objetivo de permitir a refatoração de Casos de Uso e

ser utilizado num contexto de evolução de software. Mais especificamente, Rui

(2007) utilizou o conceito de refatoração que é usado para designar mudanças feitas

no código-fonte, com o objetivo de deixá-lo mais fácil de se ler e manter, e aplicou-o

index-42_1.png

Representação de Requisitos Funcionais

28

nos Casos de Uso. Com isso, Rui (2007) definiu operações de refatoração de Casos

de Uso, formalizando várias transformações que um Caso de Uso pode sofrer, sem

que o seu significado seja alterado. Para definir estas transformações Rui (2007)

usou o meta-modelo de Casos de Uso apresentado na figura 4.

Figura 4 – Meta-Modelo Dos Casos de Uso (RUI, 2007)

O meta-modelo de Rui (2007) apresenta três diferentes níveis:

Nível de Ambiente: corresponde ao relacionamento do Caso de Uso com as

entidades externas ao sistema;

Nível de Estrutura: corresponde à definição da estrutura interna do Caso de

Uso;

Representação de Requisitos Funcionais

29

Nível de Eventos: corresponde à definição de eventos individuais.

O nível de ambiente é representado pelas seguintes entidades (RUI, 2007):

Objetivo: modela uma meta, alvo ou propósito a ser atingido ou satisfeito com

a execução de uma transação de negócio;

Caso de Uso: modela uma situação de uso do sistema, em que um ou mais

serviços do software são usados por um ou mais usuários com um ou mais

objetivos em mente. Um Caso de Uso representa uma transação de negócio

e permite descrever o comportamento do software sem a necessidade de

especificar sua estrutura interna;

Ator: modela o papel desempenhado por um usuário do software e representa

uma categoria de usuários que apresentam comportamento similar ao utilizar

o software. Um ator pode ter vários objetivos ao usar o software e, para atingir

estes objetivos, participa em vários Casos de Uso;

Usuário: é uma instância de um ator neste modelo. Usuários podem ser seres

humanos ou outros sistemas e dispositivos que se comunicam com o

software. Um usuário pode aparecer como várias instâncias de diferentes

atores dependendo do contexto. O usuário tem uma ou mais tarefas que ele

precisa realizar e ele as executa participando em um ou mais casos de uso;

Serviço: é uma função oferecida ao usuário para que ele possa satisfazer um

ou mais objetivos que tenha;

Tarefa: é uma atividade que é realizada por um ou mais usuários através da

execução de um serviço.

Representação de Requisitos Funcionais

30

O nível de estrutura é representando pelas seguintes entidades (RUI, 2007):

Episódio: consiste de uma das partes coerentes em que um Caso de Uso

pode ser dividido. Os episódios revelam a estrutura interna de um Caso de

Uso e descrevem o seu funcionamento. O mesmo episódio pode ocorrer em

diferentes Casos de Uso;

Modelo de Episódios: é uma abstração que representa o conjunto de todos os

episódios de um Caso de Uso;

Contexto: demarca o escopo de um Caso de Uso e define suas Pré-

Condições e Pós-Condições. Um contexto pode estar relacionado a um ou

mais casos de uso;

Pré-Condição: é uma propriedade do ambiente ou do sistema que precisa ser

atingida para que o Caso de Uso possa ser executado. Uma pré-condição

está sempre relacionada a um contexto;

Pós-Condição: é uma propriedade do ambiente ou do sistema que é atingida

no final da execução de um Caso de Uso. Uma pós-condição está sempre

relacionada a um contexto.

O nível de eventos é representado pela entidade Evento e seus três sub-tipos:

Estímulo, Resposta e Ação (RUI, 2007):

Evento: é uma ocorrência significativa que tem um lugar no tempo e espaço.

A diferença entre um Evento e um Episódio é que o Evento é instantâneo

(tem duração igual a zero) enquanto um Episódio tem uma duração;

Modelo de Eventos: análogo ao modelo de episódios, é uma abstração criada

por Rui (2007) para representar o conjunto de todos os eventos de um certo

episódio;

Representação de Requisitos Funcionais

31

Estímulo: é um dos sub-tipos de Evento e consiste de uma mensagem do

usuário ao sistema. Pode conter parâmetros;

Resposta: é um dos sub-tipos de Evento e consiste de uma mensagem do

sistema ao usuário. Pode conter parâmetros;

Parâmetro: representa dados que podem ser transmitidos em um estímulo ou

resposta;

Ação: um dos sub-tipos de Evento e consiste de uma mensagem interna ao

sistema, onde não existe comunicação entre o sistema e o usuário.

O modelo de Rui (2007) define em mais detalhes a estrutura dos Casos de Uso e

elimina vários graus de liberdade que a especificação de Casos de Uso permite. Os

elementos que fazem parte desta especificação e as relações entre eles ficam

limitadas àqueles estabelecidos no meta-modelo. Por ter sido concebido para o seu

trabalho na área de refatoração de Casos de Uso, o modelo leva em conta a

reutilização de episódios ao permitir que um mesmo episódio possa estar

relacionado a mais de um modelo de episódios (BEZERRA; MELNIKOFF, 2010).

Rui (2007), ao definir um meta-modelo para os Casos de Uso, contribui para maior

formalização dos Casos de Uso, tornando sua estrutura mais homogênea e precisa.

2.5 CONSIDERAÇÕES FINAIS

O capítulo mostrou que existem diversas representações de requisitos funcionais de

software, apresentou os Casos de Uso e os métodos formais e um meta-modelo de

Casos de Uso.

A escolha da representação de requisitos é uma questão importante, pois

dependendo do tipo de representação escolhida, algumas caraterísticas do software

ficam mais evidentes e claramente especificadas do que outras. Desta forma, para

representar os requisitos de um software adequadamente, devem-se combinar as