Padrões para Atribuições de Responsabilidades

Slides:



Advertisements
Apresentações semelhantes
Orientação a objetos identidade abstração classificação encapsulamento
Advertisements

Análise e Projeto Orientados a Objeto com UML e Padrões
Engenharia de Software Qualidade de Software Uma abordagem conceitual André Luis Zanon São Carlos SP – UFSCAR 2010 Engenharia de Software – UFSCAR.
UML – Visões Parte 1 Modelando um sistema.
UNIVERSIDADE ESTADUAL DE MATO GROSSO DO SUL SISTEMAS DE INFORMAÇÃO ENGENHARIA DE SOFTWARE Métricas de Software Prof.ª Adriana dos Santos Caparróz Carvalho.
Projeto conceitual Mostra ao cliente exatamente o que o sistema fará
Engenharia de Software
ATSI ExtendingAndFormalizingTheFrameworkForInormati onStyleArchitecture Alunos: Manuel Mendes- nº49703 Francisco Silva – nº51298 Cristina Fraga- nº51383.
UML – MODELAÇÃO DA ESTRUTURA Professor Sandro Carvalho.
Metodologias Equipe do Curso de ES para SMA
Linguagens de Modelagem para SMA
Cartões CRC (Class Responsibility Card)
SISTEMA É UMA ENTIDADE QUE MANTEM SUA EXISTÊNCIA ATRAVÉS DA INTERAÇÃO DE SUAS PARTES ( Bertalanffy ) Interação Mútua Diferente duma simples.
Adélia Barros Requisitos Adélia Barros
Atribuição de Responsabilidades em Projeto OO
Projeto de Software Orientado a Objetos
Modulo I Padrões GRASP Professores
Atividade de Projeto Design
Construção de Diagramas de Colaboração
(Linguagem de Modelagem Unificada)
Análise Estruturada O mais amplamente usado dos métodos de modelagem de requisitos Modelos que retratam fluxo e o conteúdo da informação (dados e controle)
Programação orientada a objetos com Java
Engenharia de Requisitos Requisito – sistema Caso de uso - usuário
Aspectos Avançados em Engenharia de Software Aula 3 Fernanda Campos
Geração de Código.
Projeto da Camada de Domínio
Princípios e Conceitos de Software(v2)
Principios e Conceitos de Projeto
Gerenciamento de Configuração
Visão crítica sobre padrões: Over Engineering
Conceitos.
Expansão dos Casos de Uso
Análise e Projeto de Sistemas UNIVERSIDADE DE CRUZ ALTA Ciência da Computação 2010/1.
Arquitetura do Software
© Nabor C. Mendonça Análise e Projeto Orientados a Objeto com UML e Padrões.
Programação Orientada à Objetos
Acoplamento e Coesão Modelagem e Programação Orientada a Objetos
UTFPR – Campus Curitiba - DAELN Cursos de Eng. Eletrônica/Eng
Padrão- MVC Model, View, Controller
RUP - Cap. 4 – Processo Centrado na Arquitetura
Apresentação Visio + VisioCase.
Integração de Ferramentas CASE
ABC reuso Reengenharia Primeiras conclusões. ABC reuso Análise do Código Fonte Arquitetura em Camadas Fachada (SIAlocacaoPlus) Negócio (Cadastros) Persistência.
Tarciane Andrade Análise de Casos de Uso Tarciane Andrade
Modelo de Análise e Projeto
Diagrama de Pacotes.
Projetando Objetos com Responsabilidades
Sistemas Propriedades de Sistemas SITP – Módulo 3.
Padrões de projeto M.Sc. Sílvio Bacalá Jr..
Expansão dos Casos de Uso
Atividade de Projeto Design. O Que é Projeto OO? É desvendar a caixa-preta de um objeto :Sistema Como o objeto complexo :Sistema deveria ser definido?
Diagramas de Colaboração entre Objetos Motivação.
Introdução a Orientação a Objetos
TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANÁLISE E PROJETO DE SISTEMAS Semana /08/2012 Professor Leomir J. Borba-
Módulo II Capítulo 1: Orientação a Objetos
Padrões de Projetos Professora Lucélia. Conceitos É uma solução conhecida para um problema comum São técnicas que nos dão uma boa solução para determinados.
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
Engenharia de Software Orientada a Objetos
1 Database Systems, 8 th Edition Sistemas de Banco de Dados: Projeto, Implementação e gestão Oitava Edição Capítulo 2 Modelo de Dados.
1 Database Systems, 8 th Edition Sistemas de Banco de Dados: Projeto, Implementação e gestão Oitava Edição Capítulo 2 Modelo de Dados.
Padrões GRASP.
Interações entre objetos
Fundamentos de Engenharia de SW Diagramas da UML Usados no Projeto de Software.
Diagrama de atividade.
Padrões de Projeto Aula 10 – Padrão Façade.
Análise e Design de Software Site:
Delegação  É uma maneira de tornar a composição tão poderosa para fins de reutilização como a herança. Na delegação, dois objetos são envolvidos no tratamento.
GRASP: Projeto de Objetos com Responsabilidade. 2 Pauta Responsabilidades e métodos Responsabilidades e métodos Padrões Padrões GRASP: Padrões e princípios.
GRASP: Projeto de Objetos com Responsabilidade – Parte 2.
1.
Transcrição da apresentação:

Padrões para Atribuições de Responsabilidades Motivação Más escolhas de atribuição de responsabilidades geram sistemas e componentes frágeis e de difícil manutenção, extensão e reutilização. Quando utilizar? Padrões são utilizados durante a criação dos diagramas de interação

Padrões para Atribuições de Responsabilidades O que são Padrões? Princípios, estilos e regras de programação, codificados em um formato estruturado, descrevendo problema/solução Um Padrão é um par nomeado problema/solução, que pode ser utilizado em novos contextos, com conselhos sobre como utilizá-lo em novas situações

Padrões para Atribuições de Responsabilidades O que não são Padrões? Novos princípios da Engenharia de Software. Ao contrário, padrões tentam codificar o conhecimento, idiomas e princípios existentes

Padrões para Atribuições de Responsabilidades Responsabilidades e Métodos Responsabilidade: contrato ou obrigação de uma classe Métodos: utilizados para implementar Responsabilidades Tipos de Responsabilidades: Fazer: ele próprio; iniciar ações em outros objetos; controlar atividades em outros objetos Conhecer: dados privados; objetos relacionados; coisas que pode calcular e derivar. São dedutíveis do modelo Conceitual

Padrões para Atribuições de Responsabilidades O que são os Padrões GRASP ? Princípios fundamentais de atribuição de responsabilidades a objetos Quais são? Information Expert Creator Controller Low Coupling High Cohesion Polymorphism Pure Fabrication Indirection Protected Variations

Padrões para Atribuições de Responsabilidades Information Expert – Especialista Solução: atribui a responsabilidade ao especialista da informação Conclusão a satisfação de uma responsabilidade requer informações espalhadas por diferentes classes. desta forma existem vários especialistas parciais que colaboram com a tarefa Favorece ao acoplamento fraco uma vez que os objetos usam suas próprias informações para executarem as tarefas As classes ficam “leves” gerando alta coesão

Padrões para Atribuições de Responsabilidades Creator – Criador Solução: atribua à classe B a responsabilidade de criar instâncias da classe A se: B agrega objetos de A B contém objetos de A B registra instâncias de objetos A B tem os dados de inicialização que serão passados para o objeto A, quando de sua criação ( B é um especialista com a relação a criação de A) Conclusão O objetivo do padrão é encontrar um Criador que necessita ser conectado ao objeto criado O criador pode ser encontrado procurando a classe que tem os dados de inicialização que serão passados durante a criação

Padrões para Atribuições de Responsabilidades Low Coupling (Acoplamento Fraco) Solução: atribuir a responsabilidade de maneira que o acoplamento permaneça fraco. Conclusão Corresponde a um padrão de avaliação Não há uma medida que determine quanto um acoplamento é muito forte O importante é avaliar o grau atual de acoplamento e julgar se seu aumento trará problemas Se o acoplamento fraco é aplicado em excesso, leva a um projeto fraco, pois conduz a poucos objetos ativos, se coesão, inchados e complexos, que efetuam todo o trabalho. acoplamento fraco permite entendimento isolado, maior reutilização

Padrões para Atribuições de Responsabilidades High Cohesion (Coesão Alta) Solução: atribuir uma responsabilidade de modo que a coesão permaneça alta. Alta Coesão - Uma classe com responsabilidades altamente relacionadas e que não executa um formidável volume de trabalho. Baixa Coesão - Uma classe que faz muitas coisas não relacionadas ou executa demasiado trabalho. Gera dificuldades para manter, reutilizar, compreender, e constantemente afetadas por mudanças. Conclusão Corresponde a um padrão de avaliação Como regra uma classe com coesão alta tem um número relativamente pequeno de métodos, com funcionalidades relacionadas e não executa muito trabalho.

Padrões para Atribuições de Responsabilidades Controller – Controlador Solução: atribui a responsabilidade do tratamento de uma mensagem de um evento do sistema a uma classe que representa uma das escolhas: controlador fachada - representa o sistema todo ou todo o negócio ou organização. Adequado quando existem poucos eventos do sistema controlador de papel - representa algo no mundo real que é ativo ( por exemplo o papel de uma pessoa) e que pode estar envolvido na tarefa. controlador de caso de uso - representa um tratador artificial de todos os eventos de sistema de um caso de uso. Adequado quando existem muitos eventos do sistema em diferentes processos.

Padrões para Atribuições de Responsabilidades Controller – Controlador Observações: Deve ser usada a mesma classe controladora para todos os eventos do sistema de um mesmo caso de uso. Classes como interfaces externas ( janelas, applet, etc.) não devem executar eventos do sistema. Apenas são responsáveis por receberem estes eventos e delegarem a um controlador Operações do sistema que refletem processos de negócio devem ser tratadas na camada de objetos de domínio. O que é um Controlador? É um objeto de interface, responsável por tratar um evento do sistema. Um controlador define um método para a operação do sistema.