Conteúdo. 1. Introdução. 2. Levantamento de Requisitos. 3. Análise Orientada a Objetos. 4. Projeto Orientado a Objetos 5. UML. 6.

Documentos relacionados
GRASP: PADRÕES PARA ATRIBUIÇÃO DE RESPONSABILIDADES. SSC 124 Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa

GRASP. Nazareno Andrade (baseado em Hyggo Almeida e Jacques Sauvé)

Padrões de Projeto de Software

INF1013 MODELAGEM DE SOFTWARE

Projeto Orientado a Objetos

[ Arquitecturas Móveis ] 2017/2018

ANÁLISE E PROJETO ORIENTADO A OBJETO (Parte 3)

15/04/2013. Pensar Orientado a Objetos. Projeto Orientado a Objetos. Características de Objetos. Classe de Objetos. Comunicação entre Objetos

PROJETO DE ARQUITETURA

Conteúdo. 1. Introdução. 2. Levantamento de Requisitos. 3. Análise Orientada a Objetos. 4. Projeto Orientado a Objetos 5. UML. 6.

Análise e Projeto de Software Parte II. Marcos Dósea

Modelos de Sistemas Casos de Uso

Rede de computadores Cliente- servidor. Professor Carlos Muniz

Padrões para atribuir responsabilidades: Expert

Alguns Exercícios Resolvidos

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini /

Grupo de Usuários Java do Noroeste Paulista. Tópicos Avançados em Java

Barramento. Prof. Leonardo Barreto Campos 1

Análise e Projeto Orientados por Objetos

Projeto Orientado a Objetos

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos

Diagramas de Classes e O Paradigma da Orientação a Objetos usando UML. Prof. Ricardo A. Ramos

EA975 - Laboratório de Engenharia de Software

Análise e Projeto Orientados a Objetos

Estudo de Caso TPV Projetando uma solução com objetos e Padrões GRASP

15/04/2013. Outro Diagrama de Classes. Primeiro Diagrama de Classes. Diagrama de Classes. Atributos. Eduardo Figueiredo

Análise. Orientada a Objetos Modelo Funcional, Modelo Estrutural e Modelo Comportamental. Linguagens: Java, C++, etc.

Classes de Projeto. Prof. Anderson Cavalcanti UFRN-CT-DCA

Projeto da Camada de Domínio. Diagramas de Colaboração/Comunicação Diagrama de Classes de Projeto (DCP)

INE 5417 Engenharia de Software I

UML Relacionamentos. Relacionamento é uma conexão entre itens A maioria dos itens relacionam-se entre si. Quatro tipos de relacionamentos:

Matéria Introdutória. Banco de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri

Técnicas de Identificação

Campeonato de Gamão. 1. Regras. 2. Servidor

Ferramenta para cálculo de métricas em softwares orientados a objetos codificados em Object Pascal

SEMINÁRIOS INTEGRADOS EM SISTEMAS DE INFORMAÇÃO. Luiz Leão

Zooloretto. Um jogo de Michael Schacht para 2 a 5 jogadores dos 8 anos em diante

Modelo do Mundo Real. Abstração. Interpretação

FUNDAÇÃO UNIVERSIDADE ESTADUAL DE MARINGÁ

UML e seus diagramas

Diagrama de Comunicação. SSC 526 Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa

Universidade Federal de Uberlândia Faculdade de Computação Programação Orientada a Objetos II Prof. Fabiano Dorça. Padrão Observer (Observador)

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos

Análise e Projeto Orientados a Objetos: Visibilidade Diagrama de Classe de Projeto

PROJETO ARQUITETURAL PARTE II: PADRÕES DE PROJETO. Projeto de Programas PPR0001

Classes o Objetos. Classes, objetos, métodos e variáveis de instância

Televisao tamanho tela emitirsom. conectarperifericos

Tabelas Hash. informação, a partir do conhecimento de sua chave. Hashing é uma maneira de organizar dados que:

CEFET/RJ Disciplina: Inteligência Artificial Professor: Eduardo Bezerra Lista de exercícios 02

Modulo II Padrões GRASP

Padrões de Projeto. Factory Method

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 15 PROFª BRUNO CALEGARO

Classes e Objetos. Sintaxe de classe em Java

Introdução a UML (Unified Modeling Language)

Desenvolvimento de Aplicações Desktop

O que é um sistema distribuído?

DIAGRAMA DE COMUNICAÇÃO

Exercícios: Vetores e Matrizes

Interações entre objetos

DIAGRAMAS DE CLASSE UML

Modelagem de Classes. Mestrado em Engenharia de Produção e Sistemas Computacionais. Profa. Adriana Pereira de Medeiros

Introdução à Análise e Projeto de Sistemas

Banco de Dados. Aula 2 - Prof. Bruno Moreno 19/08/2011

Programação Orientada a Objetos

Organização e Arquitetura de Computadores I

Hashing: conceitos. Hashing

Modelagem Orientada a Objetos

Desenvolvimento de Software Baseado em Componentes. Paulo C. Masiero

UML (Unified Modelling Language)

BANCO DE DADOS I. Prof. Luiz Antônio Vivacqua C. Meyer

ANÁLISE E PROJETO ORIENTADO A OBJETO

Modelagem de Sistemas Web. Modelagem de BD

DCC004 - Algoritmos e Estruturas de Dados II

Notas de Aula 03: Introdução a Orientação a Objetos e a UML

1) Defina os principais conceitos de orientação a objetos. 4) Porque é desejável programar com foco em interfaces?

Engenharia de Requisitos

Introdução ao POO (Projeto Orientado a Objetos)

(Engenharia de) Requisitos. Cheesman Cp 4

Conceitos de Programação Orientada por Objectos. Rui Camacho Programação 2

Introdução. descrever os tipos de interfaces e linguagens oferecidas por um SGBD. mostrar o ambiente de programas dos SGBD s

Conceitos de Programação Orientada a Objetos

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA UML UNIFIED MODELING LANGUAGE

Modelagem de Dados MODELAGEM DE DADOS. Sistemas de Banco de Dados. Profa. Rosemary Melo

Análise e Projeto Orientados a Objetos. Casos de Uso

Identificação de Componentes

Contratos O diagrama de sequência não menciona a funcionalidade das operações. Isto é, o comportamento do sistema Contrato é um documento que

Resumo de TCC: MAGIC: Um framework para jogos de cartas. Ademir Coelho

RUP Unified Process. Profª Jocelma Rios

Modelagem de dados usando o modelo Entidade- Relacionamento (ER)

Domínios, grau de dependência e coesão. Unipampa Bagé/RS Engenharia de Computação Disciplina de Engenharia de Software

Paradigma Simbólico. Sistemas de Informação UNISUL Aran Bey Tcholakian Morales, Dr. Eng. (Apostila 2)

23/05/12. Consulta distribuída. Consulta distribuída. Objetivos do processamento de consultas distribuídas

Modelagem de Sistemas. Análise de Requisitos. Modelagem

Processos ca 3 pítulo

Aula 4 Encapsulamento e Relacionamento Cleverton Hentz

M V C P R O F. M E. H É L I O E S P E R I D I Ã O

PDS. Aula 1.9 SCRUM. Prof. Dr. Bruno Moreno

Lista de Exercícios de Programação Orientada a Objetos

Análise de Sistemas. Aula 5

Transcrição:

Conteúdo 1. Introdução 2. Levantamento de Requisitos 3. Análise Orientada a Objetos 4. Projeto Orientado a Objetos 5. UML 6. Métodos Ágeis

Projeto Orientado a Objetos Definição das Operações

Responsabilidade x Operação Responsabilidades de um objeto: são as suas obrigações em torno do seu comportamento (responsabilidades de fazer e responsabilidades de conhecer). Responsabilidades são implementadas usando operações que agem sozinhas ou colaboram com outras operações e objetos. As responsabilidades são atribuídas às classes de objetos durante o projeto de objetos: responsabilidades de fazer: fazer um cálculo, criar um objeto, inicializar uma ação em outros objetos, controlar atividades em outros objetos... responsabilidades de conhecer: dados privados, dados que precisam ser calculados, objetos relacionados... A definição das operações é uma parte crítica do desenvolvimento OO.

Definição das Operações As operações são definidas durante a realização dos casos de uso. Realização de um caso de uso: descreve como um caso de uso é realizado dentro do modelo de projeto, em termos dos objetos que colaboram. utilizam diagramas de interação :Registrador :Compra fazpagamento(dinheiro) create(dinheiro) :Pagamento autoriza

Definição das Operações Durante a definição das operações são considerados: Padrão de Projeto Criador Padrão de Projeto Especialista da Informação Princípio de Baixo Acoplamento Princípio de Alta Coesão Padrão de Projeto Controlador Outros Padrões de Projeto

Criador Durante a definição das operações são considerados: Padrão de Projeto Criador Padrão de Projeto Especialista da Informação Princípio de Baixo Acoplamento Princípio de Alta Coesão Padrão de Projeto Controlador Outros Padrões de Projeto

Criador Criador: Atribuir à classe A a responsabilidade de criar uma instância da classe B se: A contém ou agrega instâncias de B; ou A usa instâncias de B; ou A tem os dados de inicialização que serão para passados para B quando ele é criado.

Criador Exemplo - Ponto de Venda: Quem deverá ser o responsável pela criação de uma instância de ItemLinha? Compra data horario Modelo Conceitual 1 contem 1..* ItemLinha quantidade * descrito-por 1 EspecificacaoProdu descricao preco IDItem

Criador Exemplo - Ponto de Venda: Quem deverá ser o responsável pela criação de uma instância de ItemLinha? Como a classe Compra contém vários objetos do tipo ItemLinha, ela pode ser a responsável. :Registrador :Compra fazeritemlinha(qtidade) create(qtidade) :ItemLinha

Criador Exemplo - Banco Imobiliário: Quem deverá ser o responsável pela criação de uma instância de Casa (Square) do Banco Imobiliário? Modelo Conceitual

Criador Exemplo - Banco Imobiliário: Quem deverá ser o responsável pela criação de uma instância de Casa (Square) do Banco Imobiliário? Como a classe Tabuleiro contém vários objetos do tipo Casa, ela pode ser a responsável.

Especialista da Informação Durante a definição das operações são considerados: Padrão de Projeto Criador Padrão de Projeto Especialista da Informação Princípio de Baixo Acoplamento Princípio de Alta Coesão Padrão de Projeto Controlador Outros Padrões de Projeto

Especialista da Informação Especialista da Informação: Atribuir uma responsabilidade ao especialista da informação, ou seja, à classe que tem a informação necessária para cumprí-la.

Especialista da Informação Exemplo - Ponto de Venda: Quem deverá ser o responsável por saber o total de uma compra? Compra data horario Modelo Conceitual 1 contem 1..* ItemLinha quantidade * descrito-por 1 EspecificacaoProdu descricao preco IDItem

Exemplo - Ponto de Venda: Especialista da Informação Quem deverá ser o responsável por saber o total de uma compra? Para determinar o total da compra é necessário conhecer todas as instâncias de ItemLinha de uma compra e a soma de seus sub-totais. Como a classe Compra conhece todas as instâncias de ItemLinha, ela pode ser responsável por conhecer o total da compra. Como a classe ItemLinha conhece a quantidade dos itens e está associada com a especificação do produto, que possui o preço de cada item, ela pode ser responsável por determinar o sub-total de um item de linha.

Especialista da Informação Exemplo - Ponto de Venda: Compra 2: tot:=gettotal :Compra 1: * sub:=getsubtotal itenslinha[i]: :ItemLinha ItemLinha data horario gettotal 1.1: p:=getpreco :EspecificacaoProduto ItemLinha quantidade getsubtota EspecificacaoProdu descricao preco IDItem getpreco

Especialista da Informação Exemplo - Banco Imobiliário: Quem deverá ser o responsável por retornar uma casa (square), a partir de uma chave? Como o Tabuleiro agregará todos os objetos casas (squares), ele pode ser a classe responsável por retornar uma casa.

Especialista da Informação Vantagens: O encapsulamento das informações é mantido, pois os objetos usam suas próprias informações para cumprir as tarefas. O comportamento é distribuído através das classes que têm as informações necessárias.

Baixo Acoplamento Durante a definição das operações são considerados: Padrão de Projeto Criador Padrão de Projeto Especialista da Informação Princípio de Baixo Acoplamento Princípio de Alta Coesão Padrão de Projeto Controlador Outros Padrões de Projeto

Baixo Acoplamento Acoplamento é uma medida da intensidade na qual um elemento (classe, subsistema, sistema, etc) está conectado a, depende de ou tem conhecimento a respeito de outros elementos. Formas comuns de acoplamento em linguagens OO: Classe X tem um atributo que referencia uma instância da classe Y. Classe X tem um método que referencia uma instância da classe Y. Classe X é uma subclasse direta ou indireta da classe Y. Y é uma interface e classe X implementa esta interface. Um elemento com baixo acoplamento não é dependente de muitos outros elementos.

Exemplo - Ponto de Venda: Baixo Acoplamento fazpagamento :Registrador :Pagamento buscainfo :Compra Suponha que a compra precise conhecer o pagamento para buscar algumas informações dele, ou seja, é necessário associá-la à instância de Pagamento. Suponha que o registrador é o responsável em fazer um pagamento e adicioná-lo à compra. Suponha que é necessário criar uma instância de Pagamento. Qual classe deverá ser a responsável pela criação de um pagamento?

Baixo Acoplamento Exemplo - Ponto de Venda: Opção 1: ct1 3: fazpagamento :Registrador 1: create p:pagamento buscainfo 2: adicionapagamento(p) :Compra Adiciona acoplamento de Registrador ao Pagamento e de Registrador à Compra.

Baixo Acoplamento Exemplo - Ponto de Venda: Opção 2: ect1 2: fazpagamento :Registrador :Pagamento buscainfo 1: adicionapagamento(p) :Compra 1.1: create Adiciona acoplamento de Registrador à Compra.

Baixo Acoplamento Exemplo - Banco Imobiliário: Por que não associar getsquare a Dog (ou a uma outra classe qualquer)? Porque tanto Dog como Tabuleiro (Board) devem conhecer os objetos Casa (Square) Dois objetos com acoplamento com Casa

Exemplo - Banco Imobiliário: Baixo Acoplamento Como Tabuleiro (Board) já conhece os objetos Casa (Square), se getsquare for associado a Tabuleiro, somente um objeto terá acoplamento à Casa.

Acoplamento Problemas das classes com alto acoplamento: Mudanças nas classes relacionadas podem gerar mudanças locais. São mais difíceis de serem entendidas isoladamente. São mais difíceis de serem reusadas pois o uso requer a presença adicional das classes das quais ela depende.

Baixo Acoplamento Use o Princípio de Baixo Acoplamento para avaliar alternativas de projeto. Se todo o resto está igual, prefira a solução com baixo acoplamento.

Alta Coesão Durante a definição das operações são considerados: Padrão de Projeto Criador Padrão de Projeto Especialista da Informação Princípio de Baixo Acoplamento Princípio de Alta Coesão Padrão de Projeto Controlador Outros Padrões de Projeto

Alta Coesão Coesão é uma medida da intensidade na qual as responsabilidades de um elemento (classe, subsistema, sistema, etc) estão relacionadas. Um elemento com responsabilidades altamente relacionadas e que não tem uma quantidade extremamente grande de trabalho, tem alta coesão.

Exemplo - Ponto de Venda: Alta Coesão fazpagamento :Registrador :Pagamento buscainfo :Compra Suponha que o Registrador será responsável por várias operações do sistema e que é necessário criar uma instância de Pagamento e associá-la a uma instância de Compra. Qual projeto suporta alta coesão?

Alta Coesão Exemplo - Ponto de Venda: Opção 1: t1 3: fazpagamento :Registrador 1: create p:pagamento 2: adicionapagamento(p) :Compra Supondo que o Registrador será responsável por várias outras operações do sistema, ele ficará sobrecarregado de tarefas.

Alta Coesão Exemplo - Ponto de Venda: Opção 2: ect1 2: fazpagamento :Registrador :Pagamento 1: adicionapagamento(p) :Compra 1.1: create Delega a responsabilidade da criação do Pagamento para a Compra, dando suporte a uma coesão mais alta no Registrador.

Exemplo - Banco Imobiliário: Alta Coesão Esquerda: PIOR - o próprio objeto BancoImobiliario (MonopolyGame) faz todo o trabalho Direita: MELHOR - o objeto BancoImobiliario (MonopolyGame) delega e distribui o trabalho entre outros objetos.

Coesão Problemas das classes com baixa coesão (classes que fazem muitas coisas não relacionadas ou fazem trabalhos demais): difícil de compreender; difícil de usar; difícil de manter; constantemente afetada por mudanças.

Alta Coesão Use o Princípio de Alta Coesão para avaliar alternativas de projeto. Se todo o resto está igual, prefira a solução com alta coesão.

Controlador Durante a definição das operações são considerados: Padrão de Projeto Criador Padrão de Projeto Especialista da Informação Princípio de Baixo Acoplamento Princípio de Alta Coesão Padrão de Projeto Controlador Outros Padrões de Projeto

Controlador / Fachada Controlador: Classe responsável pelo recebimento e manipulação de um evento do sistema (eventos gerados por atores externos). Ou seja, classe atrás da camada de interface com o usuário que deverá receber a mensagem da camada de interface com o usuário. Não é uma classe de interface com o usuário. objetos de interface com o usuário não devem conter lógica da aplicação ou negócio. Classe que representa o sistema como um todo ou um subsistema (Fachada). Classe que representa um manipulador de todos os eventos do sistema dentro de um caso de uso. Normalmente, o controlador deve delegar aos outros objetos o trabalho que precisa ser feito, coordenando e controlando este trabalho.

Exemplo - Ponto de Venda: Controlador? Sistema finalizacompra entraitem faznovacompr fazpagamento Quem deverá ser o controlador dos eventos do sistema, como entraitem e finalizacompra?

Exemplo - Ponto de Venda: Controlador Quem deverá ser o controlador dos eventos do sistema, como entraitem e finalizacompra? classe que representa o sistema como um todo ou um subsistema: Registrador classe que representa um manipulador de todos os eventos do sistema dentro de um caso de uso: ManipuladorProcessoCompra

Exemplo - Banco Imobiliário: Controlador Como conectar a camada de interface com o usuário com a camada de domínio? Qual objeto deverá receber a mensagem playgame da camada de interface com o usuário?

Exemplo - Banco Imobiliário: Controlador Como existem poucas operações do sistema, podemos definir uma classe que representa todo o sistema, BancoImobiliario (MonopolyGame).

Controlador Exemplo: Os objetos de interface não devem ter a responsabilidade de manipular os eventos do sistema. Interface com o Usuário Camada de Interface :FrameCompra 1:entrarItem (IDItem, qtidade) 1:fazerItemDeLinha (IDItem, qtidade) Camada de Domínio :Registrador :Compra 1.1:fazerItemDeLinha (IDItem, qtidade)

Exemplos de Definição das Operações do Ponto de Venda

Exemplos de Definição de Operações Exemplo - Ponto de Venda: caso de uso Processar Venda Fluxo Básico: 1. O cliente chega no caixa com os produtos e/ou serviços para comprar. 2. O caixa inicia uma nova venda. 3. O caixa entra com o identificador do item. 4. O sistema registra o item e apresenta a sua descrição, preço e o subtotal. O preço calculado é oriundo de um conjunto de regras de preço. O caixa repete os passos 3 e 4 até indicar que terminou. 5. O sistema apresenta o total com as taxas calculadas. 6. O caixa diz ao cliente o total e pergunta ao cliente a forma de pagamento. 7. O cliente paga e o sistema processa o pagamento. 8. O sistema registra que a venda foi completada e manda a informação da compra e do pagamento para o sistema externo de contabilidade (para a contabilidade e comissão) e para o sistema de estoque.

Exemplos de Definição de Operações :Caixa :Sistema faznovacompra entraitem (ident, quantidade) descrição, total * [mais itens] finalizacompra total fazpagamento (valor) troco, recibo

Exemplos de Definição de Operações Exemplo 1: faznovacompra Exemplo 2: entraitem Exemplo 3: finalizacompra Exemplo 4: Start Up

Definição da Operação faznovacompra Compra data horario Modelo Conceitual 1 contem 1..* ItemLinha quantidade * descrito-por 1 EspecificacaoProdu descricao preco IDItem

Definição da Operação faznovacompra :Caixa :Sistema faznovacompra entraitem (ident, quantidade) descrição, total * [mais itens] finalizacompra total fazpagamento (valor) troco, recibo

Definição da Operação faznovacompra Registrador escolhido como controlador porque existem poucas operações do sistema. Registrador pode ser visto como aquele que cria a Compra. Quando uma compra é criada, ela deve criar uma coleção vazia para registrar todas as instâncias de ItemLinha que serão adicionadas. Object1 :Registrador faznovacompra create :Compra create :ItemLinha itens : List<ItemLinha>

Definição da Operação entraitem :Caixa :Sistema faznovacompra entraitem (ident, quantidade) descrição, total * [mais itens] finalizacompra total fazpagamento (valor) troco, recibo

Definição da Operação entraitem Registrador continua como controlador. Compra cria um item de linha porque ela contém itens de linha. O item de linha criado pode ser armazenado na coleção de itens de linha. A criação de um item de linha precisa da quantidade (parâmetro fornecido na operação) e da especificação do produto. Registrador envia mensagem para o CatalogoProduto para buscar a especificação do produto, pois ele conhece as especificações dos produtos.

Definição da Operação entraitem ect1 3: entraitem(id, qtidade) :Registrador 2: fazitemlinha(espec, qtidade) :Compra 1: espec:=pegaespecificacao(id) :CatalogoProduto 2.1: create(espec, qtidade) 2.2: adiciona(it) it:itemlinha 1.1: espec:=procura(id) :EspecificacaoProduto : Map<Especificacao Produto> :ItemLinha itens : List<ItemLinha>

Definição da Operação finalizacompra :Caixa :Sistema faznovacompra entraitem (ident, quantidade) descrição, total * [mais itens] finalizacompra total fazpagamento (valor) troco, recibo

Definição da Operação finalizacompra Registrador continua como controlador. Compra calcula o valor total da compra porque conhece todos os itens de linha. Item Linha calcula o valor do sub-total do item de linha na compra porque conhece a quantidade de itens comprados. A Especificação do Produto retorna o preço de um produto (item de linha). 2: finalizacompra :Registrador 1: tot:=gettotal :Compra 1.1: *sub:=getsubtotal :ItemLinha itens [i]: ItemLinha 1.1.1: p:=getpreco :EspecificacaoProduto

Definição da Operação inicializar Exemplo 4: inicialização do sistema (Start Up) O diagrama de interação da operação de inicialização da aplicação é definido após todas as operações do sistema terem sido projetadas. São criados os objetos iniciais da aplicação. O objeto inicial é uma classe na raiz da hierarquia de agregação dos objetos do domínio (ou perto dela): um controlador ou um objeto que contém a maioria dos outros objetos. Se a aplicação tem interface gráfica, geralmente, o objeto inicial não controla o processo.

Exemplo de Definição de Operações Object 3: create :Loja 2: create(cat) :Registrado 1: create cat:catalogoprod 1.1: create 1.2.2:*[] adiciona(espec) :EspecificacaoProd : Map<Especificacao Produto> 1.2: carregaespecificacoes espec:especificacaoprod 1.2.1:*[] create(id,preco,descricao)

Exemplo de Definição de Operações Conexão da Camada de Interface com o Usuário e da Camada de Domínio A camada de interface com o usuário não deverá ter qualquer responsabilidade lógica do domínio. A camada de interface com o usuário deverá ser responsável somente pelas tarefas de interface com o usuário, como a atualização dos widgets. A camada de interface com o usuário deverá reenviar todas as requisições sobre as tarefas do domínio para a camada de domínio.

Exemplos de Definição das Operações do Banco Imobiliário

Exemplo do Banco Imobiliário Resultado do Modelo Conceitual será usado como inspiração para o projeto da camada de domínio do Modelo de Projeto

Definição da Operação Jogar Exemplo 1: Como projetar a operação de sistema jogar (playgame)? 1. Escolher o controlador: JogoBancoImobiliario satisfaz porque existem poucas operações do sistema e o controlador não tem muitas responsabiliades. 2. Escolher o responsável pelo algoritmo Game-Loop. for N rounds for each Player p p takes a turn round (rodada): todos os jogadores fazem uma jogada turn (jogada): um jogador rola os dados e move a peça

Definição do Algoritmo Game-Loop 2a. Quem será o responsável pelo algoritmo Game-Loop? É necessário conhecer o contador da rodada atual: nenhum objeto tem esta informação, mas, para ficar mais proximo da realidade, o BancoImobiliario poderia ter É necessário conhecer todos os jogadores: baseando-se no modelo de domínio, o BancoImobiliario é um bom candidato BancoImobiliario irá controlar o loop do jogo e coordenar as jogadas de cada rodada.

Definição do Algoritmo Game-Loop B. Quem será o responsável pela jogada (turn). É necessário conhecer a localização atual do jogador baseando-se no modelo de domínio, uma Peça conhece a sua Casa e um Jogador conhece a sua Peça. Portanto, um objeto Jogador poderia conhecer sua localização. É necessário conhecer os dois objetos Dados baseando-se no modelo de domínio, o BancoImobiliario é um bom candidato porque os dados podem ser vistos como parte do jogo. É necessário conhecer todas as casas (para mover para a nova casa) para ficar mais proximo da realidade, o Tabuleiro é um bom candidado

Definição do Algoritmo Game-Loop Qual classe escolher, Jogador, BancoImobiliario ou Tabuleiro? Guideline: Quando existem vários especialistas da informação, colocar a responsabilidade no objeto que tem a maioria das informações. nenhuma classe tem a maioria das informações Guideline: Quando existem alternativas de projeto, considerar o acoplamento e coesão. BancoImobiliario já possui responsabilidades, o que pode diminuir sua coesão, principalmente em relação a Jogador e Tabuleiro, que não possuem nenhuma responsabilidade

Definição do Algoritmo Game-Loop Qual classe escolher, Jogador, BancoImobiliario ou Tabuleiro? Guideline: Considerar uma evolução futura dos objetos de software. Mais tarde, executar uma jogada pode envolver a compra de uma propriedade, se o jogador tem dinheiro suficiente, ou se a cor da propriedade encaixa com a estratégia do Jogador. Qual o objeto indicado para saber do dinheiro do Jogador? O Jogador. Qual o objeto indicado para saber da cor do Jogador? O Jogador.

Definição do Algoritmo Game-Loop Jogador é um bom candidato, considerando as regras completas do jogo.

Definição do Algoritmo Game-Loop C. Execução de uma jogada (take a turn) Executar uma jogada significa: 1. Calcular um número random entre 2 e 12 (soma dos 2 dados) 2. Calcular a localização da nova casa 3. Mover a peça do jogador da casa antiga para a nova casa Estes passos serão coordenados pelo Jogador, já que ele é o responsável por executar uma jogada.

Definição do Algoritmo Game-Loop 1. Calcular um número random entre 2 e 12 (soma dos 2 dados) para ficar mais proximo da realidade, criamos um objeto Dado com um atributo valorface. Calcular um novo valor da face random envolve mudar a informação no Dado e, pelo Especialista da Informação, o objeto Dado deveria ser capaz de rolar ele mesmo.

Definição do Algoritmo Game-Loop 2. Calcular a localização da nova casa para ficar mais proximo da realidade, é razoável que o Tabuleiro conheça suas Casas. Assim, pelo Especialista da Informação, um Tabuleiro será o responsável por conhecer uma casa nova, dado uma casa antiga e o valor dos dados.

Definição do Algoritmo Game-Loop 3. Mover a peça do jogador da casa antiga para a nova casa para ficar mais proximo da realidade, é razoável para um Jogador conhecer a sua Peça, e uma Peça conhecer sua Casa. Assim, pelo Especialista da Informação, uma Peça atribuirá sua nova localização, mas ela pode receber a nova localização do seu proprietário, o Jogador.

Exemplo do Banco Imobiliário

Definição da Operação Inicializar Definição da Operação do Sistema inicializar do caso de uso StartUp É necessário escolher o objeto raiz que criará alguns objetos BancoImobiliario é um bom candidato

ERROR: stackunderflow OFFENDING COMMAND: ~ STACK: