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

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] eMail [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

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] eMail [0..1] status

Papéis:

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

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

Agregação: Departamento TODO 1 disciplina Parte

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

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

Exemplo de restrição subconjunto:

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] eMail [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

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

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

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

Atributo derivado Nota

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 eMail [0..1] 0..* 0..* /escolhe 1 Livro isbn 1..* título Associação derivada descrição quantEstoque preço prazoMédioEntrega

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

Restrição

Discriminador

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…”

Controle de pedidos Controle de livros

(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] eMail [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

DIAGRAMA DE ESTADOS DIAGRAMA ESTADO TRANSIÇÃO ENTRE ESTADOS

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

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.

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

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.

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

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

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.

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

III. Eventos

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.

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

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.

ESTADOS HIERÁRQUICOS

ESTADOS DE HISTÓRICO

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

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

Diferença em relação aos estados

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

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

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

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

Exemplo de Diagrama de Seqüência:

Engenharia de Projetos

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

PROJETO DE ARQUITETURA

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

Atividades Estruturacao do sistema Modelagem de controle Decomposicao modular

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

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

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

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

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

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

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)

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]