Os casos de uso modelam o sistema do ponto de vista do usuário final, ou seja, representam uma funcionalidade que o sistema realiza e que fornece um benefício a um ator específico. Criado durante a definição dos requisitos, os casos de uso devem alcançar os seguintes objetivos.
- Estabelecer os requisitos funcionais e operacionais do sistema (produto) pela definição de um cenário de uso que seja combinado entre o usuário final e a equipe de engenharia de software.
- Produzir uma descrição clara de como o usuário final e o sistema interagem um com o outro.
- Produzir uma base para o teste de validação.
Os casos de uso vão especificar o comportamento do sistema de software (ou parte dele) descrevendo as funcionalidades desejadas desempenhadas pelos atores. Os casos de uso equivalem a cenários que contêm uma sequência de passos que descrevem a interação de um usuário (um ator) com o sistema. As principais características de um caso de uso são:
- Os casos de uso são sempre iniciados por um ator.
- Devem sempre retornar um resultado (valor) ao ator.
- Cada caso de uso específica uma funcionalidade completa envolvendo os atores interessados.
- Devem sempre terminar com o resultado que deve ser dado ao ator.
Convém ressaltar que o modelo de caso de uso é facilmente compreendido pelo cliente, é por intermédio dele que conseguimos formalizar graficamente qual é o escopo do sistema, refletindo exatamente o que o cliente deseja. Por isso podemos utilizar esse gráfico como base de discussão entre o cliente e a equipe de desenvolvimento, servindo também como meio para acompanhar o progresso do desenvolvimento do software. A seguir, vamos apresentar informações complementares importantes relacionadas ao casos de uso, como uma visão geral desse conceito.
Relacionamentos
Relacionamentos basicamente representam conexões entre itens. Na UML, a maioria dos itens se relaciona entre si. Existem várias possibilidades de relacionamento na linguagem UML, os quais estão divididos basicamente em quatros tipos:
- Relacionamento de dependência.
- Relacionamento de associação.
- Relacionamento de generalização.
- Relacionamento de realização.
Relacionamento de dependência
Os relacionamentos de dependência são estabelecidos entre dois itens nos quais a alteração de um (o item independente) pode afetar a semântica do outro (o item dependente). A dependência na UML existe entre dois elementos definidos se uma mudança na definição de um elemento puder resultar em uma mudança em outro. Na UML isso é indicado por uma linha tracejada que aponta do elemento dependente ao elemento independente, conforme mostra a imagem abaixo:
Relacionamento de associação
Os relacionamentos de associação são estruturais e descrevem um conjunto de ligações (conexões) entre os objetos. São representados por uma linha sólida, conforme ilustra a figura a seguir, e nessa linha podemos incluir um nome, um papel e a multiplicidade existente. Vamos descrever, a seguir, tais elementos:
- Nome: Utilizado para descrever a natureza do relacionamento.
- Papel: É a face que a classe próxima a uma das extremidades apresenta à classe encontrada na outra extremidade da associação.
- Multiplicidade: Um indicador de multiplicidade, como 0..1, indica quantas conexões podem aparecer entre os objetos que podem ser conectados pela associação. Um asterisco é utilizado para indicar que zero ou mais instâncias de um objeto de uma classe podem estar conectados a objetos de uma classe associada.
Relacionamento de Generalização
Relacionamento de generalização são especializações nas quais os objetos dos elementos especializados (filhos) são subtituíveis por objetos dos elementos generalizados (pais). As generalizações são relacionamentos conhecidos como "é-um-tipo-de". Por exemplo, "estudante" é um tipo de uma classe mais genérica, chamada "pessoa". Quando generalizamos, estamos considerando que as subclasses compartilham a estrutura e o comportamento das superclasses.
Relacionamento de realização
Relacionamento de realização é um relacionamento semântico no qual um item especifica um contrato cujo cumprimento é realizado por outro item. Normalmente é utilizado em dois casos: entre interfaces e as classes (ou componentes que as realizam) e entre casos de uso e as colaborações que os realizam.
Em nossa próxima postagem, veremos como criar um diagrama de caso de uso dentro do Enterprise Architect para nos familiarizarmos com a ferramenta e darmos início a nossa prática de diagramação. Espero que estejam gostando e vou ficando por aqui.
Nenhum comentário:
Postar um comentário