Introdução à modelagem orientada a objetos Técnico Subsequente

RELEMBRANDO... Técnico Subsequente

1º Modelo: Diagrama de Casos de Uso

Engenharia de software orientada a objetos 17/04/2017 Introdução Modelos de Casos de Uso - MCU Exibe um conjunto de atores e casos de uso e seus relacionamentos que expressam a funcionalidade do sistema. É um modelo de análise que representa um refinamento dos requisitos funcionais. Idealizado por Ivar Jacobson em 1970 e inserida na UML na década de 90. É o modelo mais popular para a documentação de requisitos funcionais O MCU representa os possíveis usos de um sistema. Engenharia de software orientada a objetos

Associação (Relacionamento) COMPONENTES Composto por: Ator Caso de Uso Funcionário Associação (Relacionamento) Controlar Clientes CENÁRIOS Técnico Subsequente

Engenharia de software orientada a objetos Notação da UML 17/04/2017 Ator primário inicia uma seqüência de interações Ator secundário supervisiona, opera, mantém ou auxilia na utilização do sistema por atores primários. Engenharia de software orientada a objetos

Engenharia de software orientada a objetos Ator Qualquer pessoa, departamento, sistema computacional e dispositivos que utilizam funcionalidades do sistema. Pode ser usuário humano ou um outro sistema. Notação utilizada para representar um ator: Funcionário Cliente Acervo Biblioteca Engenharia de software orientada a objetos

Engenharia de software orientada a objetos Ator Não representar para o mesmo ATOR mais do que uma missão Funcionário e Cliente Funcionário Cliente Engenharia de software orientada a objetos

Engenharia de software orientada a objetos Exemplo... Suponha que você tenha um almoxarifado de peças onde clientes façam pedido e onde um operador receba tarefas do sistema para buscar peças para os pedidos dos clientes e distribuir peças do setor de compras para o almoxarifado. Como poderíamos identificar os atores e os casos de uso para este exemplo? Engenharia de software orientada a objetos

Engenharia de software orientada a objetos Exemplo... Eles são :  Cliente,  Operador, Sistema e Setor de Compras. Certo ? Engenharia de software orientada a objetos

Não errado !!! Técnico Subsequente

Ator é um papel que interage com o sistema mas não faz parte do sistema, então no lugar de Sistema poderíamos sugerir um administrador ou gerente. Então os atores seriam :   Cliente ,  Operador , Administrador e Compras. (Podem existir sub-sistemas que interagem com o sistema , neste caso eles seriam considerados atores.) Funcionário Técnico Subsequente

Cenário 1: Procure quem são os atores Quem está pressionando a tecla (interagindo com o sistema)? Sistema de Registro Estudante Operador Engenharia de software orientada a objetos

Cenário 2: Procure quem são os atores Se o sistema for online? Estudante Sistema online de Registro Engenharia de software orientada a objetos

Engenharia de software orientada a objetos Casos de Uso 17/04/2017 Um caso de uso é representado por uma elipse e um rótulo com o nome do caso de uso. A nomeação de um caso de uso inicia-se por um verbo no infinitivo. Modela um diálogo entre um ator e o sistema. Define uma funcionalidade do sistema. 17/04/2017 Engenharia de software orientada a objetos

Controlar Fornecedores Casos de Uso Não representar para o Caso de Uso mais do que uma funcionalidade. Controlar Clientes e Fornecedores Controlar Clientes Controlar Fornecedores Técnico Subsequente

Vamos praticar... Exercício 01 Leia o texto abaixo: A Computer & CIA é uma pequena empresa prestadora de serviços em manutenção de computador. Possui 6 colaboradores, sendo: 3 técnicos, 1 atendente, 1 gerente e 1 entregador. Atualmente, possui um sistema de controle de OS. Técnico Subsequente

Vamos praticar... Exercício 01 Identifique apenas os atores: O cliente chega no balcão e o Atendente faz a abertura da Ordem de Serviço (OS). O técnico acessa o sistema do laboratório para verificar as OS’s abertas. O Gerente tem acesso total ao sistema. Técnico Subsequente

NA PRÁTICA... Vamos criar um cenário de exemplo para vermos a notação de um diagrama de caso de uso: “A clínica médica Saúde Perfeita precisa de um sistema de agendamento de consultas e exames. Um paciente entra em contato com a clínica para marcar consultas visando realizar um check-up anual com seu médico de preferência. A recepcionista procura data e hora disponível mais próxima na agenda do médico e marca as consultas. Posteriormente o paciente realiza a consulta, e nela o médico pode prescrever medicações e exames, caso necessário”. Técnico Subsequente

Passos para o digrama Identificar quem são os atores do sistema; Quais são as funcionalidades que cada ator irá executar? Técnico Subsequente

Atores do Sistema Secretária Médico Consultar a agenda Agendar a consulta Cancelar a consulta Médico Realiza a consulta Prescreve Medicação Solicita Exames Técnico Subsequente

Construindo o diagrama... Técnico Subsequente

Engenharia de software orientada a objetos Construindo o Exemplo... Suponha que você tenha um almoxarifado de peças onde clientes façam pedido e onde um operador receba tarefas do sistema para buscar peças para os pedidos dos clientes e distribuir peças do setor de compras para o almoxarifado. Como poderíamos identificar os atores e os casos de uso para este exemplo? Engenharia de software orientada a objetos

DÚVIDAS? Técnico Subsequente

Associação (Relacionamento) Engenharia de software orientada a objetos Relacionamentos 17/04/2017 Componente responsável por representar a interação entre os atores e casos de usos. (Ator <--> Caso de Uso) Também representa ligações entre casos de uso ou entre atores. (Ator <--> Ator; Caso de Uso <-->Caso de Uso) Tipos de Relacionamentos : Associação de Comunicação Inclusão Extensão Generalização Ator primário inicia uma seqüência de interações Ator secundário supervisiona, opera, mantém ou auxilia na utilização do sistema por atores primários. Ator Caso de Uso Funcionário Controlar Clientes Associação (Relacionamento) Engenharia de software orientada a objetos

Engenharia de software orientada a objetos Relacionamentos 17/04/2017 Associação de Comunicação: Informa a que caso de uso o ator está associado Representa as trocas de informação entre os atores e casos de uso É o mais utilizado nos MCU Um ator pode estar associado a vários casos de uso Unidirecional: seta indica onde iniciou a comunicação. Bidirecional: falta-se a seta indica comunicação nos dois sentidos. Ator primário inicia uma seqüência de interações Ator secundário supervisiona, opera, mantém ou auxilia na utilização do sistema por atores primários. Caso de Uso A Ator Caso de Uso B Engenharia de software orientada a objetos

Engenharia de software orientada a objetos

Relacionamentos - Include Relacionamento de um caso de uso base para um caso de uso de inclusão. O caso de uso incluído é sempre abstrato. A execução do caso de uso incluído é obrigatória. O caso de uso base depende do resultado retornado pelo caso de uso incluído. Inclusão Ator <<include>> seria a relação de um caso de uso que para ter sua funcionalidade executada precisa chamar outro caso de uso. Base

Relacionamentos - Include Exemplo: Include: Quando um caso de uso “A” inclui (include) outro caso de uso “B”. Isto implica que ao executar o caso de uso “A” executa-se também o caso de uso “B”.

Relacionamentos - Extend O caso de uso de extensão é abstrato. A execução do caso de uso de extensão é opcional. Base <<extend>> Extensão

Relacionamentos - Extend Exemplo: Extends: Quando um caso de uso “A” tem um relacionamento do tipo extends com outro caso de uso “B”. Implica que ao executar o caso de uso “A” não necessariamente “B” será executado.

Relacionamentos- Generalização É um relacionamento de um caso de uso filho para o caso de uso pai (Herança). Compartilha objetivos comuns.

Relacionamentos- Generalização Exemplos: O ator pode herdar as funcionalidades (casos de uso) de outro ator.

Diagrama de Caso de Uso Ex.: O ator cliente executará os casos de uso “realizar saque” e “consultar saldo”, enquanto o gerente poderá interagir com os casos de uso “abrir conta” e “vender seguro”.

Aspectos a Considerar Um dos aspectos mais perigosos é o abuso de <<inclui>> e <<estende>> Um diagrama de caso de uso deve ser o mais simples possível. Detalhes devem ser deixados para outros diagramas, pois eles foram idealizados justamente com este objetivo. A fronteira do negócio ou sistema é muito importante, pois ajuda a diminuir a complexidade do contexto global. Conclusão: diagramas de caso de uso são ferramentas que nos ajudam a enxergar o todo por intermédio da constatação das responsabilidades que os usuários diretos têm.

Vamos praticar... Exercício 02 Preencha as palavras cruzadas conforme o enunciado: Qualquer pessoa, departamento, sistema computacional e dispositivos que utilizam funcionalidades do Sistema. A execução do caso de uso ________ é obrigatória. A execução do caso de uso ________ é opcional. O ator pode herdar as funcionalidades (casos de uso) de outro ator. O relacionamento de ____________ representa a informação de quais atores estão associados a que casos de usos. Técnico Subsequente

Vamos praticar... Exercício 02 1 2 3 4 5 Técnico Subsequente

Vamos praticar... Exercício 03 Deseja-se modelar um sistema para um pequeno hotel que atenda aos seguintes requisitos: Quando o cliente chega no hotel para fazer o check-in, o funcionário verifica se existe um quarto reservado para o cliente, caso contrário, verifica a disponibilidade do quarto e, existindo quarto disponível, efetua o registro de hospedagem, e faz o registro do cliente. Técnico Subsequente

Vamos praticar... Exercício 03 Quando o cliente deixar o hotel e solicitar que providencie sua saída, será encerrada a conta e o quarto tornará disponível para a limpeza. Quais os atores e os casos de uso? Técnico Subsequente

Revisando... Observe o diagrama abaixo e responda algumas perguntas: Técnico Subsequente

Perguntas... O Ator 1 consegue enxergar o caso de uso UC3? O Ator 2 tem acesso ao caso de uso UC1 e UC2? Os casos de usos UC1, UC2, UC3 são abstratos? Os casos de usos UC4, UC5, UC6, UC7 são concretos? Se você colocar um ator se comunicando com o caso de uso UC7, ele deixa de ser abstrato? Os casos de usos UC6, UC7 são casos generalizados do UC3? Técnico Subsequente

Técnico Subsequente

Vamos praticar... Exercício 04 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". Técnico Subsequente

Resposta... Técnico Subsequente

Especificação de Casos de Uso ou Casos de Uso Expandido

Especificando Casos de Uso A especificação de um caso de uso pode ser feita através da descrição de sequências de eventos em formato de texto. Descreve como o ator e o caso de uso interagem. Deve ser considerado: Como e quando o caso de uso inicia e termina (passos para execução do caso de uso); Como é a interação do ator com o caso de uso; A sequência padrão (funcionamento esperado); As sequências alternativas ou de exceção.

A especificação inclui: Identificação: (código) Nome: (do Caso de Uso) Atores: (todos os atores que interagem com o caso de uso) Tipo: prioridade do caso de uso (primário, secundário, opcional) Pré-condições: (o estado do sistema para que o caso de uso possa iniciar) Pós-condições: (o estado do sistema após a execução do caso de uso) Seqüência de Eventos Fluxo Básico: situação de execução ideal Alternativo: situações de erro ou exceção

Exemplo

Sequencia típica de eventos Sequencia alternativa Identificação: UC001 Nome: Sacar Dinheiro (deve ser o mesmo nome dado no diagrama de caso de uso) Atores: Cliente Tipo: Primário Pré-condições: O cliente deve possuir cartão do banco e senha cadastrada Pós-condições: Saque realizado com sucesso Sequencia típica de eventos Ator Sistema 1. Realiza a leitura do cartão 3. Valida conta corrente e senha, liberando a operação 2. Informa a senha 5. Autoriza o saque e lança o débito na conta corrente do cliente 4. informa o valor do saque 6. Libera o dinheiro Sequencia alternativa 3a. Cliente inválido 1. A operação é cancelada 5a. Fundos insuficientes

Vamos praticar... Faça o caso de uso expandido desse diagrama. Técnico Subsequente

REFERÊNCIA BIBLIOGRÁFICA SILVA, Ricardo P. e. UML 2 em modelagem orientada a objetos. Florianópolis, SC: Visual Books, 2007. 232p. Técnico Subsequente