UML - Unified Modeling Language - Estados, Pacotes e Casos de Uso (Cenários)

Neste artigo vamos conhecer um pouco mais sobre Estados, Pacotes e Casos de Uso (Cenários) em UML.

por Admilson Nogueira

Estados

Definição

Um estado é uma condição ou situação na vida de um objeto durante a qual o objeto satisfaz alguma condição, realiza alguma atividade ou aguarda um evento. Todos os objetos possuem um estado que significa o resultado de atividades executadas pelo objeto, normalmente este estado é determinado pelos valores dos atributos e ligações com outros objetos.

Um objeto muda de estado quando acontece algo, o fato do objeto alterar o seu estado chamamos de evento. Analisando as mudanças de estado que um objeto pode sofrer, podemos prever todos os possíveis comportamentos de um objeto de acordo com os eventos que o mesmo possa sofrer.

Um estado pode ter três compartimentos: Nome do Evento, Atributos e Atividades.

• Nome do Evento - mostra o nome do evento, geralmente este nome descreve o que este estado realiza;

• Atributos – mostra as variáveis de estado, onde os atributos do objeto em questão pode ser listados e atualizados;

• Atividades – o compartimento de atividades é onde podemos listar os eventos e ações. Está dividido em três eventos padrões : Entrar, Sair e Fazer.

Entrar : usado para definir atividades no momento em que o objeto entra naquele estado;

Sair : usado para definir atividades que o objeto executa antes de passar para o próximo estado;

Fazer : usado para definir atividades que o objeto executa enquanto se encontra naquele estado.

Na Prática

O comportamento de uma Classe de Objetos é representado através de um Diagrama de Transição de Estado, que descreve o ciclo de vida de uma dada classe, os eventos que causam a transição de um estado para outro e as ações resultantes da mudança de estado.

O espaço amostral dos estados de uma dada Classe corresponde a enumeração de todos os estados possíveis de um objeto.

O estado de um Objeto é uma das possíveis condições na qual o objeto pode existir. O estado compreende todas as propriedades do objetos (estáticas) associadas aos valores correntes (dinâmico) de cada uma dessas propriedades.

A notação UML para representar o estado de uma classe corresponde a um retângulo com a bordas abauladas. Veja figura:

Exemplificando melhor

Estados e Atributos

Estados podem ser distinguidos pelos valores assumidos por certos atributos.

Exemplo - O número máximo de estudantes por curso, no “Use Case” Matrícula do Aluno, é igual a 10.

Estados e Ligações

Estados também podem ser distinguidos pela existência de certas ligações.

Exemplo – A instância da Classe Professor pode ter dois estados:

• Ensinando: quando o Professor esta ministrando um Curso.
• Licenciado: quando não esta ministrando nenhum Curso.

Estados Especiais

Estado Inicial é o estado atribuído a um objeto quando é criado. O estado Inicial tem as seguintes características:

• É mandatório
• Somente um estado Inicial é permitido.
• O estado Inicial é representado por um círculo preenchido.

Estado Final é o estado que indica o fim do ciclo de vida de um objeto. O estado Final tem as seguintes características:

• É opcional.
• Pode existir mais de um estado final.
• O estado Final é representado por um “olho de boi”.

Eventos

Um evento é uma ocorrência que acontece em algum ponto no tempo e que pode modificar o estado de um objeto, podendo gerar uma resposta.

Exemplos:

• Adicionar um aluno a um curso.
• Criar um novo curso.

Transição

É a mudança do estado atual para o estado subseqüente como resultado de algum estímulo. O estado subseqüente pode ser igual ao estado original. Uma transição pode ocorrer em resposta a um evento. As transições rotuladas com o nome dos eventos.

Condição de Guarda

A condição de guarda é uma expressão Boleana de valores de atributo que permitem que a transição ocorra somente se a condição assumida pela expressão é verdadeira.

Ações

É uma operação que está associada a uma transição, ocorrendo instantaneamente e que não pode ser interrompida. Nome de uma ação é mostrado, na seta indicativa da transição, precedida por um barra inclinada (/).

Envio de eventos a partir de outro evento

Um evento pode provocar o envio de outro evento. O nome do evento enviado é mostrado, na seta indicativa de transição, precedido por um circunflexo (^) seguido pelo nome da Classe para onde o evento será enviado, separados por um ponto.

Atividade

É uma operação que está associada a um estado, leva um tempo para ser executada e que pode ser interrompida.

Envio de eventos a partir de atividade

Uma atividade também pode provocar o envio de um evento para um outro Objeto.

Transição Automática

Algumas vezes, o único propósito da existência de um estado é desenvolver uma atividade. Uma transição automática ocorre quando a atividade é completada. Se múltiplas transições automáticas existem, uma condição de guarda é necessária para cada transição e as condições de guarda devem ser mutuamente exclusivas.

Pacotes

Definição

Imagine uma pasta no Windows. Pois bem, Pacote é um mecanismo de propósito geral para organizar elementos de modelo em grupos, podendo inclusive, estar aninhando dentro de outros pacotes (pacotes subordinados). Esta abordagem facilita a análise à medida que o número de Classes de Objetos cresce num do cenário.

Todos os modelos de elementos que são ligados ou referenciados por um pacote são chamados de "Conteúdo do pacote". Um pacote possui vários modelos de elementos, e isto significa que estes não podem ser incluídos em outros pacotes, apenas referenciados.

Pacotes podem importar modelos de elementos de outros pacotes. Quando um modelo de elemento é importado, refere-se apenas ao pacote que possui o elemento. Na grande maioria dos casos, os pacotes possuem relacionamentos com outros pacotes. Embora estes não possuam semânticas definidas para suas instâncias. Os relacionamentos permitidos entre pacotes são de dependência, refinamento e generalização (herança).

O pacote tem uma grande similaridade com a agregação. O fato de um pacote ser composto de modelos de elementos cria uma agregação de composição. Se este for destruído, todo o seu conteúdo também será.

Alguns exemplos:

Pacote vazio:

Pacote composto por classes:

Pacote contendo vários outros itens:

Os Pacotes podem conter muito mais que apenas outros itens, podem também conter Diagramas, Requisitos, Modelos de Dados, dentre outros artefatos da UML.

Existem Ferramentas Case que usam o recurso dos Pacotes para armazenar artefatos contendo Planos de Testes, Planos de Manutenção, etc.

Exemplos:

Pacote de um Sub-Sistema:

Pacote de um Modelo:

Pacote de Framework:

Agora que você já tem uma pequena noção de Pacotes na UML, vamos então abordar os Cenários das Use Cases, que nada mais são do que as necessidades na execução de uma ou mais funcionalidades. Casos de Uso (Cenários)

Definição

Casos de uso especificam o comportamento do sistema ou parte(s) dele e descrevem a funcionalidade do sistema desempenhada pelos atores. Você pode imaginar um caso de uso como um conjunto de cenários, onde cada cenário é uma seqüência de passos a qual descreve uma interação entre um usuário e o sistema. Os casos de uso são representados em forma de elipse.

Não se deve detalhar muito um determinado caso de uso, o seu detalhamento vai depender do risco que o mesmo corre, quanto maior o risco, mais detalhes terá o caso de uso.

Ao definir os casos de uso a serem desenvolvidos, trate apenas dos casos de usos mais críticos para o sistema, os casos de uso que são tarefas rotineiras não precisam ser desenvolvidos. Dessa forma sua documentação não se tornará monótona. Numericamente falando, em modo geral trate apenas de 10 à 20(%) dos casos de uso mais críticos de seu sistema, estes números citados é claro que podem variar dependendo do sistema a ser desenvolvido.

Nos nomes dos casos de usos devemos sempre usar verbos, pois assim facilitará no entendimento dos mesmos. Devemos possuir uma lista com todos os nomes dos casos de usos para facilitar na identificação dos mesmos. Preencher todos os requisitos de um caso de uso é de extrema importância.

Os Cenários

Imagine vários caminhos para realizar alguma tarefa, algum requisito. Isso são os Cenários, várias possibilidades de atividades, certas ou erradas.

Exemplo: Abertura de uma conta em um determinado banco. Para essa operação, você necessita realizar vários passos, que podem resultar em sucesso ou em problemas. O chamado "caminho sem erros" é o Cenário Básico, ou Cenário Principal, onde tudo ocorre sem nenhum problema. Veja:

1. O Cliente solicita a abertura da conta;
2. O Gerente aprova a abertura;
3. O Gerente abre a conta;
4. O Cliente realiza o primeiro depósito;
5. O Cliente ganha o seu cartão magnético.

Percebeu que nesse processo não ocorreram problemas? Esse é o que chamamos de Cenário Básico.

Agora imagine que no passo 2 do Cenário Básico, o Gerente encontre o nome do Cliente no SPC, por exemplo, e não abra a sua conta. A essa situação chamamos de Cenário Alternativo, onde ocorre algum problema no fluxo do Cenário Básico. Então nosso Cenário Alternativo fica assim:

1. No passo 2 do Cenário Básico, o Cliente é citado no SPC, inviabilizando a abertura de sua conta.

Podemos ainda incluir mais situações no Cenário Alternativo:

1. No passo 2 do Cenário Básico, o Cliente é citado no SPC, inviabilizando a abertura de sua conta;
2. No passo 3 o sistema informatizado do banco apresenta problemas, retardando a abertura da conta do Cliente;
3. No passo 5 o banco está sem mídia do cartão, ou o cartão do Cliente ainda não está pronto, retardando a entrega do mesmo ao Cliente.

Dentre outra situações, o importante é prever todas as que realmente são importantes, que possam ocorrer no Cenário Básico.