A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Introdução à modelagem orientada a objetos

Apresentações semelhantes


Apresentação em tema: "Introdução à modelagem orientada a objetos"— Transcrição da apresentação:

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

2 RELEMBRANDO... Técnico Subsequente

3 Visão geral da UML Profª. Ana Paula Lima Técnico Subsequente

4 Objetivo Apresentar de forma sumária a linguagem UML O que é?
Histórico Conjunto de diagramas Classificação do diagramas Comparação entre as versões 1 e 2 da linguagem Técnico Subsequente

5 O QUE É? É uma linguagem gráfica, para visualização, especificação, construção e documentação de artefatos de sistemas complexos de software (BOOCH,2000) Técnico Subsequente

6 UML – Linguagem de Modelagem Unificada
21/04/2017 Principais autores do processo: Grady Booch, James Rumbaugh (OMT), Ivar Jacobson (OOSE) Chamados os 3 amigos Aproveitar o melhor das características das notações preexistentes

7 UML – Linguagem de Modelagem Unificada
21/04/2017 Diagramas: Os documentos gerados em um processo de desenvolvimento são chamados de artefatos na UML Os artefatos compõe as visões do sistema A UML define 14 diagramas Esta quantidade de diagramas é justificada pela necessidade de analisar o sistema por meio de diferentes perspectivas Cada diagrama fornece uma perspectiva parcial do sistema. Engenharia de software orientada a objetos

8 Comparação entre as versões de UML
Modelagem dinâmica Diagrama de casos de uso Possui Diagrama de sequência Diagrama de comunicação Possui, mas chamado de diagrama de colaboração Diagrama de máquina de estados Possui, mas chamado de diagrama statechart Diagrama de atividades Diagrama de visão geral de interação Não possui Diagrama de temporização Técnico Subsequente

9 Engenharia de software orientada a objetos
21/04/2017 UML Diagramas da UML Diagramas estruturais Diagramas comportamentais Diagramas de perfil Diagramas de objetos Diagramas de Implementação Diagramas de Interação Diagramas de Atividades Diagramas de classes Diagramas de Casos de Uso Diagramas de Seqüência Diagramas de Componentes Diagramas de pacotes Diagramas de Colaboração Diagramas de Transições de estados Diagramas de Implantação Diagramas de estrutura composta Diagramas de Visão geral Da Interação Diagramas de Temporização UML 2.0 UML 2.0 UML 2.0 Engenharia de software orientada a objetos

10 1º Modelo: Diagrama de Casos de Uso

11 Engenharia de software orientada a objetos
21/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

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

13 Engenharia de software orientada a objetos
Notação da UML 21/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

14 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

15 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

16 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

17 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

18 Engenharia de software orientada a objetos
Casos de Uso 21/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. 21/04/2017 Engenharia de software orientada a objetos

19 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

20 Engenharia de software orientada a objetos
21/04/2017 Casos de Uso Cenários É a descrição de uma das maneiras pelas quais o caso de uso pode ser utilizada. É um episódio de utilização de uma funcionalidade. Pode ser utilizada posteriormente na fase de testes Cliente insere seu cartão no caixa eletrônico. O sistema apresenta a tela de requisição de senha do Cliente. Cliente digita sua senha Sistema valida a senha e exibe o menu com as opções de saque, pagamento ou transferência. O Cliente seleciona a opção saque. Sistema apresenta tela com a requisição do valor a ser sacado. O Cliente digita o valor da quantidade que deseja sacar. ... Engenharia de software orientada a objetos

21 Outros modelos de Casos de Uso
21/04/2017 Outros modelos de Casos de Uso Formato: estrutura utilizada para organizar a sua narrativa textual: Contínuo, numerado, tabular Formato contínuo Este caso de uso inicia quando 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 Cliente fornece o valor da quantidade que deseja sacar. O sistema fornece a quantia desejada e imprime o recibo para o Cliente. O Cliente retira a quantia e o recibo , e o caso de uso termina. 21/04/2017 Engenharia de software orientada a objetos

22 Engenharia de software orientada a objetos
21/04/2017 Casos de Uso Formato numerado Cliente insere seu cartão no caixa eletrônico. O sistema requisita a senha do Cliente. Cliente fornecer sua senha Sistema valida a senha e exibe as opções de operações possíveis. O Cliente opta por realizar um saque. Sistema requisita o total a ser sacado. O Cliente fornece o valor da quantidade que deseja sacar. O sistema fornece a quantia desejada e imprime o recibo para o Cliente. O Cliente retira a quantia e o recibo , e o caso de uso termina. Engenharia de software orientada a objetos

23 Engenharia de software orientada a objetos
21/04/2017 Casos de Uso Formato Tabular Tenta prover alguma estrutura à descrição Cliente Sistema Insere seu cartão no caixa eletrônico. Fornecer sua senha Solicita realização de um saque. Fornece o valor da quantidade que deseja sacar. Retira a quantia e o recibo Requisita a senha do Cliente. Valida a senha e exibe as opções de operações possíveis. Requisita o total a ser sacado. Fornece a quantia desejada e imprime o recibo para o Cliente. Engenharia de software orientada a objetos

24 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

25 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

26 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

27 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

28 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

29 Construindo o diagrama...
Técnico Subsequente

30 Exercício prático para amanha!!
Técnico Subsequente

31 DÚVIDAS? Técnico Subsequente

32 Associação (Relacionamento) Engenharia de software orientada a objetos
Relacionamentos 21/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 : 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

33 Engenharia de software orientada a objetos
Relacionamentos 21/04/2017 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

34 Engenharia de software orientada a objetos

35 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

36 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”.

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

38 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.

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

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

41 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”.

42 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.

43 Sol, Mar e UML

44 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

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

46 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

47 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

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

49 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

50 Técnico Subsequente

51 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

52 Resposta... Técnico Subsequente

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


Carregar ppt "Introdução à modelagem orientada a objetos"

Apresentações semelhantes


Anúncios Google