IV ANÁLISE DOS CASOS DE USO
ANÁLISE
O levantamento das classes de análise marca o início da construção do modelo da análise (RUP).
Ocorre uma mudança na linguagem, enquanto no modelo de casos de uso a descrição do sistema era feita na linguagem do cliente/usuário, na análise emprega-se a linguagem dos desenvolvedores.
A tabela a seguir ilustra as diferenças entre o modelo de casos de uso e o modelo de análise segundo (Jacobson e co-autores, 1999).
Realização dos casos de uso
Segundo (Jacobson e co-autores, 1999, pg. 221), se o modelo de análise não é atualizado durante o ciclo de vida do software, ou seja, foi criado apenas para possibilitar a elaboração de um bom projeto, não há realização de casos de uso na análise.
Método de Análise
De acordo com o RUP, a análise de casos de uso é composta por:
1. Para cada caso de uso considerado em uma iteração:
- Criar uma realização de caso de uso;
- Complementar a descrição do caso de uso;
- Levantar as classes de análise examinando o comportamento do caso de uso;
- Distribuir o comportamento do caso de uso entre as classes de análise;
- Para cada classe de análise;
- Descrever as responsabilidades da classe;
- Definir atributos;
- Definir relações entre classes.
PADRÃO MVC
MVC (Model, View, and Controller) é um padrão de arquitetura de software.
A idéia do padrão MVC é desacoplar ao máximo a apresentação da aplicação (view) da lógica do negócio (business model).
O padrão MVC propõe a divisão da aplicação em três partes:
- Modelo do negócio (model): contém os dados do negócio e as regras do negócio que ditam o acesso e a modificação dos dados. De forma mais prática, encapsula os dados e os comportamentos do negócio e salva os mesmos sem se preocupar em como serão mostrados.
- Visão (view): é responsável pela interação com o usuário e por apresentar as diversas visões que dos dados do negócio. Não se preocupa em como os dados foram obtidos, apenas em apresentálos.
- Controle (controller): comanda o fluxo de obtenção, encaminhamento e apresentação das informações fazendo a intermediação entre as camadas de visão e de modelo.
PADRÃO OBSERVADOR
O objetivo do padrão observador é reduzir o acoplamento entre classes. Podemos utilizar este padrão em conjunto com o MVC para desacoplar as classes da camada de visão das do modelo.
CLASSES DE ANÁLISE
Em um diagrama de classes são definidas as classes de objetos, suas operações e atributos e as relações entre classes.
Nas fases iniciais do projeto, as classes são chamadas de classes candidatas ou de análise, pois há grande probabilidade que mudem ao longo do projeto.
Notação UML para Classes
Uma classe é representada por um retângulo dividido em três compartimentos. Os compartimentos de atributos e métodos são opcionais. Um estereótipo define um tipo para a classe.
Atributos
A sintaxe para declaração de um atributo em UML segue o formato:
[<visibilidade>]<nome>[<multiplicidade>]:[<tipo>][=<valor inicial>]
<visibilidade>:
_ + público, todas as classes têm acesso;
_ - privada, somente métodos definidos na classe podem vê-lo;
_ # protegido, métodos definidos na classe e nas classes derivadas podem vê-lo;
_ ~ pacote, visível dentro das classes de um pacote.
<nome>: nome do atributo.
<multiplicidade>: por exemplo, valores[5] ou matriz[4, 6]
<tipo>: pode-se utilizar os tipos da linguagem de implementação. Por exemplo, char, float ou int.
<valor inicial>: valor inicial para o atributo que respeite o tipo de dado.
Exemplos:
- nome: String
- sexo: char=’f’
+ código: int=20
Métodos
Sintaxe para declaração de um método em UML:
[<visibilidade>]<nome>(<lista argumentos>):[<retorno>]
<visibilidade>:
_ + público, todas as classes têm acesso;
_ - privada, somente métodos definidos na classe podem vê-lo;
_ # protegido, métodos definidos na classe e nas classes derivadas podem vê-lo;
_ ~ pacote, visível dentro das classes de um pacote.
<nome>: nome do método
_ <lista de argumentos>: (<nome_argumento>:<tipo>, ..., <nome_argumento>:<tipo>). Por exemplo,
(nome:String, idade: int)
_ <retorno>: tipo do dado retornado. Pode-se utilizar os tipos da linguagem de implementação. Por
exemplo, char, float ou int.
Exemplos:
- calcularIdadeEmMeses(Data dataNasc): int
+moverPara(x:int, y:int):void
Categorias de responsabilidades: estereótipos
De maneira geral, um estereótipo deixa clara a função de um componente em um diagrama. É possível definir seus próprios estereótipos o que permite estender a UML. No diagrama de classes há três estereótipos bastante utilizados que designam a responsabilidade das classes:
_ <<entidade>> ou <<entity>>
_ <<controle>> ou <<control>>
_ <<fronteira>> ou <<boundary>>
Classes entidade
É utilizado em classes que armazenam informações do domínio a longo-prazo. Objetos destas classes são normalmente persistentes, mas não é uma regra geral. Frequentemente estas classes se encontram na camada do modelo, por isso não dependem (ou ao menos não deveriam depender) do contexto
onde o sistema está inserido.
Classes com este estereótipo podem ser representadas pelo ícone alternativo da figura abaixo.
Classes de fronteira
É utilizado em classes que realizam a interação entre sistema e ator (humano ou não). São classes que dependem do contexto onde o sistema está inserido, dado que o contexto é dado justamente pelas interações com o mundo externo.
Classes de fronteira representam protocolos de interação com outros sistemas, interfaces com usuários, interação entre sistema e dispositivos. Classes com este estereótipo podem ser representadas pelo ícone da figura abaixo.
Estereótipo de controle
É utilizado em classes que encapsulam o controle/lógica de um caso de uso, ou seja, aquelas que comandam a execução de um caso de uso fazendo a ligação das classes de fronteira com as de entidade. Normalmente são dependentes da aplicação. Classes com este estereótipo podem ser representadas pelo ícone da figura abaixo.
Linhas Mestras
Estas linhas são extremamente gerais e, portanto, sujeitas a adaptações em função do problema em mãos. Por exemplo, se a fronteira com um ator for extremamente simples pode-se conjugar controle e fronteira. Se o controle para todos os casos de uso for extremamente simples, pode-se colocá-los numa só classe de controle.
TOUR