PERSPECTIVA CONCEITUAL

Apresentação em tema: "PERSPECTIVA CONCEITUAL"— Transcrição da apresentação:

1 PERSPECTIVA CONCEITUAL
DIAGRAMA DE CLASSES PERSPECTIVA CONCEITUAL 1ª PARTE DIAGRAMA CLASSE, ATRIBUTO E OPERAÇÃO ASSOCIAÇÃO CLASSE ASSOCIATIVA AGREGAÇÃO E COMPOSIÇÃO RESTRIÇÕES ELABORANDO O DIAGRAMA

2

3

4

5

6

7 Diagrama de Classes (com perspectiva conceitual)
Cliente Pedido código numPedido CPF dataEmissão nome nomePresenteado [0..1] endereço 1 1 faz -> 1..* 1..* endereçoEntrega telefone [0..1] dataCancelamento [0..1] [0..1] status 1 1 Fatura 0..* 0..* 1..* 1..* numFatura dataEmissão Item pedido dataVencimento valorPago [0..1] quantidadePedida dataPagamento [0..1] 0..* 0..* 1..* 1..* preçoCobrado dataPedidoCancelamento [0..1] dataCancelamento [0..1] status 0..* 0..* 1 1 Item faturado quantFaturada Livro isbn { Se uma fatura atende a um título pedido, necessariamente os itens descrição pedidos ligados à fatura devem ser quantEstoque do pedido ao qual a fatura está preço relacionada } prazoMédioEntrega

8

9

10

11

12

13 Cliente Pedido código numPedido CPF dataEmissão nome nomePresenteado [0..1] endereço faz -> 1 1..* endereçoEntrega telefone [0..1] dataCancelamento [0..1] [0..1] status

14

15

16

17 Papéis:

18

19 quantFaturada ?? Fatura numFatura dataEmissão Item pedido
dataVencimento valorPago [0..1] quantidadePedida dataPagamento [0..1] preçoCobrado 0..* 1..* dataPedidoCancelamento[0..1] dataCancelamento [0..1] status

20 Classe associativa Fatura numFatura dataEmissão Item pedido
dataVencimento valorPago [0..1] quantidadePedida dataPagamento [0..1] preçoCobrado 0..* 0..* 1..* 1..* dataPedidoCancelamento [0..1] dataCancelamento [0..1] status Item faturado Classe associativa quantFaturada

21

22

23

24

25 Agregação: Departamento TODO 1 disciplina Parte

26 Composição: Pedido numPedido dataEmissão nomePresenteado [0..1]
endereçoEntrega dataCancelamento [0..1] status 1..* Item pedido quantidadePedida preçoCobrado

27

28 Exemplo de restrição ou:
Produto Venda id id descrição forma pagamento preço custo data preço venda 0..1 0..1 comissão 1..* 1..* 0..* 0..* {ou} Serviço Item id quant descrição 0..* 0..* 0..1 0..1 preço

29 Exemplo de restrição subconjunto:

30 Exemplo de restrição relacionada a associações:
Cliente Pedido código numPedido CPF dataEmissão nome nomePresenteado [0..1] endereço faz -> 1 1 1..* 1..* endereçoEntrega telefone [0..1] dataCancelamento [0..1] [0..1] status 1 1 Fatura 0..* 0..* 1..* 1..* numFatura dataEmissão Item pedido dataVencimento valorPago [0..1] quantidadePedida dataPagamento [0..1] 0..* 0..* 1..* 1..* preçoCobrado dataPedidoCancelamento [0..1] dataCancelamento [0..1] status 0..* 0..* 1 1 Item faturado quantFaturada Livro isbn { Se uma fatura atende a um título pedido, necessariamente os itens descrição pedidos ligados à fatura devem ser quantEstoque do pedido ao qual a fatura está preço relacionada } prazoMédioEntrega

31 PERSPECTIVA CONCEITUAL
DIAGRAMA DE CLASSES PERSPECTIVA CONCEITUAL 2ª PARTE DICAS DEPENDÊNCIAS AVANÇADO AGREGAÇÃO ATRIBUTOS E ASSOCIAÇÕES DERIVADAS ASSOCIAÇÃO TERNÁRIA GENERALIZAÇÃO ORGANIZAÇÃO DAS CLASSES EM PACOTES ELABORANDO O DIAGRAMA ERROS COMUNS

32 DICAS Foco: aspecto estático do sistema
Não prejudicar a leitura com minimalismos Generalizações: evitar mais do que 5 níveis Nome para cada diagrama Evitar linhas cruzadas Elementos semânticos semelhantes próximos fisicamente Pode-se usar notações visuais que chamem a atenção É possível usar mais que um relacionamento, mas tentar evitar

33 DEPENDÊNCIAS AVANÇADO
Tipos Definidos pela UML Bind: origem instancia o destino Derive: Origem computada através do destino (ex. Idade -> Data de Nascimento) Friend: Origem recebe visibilidade especial no destino InstanceOf Instantiate Powertype Refine Use

34

35 Atributo derivado Nota

36 Associação derivada Pedido numPedido dataEmissão
nomePresenteado [0..1] endereçoEntrega dataCancelamento [0..1] 1..* status <- faz Cliente 1 1..* código CPF Item pedido nome quantidadePedida endereço preçoCobrado telefone [0..1] / quantAtendida [0..1] 0..* 0..* /escolhe 1 Livro isbn 1..* título Associação derivada descrição quantEstoque preço prazoMédioEntrega

37

38

39

40

41

42

43

44 Pagamento Consulta data prevista data hora data pagamento sintomas valor cobrado diagnóstico 1 1 1 1 valor pago medicamentos Convênio Pagamento Particular Pagamento por Convênio 0..* 0..* 1 1 nome tipo número associado telefone número cheque data cobrança número banco

45

46 Restrição

47

48 Discriminador

49

50 Exercicio: Modele os Relacionamentos
Usar classes e associações para definir o glossário do sistema “Jogo de Futebol” descrito de seguida: “O jogo de futebol é realizado por duas equipes de jogadores. Cada equipe é composta por 11 jogadores, com diferentes funções: o goleiro, zagueiros, médios, atacantes, e pontas de lança. O ponta de lança é um atacante especial por ter especiais características de goleador... O jogo é realizado num campo com medidas regulamentares (em comprimento e largura), tem duas balizas, cada qual em extremos opostos do campo. Ganha o jogo a equipe que marcar mais gols (i.e., colocar a bola) na baliza do adversário. No jogo apenas existe uma única bola, que apresenta características (peso, diâmetro, …) regulamentares... O jogo de futebol é mediado por uma equipe de 3 árbitros, em que um é o árbitro principal, e os outros dois são árbitros auxiliares…”

51

52 Controle de pedidos Controle de livros

53

54 (from Controle de Livros)
Cliente Pedido código numPedido CPF dataEmissão nome nomePresenteado [0..1] endereço 1 1 faz -> 1..* 1..* endereçoEntrega telefone [0..1] dataCancelamento [0..1] [0..1] status 1 1 Fatura 0..* 0..* 1..* 1..* numFatura dataEmissão Item pedido dataVencimento valorPago [0..1] quantidadePedida dataPagamento [0..1] 0..* 0..* 1..* 1..* preçoCobrado dataPedidoCancelamento [0..1] dataCancelamento [0..1] Nome do package status 0..* 0..* 1 1 Item faturado Livro (from Controle de Livros) quantFaturada isbn { Se uma fatura atende a um título pedido, necessariamente os itens descrição pedidos ligados à fatura devem ser quantEstoque do pedido ao qual a fatura está preço relacionada } prazoMédioEntrega

55

56

57

58

59 DIAGRAMA DE ESTADOS DIAGRAMA ESTADO TRANSIÇÃO ENTRE ESTADOS

60 I. DIAGRAMA DE ESTADOS Um diagrama de estados é uma das formas de se visualizar uma máquina de estados Máquinas de Estado permitem a modelagem de aspectos dinâmicos de um sistema Máquinas de estado também podem ser vistas através de Diagramas de Atividades Diagrama de Estados enfatizam os estados dos objetos e as transições entre estes estados enquanto o Diagrama de Atividades enfatiza o fluxo de controle de uma atividade para outra

61 Em um Diagrama de Estado são descritos os estados de um objeto ao longo de sua vida.
A modelagem dos estados de um objeto descreve a ordem que o objeto pode responder a eventos, desde a sua criação até a sua destruição. Há muitas possibilidades de se utilizar um Diagrama de Estados. Na etapa de Análise, por exemplo, ele pode ser útil para observarmos a mudança de estados ao longo de toda a vida do objeto a partir dos eventos e dos casos de uso que foram descritos. Exemplo: Diagrama de Estados representando um objeto Pedido.

62 Cliente faz pedido Cliente solicita cancelamento de pedido Funcionário fatura pedido Pedido criado Pedido cancelado [ foram enviados todos os livros ] Funcionário fatura pedido[ não foram enviados todos os livros ] Gerente avalia cancelamento de fatura [ canceladas todas as faturas ] Funcionário fatura pedido [ não foram enviados todos os livros ] Pedido parcialmente atendido Cliente solicita cancelamento de fatura Gerente avalia Funcionário fatura pedido cancelamento de fatura [ foram enviados todos os livros ] [ há faturas a serem Gerente avalia avaliadas ] cancelamento de fatura Pedido com solicitação de cancelamento de fatura [ há livros a enviar ] Cliente solicita cancelamento de fatura Pedido totalmente atendido Gerente avalia cancelamento de fatura [ foram enviados todos os livros e há fatura não paga ] Cliente paga fatura[ todas as faturas foram pagas ] Gerente avalia cancelamento de fatura[ o cancelamento é aprovado, foram enviados todos os livros e já tinham sido pagas as demais faturas ] Pedido fechado

63 II. ESTADO Estado: representa uma situação na vida de um objeto durante a qual o objeto satisfaz alguma condição, realiza alguma atividade ou aguarda um evento. Exemplo: Pedido criado Este estado corresponde a uma situação em que o pedido foi feito por um cliente mas ainda não foi atendido.

64 Estado inicial e final: são dois estados especiais
Estado inicial: indica o local de início da máquina de estado Estado final: indica que a execução da máquina de estado foi concluída

65 Partes que compõem um estado:
Nome Ações de Entrada e Saída Transições Internas Subestados Eventos Adiados

66 Estado: representa uma situação na vida de um objeto durante a qual o objeto satisfaz alguma condição, realiza alguma atividade ou aguarda um evento. Exemplo: Pedido criado Este estado corresponde a uma situação em que o pedido foi feito por um cliente mas ainda não foi atendido.

67 III. Eventos Tipos de Eventos: Externos: sistema e atores
Internos: objetos no interior do sistema

68 III. Eventos

69 IV. TRANSIÇÃO É um relacionamento entre dois estados, indicando que um objeto passará de um estado origem ao estado destino quando um certo evento ocorrer e as condições especificadas forem satisfeitas.

70 Componentes da transição:
Estado de origem: é o estado atingido pela transição. Estado de destino: é o estado que estará ativo após a conclusão da transição. Evento de ativação: é a ocorrência de um estímulo capaz de ativar uma transição de estado. Estado de origem Evento de ativação Estado de destino

71 Condição de proteção: é representada por uma expressão booleana entre colchetes, colocada depois do evento, que é avaliada quando a transição é iniciada. Se a expressão for avaliada como falsa a transição não será iniciada.

72

73

74 ESTADOS HIERÁRQUICOS

75 ESTADOS DE HISTÓRICO

76 Exemplo Fuga Persegue Espera Ataque Atacado Morre Vida < 30%
Dist (player) < 10m Dist (player) < 4m Dist (player) > 10m Vida < 30% Fuga Persegue Dist (player) > 4m Vida < 30% Levou tiro Espera Ataque Levou tiro Atacado Vida <= 0 Morre

77 DIAGRAMA DE ATIVIDADES
ATIVIDADE, TRANSIÇÃO, PONTO DE DECISÃO, BARRA DE SINCRONIZAÇÃO E RAIAS (SWIMLANE)

78

79

80

81

82

83 Diferença em relação aos estados

84

85 - Podem haver pontos de decisão encadeados?
- Podem ocorrer loops

86

87 Diferença dos pontos de decisão e barra de sincronização?

88

89

90 DIAGRAMA DE SEQÜÊNCIA DIAGRAMA DE SEQÜÊNCIA
NOTAÇÕES DO DIAGRAMA DE SEQÜÊNCIA DIAGRAMA DE SEQÜÊNCIA COM PERSPECTIVA CONCEITUAL

91 Diagrama de colaboração: ênfase a organização estrutural dos objetos que enviam e recebem mensagens

92 Exemplo de Diagrama de Seqüência:

93

94

95

96

97

98

99

100 Engenharia de Projetos

101 Documentos de especificacao de Projetos
- Projeto Arquitetural - Projeto de Interface - Projeto de dados - Projeto de componentes - Projeto de implantacao

102 PROJETO DE ARQUITETURA

103 Quatro passos elementares
-Representação do contexto -Abstrações de mais alto nível através de arquétipos -Componentes identificados e representados no contexto de arquitetura - Instanciações especificas de arquitetura

104 Atividades Estruturacao do sistema Modelagem de controle
Decomposicao modular

105 ESTRUTURACAO DO SISTEMA (divisao em subsistemas)
DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES

106 Tipos Arquitetura centrada em dados (grande fluxo de dados entre subsistemas) Arquitetura Cliente / Servidor (componentes: cliente, servidor, redes) Arquitetura em camadas ou Maquinas Abstratas Arquitetura de chamada e retorno Arquitetura orientada a objetos Depósito de dados Subsistema 1 Subsistema 2 Subsistema 3

107 Padroes Arquiteturais
Concorrencia Persistencia (dados subsistem depois de criados) Distribuicao (ex.: uso de broker - intermediario, CORBA)

108 Diagrama Arquitetural de Contexto
Subordinadores Subordinados Sistema no nivel de pares Atores

109 Modelagem de Controle Controle centralizado: um subsistema possui responsabilidade geral (ex. Main() ) Controle baseado em eventos: resposta a eventos externos

110 Decomposicao em Modulos
Modelo orientado a objetos Modelo de fluxo de dados (ex. Unix: duto e filtro) Filtro

111 Arquétipos Classe ou Padrão que representa uma abstração central critica para o projeto de arquitetura para sistema alvo. (classes abstratas, blocos construtivos, modelagem abstrata parcial)

112 Exercício Desenvolva para o projeto de um simulador de submarinos da PETROBRAS os seguintes projetos de arquitetura: - Diagrama de Classes -Tipos de Arquitetura a serem usados - Padrões de Arquitetura em relação a Concorrência, Persistência e Distribuição [descreva na forma de requisitos de sistema]