Casos de uso Objetivo:



Documentos relacionados
Resolução da lista de exercícios de casos de uso

Uma visão mais clara da UML Sumário

Casos de Uso. Professor MSc Wylliams Barbosa Santos wylliams.wordpress.com Laboratório de Programação

MODELAGEM DE SISTEMAS

Utilizando os Diagramas da UML (Linguagem Unificada de Modelagem) para desenvolver aplicação em JSF

Curso de Licenciatura em Informática

04/07/2015 UML. Prof. Esp. Fabiano Taguchi DEFINIÇÃO DE REQUSIITOS

Desenvolvimento de uma Etapa

UML & Padrões Aula 3. UML e Padrões - Profª Kelly Christine C. Silva

DIAGRAMA DE ATIVIDADES

Atendimento de Demandas CTIC

Fundamentos de Teste de Software

3 Qualidade de Software

O Processo de Engenharia de Requisitos

Modelos de Sistemas Casos de Uso

Diagrama de Casos de Uso

Gerenciamento da Integração (PMBoK 5ª ed.)

DESENVOLVENDO O SISTEMA

PUC-Rio. Tópico 6: Diagrama de Sequência C E. Luiz Antônio M. Pereira. lpereira@uninet.com.br 1/41

Guia de utilização da notação BPMN

4.1. UML Diagramas de casos de uso

Tópicos da Aula. Que é são requisitos? Tipos de Requisitos. Requisitos Funcionais. Classificação de Requisitos. Requisitos de Software.

CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

Modelagem com UML. Fabio Perez Marzullo. IEEE Body of Knowledge on Services Computing Committee on Services Computing, IEEE Computer Society

MANUAL DA SECRETARIA

2 Fundamentação Conceitual

SISTEMA DE SERVIÇOS DE INFRA-ESTRUTURA DA UFRGS

Manual do Portal do Fornecedor. isupplier

Manual do Usuário do Produto EmiteNF-e. Manual do Usuário

Módulo 12 Gerenciamento Financeiro para Serviços de TI

Diagramas de Casos de Uso

Sistema de Gestão de Recursos de Aprendizagem

MINISTÉRIO DA SAÚDE. Secretária de Gestão Estratégica e Participativa da Saúde SGEP. Coordenação de Desenvolvimento dos Sistemas de Saúde - CDESS

Guia para elaboração do Modelo de Domínio Metodologia Celepar

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW

3.1 Definições Uma classe é a descrição de um tipo de objeto.

UML: Diagrama de Casos de Uso, Diagrama de Classes

UML Unified Modeling Language. Professor: André Gustavo Bastos Lima

Sistema Integrado de Gerenciamento de Imposto Sobre Serviços.

MANUAL DO USUÁRIO PORTAL DO PROFESSOR

UML Itens Estruturais - Interface

3. Fase de Planejamento dos Ciclos de Construção do Software

NOTIFICANDO USUÁRIOS SOBRE UMA NOVA EDIÇÃO

COORDENAÇÃO DE EAD MANUAL DE UTILIZAÇÃO DO MOODLE 2.6 PERFIL ALUNO. Versão 1.0

Manual de orientação do Sistema de Requisição de Recibos Eleitorais SRE

COTAÇÃO DE COMPRAS COM COTAÇÃO WEB

Conectar diferentes pesquisas na internet por um menu

BearingNet - Orçamentos Contenuto

Sumário FPD Formulário de projeto P&D...4

Uma visão mais clara da UML Sumário

Exercícios Diagrama de Casos de Uso. Disciplina: Engenharia de Requisitos

CALEDÁRIO ESCOLAR. Página 1 de 24

Especificação dos Requisitos do Software. Sistema de Controle e Gerenciamento de Loja de Vestuários e Acessórios

ESTENDENDO A UML PARA REPRESENTAR RESTRIÇÕES DE INTEGRIDADE

GUIA DO COORDENADOR DE PROJETOS

ProcessoUnificado: Prof. Anderson Cavalcanti UFRN-CT-DCA

Oportunidades GIFE. Como divulgar vagas na Comunidade

MINISTÉRIO DA EDUCAÇÃO UNIVERSIDADE FEDERAL DE GOIÁS CERCOMP/CENTRO DE RECURSOS COMPUTACIONAIS SAU - SERVIÇO DE ATENDIMENTO AO USUÁRIO

Mapa Mental de Engenharia de Software - Diagramas UML

Portal de Aprendizado Tutorial do Aluno

Engenharia de Software III

Licenciatura em Informática. - Análise e Conceção de Sistemas de Informação. Gestão de Condómino. Documento de Análise.

Sistemas Corporativos da USP (Web)

ADMINISTRAÇÃO I. Família Pai, mãe, filhos. Criar condições para a perpetuação da espécie

Trabalho Computacional 2. Aplicativo para Gestão Financeira. Grupos: Os trabalhos devem ser feitos individualmente ou em duplas.

Disciplina Técnicas de Modelagem

Modelagem de Sistemas Prof. Marcos Roberto e Silva

Gerenciamento do Tempo do Projeto (PMBoK 5ª ed.)

BR DOT COM SISPON: MANUAL DO USUÁRIO

Engenharia de Software Engenharia de Requisitos. Análise Orientada a Objetos Prof. Edison A M Morais prof@edison.eti.

Diretrizes de Qualidade de Projetos

Metadados. 1. Introdução. 2. O que são Metadados? 3. O Valor dos Metadados

Tema 1: Modelo Estático

2 Ferramentas Utilizadas

Professor: Curso: Disciplina: Aula 4-5-6

Endereço de acesso:

Sistema de Gerenciamento de Projetos V 1.01 MANUAL DO COORDENADOR

1223o TUTORIAL PRÉ-VENDA. Realização: DEPARTAMENTO DE IMPLANTAÇÃO EQUIPE DE DOCUMENTAÇÃO

Teste de Software: Um Breve Estudo do Importante Processo no Desenvolvimento de Softwares

Como estudar o SIPIA CT

O Processo Unificado: Captura de requisitos

CAPÍTULO 2. BANCOS DE DADOS DISTRIBUÍDOS

4- PROJETO DE BANCO DE DADOS

Caro participante, seja bem-vindo!!!

Modelagem Dinâmica com UML

MANUAL MOODLE - PROFESSORES

RELATÓRIO DE PROGRAMAÇÃO II. Igor Bissoli. Ramon Bambini. Victor Melo

SISTEMA UNIFICADO DE ADMINISTRAÇÃO PÚBLICA SUAP

Modelo Ambiental: Define as fronteiras entre o sistema e o resto do mundo.

Diagrama de Caso de Uso. Biblioteca

MANUAL CHAT DE ATENDIMENTO VIASOFT

CNEC FACULDADE CENECISTA DE CAPIVARI

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 16 PROFª BRUNO CALEGARO

Parecer Consultoria Tributária Segmentos Nota Fiscal Complementar de quantidade e valor

Manual de Utilização

MAIS CONTROLE SOFTWARE Controle Financeiro / Fluxo de Caixa (MCS Versão ) Índice

Transcrição:

Casos de uso Objetivo: Auxiliar a comunicação entre os analistas e o cliente. Descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. O cliente deve ver no diagrama de Casos de Uso as principais funcionalidades de seu sistema.

Notação (representação): Atores Um ator é representado por um boneco e um rótulo com o nome do ator. Um ator é um usuário do sistema, que pode ser um usuário humano ou um outro sistema computacional.

Caso de uso Um caso de uso é representado por uma elipse e um rótulo com o nome do caso de uso. Um caso de uso define uma grande função do sistema. A implicação é que uma função pode ser estruturada em outras funções e, portanto, um caso de uso pode ser estruturado.

Relacionamento (ajudam a descrever casos de uso). Entre um ator e um caso de uso. Associação Navegabilidade para Uma direção ator Caso de uso Navegabilidade para Ambos os lados Define uma funcionalidade do sistema do ponto de vista do usuário

Entre atores. Generalização Ator B - Os casos de uso de B são também casos de uso de A - A tem seus próprios casos de uso Ator A

Entre casos de uso. Inclusão <<include>> - instância outros casos de uso para suas condições Extensão <<extend>> - acrescenta outros casos de uso para suas condições Fornecer dados Do cliente <<include>> Incluir produto No pedido <<include>> Definir formas De pagamentos <<include>> Vendedor 1 * Colocar Pedido <<extend>> O vendedor pede o catálogo Consultar catálogos

Sistema. Limites do sistema: representado por um retângulo envolvendo os casos de uso que compõem o sistema. Nome do sistema: Localizado dentro do retângulo. Multiplicidade. Indica quantos objetos estão relacionados ao link. Ex. 1...*, 1...1, *...*, etc Ator. Primário e secundário

Exemplo

Cenários Deve-se especificar o comportamento de um caso de uso descrevendo textualmente um ou mais fluxos de ações, de modo que um usuário não técnico o possa entender sem dificuldade. Tal especificação deve incluir: Como e quando o caso de uso começa e termina; Quando é que o caso de uso interage com os atores; Que objetos são trocados; Cenário principal, e Cenários alternativos (e.g., situações de exceção).

Exemplo A operação de um caixa eletrônico tem início a partir de uma sessão em que o cliente seleciona a opção de realizar saque. O cliente então escolhe uma quantia a ser retirada, a partir de um conjunto de opções de quantia disponíveis. O sistema verifica se o caixa eletrônico tem saldo e notas adequadas para compor o valor solicitado (Ex. R$ 50,00 não podem ser fornecidos se só houver três notas de R$ 20,00). Caso tenha notas adequadas, os números da conta e da agência do cliente são enviados ao banco para determinar se existe saldo suficiente na conta do Cliente. Se não houver saldo, uma mensagem adequada é reportada. Havendo saldo, o sistema inicia uma transação com o ator banco e solicita a retirada da quantia desejada e o banco aprova ou desaprova a transação. Se a transação é aprovada, a máquina libera a quantia correspondente e emite um recibo. Se a transação é desaprovada, uma mensagem adequada é reportada. O banco é notificado, independentemente de uma transação aprovada ter sido completada ou não pela máquina. Se a transação é completada, o banco realiza o débito na conta do cliente.

Caso de Uso - Realizar Saque Objetivo: Este caso de uso possibilita a um cliente realize um saque de um caixa eletrônico Atores: Cliente, Banco Pré-Condições: Cliente autenticado Condição de Entrada: o ator Cliente seleciona a opção realizar saque Fluxo Principal 1. O sistema pergunta ao Cliente a quantia a ser retirada. 2. O Cliente digita a quantia desejada.[a1] 3. O sistema verifica se a importância requisitada é maior do que a quantia disponível. 4. O saldo é suficiente no caixa [A2] 5. 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). 6. Valores disponíveis [A3] 7. O sistema contata o ator banco para determinar se existe saldo suficiente na conta do Cliente. 8. O banco informa que cliente tem saldo[a4] 9. O sistema inicia uma transação com o ator banco e solicita a retirada da quantia desejada. 10. O banco envia aprovação da transação.[a5] 11. O sistema libera a quantia desejada 12. O sistema emite um recibo para o Cliente 13. O sistema fecha a transação com o ator banco. 14. O sistema envia ao banco um log da transação. 15. O caso de uso se encerra.

Fluxos Alternativos A1 O cliente não digita a quantia desejada Após 20 seg encerra o caso de uso A2 O caixa automático não tem disponibilidade de dinheiro para atender a solicitação do ator cliente 1. O sistema reporta uma mensagem de falta de recursos no caixa 2. O caso de uso se encerra. A3 O caixa automático não tem disponibilidade notas para compor o valor solicitado pelo ator cliente 1. O sistema reporta uma mensagem de não temos notas de R$X,00 disponíveis para compor esse valor, tente outro valor 2. O caso de uso retorna para o passo 1 do fluxo principal A4. O Cliente não tem saldo suficiente 1. O sistema reporta uma mensagem seu saldo não é suficiente para esse saque 2. O caso de uso se encerra. A5 O 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 mensagem adequada 2. O caso de uso se encerra.

Diagrama de Classe Objetivo: Descrever os vários tipos de objetos no sistema e o relacionamento entre eles.

Perspectivas Um diagrama de classes pode oferecer três perspectivas, cada uma para um tipo de usuário diferente. São elas: (1) Conceitos ou Entidades Representa os conceitos do domínio em estudo. Perspectiva destinada ao cliente.

(2) Classes Tem foco nas principais interfaces da arquitetura, nos principais métodos, e não como eles irão ser implementados. Perspectiva destinada as pessoas que não precisam saber detalhes de desenvolvimento, tais como gerentes de projeto.

(3) Classes de Software Aborda vários detalhes de implementação, tais como navegabilidade, tipo dos atributos, etc. Perspectiva destinada ao time de desenvolvimento.

Um diagrama de classes contém: Entidades Relacionamentos

# Entidades Classe: é representada na forma de um retângulo, contendo duas linhas que separam 3 partes. A primeira contém no nome da classe, a segunda os atributos da classe e a última os métodos da mesma. Interface: Representação Gráfica

Perspectivas: Conceitual Apenas classes são utilizadas. Neste tipo de perspectiva, uma classe é interpretada como um conceito. Apenas atributos são utilizados. Especificação Tanto classes como interfaces são utilizados neste tipo de perspectiva. O foco consiste em mostrar as principais interfaces e classes juntamente com seus métodos. Não é necessário mostrar todos os métodos, pois o objetivo deste diagrama nesta perspectiva é prover uma maior entendimento da arquitetura do software a nível de interfaces. Implementação Nesta perspectiva, vários detalhes de implementação podem ser abordados, tais como: visibilidade de atributos e métodos; parâmetros de cada método, inclusive o tipo de cada um; tipos dos atributos e dos valores de retorno de cada método.

# Relacionamentos Papel: Descreve o relacionamento. Multiplicidade (utilizado em todas as perspectivas de forma uniforme) Notações possíveis Exemplo:

Associação (utilizado em todas as perspectivas) Representação Gráfica Associação Perspectiva: Conceitual Define um relacionamento entre duas entidades conceituais do sistema. Especificação Define responsabilidades entre duas classes. Implica que existem métodos que tratam desta responsabilidade. Implementação Permite saber quem está apontando para quem, através da representação gráfica da navegabilidade. Além disto, é possível compreender melhor de que lado está a responsabilidade.

Herança ou Generalização (utilizado em todas as perspectivas) Representação Gráfica Perspectiva: Seja B uma generalização (extensão) de A. Conceitual Considera que B é um subtipo ou um tipo especial de A. O que é válido para A, também é válido para B. Especificação Ocorre uma herança de interface. Implementação Ocorre uma herança de implementação. Exemplo de uma herança de implementação:

Navegabilidade (utilizado apenas na perspectiva de implementação) Um relacionamento sem navegabilidade implica que ele pode ser lido de duas formas, isto é, em suas duas direções. Ex.: Uma empresa possui um trabalhador, como também um trabalhador trabalha em uma empresa. Utilizando a propriedade de navegabilidade, podemos restringir a forma de ler um relacionamento. Isto é, em vez de termos duas direções, teremos apenas uma direção (de acordo com a direção da navegação). Ex.: Uma empresa possui um trabalhador.

Agregação (utilizado apenas na perspectiva de implementação) Definição Agregação é uma associação em que um objeto é parte de outro, de tal forma que a parte pode existir sem o todo. Em mais baixo nível, uma agregação consiste de um objeto contendo referências para outros objetos, de tal forma que o primeiro seja o todo, e que os objetos referenciados sejam as partes do todo. A diferença entre os relacionamentos de associação e agregação ainda é algo de bastante discussão entre os gurus. De forma geral, utiliza-se agregação para enfatizar detalhes de uma futura implementação (perspectiva de implementação). Representação gráfica Agregação com navegabilidade

Composição (utilizado apenas na perspectiva de implementação) Definição Em mais baixo nível, em termos de passagem por parâmetro, seria uma passagem por valor. Enquanto que agregação seria uma passagem por referência. O todo contém as partes (e não referências para as partes). Quando o todo desaparece, todas as partes também desaparecem. Representação Gráfica

Implementação (utilizado apenas na perspectiva de implementação) Definição Utilizado para indicar que uma classe implementa uma interface Representação Gráfica Exemplo

Exemplos

Diagrama de interação: sequência Diagramas de Interação são modelos que descrevem como grupo de objetos colaboram em um determinado comportamento. Um diagrama de interação captura o comportamento entre objetos dentro um único caso de uso.

Consiste em um diagrama que tem o objetivo de mostrar como as mensagens entre os objetos são trocadas no decorrer do tempo para a realização de uma operação. Em um diagrama de sequência, os seguintes elementos podem ser encontrados: Linhas verticais representando o tempo de vida de um objeto (lifeline); Estas linhas verticais são preenchidas por barras verticais que indicam exatamente quando um objeto passou a existir. Quando um objeto desaparece, existe um "X" na parte inferior da barra; Linhas horizontais ou diagonais representando mensagens trocadas entre objetos. Estas linhas são acompanhadas de um rótulo que contém o nome da mensagem e, opcionalmente, os parâmetros da mesma. Observe que também podem existir mensagens enviadas para o mesmo objeto, representando uma iteração; Uma condição é representada por uma mensagem cujo rótulo é envolvido por colchetes; Mensagens de retorno são representadas por linhas horizontais tracejadas. Este tipo de mensagem não é frequentemente representada nos diagramas, muitas vezes porque sua utilização leva a um grande número de setas no diagrama, atrapalhando o entendimento do mesmo. Este tipo de mensagem só deve ser mostrada quando for fundamental para a clareza do diagrama.

Exemplo: Partindo do diagrama de Casos de Uso

Exemplo: Partindo do diagrama de Casos de Uso

Exercício Elabore o Diagrama de Casos de Uso para uma biblioteca escolar.

Exercício Elabore o Diagrama de Casos de Uso para um sistema de reserva de salas.

Exercício Elabore o Diagrama de Casos de Uso para um sistema de entrega de pizzas.

Exercício Faça o diagrama de casos de uso para um sistema de Inscrição de um congresso, por exemplo o SICOMP (Simpósio Interinstitucional de Computação).

Exercício Construa um modelo de casos de uso para a seguinte situação fictícia: "Estamos criando um serviço de entregas. Nossos clientes podem nos requisitar a entrega de volumes. Alguns volumes são considerados de maior valor por nossos clientes, e, portanto, eles querem ter tais volumes segurados durante o transporte. Contratamos uma companhia de seguro para segurar volumes de valor"