Aula V_Introdução a UML e Casos de Uso

Prévia do material em texto

Engenharia de Software I
Introdução à
Unified Modeling Language (UML)
– Diagramas de Caso de Uso
2
Linguagem de Modelagem Unificada (UML)
Legal!!!
Mas o que é essa tal de Linguagem de 
Modelagem Unificada (UML)?
3
Unified Modeling Language - UML
§ O que é UML?
ü É uma linguagem visual para especificar, construir e
documentar os artefatos dos sistemas.
ü Um apoio ao processo de desenvolvimento.
ü Uma linguagem visual.
ü Independente de linguagem de programação.
ü Independente de processo de desenvolvimento.
4
A Linguagem de Modelagem Unificada (UML)
§ Com a adoção do Paradigma de Orientação a Objeto,
surgiram diversas forma de modelar um sistema.
§ A junção dessas técnicas, fez surgir a UML.
§ Aprovada em 1997 pela OMG (Object Management
Group), vem tendo grande aceitação pela comunidade de
desenvolvedores.
5
A Linguagem de Modelagem Unificada (UML)
§ Cada elemento gráfico da UML possui uma sintaxe (forma
correta de desenhá-lo) e uma semântica que define o
significado do elemento e para que ele deve ser usado.
§ A especificação completa da UML pode ser obtida no site
da OMG (www.omg.org).
6
Como são expressos os modelos de sistemas em 
software?
§ Para representar os sistemas de software são usados
diagramas e informações textuais.
§ Diagrama, é a coleção de elementos gráficos que possuem
um significado pré-definido.
ü A Modelagem consiste na utilização de notações gráficas e
textuais com o objetivo de construir modelos que representam as
partes essenciais de um sistema, considerando-se diversas
perspectivas diferentes e complementares.
7
Diagramas da UML
§ Os artefatos gráficos produzidos durante o
desenvolvimento de um sistema de software são definidos
através da utilização dos diagramas da UML.
üEstes documentos podem ser textuais ou gráficos.
üEstes documentos são denominados artefatos de software.
üSão os artefatos que compõem as visões do sistema.
§ Um processo de desenvolvimento que utiliza a UML como
linguagem de modelagem envolve a criação de diversos
documentos.
8
Principais Modelos UML usados no Projeto
§ Diagramas de estrutura:
§ Diagramas de comportamento:
§ Diagramas de interação:
ü Diagrama de Classe.
ü Diagrama de Componente.
ü Diagrama de Colaboração.
ü Diagrama de Caso de Uso.
ü Diagrama de Estado.
ü Diagrama de Atividade.
ü Diagrama de Sequência.
Extração de Requisitos
§ Usuários podem não ter uma ideia precisa do sistema por eles requerido.
§ Usuários têm dificuldades para descrever seu conhecimento sobre o domínio do problema.
§ Usuários e analistas têm diferentes pontos de vista do problema (por terem formações
diferentes).
§ Usuários podem antipatizar com o novo sistema e se negar a participar da extração(ou
mesmo fornecer informações errôneas).
§ Analistas acham que entendem os problemas dos usuários melhor do que os próprios
usuários!
Relembrando dificuldades na extração de 
Requisitos
§ O modelo de Casos de Uso é uma representação das
funcionalidades externamente observáveis do sistema e que
interagem com o mesmo.
§ O modelo de Casos de Uso modela os Requisitos
Funcionais do sistema.
Introdução – Diagrama de Caso de Uso
§ O diagrama da UML utilizado na modelagem de Casos de
Uso é o Diagrama de Casos de Uso.
§ Técnica de modelagem idealizada por Ivar Jacobson, na
década de 1970.
§ Posteriormente, a notação de Casos de Uso foi adicionada à
UML.
Introdução
§ Este modelo direciona tarefas diversas posteriores do ciclo
de vida do sistema de software.
§ Além disso, o modelo de Casos de Uso força os
desenvolvedores a moldar o sistema de acordo com o
usuário.
Introdução
14
Casos de Uso
§ Eles possibilitam um formato de apresentação
compreensível que pode ser utilizado para aprimorar a
comunicação, especialmente entre os projetistas da
aplicação e os clientes.
§ Eles são úteis para fases posteriores do ciclo de vida,
ajudando na identificação dos objetos, desenvolvimento
de planos de teste e documentação.
§ Um Caso de Uso é a especificação de uma sequência de
interações entre um sistema e os agentes externos.
§ Define parte da funcionalidade de um sistema, sem revelar
a estrutura e o comportamento internos deste sistema.
§ Um modelo de Casos de Uso típico é formado de vários
Casos de Uso.
Casos de Uso
Casos de Uso
17
Casos de Uso
§ Um Caso de Uso especifica o comportamento de um sistema ou
parte dele. É também uma descrição do conjunto de passos que o
sistema executará para desempenhar suas funções.
§ Um caso de uso é baseado em um cenário descritivo de como a
entidade externa interage com o sistema. Ele identifica eventos que
podem ocorrer e descreve a estes resposta do sistema para tais
eventos.
§ Cada Caso de Uso é definido através da descrição narrativa
das interações que ocorrem entre o(s) elemento(s)
externo(s) e o sistema.
§ Há várias formas de se descrever Casos de Uso:
Descrições Narrativas
ü Descrição Contínua.
ü Descrição Numerada.
ü Descrição Cliente/Sistema.
§ O Cliente chega ao caixa eletrônico e insere seu cartão. O
Sistema requisita a senha do Cliente. Após o Cliente
fornecer sua senha e esta ser validada, o Sistema exibe as
opções de operações possíveis. O Cliente opta por realizar
um saque. Então o Sistema requisita o total a ser sacado. O
Sistema fornece a quantia desejada e imprime o recibo para
o Cliente.
Exemplo de Descrição Contínua
1. Cliente insere seu cartão no caixa eletrônico.
2. Sistema apresenta solicitação de senha.
3. Cliente digita senha.
4. Sistema exibe menu de operações disponíveis.
5. Cliente indica que deseja realizar um saque.
6. Sistema requisita quantia a ser sacada.
7. Cliente retira a quantia e recibo.
Exemplo de Descrição Numerada
Exemplo de Descrição Cliente/Sistema
§ O grau de detalhamento a ser utilizado na descrição de um
Caso de Uso também pode variar (grau de abstração).
§ Um Caso de Uso sucinto descreve as interações sem
muitos detalhes.
§ Um Caso de Uso expandido descreve as interações em
detalhes.
Detalhamento
§ Uma abstração é qualquer modelo que inclui os aspectos
relevantes de alguma coisa, ao mesmo tempo em que
ignora os menos importantes.
Abstração
§ Abstração depende do observador.
Abstração
§ O modelo de Casos de Uso de um sistema é composto de:
Componentes do Modelo
ü Casos de uso.
ü Atores.
ü Relacionamentos entre os elementos anteriores (UC e Atores).
Exemplo de Notação
§ Elemento externo que interage com o sistema.
Atores
ü “externo”: atores não fazem parte do sistema.
ü “interage”: um ator troca informações com o sistema.
§ Casos de uso representam uma sequência de interações entre o
sistema e o ator.
ü no sentido de troca de informações entre eles.
§ Normalmente um agente externo inicia a sequência de
interações como o sistema, ou um evento acontece para que o
sistema responda.
§ Categorias de Atores:
Atores
ü Pessoas (Empregado, Cliente, Gerente,
Almoxarife, Vendedor, etc).
ü Organizações (Empresa Fornecedora, Agência
de Impostos, Administradora de Cartões, etc);
ü Outros sistemas (Sistema de Cobrança, Sistema
de Estoque de Produtos, etc).
ü Equipamentos (Leitora de Código de Barras,
Sensor, etc.)
§ Um ator corresponde a um papel representado em relação ao
sistema.
Atores
ü O mesmo indivíduo pode ser o Cliente que compra
mercadorias e o Vendedor que processa vendas.
ü Uma pessoa pode representar o papel de Funcionário de
uma instituição bancária que realiza a manutenção de um
caixa eletrônico, mas também pode ser o Cliente do banco
que realiza o saque de uma quantia.
§ O nome dado a um ator deve lembrar o seu papel, ao invés de
lembrar quem o representa.
§ Um ator pode participar de muitos casos de uso.
§ Um casode uso pode envolver vários atores, o que resulta na
classificação dos atores em primários ou secundários.
Atores
ü Um ator primário é aquele que inicia uma sequência de
interações de um caso de uso.
ü Atores secundários supervisionam, operam, mantêm ou
auxiliam na utilização do sistema.
§ Exemplo: para que o Usuário (ator primário) requisite uma
página a um Browser (sistema), um outro ator (secundário)
está envolvido, o Servidor Web.
§ Casos de uso e atores não existem sozinhos. Pode haver
relacionamentos entre eles.
§ A UML define diversos de relacionamentos no modelo de casos
de uso:
Relacionamentos
ü Comunicação ou Associação
ü Inclusão;
ü Extensão;
ü Generalização.
§ Analogia útil: rotina.
§ Quando dois ou mais casos de uso incluem uma sequência de
interações comum, esta sequência comum pode ser descrita em
um outro caso de uso.
Relacionamento de Inclusão
ü Em uma linguagem de programação, instruções podem ser
agrupadas em uma unidade lógica chamada rotina.
ü Sempre que essas instruções devem ser executada, a rotina
correspondente é chamada.
§ Este caso de uso comum:
§ Um exemplo: considere um sistema de controle de transações
bancárias. Alguns casos de uso deste sistema são Obter
Extrato, Realizar Saque e Realizar Transferência.
Relacionamento de Inclusão
ü evita a descrição de uma mesma sequência de interações
mais de uma vez e;
ü torna a descrição dos casos de uso mais simples.
ü Há uma sequência de interações em comum: a sequência
de interações para validar a senha do cliente.
Relacionamento de Inclusão
Notação
§ Utilizado para modelar situações onde diferentes sequências de
interações podem ser inseridas em um caso de uso.
§ SejamA e B dois casos de uso.
Relacionamento de Extensão
ü Um relacionamento de extensão de A para B indica que
um ou mais dos cenários de B podem incluir o
comportamento especificado por A.
ü Neste caso, diz-se que B estende A.
ü O caso de uso A é chamado de estendido e o caso de uso B
de extensor.
§ Exemplo: considere um processador de textos. Considere que
um dos casos de uso deste sistema seja Editar Documento.
§ No cenário típico deste caso de uso, o ator abre o documento,
modifica-o, salva as modificações e fecha o documento.
§ Mas, em outro cenário, o ator pode desejar que o sistema faça
uma verificação ortográfica no documento.
§ Em outro, o ele pode querer realizar a substituição de um
fragmento de texto por outro.
Relacionamento de Extensão
§ Interações de Substituir Texto (Descrição Enumerada):
Relacionamento de Extensão
1. Em qualquer momento durante Editar Documento, o ator
pode optar por substituir um fragmento de texto por outro.
2. O ator fornece o texto a ser substituído e o texto substituto.
3. O ator define os parâmetros de substituição (substituir
somente palavras completas ou ocorrências dentro de
palavras; substituir no documento todo ou somente na
parte selecionada; ignorar ou considerar letras maiúsculas e
minúsculas).
4. O sistema substitui todas as ocorrências encontradas no
texto.
Relacionamento de Extensão
Notação
§ Relacionamento no qual o reuso é mais evidente.
§ Este relacionamento permite que um caso de uso (ou um ator)
herde características de um caso de uso (ator) mais genérico.
§ O caso de uso (ator) herdeiro pode especializar o
comportamento do caso de uso (ator) base.
§ Pode existir entre dois casos de uso ou entre dois atores.
Relacionamento de Generalização
§ Na generalização entre casos de uso, sejam A e B dois casos de
uso.
§ Vantagem: comportamento do caso de uso original é reutilizado
pelos casos de uso herdeiros.
Relacionamento de Generalização
ü Quando B herda de A, as sequências de comportamento de A
valem também para B.
ü Quando for necessário, B pode redefinir as sequências de
comportamento de A.
ü Além disso, B participa em qualquer relacionamento no qual A
participa.
ü Somente o comportamento que não faz sentido ou é diferente
para um herdeiro precisa ser redefinido.
§ A generalização entre atores significa que o herdeiro possui o
mesmo comportamento que o ator do qual ele herda.
§ Além disso, o ator herdeiro pode participar em casos de uso em
que o ator do qual ele herda não participa.
§ Um exemplo: considere uma biblioteca na qual pode haver
alunos e professores como usuários.
Relacionamento de Generalização
ü Ambos podem realizar empréstimos de títulos de livros e
reservas de exemplares.
ü No entanto, somente o professor pode requisitar a compra de
títulos de livros à biblioteca.
Relacionamento de Generalização
Notação
§ Uma breve descrição para cada ator deve ser adicionada ao
modelo de casos de uso.
§ O nome de um ator deve lembrar o papel desempenhado pelo
mesmo no sistema.
Documentação dos Atores dos Casos de Uso
§ UML não define uma estruturação específica a ser utilizada na
descrição do formato expandido de um caso de uso.
§ A seguir, é apresentada uma sugestão de descrição.
Documentação dos casos de uso
ü A equipe de desenvolvimento deve utilizar o formato de
descrição que lhe for realmente útil.
§ Nome
§ Descrição
§ Identificador
§ Importância
§ Ator Primário
§ Atores Secundários
§ Pré-condições
Documentação dos casos de uso
§ Fluxo Principal
§ Fluxos Alternativos
§ Regras do Negócio
§ Notas de Implementação
Caso de Uso – Realizar Saque
§ Sumário: Este caso de uso possibilita a um cliente realize um saque de um
caixa eletrônico.
§ Ator Primário: Cliente.
§ Ator Secundário: Banco.
§ Pré-Condições: Cliente autenticado.
§ Fluxo Principal
1. O caso de uso tem início quando o ator Cliente seleciona a opção realizar saque.
2. O sistema pergunta ao Cliente a quantia a ser retirada.{Especifica Valor}.
3. O Cliente digita a quantia desejada.{Verifica Disponibilidade de Valor no Caixa}.
4. Executa o sub-fluxo “Avalia Quantia Disponível”. {Verifica Saldo Suficiente}.
5. O sistema contata o ator banco para determinar se existe saldo suficiente na conta
do Cliente. {Aprova Transação}.
6. O sistema inicia uma transação com o ator banco e solicita a retirada da quantia
desejada.
Caso de Uso – Realizar Saque
§ Fluxo Principal...
§ S1: Avalia Quantia Disponível
7. O sistema libera a quantia desejada.
8. O sistema emite um recibo para o Cliente.
9. O sistema fecha a transação com o ator banco.
10.O sistema armazena um log da transação.
11.O caso de uso se encerra.
1. O sistema determina se tem fundos suficientes à mão para fornecer a
quantia solicitada
2. O sistema verifica se a importância requisitada é maior do que a quantia
disponível.
3. O sistema verifica se a importância desejada pode ser fornecida com as
notas existentes no caixa eletrônico. (R$ 50,00 não podem ser fornecidos se
só houver três notas de R$ 20,00).
Caso de Uso – Realizar Saque
§ Fluxo Alternativo
A1 O cliente não digita a quantia desejada
Em {Especifica Valor} se o ator cliente não especifica a quantia
desejada
1. ...
A2 O caixa automático não pode fornecer a quantia solicitada
Em {Verifica Disponibilidade de Valor no Caixa} se o caixa não
tem disponibilidade de dinheiro para atender a solicitação do ator
cliente.
1. O sistema reporta uma mensagem adequada
2. O caso de uso se encerra.
Caso de Uso – Realizar Saque
§ Fluxo Alternativo
A3 O link com o banco caiu
Em qualquer ponto do fluxo principal.
1. ...
A4 O Cliente não tem saldo suficiente
Em {Verifica Saldo Suficiente} se o ator Cliente não tem recursos suficientes
em sua conta para cobrir a retirada
1. O sistema reporta uma mensagem adequada
2. O caso de uso se encerra.
A5 O banco não aprova a transação
Em {Aprova Transação} se o ator Banco não aprova a transação devido à
violação de alguma regra de negócio (por exemplo: limite diário excedido)
1. O sistema reporta uma mensagemadequada
2. Retorna ao fluxo principal.
§ São políticas, condições ou restrições que devem ser
consideradas na execução dos processos existentes em uma
organização.
§ Descrevem a maneira pela qual a organização funciona.
§ Estas regras são identificadas e documentadas no chamado
modelo de regras do negócio.
§ A descrição do modelo de regras do negócio pode ser feita
utilizando-se texto informal, ou alguma forma de estruturação.
Regras de Negócio
§ Alguns exemplos de regras de negócio:
Regras de Negócio
ü O valor total de um pedido é igual à soma dos totais dos itens
do pedido acrescido de 10% de taxa de entrega.
ü Um professor só pode estar lecionando disciplinas para as quais
esteja habilitado.
ü Um cliente do banco não pode retirar mais de R$ 1.000 por dia
de sua conta.
ü Os pedidos para um cliente não especial devem ser pagos
antecipadamente.
§ Regras do negócio normalmente têm influência sobre um ou
mais casos de uso.
§ Os identificadores das regras do negócio devem ser adicionados
à descrição do caso de uso.
Regras de Negócio
ü Utilizando a seção “regras do negócio” da descrição do caso de
uso.
§ Possível formato para documentação de uma regra de negócio.
Regras de Negócio
Modelo de Casos de Uso no Processo de 
Desenvolvimento
§ Na fase de construção, casos de uso formam uma base natural
através da qual podem-se realizar as iterações do
desenvolvimento.
§ Um grupo de casos é alocado a cada iteração.
§ Em cada iteração, o grupo de casos de uso é detalhado e
desenvolvido.
§ O processo continua até que todos os casos de uso tenham sido
desenvolvidos e o sistema esteja completamente construído.
Procedimentos Gerais
1) Identifique os atores e casos de uso na fase de concepção.
2) Na fase de elaboração:
3) Associe cada grupo de casos de uso a uma iteração da fase de
construção.
ü desenhe o(s) diagrama(s) de casos de uso;
ü escreva os casos de uso em um formato de alto nível e
essencial.
ü ordene a lista de casos de uso de acordo com prioridade e
risco.
ü Grupos mais prioritários e arriscados na iterações iniciais.
Procedimentos Gerais
4) Identifique os atores e casos de uso na fase de concepção.
5) Implemente estes casos de uso.
ü Detalhe os casos de uso do grupo associado a esta
iteração (nível de abstração real).
57
Exercícios – Elabora UC e Documentação do UC