Embed Size (px)
Citation preview
UML: The Unified Modeling Language /
Use Cases
Professora: Aline Vasconcelos
Cefet Campos
2
Roteiro UML: uma definição Requisitos Funcionais e Não-Funcionais Stakeholders Glossário Casos de Uso Atores Cenários Diagramas de Casos de Uso Descrição de Casos de Uso Relacionamentos entre Casos de Uso e entre
Atores
3
UML: uma definição
UML representa uma Linguagem de Modelagem e não um
Método. Trata-se de uma linguagem visual (diagramática).
Método = procedimento formal para a realização de uma
tarefa
Métodos consistem, pelo menos em princípio, de um processo e de uma linguagem de modelagem.
A linguagem de modelagem é a notação (principalmente gráfica) utilizada por métodos para expressar projetos.
O processo é a sugestão dos passos a serem seguidos na elaboração de um projeto.
4
UML: diagramas (1/3) Apresenta nove diagramas para a modelagem de sistemas orientados a
objetos, sendo que, em cada um deles, uma diferente perspectiva do sistema é enfocada.
OS DIAGRAMAS ESTÁTICOS:
– Diagrama de Classes: reflete os tipos de objetos (classes) que compõem o domínio de problema e o domínio da solução, com sua estrutura e relacionamentos.
– Diagrama de Objetos: gráfico de instâncias, incluindo objetos com seus valores de dados (atributos). Representa uma instância do diagrama de classe, como uma foto de determinados objetos do sistema em algum momento no tempo. É utilizado para exemplificar o diagrama de classes.
– Diagrama de Caso de Uso (Use Case): reflete um modo de descrever a visão externa do sistema e suas interações com o mundo exterior, representando uma visão de alto nível de funcionalidade intencional mediante o recebimento de um tipo de requisição do usuário. Na modelagem de casos de uso, o sistema é visto como uma caixa-preta que oferece respostas aos usuários sem enfocar de que forma o atendimento a essas requisições é implementado internamente.
5
UML: diagramas (2/3) OS DIAGRAMAS DINÂMICOS:
– Diagramas de Interação: enfatizam interações entre objetos através da troca de mensagens. Refletem a estrutura dinâmica de um sistema orientado a objetos. As interações, ou seja, seqüências de troca de mensagens entre objetos, visam a realização de um propósito específico, tal como a realização de um caso de uso. Há dois tipos de diagramas de interação: Diagrama de Seqüência – enfatiza o aspecto temporal nas trocas de mensagens; Diagrama de Colaboração – representação espacial, gráfica de uma colaboração entre objetos.
– Diagrama de Estado: mostra as seqüências de estados pelos quais um objeto ou interação passa ao longo de sua vida em resposta a estímulos recebidos (eventos).
– Diagrama de Atividades:descreve uma seqüência de atividades para a realização de um processo, sendo úteis para a modelagem de workflows. Representa uma variante do Diagrama de Estados, no qual a maioria, se não todos os estados, são atividades.
6
UML: diagramas (3/3)
OS DIAGRAMAS FÍSICOS:- Diagramas de Componente: mostra os vários componentes em um sistema e duas dependências. Um componente representa, neste caso, um módulo físico do código.
- Diagramas de Utilização ou Implantação (deployment diagrams): mostra as relações físicas entre componentes de software e hardware no sistema implementado.
7
Requisitos (1/2):
Requisitos:– (1) Uma condição ou capacidade necessária para um usuário
resolver um problema ou alcançar um objetivo.– (2) Uma condição ou uma capacidade que deve ser alcançada ou
estar presente em um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto.
O documento que descreve todos os requisitos de um software, usualmente num formato ou linguagem inteligível pelo cliente, é a Descrição de Requisitos.
O documento que especifica estes requisitos, utilizando um formato mais apropriado para a implementação, é a Especificação de Requisitos.
Geralmente, ambos os documentos (descrição e especificação de requisitos) descrevem o que o software proposto deve fazer sem se preocupar em como deve ser feito.
8
Requisitos (2/2):
Requisitos Funcionais:– Descrevem uma interação entre o sistema e seu meio ambiente. – Funcionalidades do sistema conforme percebidas pelos atores externos
(usuários).
Requisitos Não-Funcionais:– Ou restrições, descrevem uma restrição para o sistema que limita as
possíveis escolhas de solução para o problema. – Normalmente conhecidos como Requisitos de Qualidade de uma
aplicação. – Devem ser detalhados em uma seção da documentação do Projeto do
Software.
Uma Especificação de Requisitos é importante porque:– Estabelece uma base de concordância entre o cliente e o fornecedor sobre
o que o software fará. – Mapeia o problema. – Uma especificação de requisitos de alta qualidade é um pré-requisito para
um software de alta qualidade.
9
Requisitos Não-Funcionais
Fatores de Qualidade de Software, segundo McCall [MCC77]:– Corretitude: à medida que um software satisfaz sua especificação
e cumpre os objetivos visados pelo cliente.
– Confiabilidade: probabilidade da operação livre de falhas de um programa de computador num ambiente específico durante determinado tempo.
– Eficiência: a quantidade de recursos de computação e de código exigida para que um programa execute sua função.
– Integridade: à medida que o acesso ao software ou a dados por pessoas não-autorizadas pode ser controlado,
– Usabilidade: o esforço para aprender, operar, preparar a entrada e interpretar a saída de um programa.
10
Requisitos Não-Funcionais
Fatores de Qualidade de Software, segundo McCall [MCC77]:– Manuteniblidade: o esforço exigido para localizar e reparar erros
num programa.
– Flexibilidade: o esforço exigido para modificar um programa operacional.
– Testabilidade: o esforço exigido para testar um programa a fim de garantir que ele execute sua função pretendida.
– Portabilidade: o esforço exigido para transferir o programa de um ambiente de sistema de hardware e/ou software para outro.
– Reusabilidade: à medida que um programa (ou partes de um programa) pode ser reusado em outras aplicações – relacionada ao empacotamento e escopo das funções que o programa executa.
– Interoperabilidade: o esforço exigido para se acoplar um sistema a outro.
11
Stakeholders
Pessoas atingidas pelos resultados produzidos pelo sistema e pelo projeto do sistema.
Exemplos de Stakeholders:
– Clientes: encomendam o produto e financiam o desenvolvimento– Usuários diretos: utilizam diretamente o produto– Usuários indiretos: recebem resultados do software, sem operá-lo
diretamente• Ex: Gerentes/Diretores
– Analistas ou Setores responsáveis por sistemas relacionados – Responsáveis pelo desenvolvimento, implantação e
manutenção do software,– etc.
12
Glossário:
Um Glossário deve ser produzido ao longo da atividade de coleta e especificação de requisitos ou durante a modelagem do negócio.
O Glossário conterá os termos utilizados pelos usuários com sua descrição.
Um documento de glossário ajuda a compreender as funcionalidades descritas pelos casos de uso.
13
Casos de Uso:
Originado a partir do método do Jacobson.
Casos de Uso são utilizados para modelar os requisitos funcionais do sistema.
Casos de Uso descrevem as funcionalidades do sistema, conforme esperadas pelos usuários, retratando um “diálogo” que uma entidade externa, chamada Ator, realiza com o sistema.
Um Caso de Uso é baseado num cenário descritivo de como o Ator interage com o sistema. Ele identifica eventos que podem ocorrer e descreve as respostas do sistema para estes eventos.
Um Caso de Uso, em última instância, representa um fluxo de eventos completo e com significado, descrevendo uma situação de uso particular do sistema.
Símbolo:
Função 1
14
Atores:
Ator: um papel que um usuário executa em relação ao sistema.
Os atores desempenham os casos de uso. Um único ator pode desempenhar vários casos de uso; um único caso de uso pode ter reciprocamente vários atores desempenhando-o ou participando.
Atores podem ser vistos como participantes do caso de uso que obtêm valor dos mesmos.
Atores podem ser: humanos, outros sistemas, dispositivos externos, etc., que interagem com o sistema.
Símbolo:
Ator 1
15
Cenários:
Um cenário é uma seqüência de eventos (estímulos) e respostas que descreve uma interação entre um usuário (Ator) e um sistema. Portanto, se você tivesse uma loja on-line baseada na web (loja virtual), poderíamos ter um cenário de compra de produto que diria:
O cliente navega pelo catálogo de itens de mercadoria e adiciona os itens desejados ao seu carrinho de compras. O cliente encerra a compra, visualizando o carrinho, informando o endereço de entrega, o número do cartão de crédito e confirmando a venda. O sistema procede à autorização do cartão de crédito, totaliza a venda e informa o valor total ao cliente e confirma a venda imediatamente, enviando um e-mail ao cliente logo a seguir.
16
Cenários na Descrição de Casos de Uso:
Compra de um Produto:1. O cliente navega pelo catálogo e seleciona itens a serem comprados.
2. O cliente vai para o checkout.
3. O cliente preenche o formulário da remessa, com: nome, data de nascimento, identidade, endereço e opção de entrega.
4. O sistema apresenta a informação total do faturamento incluindo a remessa, os preços e os impostos.
5. O cliente preenche a informação de cartão de crédito.
6. O sistema valida o número do cartão e autoriza a compra.
7. O cliente confirma imediatamente a venda
8. O sistema envia uma confirmação para o cliente por e-mail.
ClienteComprar Produto
17
Cenários na Descrição de Casos de Uso:
Fluxo Alternativo 1:Falha na Autorização do Cartão de Crédito
No item 6, o sistema falha na autorização da compra por crédito. Permite ao cliente re-submeter a informação do cartão de crédito e tentar novamente.
Fluxo Alternativo 2: Compra por Cliente Regular
No item 3, o cliente informa seu código de cliente regular. O sistema apresenta os dados do cliente, o número do cartão de crédito do cliente e os dados da compra. O cliente pode aceitar ou escrever por cima das informações apresentadas. Se cliente altera cartão, continua no passo 6, senão, continua no passo 7.
ClienteComprar Produto
18
Diagrama de Casos de Uso: exemplo 1
SISTEMA DE CONTROLE DE BIBLIOTECA
Reservar Item
Remover Reserva
Emprestar Item
Devolver Item
Registrar Título
Remover Título
Registrar Item
Remover Item
Registrar Usuário
Remover Usuário
Bibliotecário
19
Diagrama de Casos de Uso: exemplo 1
Usuário da Biblioteca
Consultar Títulos
20
Descrição de Casos de Uso: Possíveis Seções em uma Descrição
Caso de Uso: nome do caso de uso.
Ator que inicia o Caso de Uso: ator responsável por disparar o evento que dá início ao caso de uso. Se for um caso de uso de inclusão ou de extensão, serãodefinidos, nesta seção, os casos de uso que iniciam estecaso de uso em questão.
Objetivos: descreve, em linhas gerais, o que o caso de uso faz. Que funcionalidade o mesmo provê para o ator (usuário do sistema). Em alguns casos, ao invés de objetivos tem-se uma seção de Descrição, a qual contém uma mini-descrição e um resumo dos objetivos do caso de uso.
21
Descrição de Casos de Uso: Possíveis Seções em uma Descrição
Pré-condições: condições que devem ser satisfeitas antes do caso de uso ser executado. Representa o estado em que um outro caso de uso deve deixar o sistema para que o caso de uso em questão possa ser iniciado. Pré-condições não devem ser validadas dentro do fluxo execução do caso de uso.
Fluxo de Eventos: – Fluxo Principal: seqüência de eventos descrevendo o
cenário básico ou principal do caso de uso. A seqüência de eventos traduz um diálogo entre os atores participantes do caso de uso e o sistema.
– Fluxos Alternativos: seqüências de eventos alternativas. Podem representar alguma variação em relação ao fluxo básico de eventos, uma condição de erro no fluxo básico ou uma seqüência de eventos diferente, ou seja, um outro cenário que esteja relacionado aos objetivos e funcionalidade provida pelo caso de uso.
22
Descrição de Casos de Uso: Possíveis Seções em uma Descrição
Subfluxos: partes (conjunto de eventos) do fluxo de eventos que são extraídas, descritas em outro lugar (abaixo do fluxo principal) com um nome e referenciadas no fluxo principal e/ou em fluxos alternativos.
Exceções: alguma condição diferente do normal, do esperado, que possa levar o sistema a falhar. Representa também uma situação de erro, como as que podem ser representadas em um fluxo alternativo.
Pontos de Extensão: representam locais em um fluxo de eventos onde um comportamento adicional pode ser inserido. O comportamento pode ser inserido tanto através de um fluxo alternativo como através de um caso de uso de extensão. Para casos de uso de extensão, este comportamento adicional e a condição para sua inserção são especificados no caso de uso de extensão.
23
Descrição de Casos de Uso: Possíveis Seções em uma Descrição
Pós-condições: retratam o estado do sistema após a execução do caso de uso. Pós-condições podem ser omitidas quando o resultado do caso de uso é óbvio ou quando não ocorre nenhuma mudança de estado significativa no sistema após a execução do caso de uso.
Regras de Negócio: condições ou restrições sobre os processos de negócio, ou seja, sobre a forma como o negócio é executado. As Regras de Negócio devem ser checadas no fluxo de eventos do caso de uso.
Observações: detalhes a respeito do sistema que não devem estar explícitos no fluxo de eventos do caso de uso, mas que acrescentam informação significativa para o leitor compreender a funcionalidade descrita pelo caso de uso ou para se compreender o funcionamento do sistema.
24
Diagrama de Casos de Uso: exemplo 2
Sistema de Controle de Vendas
Registrar Parcelas de Pagamento
Manter Clientes
Caixa
Manter Produtos
Gerente
Manter Fornecedores
Vender Produtos
<<extend>>
Registrar Entrega de Produto Atualizar Estoque de Produto
<<include>>
<<include>>
25
Relacionamentos entre Casos de Uso
Inclusão: (referenciado como: uses, include ou inclui)
Um relacionamento de Inclusão do Caso de Uso A para o Caso de Uso B, indica que o comportamento de B estará incluído no comportamento de A.
Principal objetivo: reutilização
A associação de inclusão ocorre, principalmente, quando há uma parte do comportamento que é semelhante em mais de um caso de uso e não se deseja ficar copiando a descrição deste comportamento.
Ex:
Caixa Vender Produtos
Atualizar Estoque de ProdutoRegistrar Entrega de ProdutoGerente
<<include>>
<<include>>
26
Relacionamentos entre Casos de Uso
Extensão: (referenciado como: estende ou extend)
Um relacionamento de extensão do Caso de Uso B para o Caso de Uso A, indica que o comportamento de A pode ser estendido pelo comportamento especificado em B.
O caso de uso de extensão pode acrescentar comportamento ao caso de uso base.
Extensão deve ser utilizada quando se está descrevendo uma variação em comportamento normal do caso de uso. É um comportamento adicional.
Pontos de extensão podem ser declarados no caso de uso base.
Ex:
Caixa Vender Produtos
Registrar Parcelas de Pagamento
<<extend>>
27
Relacionamentos entre Casos de Uso
Generalização:
Um relacionamento de generalização entre um Caso de Uso A e Casos de Uso B e C, indica que o comportamento de A é especializado em B e C.
Os casos de uso B e C apresentam uma estrutura muito semelhante (fluxos de eventos, regras, etc.), então, a parte em comum é fatorada para um caso de uso de generalização ª
Os casos de uso especializados B e C podem acrescentar comportamento (passos no fluxo principal, fluxos alternativos adicionais), sobrescrever comportamento ou acrescentar dados de entrada e saída, regras, etc.
Ex:
Emitir Boletim de Alunos do 3º Grau
Emitir Boletim de Alunos do 2º Grau
SecretáriaEmitir Boletim
28
Relacionamentos entre Atores
Generalização:
Um relacionamento de generalização entre Atores significa que os Atores B e C representam papéis que especializam o papel definido pelo Ator A.
O relacionamento de generalização entre atores indica que os atores pertencem a um mesmo grupo semântico de usuários (ou papéis) e que compartilham responsabilidades. Os atores especializados herdam todas as características e links de comunicação do ator da generalização. Dessa forma, todos os casos de uso que o ator generalizado pode executar poderão ser executados também pelos atores das especializações.
Ex:
Gerente Diretor
CoordenadorAcompanhar Desempenho de
Funcionários
29
Passos para Elaborar o Modelo de Casos de Uso do Sistema
Identificar os Atores do Sistema
Identificar os Casos de Uso do Sistema
Identificar as Associações entre Atores e Casos de Uso
Elaborar o Diagrama de Casos de Uso
Dividir os casos de uso em pacotes se houver necessidade
Descrever os casos de uso
Verificar relacionamentos entre casos de uso: inclusão, extensão e generalização
30
Referências
http://www.omg.org/ http://www.rational.com/uml/resources/documentation/index.jsp Fowler, M. UML Essencial, Ed. Campus, 2000. Bittner, Kurt, Spence, Ian. Use Case Modeling. Addison-
Wesley. August, 2002.
