Kanaan i midtre bronsealder

A Análise de Sistemas, enquanto actividade necessária à identificação dos problemas, apresentação de soluções alternativas e averiguação da viabilidade, inclui a identificação do contexto do sistema (o que se encontra dentro e fora do sistema) e a identificação dos requisitos do sistema que devem ser analisados e especificados. A ênfase no aspecto visual em detrimento do textual tem levado alguns autores a defenderem o uso de Diagramas de Casos de Utilização nesta fase do processo de desenvolvimento do sistema, mais concretamente na etapa de Especificação dos Requisitos.

121

4.3.2.1.1 Especificação de Requisitos através de Diagramas de Casos de Utilização

Um requisito corresponde a uma funcionalidade ou condição que o sistema deverá satisfazer. Tipicamente, os requisitos podem dividir-se em funcionais e não-funcionais.

Os requisitos funcionais descrevem a funcionalidade desejada para o sistema, uma vez que permitem descrever as funções que os utilizadores necessitam ou requerem do sistema. Os requisitos não-funcionais correspondem a características globais, tais como manutenção, usabilidade, desempenho, fiabilidade e segurança.

Os questionários, a observação das actividades, a recolha e análise de documentos que circulam no sistema, a promoção de reuniões e a elaboração e validação de protótipos do sistema são algumas das formas de detectar aquilo que o sistema faz actualmente e deverá fazer futuramente. Por conseguinte, a Especificação de Requisitos para um novo sistema corresponderá ao que o sistema faz actualmente, mais as necessidades não atendidas, menos os seus problemas.

Aparentemente, identificar e descrever os requisitos de um sistema parece tarefa fácil. Contudo, aquando do levantamento de requisitos, rapidamente nos apercebemos de que cada potencial utilizador possui interpretações e representações subjectivas acerca do sistema e que nem sempre aquilo que é pedido corresponde àquilo de que na realidade se necessita. Genericamente, o objectivo desta etapa é expressar sem incertezas as funcionalidades que o sistema deve oferecer ao seu utilizador e, para evitar falsas expectativas, pode incluir o que o sistema não fará. A Especificação dos Requisitos deve ser o ponto de partida para o Projecto do Sistema e não tem (ou não deveria ter) como propósito limitar as opções dos projectistas. É importante distinguir a actividade de Especificação de Requisitos que ocorre durante a Análise do Sistema da actividade de Especificação que ocorre durante o Projecto do Sistema. A Especificação de Requisitos deve especificar o que se espera que o sistema faça, sem preocupações de como o fará. A resolução dessas preocupações corresponderá à Especificação inerente à fase de Projecto do Sistema.

Aliás, a etapa de Especificação dos Requisitos não só deverá permitir a especificação do que o sistema deverá fazer através de uma listagem de requisitos e de outras informações tais como fluxos de informação, componentes e suas relações, restrições, áreas internas e externas do sistema, mas também deverá incluir a determinação dos critérios de validação com vista a avaliar se o sistema cumpre o que foi especificado. A importância que esta etapa tem vindo a assumir levou ao aparecimento, no início da década de 90, da Engenharia de Requisitos. Desde então, há autores que defendem que os requisitos devem ser apresentados

122

visualmente através de Diagramas de Casos de Utilização e, seguidamente, cada caso deverá ser especificado com detalhe através de uma descrição textual.

Por um lado, os Diagramas de Casos de Utilização podem ser usados para modelar o contexto de um sistema, identificando a sua fronteira e os utilizadores ou sistemas externos com os quais interage. Por outro, podem ser usados para modelar os requisitos de um sistema, identificando o que o sistema deve fazer. A especificação de casos de utilização é considerada como uma abordagem adequada à modelação de requisitos funcionais uma vez que facilita a comunicação entre a equipa de projecto e os utilizadores e promove a comunicação, a gestão e a condução no desenvolvimento do próprio projecto [Silva 2001].

4.3.2.1.2 Diagrama de Casos de Utilização

O Diagrama de Casos de Utilização permite visualizar actores, casos de utilização e interacções identificadas para o sistema (ver figura 51). Os Diagramas de Casos de Utilização podem ser encarados como Diagramas de Contexto que identificam o domínio do sistema e mostram os actores com os quais interage (actores não são necessariamente utilizadores, podem ser também sistemas informáticos, equipamentos de hardware especializados ou, simplesmente, mecanismos de passagem do tempo). Mas, estes diagramas também podem ser vistos como modelos que têm como principal papel comunicar a funcionalidade e o comportamento do sistema ao utilizador.

descrição da associação

Actor Fluxo de Informação Associação

Caso de Utilização

Figura 51 – Notação UML para Diagramas de Casos de Utilização

Podem ser criados vários Diagramas de Casos Utilização consoante as necessidades; no entanto o diagrama principal oferece-nos a visão geral dos limites do sistema (actores) e da funcionalidade principal (casos de utilização).

Um actor é alguém ou alguma coisa que interage com o sistema. Um actor pode apenas receber informação do sistema, apenas fornecer informação ao sistema ou fornecer informação ao sistema e receber informação do sistema. A identificação dos actores de um sistema deve ser efectuada de forma iterativa, uma vez que um actor pode assumir vários papéis ao longo do tempo (o que acabará por dificultar a identificação dos actores). Por

123 exemplo, dois utilizadores são actores diferentes desde que usem o sistema de forma diferente. Mas se usarem o sistema da mesma forma serão considerados actores iguais, mesmo que um seja professor e o outro aluno.

Um caso de utilização (comando de utilização ou caso de uso) é uma sequência de transacções realizadas por um sistema, ou melhor, é uma sequência de acções que um ou mais actores realizam num sistema. Podemos afirmar que os casos de utilização descrevem em Português Estruturado (ou noutra língua) a funcionalidade oferecida pelo sistema, isto é, as capacidades disponibilizadas a um actor pelo sistema. O caso de utilização modela a forma como um actor (pessoa, organização ou sistema externo) interage com o sistema (ou, mais especificamente, com a aplicação). Em suma, o conjunto dos casos de utilização constitui todas as formas possíveis de utilização do sistema.

Cada caso de utilização contém um fluxo de eventos. O fluxo de eventos descreve “o que” o sistema deve fazer e não “como” é que o sistema deve fazer. Isto é, um fluxo de eventos é uma descrição dos eventos necessários para alcançar a funcionalidade ou o comportamento exigido nesse caso de utilização. Os fluxos de eventos podem ser vistos como possíveis cenários ilustrando o comportamento do sistema. Cada fluxo de eventos ou cenário deve incluir a resposta às seguintes questões:

• Quando e como é que o caso de utilização é iniciado ou terminado? • Qual a interacção que o caso de utilização tem com os actores? • Quais os dados de que o caso de utilização necessita?

• Qual a sequência normal de eventos ou cenário principal para o caso de utilização? • Existem cenários ou fluxos alternativos ou excepcionais para este caso de utilização?

Entre os actores e os casos de utilização existem associações, tal como se pode verificar na figura 52.

<<communicat

e>> <<include>>

<<extend>>

Figura 52 – Tipos de relações nos Diagramas de Casos de Utilização

Este tipo de associações designam-se por associações de comunicação (communicate), uma vez que representam a comunicação entre actores e casos de utilização em termos de

124

fluxo da informação (consoante a direcção da seta). Mas, entre casos de utilização também podem existir associações ou relações, a saber: generalização, inclusão (include) e extensão (extend). Estas relações derivam do facto da UML ter um conceito chamado estereótipo, o qual permite criar novos elementos de modelagem estendendo os elementos básicos. Os estereótipos servem assim para criar as relações necessárias entre casos de utilização.

Este tipo de relações possibilita a reutilização de especificações (não é propriamente reutilização de software, mas as vantagens são óbvias), já que existem vários casos de utilização que partilham peças da mesma funcionalidade. Essa funcionalidade pode passar a constituir um caso de utilização e assim, a relação de inclusão é criada entre este novo caso de utilização e qualquer outro caso de utilização que necessite desta funcionalidade.

Quanto à relação de extensão, esta pode ser usada para definir um comportamento opcional, um comportamento que só é executado se forem garantidas determinadas condições ou uma escolha inerente a vários fluxos que podem ser executados de acordo com a selecção do actor. Desta forma, o caso de utilização pode ser estendido como o comportamento de outro caso.

Finalmente, uma relação de generalização entre casos de utilização permite definir casos pela generalização ou, em sentido inverso, pela especialização. Por exemplo, a generalização entre casos de utilização ilustrada na figura 53 mostra que o caso de utilização “Validar utilizador” é especializado noutros quatro, que utilizam diferentes mecanismos para autenticação do utilizador (Ler palavra passe, Ler cartão, Ler impressão digital ou Ler íris).

Ler palavra passe Ler impressão digital Ler íris/retina Ler cartão Validar utilizador

Figura 53 – Relação de Generalização/Especialização

Em suma, os Diagramas de Casos de Utilização são utilizados nas fases de especificação de requisitos e na modelação de processos de negócio com o intuito de modelar o contexto do sistema, os requisitos do sistema e, consequentemente, o comportamento do sistema na perspectiva dos utilizadores.

125 Com o intuito de facilitar a aplicação deste tipo de diagramas pode ser usado o seguinte conjunto de passos [Silva 2001]:

• Identificar os actores do sistema (utilizadores, sistemas externos, etc.); • Identificar, para cada actor, os seus casos de utilização principais;

• Identificar os casos de utilização que sejam recorrentes em mais do que um dos casos originais. Caso existam, deve criar-se um novo caso de utilização e estabelecer-se uma relação de inclusão entre o novo caso e os casos originais envolvidos. Repetir o processo até não se conseguir identificar qualquer outro caso a reutilizar;

• Definir pontos de extensão e, conjuntamente, definir um ou mais casos de utilização que os permitam estender nesses pontos com vista a tratar casos de utilização que pretendam ser flexíveis e versáteis. Para tal, cria-se uma relação de extensão do novo caso para o caso estendido;

• Especificar textualmente cada caso de utilização segundo um determinado formato previamente definido.