Diagramas de Seqüência

Apresentação em tema: "Diagramas de Seqüência"— Transcrição da apresentação:

1 Diagramas de Seqüência
Projeto de Sistemas de Software

2 Interações Comportamento que
Envolve conjunto de mensagens trocadas entre objetos dentro de um determinado contexto Objetiva atingir resultado específico Acontecem em função da troca de mensagens entre objetos Usadas para a modelagem dos aspectos dinâmicos de um sistema

3 Comunicação entre Objetos
mensagem o:Ob1 :Ob2 Mensagem = Ident. Objeto Ident. Operação Parâmetros Mensagem Recepção de mensagem por um objeto Considerado instância de evento Decorrência da passagem de uma mensagem Repercute ação representada por um comando executável Comando Executável: abstração de procedimento computacional

4 Diagramas de Interação
Deseja-se representar o comportamento de vários objetos Dentro de um único caso de uso A partir das mensagens que são passadas entre eles Objetivo Definir um contexto de caso de uso Estabelecer os objetos que interagem e seus relacionamentos Termo genérico que se aplica a quatro tipos de diagramas que enfatizam interações entre objetos Diagrama de Seqüência Diagrama de Colaboração/Comunicação Vista Geral de Interação Temporal ou Timing

5 Duas formas de representação
Informações bastante similares mas de maneira diferente Diagrama de Seqüência Interação enfatizando o tempo de seqüência Mostra objetos participando em interações de acordo com suas linhas de vida e as mensagens que trocam Diagrama de Comunição Interação enfatizando o relacionamento entre os objetos

6 Diagrama de seqüência ObjetoA ObjetoB [se novo] <<create>>
Tempo (top-down) ObjetoA ObjetoB [se novo] <<create>> mensagem mensagem (auto delegação) valor de retorno <<destroy>> (caixa de)ativação condição de guarda mensagem síncrona objeto símbolo de destruição linha de vida

7 Termos e conceitos Objetos Linhas de vida Mensagens Focos de controle

8 Objetos Apresentados na dimensão horizontal do diagrama
Ordem dos objetos não é considerada Dispô-los de forma a tornar o diagrama “mais legível” Objetos tem nomes obj:Classe Ex.: joão:Dentista :Floricultor (um objeto floricultor não identificado) obj1: (um objeto obj1 sem classe definida)

9 Objetos

10 Linhas de Vida Dimensão vertical do diagrama
Apresentam o tempo de vida dos objetos Pode apresentar a ativação ou a desativação dos objetos Indicam que os objetos estão executando algo Foco de controle Caixas de ativação podem ser empilhadas Indica chamada de método do próprio objeto Objeto jose no slide anterior Podem representar a criação e a destruição de objetos

11 Linhas de Vida Linhas de vida Criação Destruição (Caixas de) Ativação
new() Criação Destruição kill() (Caixas de) Ativação

12 Mensagens Objetos interagem através da troca de mensagens Sintaxe
Setas sólidas que vão do objeto solicitante para o solicitado Para o próprio objeto: auto-delegação Rotulados com os nomes dos estímulos mais os argumentos (ou valores dos argumentos) do estímulo Sintaxe onde return é o nome do valor de retorno message é o nome da mensagem parameter é o nome de um parâmetro da mensagem parameterType é o nome do tipo desse parâmetro returnType é o tipo do valor de retorno return := message(parameter:parameterType):returnType

13 Mensagens - Tipos Tipos de ação que uma mensagem pode representar call
Invoca uma operação sobre um objeto Objeto pode mandar uma chamada para si próprio Resultando na execução local de uma operação return Representa o retorno de um valor para o objeto que chamou a operação Opcional create Criação de um objeto destroy Eliminação de um objeto new() <<create>> kill() <<destroy>>

14 Mensagens - Representações
Símbolo Significado                  Mensagem síncrona Mensagem assíncrona Mensagem de retorno (opcional)

15 Mensagens Auto-delegação mensagens

16 Mensagens – Condições de Guarda
Mensagens podem apresentar condições de guarda condições em que a mensagem é enviada [condição de guarda] :Aluno :Sistema :Impressora login() sistemaOk matricula() turmaCheia [sem vaga] matriculado imprimirRelatório() [com vaga] Matrícula

17 Mensagens - Iteração Uma mensagem pode ser enviada repetidas vezes

18 vendedor pedido * adicionarItem

19 Foco de Controle Período de tempo que o objeto executa uma ação
Relação de controle entre ativação e o responsável pela sua invocação

20 Diagrama de Seqüência Construção
Escolher um caso de uso Identificar os objetos que fazem parte da interação Identificar o objeto que começa a interação Identificar as mensagens trocadas entre os objetos Identificar a sequência destas mensagens

21 Análise OO do RUP Fronteira (boundary) Controle (control)
Objetivo Modelar o comportamento de cada caso de uso com o objetivo de detalhar os serviços de negócios oferecidos pelo sistema Uso de apenas 3 tipos de classes Fronteira (boundary) Classes de interface com o mundo externo (ex: GUI, sistemas externos) Controle (control) Coordenam o comportamento do caso de uso definindo uma interface entre classes fronteira e entidade Entidade (entity) Classes que armazenam informações manipuladas pelo sistema

22 Blog - Casos de uso

23 Blog - Diagrama de Seqüência: Criar blog

24 Blog - Diagrama de Seqüência: Criar Nota

25 Estudo de Caso

26 Estudo de Caso Considerações sobre o que o sistema se propõe a fazer:
O sistema suportará um cadastro de clientes, onde cada cliente cadastrado poderá ter várias contas correntes, vários dependentes ligados a ele, e várias contas de poupança. Cada dependente poderá possuir várias contas de poupança, mas não poderá ter uma conta corrente própria. Entendemos poupança como uma conta que possui um valor, um prazo de aplicação a uma taxa de juros (definida no vencimento da poupança). Entendemos Aplicações Pré-fixadas como uma aplicação de um valor, em um prazo pré-determinado a uma taxa de juros previamente definida. Tanto a conta-corrente quanto a poupança deverão manter um histórico de todas as movimentações de crédito, débito, transferências e aplicações de pré-fixados (pré-fixados apenas para conta corrente). Uma conta corrente poderá ter várias aplicações pré-fixadas ligadas a ela.

27 Fases do Desenvolvimento
Análise de Requisitos: Modelar o diagrama de casos de uso do sistema. O sistema implementará funções básicas que serão desempenhadas pela Administração do banco e pelos seus clientes. As principais funções do sistema são: Cadastrar novo cliente Excluir ou editar cliente Cadastrar dependente Excluir ou editar dependente Abrir conta corrente Fechar conta corrente Abrir poupança Fechar poupança Movimentar conta corrente Aplicar em pré-fixados Consultar histórico de conta corrente ou poupança Cadastrar Agência Excluir ou Editar Agência

28 Diagrama de Casos de Uso
Representa uma sucessão particular de transações entre o sistema e um ator (um usuário final ou um sistema externo ao sistema analisado). Permite definir todos os modos nos quais os usuários interagem com a aplicação a ser construída.

29 Diagrama de Casos de Uso
Cadastrar Cliente Administração do Banco Remover ou Atualizar Cliente Cadastrar Dependente Remover ou Atualizar Dependente Abrir Conta Corrente Fechar Conta Corrente Abrir Poupança Fechar Poupança Cadastrar Agência Remover ou Atualizar Agência Cadastrar Operação (Histórico) Remover ou Atualizar Operação (Histórico)

30 Diagrama de Casos de Uso
Movimentar Conta Corrente Gerar Histórico <<usa>> <<usa>> Aplicar em pré-fixados Consultar Histórico de Conta Corrente Cliente

31 Diagrama de Casos de Uso
Manter Dependente Manter Agência Cliente Movimentar Conta Corrente Administração do Banco Manter Cliente Consultar Histórico de Conta Corrente <<usa>> Manter Operação (Histórico) Manter Conta Corrente Aplicar em pré-fixados <<usa>> <<estende>> Manter Poupança

32 Fases do Desenvolvimento
Análise: Modelar o diagrama de classes. Na fase de análise, tendo em mãos o diagrama de use-case, podemos definir o diagrama de classes do sistema. Este primeiro diagrama da fase de análise deverá ser totalmente despreocupado de qualquer tipo de técnica relacionada à implementação do sistema, ou seja, métodos e atributos de acesso a banco de dados, estrutura de mensagens entre objetos, etc não deverão aparecer nesse primeiro diagrama, apenas os tipos de objetos básicos do sistema.

33 Diagrama de Classes O Diagrama de Classes é uma estrutura lógica que permite o desenvolvimento das Classes do Sistema. Para cada Classe desenvolvida no diagrama é possível especificar seus atributos e operações, assim como o relacionamento com as demais classes do sistema.

34 Diagrama de Classes Agência Histórico Conta Corrente Operação
Cod_Agencia:Caracter Nome_Agencia: Caracter Criar ( ) Destruir ( ) Histórico Data: Data Operação: Operação Valor: Numérico Criar ( ) Destruir ( ) 1 Possui * * Possui Gera * 1 1 Conta Corrente Cod: Caracter Saldo: Numérico Vetor_Aplic_PreFix: Aplic_Pre_Fixadas Vetor_Historico: Historico Agência: Caracter Criar ( ) Destruir ( ) Depositar ( ) Debitar ( ) Transferir ( ) Obter_Saldo ( ) Aplicar_Prefix ( ) Tirar_Extrato ( ) Retirar_Aplic_Prefix ( ) Operação Cod_Agencia:Caracter Nome_Agencia: Caracter Criar ( ) Destruir ( ) Aplicações Pré Fixadas * Valor: Numérico Data_Venc: Data Taxa: Numérico Criar ( ) Destruir ( )

35 Diagrama de Classes Conta Corrente Cliente Poupança Dependente
* 1 Cliente Cod: Caracter Saldo: Numérico Vetor_Aplic_PreFix: Aplic_Pre_Fixadas Vetor_Historico: Historico Agência: Caracter Criar ( ) Destruir ( ) Localizar ( ) Abrir_Conta_Corrente ( ) Remover_Conta_Corrente ( ) Adic_Dependente ( ) Excluir_Dependente ( ) Abrir_Poupança ( ) Fechar_Poupança ( ) Possui Poupança Data_Venc: Data Criar ( ) Destruir ( ) Possui * 1 * Possui 1 Dependente Nome: Caracter CPF: Numérico Parentesco: Caracter Vetor_Poupanças: Poupança Criar ( ) Destruir ( ) Localizar ( ) Abrir_Poupança ( ) Fechar_Poupança ( ) Possui 1 *

36 Diagrama de Objetos Diagrama de Classes Diagrama de Objetos Conta
Aplicações Cliente possui Cod: Caracter Cod_Conta: Caracter Cod: Caracter Saldo: Numérico Nome_Aplicação: Caracter Saldo: Numérico * Agência: Agência * cl2: Cliente Código: " " Saldo: 100 cl1: Cliente Cod: “Cc2310 Saldo: 50 Agência: Central : Conta :aplicação c1: Conta c2: Conta c3: Conta CurtoPrazo :Aplicação FdoFix Cod: “Cc205" Saldo: 30 Agência: Rio Bco Cod_Conta: Cc2310 Nome_Aplicação: Fix Cod_Conta: 205 Nome_Aplicação: Fdo Diagrama de Objetos

37 Fases do Desenvolvimento
Análise: Modelar os diagramas de interação. Já tendo em mãos as funções primordiais do sistema (diagrama de casos de uso) e o diagrama de classes da análise do domínio do problema, partiremos agora para traçar como estas classes irão interagir para realizar as funções do sistema. Nesta fase nenhum tipo de técnica de implementação deve ser considerada. Para modelar como os objetos do sistema irão interagir entre si, utiliza-se o diagrama de seqüência ou o de colaboração. E modela-se um diagrama para cada função (caso de uso) definida no diagrama de casos de uso. Escolhe-se o diagrama de seqüência para dar mais ênfase à ordem cronológica das interações entre os objetos. Já se faz necessário utilizar idéias básicas da modelagem da interface do sistema como as janelas. Mas esses objetos de interface serão totalmente detalhados na fase de design.

38 Diagrama de Seqüência Um Diagrama de Seqüência mostra interações de objetos organizadas em uma seqüência de tempo e de mensagens trocadas, auxiliando na elaboração dos cenários, implementando a seqüência dos eventos entre os atores e objetos do Sistema.

39 Diagrama de Seqüência :Janela Abrir Conta Corrente
Administração do Banco :Janela Abrir Conta Corrente :Cliente :Conta Corrente :Histórico 1: Dados do Cliente() 2: Localizar (Caracter) 3: Criar (Cliente) 4: Criar (Operação)

40 Fases do Desenvolvimento
Análise: Modelar outros diagramas utilizados na UML para a modelagem dos aspectos dinâmicos do sistema (diagramas de atividades e de estados). Nesta fase, modela-se também o diagrama de estados das classes. Mas este se enquadra em situações onde o comportamento dos objetos é importante para aplicação. Por exemplo, em casos de modelagens de sistemas para equipamentos mecânicos.

41 Diagrama de Estados A idéia básica do Diagrama de Estado, é estudar certos tipos de lógicas que envolvem transições possíveis entre diferentes estados. Um Diagrama de Estados descreve os possíveis estados de uma classe e os eventos que causam transições dos estados. São úteis para mostrar o ciclo de vida de uma classe.

42 Diagrama de Estados Criada Associada a Cliente
Objeto: Conta Corrente Remover conta Criada Fechada fazer: Enviar msg Fechamento Adicionar Conta a Cliente Closed entry: Finalize course Associada a Cliente entrada: Atualizar Cliente saída: Emitir nº Conta

43 Diagrama de Atividades
A principal utilização do Diagrama de Atividades é para modelar fluxos de procedimentos (workflow), onde existe o trabalho cooperativo.

44 Diagrama de Atividades
Cliente Administração do Banco Solicitar abertura conta Abrir conta Associar cliente a conta Movimentar conta [Solicitação_encerramento=Sim] Encerrar conta H

45 Diagramas detalhados no Projeto
Cliente Conta ... * 1 Poupança . . . Conceitos do domínio Modelos da Análise de Requisitos (Domínio do Problema) Diagramas detalhados no Projeto Modelos da Análise :Sistema Processo de Abertura de Conta :Caixa Processo Abertura NovoCliente() Cliente chega Caixa cadastra Gerente cria conta ... Evts sistema Caixa Classes conceituais inspiram nomes de algumas classes no Projeto Entrar dados () ... Diagrama de Casos de Uso Cenário Diagrama de Seqüência do Sistema Realização do Caso de Uso com Diagramas de Interação Modelos do Projeto :Abertura :Rel de Contas CriarNovaConta() AssociarCliente() :ContaCliente entraDados(CPF,tpcta) adicionarDados(CPF,tpcta) . . . Classes descobertas no Projeto podem ser resumidas em Diagrama de Classes Abertura Relação de Contas ... 1 * ... criarNovaCta() ObterEspecificação(...):EspecificaçaoCta entrarDados(...) ... ...

46 Fases do Desenvolvimento
Testes: Nesta fase, a aplicação deverá ser testada. Deve-se verificar se o programa suporta toda a funcionalidade que lhe foi especificada na fase de análise de requisitos com o diagrama de casos de uso. A aplicação também deve ser testada da forma mais informal, colocando-se o sistema nas mãos dos usuários.