Variações Protegidas
Toda aplicação tem pontos de variação, identifique os pontos de variação ou instabilidade prevista, atribuindo responsabilidades para criar uma interface estável em torno deles. Na variação protegida temos as variações evolutivas e as variações corretivas.Mecanismos de Variações Protegidas· Agentes (Brokers) – é encarregado de levar as requisições que recebe, localiza qual local de destino e entrega ao local correto.· Máquinas Virtuais – simulam vários sistemas em um único meio físico, dá maior portabilidade aos sistemas em ambientes instáveis.· Projetos dirigidos por dados (dataDriver design) – troca de informações entre aplicações através de arquivos configurados por exemplo XML, framework Spring, TomCat, etc.· Pesquisa de serviços – é ter alguém que forneça serviços, e ter alguém que consome os serviços disponibilizados, podemos citar como exemplo o novo paradigma SOA.· Projetos dirigidos por interpretadores – são aplicações que interpretam ambientes ou sistemas diferentes, por exemplo JVM, Engine Regras.· Projetos reflexivos ou de meta-dados – nesse caso reflete o que tem dentro da classe, por exemplo: o normal a se fazer em uma consulta em banco de dados é pesquisar pelo catalogo do banco e não a colunas, se alguém vier a mudar a tabela que está consultando, alterando apenas o nome das colunas, isso irá prejudicar sua consulta, no caso de uma consulta pelo catalogo do banco o problema descrito acima não irá acontecer pois sua consulta irá solicitar ao catalogo que por sua vez possui o índice da tabela que está consultando e assim retornará os dados da coluna relacionada a consulta.· Acesso Uniforme – não se preocupa com a estrutura da linguagem, não se restringe a propriedades, métodos, procedimentos, etc., tudo é igual seja ele com definições de propriedade, métodos ou procedimentos, exemplos de linguagens que não se preocupa com definições são: linguagem EIFFEL, C#, etc.· Princípios da substituição de Liskov – como mecanismo de variação protegida a substituição de Liskov prevê que se declararmos classes como interface qualquer classe poderá implementar a superclasse.Padrão não Fale com EstranhosObjetivo é evitar o acoplamento indireto, ou seja, que um cliente precise ter conhecimento de objetos indiretos, ou das representações internas de objetos diretamente referenciados. As mensagens podem ser mandadas dentro da própria classe, não pode mandar mensagens para classes diferentes (externas), se sair disso se torna frágil.§ Objetos referenciados diretamente – “familiares”§ Objetos referenciados indiretamente – “estranhos”§ Novas operações serão necessárias nos objetos diretamente referenciados para funcionarem como operações intermediárias.Restrições para envio de mensagem – se sair do escopo abaixo a classe se torna frágil· O objeto this· Um parâmetro do método· Um atributo de this· Um elemento de uma coleção que seja de this· Um objeto criado dentro do métodoPor exemplo se um método mandar mensagem para outro método e assim por diante, há uma fragilidade, pois se houver uma cadeia muito longa de métodos um mandando mensagem para outro pode haver quebras e a aplicação pode vir a falhar, isso pode ser resolvido através do padrão não fale com estranhos seguindo seu escopo.
XP
Extreme Programming, ou XP, é um processo de desenvolvimento de sof-tware voltado para:• Projetos cujos requisitos são vagos e mudam com freqüência;• Desenvolvimento de sistemas orientados a objeto;• Equipes pequenas, preferencialmente até 12 desenvolvedores;• Desenvolvimento incremental (ou iterativo), onde o sistema começa aser implementado logo no início do projeto e vai ganhando novas funci-onalidades ao longo do tempo.Existe uma categoria de processos de desenvolvimento conhecida como Pro-cessos Ágeis de Desenvolvimento, dentro da qual o XP e outros processos seencaixam. Eles compartilham a premissa de que o cliente aprende sobresuas necessidades, na medida em que é capaz de manipular o sistema queestá sendo produzido. Com base no feedback do sistema ele re-avalia as suasnecessidades e prioridades, gerando mudanças que devem ser incorporadasao software. O aprendizado é importante, porque permite que o clientedirecione o desenvolvimento de modo que a equipe produza sempre aquiloque tem o maior valor para o seu negócio.O XP é um processo de desenvolvimento que busca assegurar que o clientereceba o máximo de valor de cada dia de trabalho da equipe de desenvolvi-mento. Ele é organizado em torno de um conjunto de valores e práticas queatuam de forma harmônica e coesa para assegurar que o cliente semprereceba um alto retorno do investimento em software.
terça-feira, 17 de junho de 2008
AULA 29 e 30 - INVENÇÃO PURA, INDIREÇÃO E NÃO FALE COM ESTRANHOS
Invenção Pura
- Característica principal de projetos OO: utilizam os conceitos do domínio do problema para compor a implementação em software.
- Em algumas situações, a atribuição de responsabilidades somente às classes do domínio leva a problemas em termos de coesão e acoplamento.
- Característica principal de projetos OO: utilizam os conceitos do domínio do problema para compor a implementação em software.
- Em algumas situações, a atribuição de responsabilidades somente às classes do domínio leva a problemas em termos de coesão e acoplamento.
- Problema: A quem atribuir responsabilidades quando as classes do domínio não são adequadas e não se quer violar os princípios da Coesão Alta e do Acoplamento Fraco ? Como criar componentes de software conectáveis ?
- Solução: Atribuir um conjunto de responsabilidades altamente coeso a uma classe artificial – que não representa nada no domínio do problema. Tal classe é construída especialmente para melhorar a coesão e diminuir o acoplamento, facilitando a reutilização (uma invenção da imaginação)
Exemplo:
Nesse caso, a solução é criar uma nova classe que é unicamente responsável por salvar objetos em algum tipo de meio de armazenamento persistente, como um banco de dados relacional.
Chamamos esta solução de IntermediárioArmazenamentoPersistente.
Esta classe é uma Invenção Pura.
Beneficios:
-Melhora acoplamento e coesão: a classe venda permanece bem projetada.
-Cria-se objetos mais genéricos e reutilizáveis: a própria classe inventada. É importante ter isso em mente
-Invenção pura são objetos tipicamente centrados na funcionalidade (cuidado com abusos para não perder o espírito de bons projetos OO!).
-É considerada como parte da camada de serviços de alto nível OO em uma arquitetura.
Indireção
-Suponha que:
-A aplicação TPV precisa manipular um modem, para transmitir solicitações de autorização de crédito.
-O SO oferece uma API para fazer isso
-A classe ServiçoAutorizaçãodeCrédito é responsável por falar com o modem .Tal classe fica altamente acoplada com a API e o SO.
-Problema: Como evitar o acoplamento direto? Como desacoplar objetos de maneira a apoiar o Acoplamento Fraco e manter o alto potencial de reutilização?
-Solução: Atribuir a responsabilidade a um objeto intermediário que faz a mediação entre outros componentes ou serviços, de modo que eles não estejam diretamente acoplados
-Problema: Como evitar o acoplamento direto? Como desacoplar objetos de maneira a apoiar o Acoplamento Fraco e manter o alto potencial de reutilização?
-Solução: Atribuir a responsabilidade a um objeto intermediário que faz a mediação entre outros componentes ou serviços, de modo que eles não estejam diretamente acoplados
-Benefício: Acoplamento fraco – com o objetivo de desacoplar outros componentes ou serviços, introduz-se uma indireção.
-Muitas invenções puras são conseqüências da indireção.
Não fale com estranhos
-Motivação: O objetivo é evitar o acoplamento indireto, ou seja, que um cliente precise ter conhecimento de objetos indiretos, ou das representações internas de objetos diretamente referenciados.
-Objetos referenciados diretamente – “familiares”
-Objetos referenciados indiretamente – “estranhos”
-Novas operações serão necessárias nos objetos diretamente referenciados para funcionarem como operações intermediárias.
-Problema: Como evitar o conhecimento da estrutura de objetos indiretamente referenciados?
-Solução: Atribuir responsabilidade a um objeto diretamente referenciado por um cliente, de forma que este colabore mantendo contato com o objeto “estranho” (indiretamente referenciado)
-Lei de Demétrio
-Dentro de um método, as mensagens devem ser enviadas somente para os seguintes objetos:
-O objeto this (ou self)
-Um parâmetro do método
-Um atributo de self
-Um elemento de uma coleção que é um atributo de self
-Um objeto criado dentro do método
AULA 27 e 28 - PADRÕES GRASP 2ª PARTE POLIMORFISMO
Polimorfismo
- lternativas com base no tipo: variação condicional é comumente encontrada em programas.
- Uso de lógica condicional: torna difícil a extensão de um programa para atender novas variantes, pois mudanças são necessárias em vários lugares.
- Componentes de software “conectáveis” : sendo os componentes do tipo cliente-servidor, como substituir um componente servidor, sem afetar o cliente?
- Problema: Como tratar alternativas com base no tipo ? Como criar componentes de software conectáveis ?
- Solução: Atribuir responsabilidade pelo comportamento, aos tipos para os quais o comportamento varia, usando operações polimórficas.
- Corolário: não teste o tipo de um objeto nem use condições lógicas no código para executar alternativas que variam com base no tipo
- Exemplo: No sistema TPV, quem deveria ser o responsável pela autorização de diferentes tipos de pagamentos?
- Como a autorização varia de acordo com o tipo de pagamento (dinheiro, cartão de crédito ou cheque), usando o padrão Polimorfismo devemos atribuir a responsabilidade à cada tipo de pagamento, implementada como uma operação polimórfica autorizar.
- Facilidade de extensão: futuras extensões, quando necessárias para novos tipos não previstos, são fáceis de acrescentar
- Objetos clientes: necessitarão pouca ou nenhuma modificação, na medida que o novo servidor suporte as operações polimórficas esperadas pelo cliente.
- lternativas com base no tipo: variação condicional é comumente encontrada em programas.
- Uso de lógica condicional: torna difícil a extensão de um programa para atender novas variantes, pois mudanças são necessárias em vários lugares.
- Componentes de software “conectáveis” : sendo os componentes do tipo cliente-servidor, como substituir um componente servidor, sem afetar o cliente?
- Problema: Como tratar alternativas com base no tipo ? Como criar componentes de software conectáveis ?
- Solução: Atribuir responsabilidade pelo comportamento, aos tipos para os quais o comportamento varia, usando operações polimórficas.
- Corolário: não teste o tipo de um objeto nem use condições lógicas no código para executar alternativas que variam com base no tipo
- Exemplo: No sistema TPV, quem deveria ser o responsável pela autorização de diferentes tipos de pagamentos?
- Como a autorização varia de acordo com o tipo de pagamento (dinheiro, cartão de crédito ou cheque), usando o padrão Polimorfismo devemos atribuir a responsabilidade à cada tipo de pagamento, implementada como uma operação polimórfica autorizar.
- Facilidade de extensão: futuras extensões, quando necessárias para novos tipos não previstos, são fáceis de acrescentar
- Objetos clientes: necessitarão pouca ou nenhuma modificação, na medida que o novo servidor suporte as operações polimórficas esperadas pelo cliente.
AULA 25 e 26 - PADRÃO MVC
O padrão MVC
O modelo de três camadas fisícas ( 3-tier ) divide um aplicativo de modo que a lógica de negócio resida no meio das três camadas físicas. Isto é chamado de camada física intermediária ou camada física de negócios. A maior parte do código escrito reside na camada de apresentação e de negócio.
A arquitetura MVC - (Modelo Visualização Controle) fornece uma maneira de dividir a funcionalidade envolvida na manutenção e apresentação dos dados de uma aplicação. A arquitetura MVC não é nova e foi originalmente desenvolvida para mapear as tarefas tradicionais de entrada , processamento e saída para o modelo de interação com o usuário. Usando o padrão MVC fica fácil mapear esses conceitos no domínio de aplicações Web multicamadas.
Na arquitetura MVC o modelo representa os dados da aplicação e as regras do negócio que governam o acesso e a modificação dos dados. O modelo mantém o estado persistente do negócio e fornece ao controlador a capacidade de acessar as funcionalidades da aplicação encapsuladas pelo próprio modelo.
Um componente de visualização renderiza o conteúdo de uma parte particular do modelo e encaminha para o controlador as ações do usuário; acessa também os dados do modelo via controlador e define como esses dados devem ser apresentados.
Um controlador define o comportamento da aplicação , é ele que interpreta as ações do usuário e as mapeia para chamadas do modelo. Em um cliente de aplicações Web essas ações do usuário poderiam ser cliques de botões ou seleções de menus. As ações realizadas pelo modelo incluem ativar processos de negócio ou alterar o estado do modelo. Com base na ação do usuário e no resultado do processamento do modelo , o controlador seleciona uma visualização a ser exibida como parte da resposta a solicitação do usuário. Há normalmente um controlador para cada conjunto de funcionalidades relacionadas.
A arquitetura de 3 camadas que esta representada abaixo é uma implementação do modelo MVC . O modelo MVC esta preocupado em separar a informação de sua apresentação.
O modelo de três camadas fisícas ( 3-tier ) divide um aplicativo de modo que a lógica de negócio resida no meio das três camadas físicas. Isto é chamado de camada física intermediária ou camada física de negócios. A maior parte do código escrito reside na camada de apresentação e de negócio.
A arquitetura MVC - (Modelo Visualização Controle) fornece uma maneira de dividir a funcionalidade envolvida na manutenção e apresentação dos dados de uma aplicação. A arquitetura MVC não é nova e foi originalmente desenvolvida para mapear as tarefas tradicionais de entrada , processamento e saída para o modelo de interação com o usuário. Usando o padrão MVC fica fácil mapear esses conceitos no domínio de aplicações Web multicamadas.
Na arquitetura MVC o modelo representa os dados da aplicação e as regras do negócio que governam o acesso e a modificação dos dados. O modelo mantém o estado persistente do negócio e fornece ao controlador a capacidade de acessar as funcionalidades da aplicação encapsuladas pelo próprio modelo.
Um componente de visualização renderiza o conteúdo de uma parte particular do modelo e encaminha para o controlador as ações do usuário; acessa também os dados do modelo via controlador e define como esses dados devem ser apresentados.
Um controlador define o comportamento da aplicação , é ele que interpreta as ações do usuário e as mapeia para chamadas do modelo. Em um cliente de aplicações Web essas ações do usuário poderiam ser cliques de botões ou seleções de menus. As ações realizadas pelo modelo incluem ativar processos de negócio ou alterar o estado do modelo. Com base na ação do usuário e no resultado do processamento do modelo , o controlador seleciona uma visualização a ser exibida como parte da resposta a solicitação do usuário. Há normalmente um controlador para cada conjunto de funcionalidades relacionadas.
A arquitetura de 3 camadas que esta representada abaixo é uma implementação do modelo MVC . O modelo MVC esta preocupado em separar a informação de sua apresentação.
Camada de apresentação ou visualização - Não esta preocupada em como a informação foi obtida ou onde ela foi obtida apenas exibe a informação.
inclui os elementos de exibição no cliente : HTML , XML , ASP , Applets .
É a camada de interface com o usuário.
É usada para receber a entrada de dados e apresentar o resultado
Camada de lógica da Aplicação - É o coração da aplicação . Responsável por tudo que a aplicação vai fazer.
modela os dados e o comportamento por atrás do processo de negócios
se preocupa apenas com o armazenamento , manipulação e geração de dados
É um encapsulamento de dados e de comportamento independente da apresentação.
Camada de Controle - determina o fluxo da apresentação servindo como uma camada intermediária entre a camada de apresentação e a lógica.
controla e mapeia as ações
Vantagens do modelo MVC :
Como o modelo MVC gerencia múltiplos visualizadores usando o mesmo modelo é fácil manter , testar e atualizar sistemas múltiplos
É muito simples incluir novos clientes apenas incluindo seus visualizadores e controles
Torna a aplicação escalável
É possível ter desenvolvimento em paralelo para o modelo , visualizador e controle pois são independentes.
Desvantangens do modelo MVC:
Requer uma quantidade maior de tempo para analizar e modelar o sistema
Requer pessoal especializado
Não é aconselhável para pequenas aplicações
quinta-feira, 8 de maio de 2008
AULA 23 e 24 - PADRÃO COMMAND
Encapsular uma solicitação como um objeto, desta forma permitindo parametrizar clientes com diferentes solicitações, enfileirar ou fazer o registro (log) de solicitações e suportar operações que podem ser desfeitas.
Algumas vezes é necessário emitir solicitações para objetos nada sabendo sobre a operação que está sendo solicitada ou sobre o receptor da mesma.
Utilizar quando:
Parametrizar objetos por uma ação a ser executada. Você pode expressar tal parametrização numa linguagem procedural através de uma função callback, ou seja, uma função que é registrada em algum lugar para ser chamada em um momento mais adiante. Os Commands são uma substituição orientada a objetos para callbacks;
Especificar, enfileirar e executar solicitações em tempos diferentes. Um objeto Command pode ter um tempo de vida independente da solicitação original. Se o receptor de uma solicitação pode ser representado de uma maneira independente do espaço de endereçamento, então você pode transferir um objeto Command para a solicitação para um processo diferente e lá atender a solicitação;
Suportar desfazer operações. A operação Execute, de Command, pode armazenar estados para reverter seus efeitos no próprio comando. A interface do Command deve ter acrescentada uma operação Unexecute, que o reverte.efeitos de uma chamada anterior de Execute. Os comandos executados são armazenados em uma lista histórica. O nível ilimitado de desfazer e refazer operações é obtido percorrendo esta lista para trás e para frente, chamando operações Unexecute e Execute, respectivamente.
A chave deste padrão è uma classe abstrata Command, a qual declara uma interface para execução de operações. Na sua forma mais simples, esta interface inclui uma operação abstrata Execute. As subclasses concretas de Command especificam um par receptoração através do armazenamento do receptor como uma variável de instância e pela implementação de Execute para invocar a solicitação. O receptor tem o conhecimento necessário para poder executar a solicitação.
Também conhecido como Action, Transaction (Ação, Transação, respectivamente).
Obtido em http://pt.wikipedia.org/wiki/Command
EXEMPLO:
public class DvdName {
private String titleName;
public DvdName(String titleName) {
this.setTitleName(titleName);
}
public final void setTitleName(String titleNameIn) {
this.titleName = titleNameIn;
}
public final String getTitleName() {
return this.titleName;
}
public void setNameStarsOn() {
this.setTitleName(this.getTitleName().replace(' ','*'));
}
public void setNameStarsOff() {
this.setTitleName(this.getTitleName().replace('*',' '));
}
public String toString() {
return ("DVD: " + this.getTitleName());
}
}
public abstract class CommandAbstract {
public abstract void execute();
}
public class DvdCommandNameStarsOn extends CommandAbstract {
private DvdName dvdName;
public DvdCommandNameStarsOn(DvdName dvdNameIn) {
this.dvdName = dvdNameIn;
}
public void execute() {this.dvdName.setNameStarsOn();
}
}
public class DvdCommandNameStarsOff extends CommandAbstract {
private DvdName dvdName;
public DvdCommandNameStarsOff(DvdName dvdNameIn) {
this.dvdName = dvdNameIn;
}
public void execute() {
this.dvdName.setNameStarsOff();
}
}
class TestCommand {
public static void main(String[] args) {DvdName jayAndBob = new DvdName("Jay and Silent Bob Strike Back");
DvdName spongeBob = new DvdName("Sponge Bob Squarepants - " +"Nautical Nonsense and Sponge Buddies");
System.out.println("as first instantiated");
System.out.println(jayAndBob.toString());
System.out.println(spongeBob.toString());
CommandAbstract bobStarsOn = new DvdCommandNameStarsOn(jayAndBob);
CommandAbstract bobStarsOff = new DvdCommandNameStarsOff(jayAndBob);
CommandAbstract spongeStarsOn = new DvdCommandNameStarsOn(spongeBob);
CommandAbstract spongeStarsOff = new DvdCommandNameStarsOff(spongeBob);
bobStarsOn.execute();spongeStarsOn.execute();
System.out.println(" ");System.out.println("stars on");
System.out.println(jayAndBob.toString());
System.out.println(spongeBob.toString());
spongeStarsOff.execute();System.out.println(" ");
System.out.println("sponge stars off");
System.out.println(jayAndBob.toString());
System.out.println(spongeBob.toString());
}}
UML do Exempo:
AULA 21 e 22 - PADRÃO OBSERVER
O padrão Observer define uma relação de dependência "um-para-muitos" entre objetos, tal que quando há mudança no estado de um objeto, todos os seus dependentes são notificados e atualizados automaticamente. Esse padrão tem como elementos participantes o Subject, que define uma interface para adicionar/remover dependentes e notificar os dependentes; o ConcreteSubject, que retém o estado de interesse dos objetos ConcreteObserver e notifica esses objetos de sua mudança de estado; o Observer que define uma interface para atualizar os objetos que precisam ser notificados das mudanças no Subject e o ConcreteObserver, que implementa a interface de Observer e precisa atualizar o seu estado conforme o estado do Subject ao qual está associado.
No sistema proposto, o padrão Observer é aplicado em: • ControladorDeJogo - É responsabilidade de cada Controlador de Jogo apresentar graficamente o estado atual do jogo. Para isso, o ControladorDeJogo atua como observador (ConcreteObserver) sobre a Sessão, sendo notificado de cada modificação no Estado. • Sessao - A Sessao por sua vez, atua como o objeto observado (ConcreteSubject) notificando os objetos dependentes das mudanças no Estado. • ControladorDeSessoes - O ControladorDeSessoes apresenta ao usuário todas as sessões disponíveis, para que o Controlador possa apresentar toda Sessao recentemente criada e deixe de apresentar aquelas que já terminaram, o controlador atua como observador sobre o ServidorDePartidas, sendo notificado de toda Sessao que é criada ou terminada. • ServidorDePartidas - O ServidorDePartidas, assim como a Sessao, atua como objeto observado tendo como responsabilidade notificar cada ControladorDeSessoes quando uma sessao e criada ou terminada.
Observação: Tendo em vista as constantes alterações no Estado devido a dinâmica do jogo, é interessante que cada ControladorDeJogo seja notificado uma única vez por ciclo, ou seja, permitir que a LogicaDoJogo atualize cada elemento para então notificar os Controladores.
No sistema proposto, o padrão Observer é aplicado em: • ControladorDeJogo - É responsabilidade de cada Controlador de Jogo apresentar graficamente o estado atual do jogo. Para isso, o ControladorDeJogo atua como observador (ConcreteObserver) sobre a Sessão, sendo notificado de cada modificação no Estado. • Sessao - A Sessao por sua vez, atua como o objeto observado (ConcreteSubject) notificando os objetos dependentes das mudanças no Estado. • ControladorDeSessoes - O ControladorDeSessoes apresenta ao usuário todas as sessões disponíveis, para que o Controlador possa apresentar toda Sessao recentemente criada e deixe de apresentar aquelas que já terminaram, o controlador atua como observador sobre o ServidorDePartidas, sendo notificado de toda Sessao que é criada ou terminada. • ServidorDePartidas - O ServidorDePartidas, assim como a Sessao, atua como objeto observado tendo como responsabilidade notificar cada ControladorDeSessoes quando uma sessao e criada ou terminada.
Observação: Tendo em vista as constantes alterações no Estado devido a dinâmica do jogo, é interessante que cada ControladorDeJogo seja notificado uma única vez por ciclo, ou seja, permitir que a LogicaDoJogo atualize cada elemento para então notificar os Controladores.
AULA 19 e 20 - PADRÃO SINGLENTON
Singleton, é um padrão de projeto de software (do inglês Design Pattern). Este padrão garante a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto.
Nota linguística: O termo vem do significado em inglês quando se resta apenas uma carta nas mãos, num jogo de baralho.
Muitos projetos necessitam que algumas classes tenham apenas uma instância. Por exemplo, em uma aplicação que precisa de uma infraestrutura de log de dados, pode-se implementar uma classe no padrão singleton. Desta forma existe apenas um objeto responsável pelo log em toda a aplicação que é acessível unicamente através da classe singleton.
Exemplos
Em Java
Segue um exemplo em Java de classe Singleton usada em log de dados. Esta classe suporta inicialização sob demanda e ambientes multi-thread.public class SingletonLog {
// Construtor privado. Suprime o construtor publico padrao.
private SingletonLog() {
// Leitura da configuração de log. Normalmente descrita em um arquivo.
}
// Faz o log de eventos da aplicacao
public void doLog(String eventDescription) {
}
//Retorna a instancia unica da classe SingletonLog
public static SingletonLog getInstance() {
return SingletonLogHolder.instance;
}
//Classe auxiliar para criacao da instancia. Evita problemas de sincronizacao de threads.
private static class SingletonLogHolder {
private static SingletonLog instance = new SingletonLog();
}
}
Nota linguística: O termo vem do significado em inglês quando se resta apenas uma carta nas mãos, num jogo de baralho.
Muitos projetos necessitam que algumas classes tenham apenas uma instância. Por exemplo, em uma aplicação que precisa de uma infraestrutura de log de dados, pode-se implementar uma classe no padrão singleton. Desta forma existe apenas um objeto responsável pelo log em toda a aplicação que é acessível unicamente através da classe singleton.
Exemplos
Em Java
Segue um exemplo em Java de classe Singleton usada em log de dados. Esta classe suporta inicialização sob demanda e ambientes multi-thread.public class SingletonLog {
// Construtor privado. Suprime o construtor publico padrao.
private SingletonLog() {
// Leitura da configuração de log. Normalmente descrita em um arquivo.
}
// Faz o log de eventos da aplicacao
public void doLog(String eventDescription) {
}
//Retorna a instancia unica da classe SingletonLog
public static SingletonLog getInstance() {
return SingletonLogHolder.instance;
}
//Classe auxiliar para criacao da instancia. Evita problemas de sincronizacao de threads.
private static class SingletonLogHolder {
private static SingletonLog instance = new SingletonLog();
}
}
AULA 17 e 18 - PADRÕES GOF
Os padrões de projeto de software ou padrões de desenho de software, também muito conhecido pelo termo original em inglês: Design Patterns, descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Um padrão de projeto estabelece um nome e define o problema, a solução, quando aplicar esta solução e suas conseqüências.
Os padrões de projeto visam facilitar a reutilização de soluções de desenho - isto é, soluções na fase de projeto do software, sem considerar reutilização de código. Também acarretam um vocabulário comum de desenho, facilitando comunicação, documentação e aprendizado dos sistemas de software.
Os padrões "GoF" são organizados em famílias de padrões: de criação, estruturais e comportamentais. Os padrões de criação são relacionados à criação de objetos, os estruturais tratam das associações entre classes e objetos e os comportamentais das interações e divisões de responsabilidades entre as classes ou objetos.
Um padrão "GoF" também é classificado segundo o seu escopo; de classe ou de objeto. Nos padrões com escopo de classe os relacionamentos que definem este padrão são definidos através de herança e em tempo de compilação. Nos padrões com escopo de objeto o padrão é encontrado no relacionamento entre os objetos definidos em tempo de execução.
Formas de classificação
- Classificação GOF
- Criação
- Estrutura
- Comportamento
- Classificação de hetsker
- Interface
- Responsabilidade
- Construção
- Operação
- Extensão
AULA 15 e 16 - COESÃO
Alta coesão é um princípio de ouro que deve ser sempre mantido em mente durante o projeto
Tipos de coesão entre módulos
· Coincidental (pior)
· Lógico
· Temporal
· Procedural
· De comunicação
· Sequencial
· Funcional (melhor)
Coesão coincidental
· Há nenhuma (ou pouca) relação construtiva entre os elementos de um módulo
· No linguajar OO:
· Um objeto não representa nenhum conceito OO
· Uma coleção de código comumente usado e herdado através de herança (provavelmente múltipla)
class Angu {
public static int
acharPadrão(String texto, String padrão) {
// ...
}
public static int média(Vector números) {
// ...
}
public static outputStream abreArquivo(string nomeArquivo) {
// ...
}
}
class Xpto extends Angu { // quer aproveitar código de Angu
...
}
Coesão lógica
· Módulo faz um conjunto de funções relacionadas, uma das quais é escolhida através de um parâmetro ao chamar o módulo
· Semelhante a acoplamento de controle
· Cura: quebrar em métodos diferentes
public void faça(int flag) {
switch(flag) {
case ON:
// coisas para tratar de
ON
break;
case OFF: // coisas para tratar de OFF
break;
case FECHAR:
// coisas para tratar de FECHAR
break;
case COR: // coisas para tratar de COR
break;
}
}
Tipos de coesão entre módulos
· Coincidental (pior)
· Lógico
· Temporal
· Procedural
· De comunicação
· Sequencial
· Funcional (melhor)
Coesão coincidental
· Há nenhuma (ou pouca) relação construtiva entre os elementos de um módulo
· No linguajar OO:
· Um objeto não representa nenhum conceito OO
· Uma coleção de código comumente usado e herdado através de herança (provavelmente múltipla)
class Angu {
public static int
acharPadrão(String texto, String padrão) {
// ...
}
public static int média(Vector números) {
// ...
}
public static outputStream abreArquivo(string nomeArquivo) {
// ...
}
}
class Xpto extends Angu { // quer aproveitar código de Angu
...
}
Coesão lógica
· Módulo faz um conjunto de funções relacionadas, uma das quais é escolhida através de um parâmetro ao chamar o módulo
· Semelhante a acoplamento de controle
· Cura: quebrar em métodos diferentes
public void faça(int flag) {
switch(flag) {
case ON:
// coisas para tratar de
ON
break;
case OFF: // coisas para tratar de OFF
break;
case FECHAR:
// coisas para tratar de FECHAR
break;
case COR: // coisas para tratar de COR
break;
}
}
AULA 14 - PADRÃO CONTROLLER
Controller
Problema
Quem deveria receber a responsabilidade de tratar eventos do sistema?
Um evento do sistema é um evento de alto nível gerado por um ator externo
Estão associados a operações do sistema que já vimos nos Diagramas de Sequência do Sistema
Exemplo do estudo de caso: Caixa pressiona "Fim de venda"
Solução
Use um controlador
Um controlador é um objeto que não é de interface GUI responsável pelo tratamento de eventos do sistema
Um controlador define métodos para as operações do sistema
Atribuir a responsabilidade pelo tratamento de eventos do sistema a uma classe de acordo com uma das alternativas abaixo:
Representa o "sistema" como um todo (facade controller)
Representa o negócio ou organização como um todo (facade controller)
Representa algo no mundo real que é ativo (por exemplo, o papel de uma pessoa) que poderia estar envolvido na tarefa (role controller)
Representa um handler artificial de todos os eventos do sistema para um Use Case particular, normalmente chamado "Handler" (use case controller)
Exemplo
No estudo de caso, há várias operações de sistema:
Quem deveria ser o controlador para os eventos do sistema?
Pelo padrão Controller, temos as seguintes alternativas:
Representa o "sistema": TPDV
Representa o negócio ou organização: Loja
Representa algo no mundo real ...: Caixa
Representa um handler artificial ...: CompraItemHandler
A escolha particular depende de fatores discutidos na seção Discussão
Por exemplo, se fosse TPDV, teríamos:
Discussão
De forma geral, o mesmo controlador deve ser usado para todas as operações de um mesmo Use Case de forma a manter a informação de estado do Use Case
A informação de estado pode ser útil para detectar sequências erradas de eventos de sistema
Exemplo: façaPagamento() antes de fimDeVenda()
Não coloque toda a inteligência no controlador
Delegue para outros objetos,para manter coesão
Use um Handler artificial quando as outras alternativas exibem acoplamento alto ou coesão baixa
Quando está surgindo um "God class"
Usado em sistemas mais complexos
Observe que classes "Window", "Applet", "Application", "View", "Document" não devem ser controladores
Tais classes podem receber o evento e delegá-lo ao controlador
Não se deve colocar business logic num objeto de interface com o usuário
Um design correto seria:
Um design incorreto seria:
O Role Controller pode levar a um mau projeto
O fato de algo ser feito por uma pessoa no mundo real não necessariamente significa que isso é uma boa alternativa em software
É mais comum "dar vida aos objetos" (não animados)
Consequências
Maior possibilidade de reuso, já que o business logic não está nos objetos de interface
Exemplo: embutir o business logic num objeto de interface não permitiria fazer EAI (Enterprise Application Integration)
Ajuda a verificar o sequenciamento das operações do sistema, através do estado do controlador
Responsabilidades, Role Playing e Cartões CRC
Embora não faça parte de UML, uma técnica chamada Cartões CRC é muito usada para atribuir responsabilidades durante o projeto
CRC = Class-Responsibility-Collaborations
CRC cards inventadas por Ward Cunningham e Kent Beck (Tektronix)Cartão CRC é um cartão pequeno (para só escrever o essencial) para cada classe
Escreve-se o nome da classe, suas responsabilidades e colaborações
Só pense nas responsabilidades de alto nível
São desenvolvidos em pequenos grupos em que cada pessoa assume o papel (Role) de uma ou mais classes
Mais detalhes aqui:
Designing Object-Oriented Software, Wirfs-Brock, Wilkerson e Wiener; Prentice Hall, 1990.
Algumas pessoas acham que é melhor usar ferramentas gráficas em vez de CRC Controller
Problema
Quem deveria receber a responsabilidade de tratar eventos do sistema?
Um evento do sistema é um evento de alto nível gerado por um ator externo
Estão associados a operações do sistema que já vimos nos Diagramas de Sequência do Sistema
Exemplo do estudo de caso: Caixa pressiona "Fim de venda"
Solução
Use um controlador
Um controlador é um objeto que não é de interface GUI responsável pelo tratamento de eventos do sistema
Um controlador define métodos para as operações do sistema
Atribuir a responsabilidade pelo tratamento de eventos do sistema a uma classe de acordo com uma das alternativas abaixo:
Representa o "sistema" como um todo (facade controller)
Representa o negócio ou organização como um todo (facade controller)
Representa algo no mundo real que é ativo (por exemplo, o papel de uma pessoa) que poderia estar envolvido na tarefa (role controller)
Representa um handler artificial de todos os eventos do sistema para um Use Case particular, normalmente chamado "Handler" (use case controller)
Exemplo
No estudo de caso, há várias operações de sistema:
Quem deveria ser o controlador para os eventos do sistema?
Pelo padrão Controller, temos as seguintes alternativas:
Representa o "sistema": TPDV
Representa o negócio ou organização: Loja
Representa algo no mundo real ...: Caixa
Representa um handler artificial ...: CompraItemHandler
A escolha particular depende de fatores discutidos na seção Discussão
Por exemplo, se fosse TPDV, teríamos:
Discussão
De forma geral, o mesmo controlador deve ser usado para todas as operações de um mesmo Use Case de forma a manter a informação de estado do Use Case
A informação de estado pode ser útil para detectar sequências erradas de eventos de sistema
Exemplo: façaPagamento() antes de fimDeVenda()
Não coloque toda a inteligência no controlador
Delegue para outros objetos,para manter coesão
Use um Handler artificial quando as outras alternativas exibem acoplamento alto ou coesão baixa
Quando está surgindo um "God class"
Usado em sistemas mais complexos
Observe que classes "Window", "Applet", "Application", "View", "Document" não devem ser controladores
Tais classes podem receber o evento e delegá-lo ao controlador
Não se deve colocar business logic num objeto de interface com o usuário
Um design correto seria:
Um design incorreto seria:
O Role Controller pode levar a um mau projeto
O fato de algo ser feito por uma pessoa no mundo real não necessariamente significa que isso é uma boa alternativa em software
É mais comum "dar vida aos objetos" (não animados)
Consequências
Maior possibilidade de reuso, já que o business logic não está nos objetos de interface
Exemplo: embutir o business logic num objeto de interface não permitiria fazer EAI (Enterprise Application Integration)
Ajuda a verificar o sequenciamento das operações do sistema, através do estado do controlador
Responsabilidades, Role Playing e Cartões CRC
Embora não faça parte de UML, uma técnica chamada Cartões CRC é muito usada para atribuir responsabilidades durante o projeto
CRC = Class-Responsibility-Collaborations
CRC cards inventadas por Ward Cunningham e Kent Beck (Tektronix)Cartão CRC é um cartão pequeno (para só escrever o essencial) para cada classe
Escreve-se o nome da classe, suas responsabilidades e colaborações
Só pense nas responsabilidades de alto nível
São desenvolvidos em pequenos grupos em que cada pessoa assume o papel (Role) de uma ou mais classes
Mais detalhes aqui:
Designing Object-Oriented Software, Wirfs-Brock, Wilkerson e Wiener; Prentice Hall, 1990.
Algumas pessoas acham que é melhor usar ferramentas gráficas em vez de CRC
Problema
Quem deveria receber a responsabilidade de tratar eventos do sistema?
Um evento do sistema é um evento de alto nível gerado por um ator externo
Estão associados a operações do sistema que já vimos nos Diagramas de Sequência do Sistema
Exemplo do estudo de caso: Caixa pressiona "Fim de venda"
Solução
Use um controlador
Um controlador é um objeto que não é de interface GUI responsável pelo tratamento de eventos do sistema
Um controlador define métodos para as operações do sistema
Atribuir a responsabilidade pelo tratamento de eventos do sistema a uma classe de acordo com uma das alternativas abaixo:
Representa o "sistema" como um todo (facade controller)
Representa o negócio ou organização como um todo (facade controller)
Representa algo no mundo real que é ativo (por exemplo, o papel de uma pessoa) que poderia estar envolvido na tarefa (role controller)
Representa um handler artificial de todos os eventos do sistema para um Use Case particular, normalmente chamado "
Exemplo
No estudo de caso, há várias operações de sistema:
Quem deveria ser o controlador para os eventos do sistema?
Pelo padrão Controller, temos as seguintes alternativas:
Representa o "sistema": TPDV
Representa o negócio ou organização: Loja
Representa algo no mundo real ...: Caixa
Representa um handler artificial ...: CompraItemHandler
A escolha particular depende de fatores discutidos na seção Discussão
Por exemplo, se fosse TPDV, teríamos:
Discussão
De forma geral, o mesmo controlador deve ser usado para todas as operações de um mesmo Use Case de forma a manter a informação de estado do Use Case
A informação de estado pode ser útil para detectar sequências erradas de eventos de sistema
Exemplo: façaPagamento() antes de fimDeVenda()
Não coloque toda a inteligência no controlador
Delegue para outros objetos,para manter coesão
Use um Handler artificial quando as outras alternativas exibem acoplamento alto ou coesão baixa
Quando está surgindo um "God class"
Usado em sistemas mais complexos
Observe que classes "Window", "Applet", "Application", "View", "Document" não devem ser controladores
Tais classes podem receber o evento e delegá-lo ao controlador
Não se deve colocar business logic num objeto de interface com o usuário
Um design correto seria:
Um design incorreto seria:
O Role Controller pode levar a um mau projeto
O fato de algo ser feito por uma pessoa no mundo real não necessariamente significa que isso é uma boa alternativa em software
É mais comum "dar vida aos objetos" (não animados)
Consequências
Maior possibilidade de reuso, já que o business logic não está nos objetos de interface
Exemplo: embutir o business logic num objeto de interface não permitiria fazer EAI (Enterprise Application Integration)
Ajuda a verificar o sequenciamento das operações do sistema, através do estado do controlador
Responsabilidades, Role Playing e Cartões CRC
Embora não faça parte de UML, uma técnica chamada Cartões CRC é muito usada para atribuir responsabilidades durante o projeto
CRC = Class-Responsibility-Collaborations
CRC cards inventadas por Ward Cunningham e Kent Beck (Tektronix)Cartão CRC é um cartão pequeno (para só escrever o essencial) para cada classe
Escreve-se o nome da classe, suas responsabilidades e colaborações
Só pense nas responsabilidades de alto nível
São desenvolvidos em pequenos grupos em que cada pessoa assume o papel (Role) de uma ou mais classes
Mais detalhes aqui:
Designing Object-Oriented Software, Wirfs-Brock, Wilkerson e Wiener; Prentice Hall, 1990.
Algumas pessoas acham que é melhor usar ferramentas gráficas em vez de CRC Controller
Problema
Quem deveria receber a responsabilidade de tratar eventos do sistema?
Um evento do sistema é um evento de alto nível gerado por um ator externo
Estão associados a operações do sistema que já vimos nos Diagramas de Sequência do Sistema
Exemplo do estudo de caso: Caixa pressiona "Fim de venda"
Solução
Use um controlador
Um controlador é um objeto que não é de interface GUI responsável pelo tratamento de eventos do sistema
Um controlador define métodos para as operações do sistema
Atribuir a responsabilidade pelo tratamento de eventos do sistema a uma classe de acordo com uma das alternativas abaixo:
Representa o "sistema" como um todo (facade controller)
Representa o negócio ou organização como um todo (facade controller)
Representa algo no mundo real que é ativo (por exemplo, o papel de uma pessoa) que poderia estar envolvido na tarefa (role controller)
Representa um handler artificial de todos os eventos do sistema para um Use Case particular, normalmente chamado "
Exemplo
No estudo de caso, há várias operações de sistema:
Quem deveria ser o controlador para os eventos do sistema?
Pelo padrão Controller, temos as seguintes alternativas:
Representa o "sistema": TPDV
Representa o negócio ou organização: Loja
Representa algo no mundo real ...: Caixa
Representa um handler artificial ...: CompraItemHandler
A escolha particular depende de fatores discutidos na seção Discussão
Por exemplo, se fosse TPDV, teríamos:
Discussão
De forma geral, o mesmo controlador deve ser usado para todas as operações de um mesmo Use Case de forma a manter a informação de estado do Use Case
A informação de estado pode ser útil para detectar sequências erradas de eventos de sistema
Exemplo: façaPagamento() antes de fimDeVenda()
Não coloque toda a inteligência no controlador
Delegue para outros objetos,para manter coesão
Use um Handler artificial quando as outras alternativas exibem acoplamento alto ou coesão baixa
Quando está surgindo um "God class"
Usado em sistemas mais complexos
Observe que classes "Window", "Applet", "Application", "View", "Document" não devem ser controladores
Tais classes podem receber o evento e delegá-lo ao controlador
Não se deve colocar business logic num objeto de interface com o usuário
Um design correto seria:
Um design incorreto seria:
O Role Controller pode levar a um mau projeto
O fato de algo ser feito por uma pessoa no mundo real não necessariamente significa que isso é uma boa alternativa em software
É mais comum "dar vida aos objetos" (não animados)
Consequências
Maior possibilidade de reuso, já que o business logic não está nos objetos de interface
Exemplo: embutir o business logic num objeto de interface não permitiria fazer EAI (Enterprise Application Integration)
Ajuda a verificar o sequenciamento das operações do sistema, através do estado do controlador
Responsabilidades, Role Playing e Cartões CRC
Embora não faça parte de UML, uma técnica chamada Cartões CRC é muito usada para atribuir responsabilidades durante o projeto
CRC = Class-Responsibility-Collaborations
CRC cards inventadas por Ward Cunningham e Kent Beck (Tektronix)Cartão CRC é um cartão pequeno (para só escrever o essencial) para cada classe
Escreve-se o nome da classe, suas responsabilidades e colaborações
Só pense nas responsabilidades de alto nível
São desenvolvidos em pequenos grupos em que cada pessoa assume o papel (Role) de uma ou mais classes
Mais detalhes aqui:
Designing Object-Oriented Software, Wirfs-Brock, Wilkerson e Wiener; Prentice Hall, 1990.
Algumas pessoas acham que é melhor usar ferramentas gráficas em vez de CRC
domingo, 23 de março de 2008
AULA 11, 12 e 13 - ACOPLAMENTO DE CONTROLE
Acoplamento de controle
Passar flags de controle entre objetos de forma que um objeto controle as etapas de processamento de outro objeto
Ocorrência comum:
Objeto a manda uma mensagem para objeto b
b usa um parâmetro da mensagem para decidir o que fazer class Lampada {
public final static int ON = 0;
public void setLampada(int valor) {
if(valor == ON) {
// liga lampada
} else if(valor == 1) {
// desliga lampada
} else if(valor == 2) {
// pisca
}
}
}
Lampada lampapa = new Lampada();
lampada.setLampada(Lampada.ON);
lampada.setLampada(2);
Solução: decompor a operação em múltiplas operações primitivas class Lampada {
public void on() { // liga lampada }
public void off() { // desliga lampada }
public void pisca() { // pisca }
}
Lampada lampada = new Lampada();
lampada.on();
lampada.pisca();
Ocorrência comum:
Objeto a manda mensagem para objeto b
b retorna informação de controle para a
Exemplo: retorno de código de erro class Teste {
public int printFile(File aImprimir) {
if(aImprimir está corrompido ) {
return CORRUPTFLAG;
}
// etc. etc.
}
}
Teste umTeste = new Teste();
int resultado = umTese.printFile(miniTeste);
if(resultado == CORRUPTFLAG) {
// oh! oh!
} else if(resultado == -243) {
// etc. etc.
Solução: use exceções class Teste {
public int printFile(File aImprimir) throws PrintExeception {
if(aImprimir está corrompido ) {
throw new PrintExeception();
}
// etc. etc.
}
}
try {
Teste umTeste = new Teste();
umTeste.printFile(miniTeste);
} catch(PrintException printError) {
// mail para a turma: não tem miniteste amanhã!
}
Passar flags de controle entre objetos de forma que um objeto controle as etapas de processamento de outro objeto
Ocorrência comum:
Objeto a manda uma mensagem para objeto b
b usa um parâmetro da mensagem para decidir o que fazer class Lampada {
public final static int ON = 0;
public void setLampada(int valor) {
if(valor == ON) {
// liga lampada
} else if(valor == 1) {
// desliga lampada
} else if(valor == 2) {
// pisca
}
}
}
Lampada lampapa = new Lampada();
lampada.setLampada(Lampada.ON);
lampada.setLampada(2);
Solução: decompor a operação em múltiplas operações primitivas class Lampada {
public void on() { // liga lampada }
public void off() { // desliga lampada }
public void pisca() { // pisca }
}
Lampada lampada = new Lampada();
lampada.on();
lampada.pisca();
Ocorrência comum:
Objeto a manda mensagem para objeto b
b retorna informação de controle para a
Exemplo: retorno de código de erro class Teste {
public int printFile(File aImprimir) {
if(aImprimir está corrompido ) {
return CORRUPTFLAG;
}
// etc. etc.
}
}
Teste umTeste = new Teste();
int resultado = umTese.printFile(miniTeste);
if(resultado == CORRUPTFLAG) {
// oh! oh!
} else if(resultado == -243) {
// etc. etc.
Solução: use exceções class Teste {
public int printFile(File aImprimir) throws PrintExeception {
if(aImprimir está corrompido ) {
throw new PrintExeception();
}
// etc. etc.
}
}
try {
Teste umTeste = new Teste();
umTeste.printFile(miniTeste);
} catch(PrintException printError) {
// mail para a turma: não tem miniteste amanhã!
}
AULA 9 E 10 - GRASP Padrão criador cont
//METODO ACESSOR
public string getDescricao() {
return Descricao;
}
//METODO MUTATORIO
Public void setDescricao(string valor) {
descricao = valor;
}
Public class itemvenda() {
Private double qtde;
Private produto P;
}
public void setP(produto p) {
this.p = p;
}
Public classe venda() {
//Porque usa set? Baixo acomplamento porque a HASH está ligada na SET.
Private set itemvendalist = new hashset();
Private date Datavenda;
Private integer idvenda;
Public criaritemvenda(produto,double qtde) {
itemvenda i = new itemvenda() ;
i.set(p);
i.setqtde(qtde);
itemvendalist.add(i);
}
public string getDescricao() {
return Descricao;
}
//METODO MUTATORIO
Public void setDescricao(string valor) {
descricao = valor;
}
Public class itemvenda() {
Private double qtde;
Private produto P;
}
public void setP(produto p) {
this.p = p;
}
Public classe venda() {
//Porque usa set? Baixo acomplamento porque a HASH está ligada na SET.
Private set
Private date Datavenda;
Private integer idvenda;
Public criaritemvenda(produto,double qtde) {
itemvenda i = new itemvenda() ;
i.set(p);
i.setqtde(qtde);
itemvendalist.add(i);
}
AULA 7 E 8 - GRASP Padrão criador
Problema: Quem deve criar novas instancias de uma classe?
Solução: Atribuir a classe B a resonsabilidade de criar instancias de A quando.
a) B agrega objetos de classe A
b) B contém instancias de A
c) B usa uma coleção de A
d) B possui os dados para criar A
B é criador de A se mais de uma opção se aplica
Exemplo
No estudo de caso, quem deveria criar uma instância de LinhaDetalheVenda?
Pelo padrão Creator, precisamos achar alguém que agrega, contém, ... instâncias de LinhaDetalheVenda
Considere o modelo conceitual parcial abaixo:
Venda agrega instâncias de LinhaDetalheVenda e é portanto um bom candidato para criar as instâncias
Chegamos aos seguintes diagramas:
Discussão
Escolhemos um criador que deve estar conectado ao objeto criado, de qualquer forma, depois da criação
Isso leva a fraco acoplamento
Exemplo de criador que possui os valores de inicialização
Uma instância de Pagamento deve ser criada
A instância deve receber o total da venda
Quem tem essa informação? Venda
Venda é um bom candidato para criar objetos da classe Pagamento
Consequências
Fraco acoplamento, já que o objeto criado deve normalmente ser visível ao criador, depois da criação
Solução: Atribuir a classe B a resonsabilidade de criar instancias de A quando.
a) B agrega objetos de classe A
b) B contém instancias de A
c) B usa uma coleção de A
d) B possui os dados para criar A
B é criador de A se mais de uma opção se aplica
Exemplo
No estudo de caso, quem deveria criar uma instância de LinhaDetalheVenda?
Pelo padrão Creator, precisamos achar alguém que agrega, contém, ... instâncias de LinhaDetalheVenda
Considere o modelo conceitual parcial abaixo:
Venda agrega instâncias de LinhaDetalheVenda e é portanto um bom candidato para criar as instâncias
Chegamos aos seguintes diagramas:
Discussão
Escolhemos um criador que deve estar conectado ao objeto criado, de qualquer forma, depois da criação
Isso leva a fraco acoplamento
Exemplo de criador que possui os valores de inicialização
Uma instância de Pagamento deve ser criada
A instância deve receber o total da venda
Quem tem essa informação? Venda
Venda é um bom candidato para criar objetos da classe Pagamento
Consequências
Fraco acoplamento, já que o objeto criado deve normalmente ser visível ao criador, depois da criação
domingo, 24 de fevereiro de 2008
AULA 5 E 6 - GRASP
Grasp = General Responsability Assignement
5 formas que um sistema Grasp deve apresentar
1 - Especialista
2 - Criador
3 - Alta coesão
4 - Baixo Acoplamento
5 - Controlador
Tivemos um exemplo de um sistema especialista
Problema: A quem cabe a responsabilidade de conhecer?
Resposta: Atribuir a responsabilidade à classe que detém a informação
O que isso quiz dizer?
Que se deve ter um especialista(Classe) para cada funcionalidade do sistema, ou seja se precisamos fazer uma cirurgia de estomago, devemos ter um medico especializado em esse certo tipo de cirurgia, igual aos sistema, se desejarmos fazermos uma conta que envolva soma, devemos chamar a classe que efetua essa operação.
5 formas que um sistema Grasp deve apresentar
1 - Especialista
2 - Criador
3 - Alta coesão
4 - Baixo Acoplamento
5 - Controlador
Tivemos um exemplo de um sistema especialista
Problema: A quem cabe a responsabilidade de conhecer?
Resposta: Atribuir a responsabilidade à classe que detém a informação
O que isso quiz dizer?
Que se deve ter um especialista(Classe) para cada funcionalidade do sistema, ou seja se precisamos fazer uma cirurgia de estomago, devemos ter um medico especializado em esse certo tipo de cirurgia, igual aos sistema, se desejarmos fazermos uma conta que envolva soma, devemos chamar a classe que efetua essa operação.
A figura acima demonstra um sistema especialista.
Como dito em aula, a exemplo de um sistema de supermerado temos 3 funções ObterTotal, ObterSubTotaol e ObterPreco
ObterTotal: Essa função é encarregada por pegar a quantidade e multiplicar pelo total de itens mas para isso precisamos da função ObterSubTotal, pois é ela que contém a quantidade de itens que o cliente adiquiriu.
ObterSubTotal: Essa função é a responsável por contar quantos itens o cliente levou e até o item qual foi o valor de sua compra, mas para isso precisamos do preço de cada produto, por isso devemos chamar a função ObterPreço. Essa função é importantissima em um sistema de supermercado pois é ele que a partir de que o cliente vai passando os produtos pelo sistema, na tela vai apresentando até aquele produto qual foi o valor da compra até aquele momento, isso serve para aqueles que tem um limite de compra, se quizeram para por ali, podem parar pois estão vendo na tela quanto foi o valor até aquele item.
ObterPreço: É a função responsável por ter a descrição de cada produto e seu preço
Um Sistema especialista na informação é o padrão mais usado nos dias de hoje. A informação desse sistema frequentemente se encontra espalhada pela fraco acoplamento, e existem menssagens para estabelecer contato entre as colaborações.
ACOMPLAMENTO = DEPENDENCIA
Um Sistema especialista é uma classe de programa de computador desenvolvido por pesquisadores de Inteligência artificial durante os anos 70 (1970) e aplicado comercialmente durante os anos 80 (1980). Em síntese, são programas constituídos por uma série de regras que analisam informações (normalmente fornecidas pelo usuário do sistema) sobre uma classe específica de problema (ou domínio de problema).
Um termo relacionado é wizard (software) (em inglês). Como um sistema especialista, um wizard também é um programa de computador interativo que auxilia o usuário a resolver um problema. Normalmente, o termo wizard é empregado para designar programas que pesquisam uma base de dados procurando por critérios informados pelo usuário. Infelizmente, a distinção entre essas duas definições não é universal, e alguns programas baseados em regras são também chamados de wizards.
Tipos de problemas solucionados por sistemas especialistas
Tipicamente, os problemas que podem ser solucionados por um sistema especialista são do tipo que seria atendido por um especialista humano - um médico ou outro profissional ( na maioria dos casos ). Especialistas reais no domínio do problema ( que normalmente é bem específico, como por exemplo "'diagnosticar doenças de pele em adolescentes'" ) fornecem regras gerais indicando como analisariam o problema, tanto explicitamente com a ajuda de um analista de sistema experiente, como implicitamente, fazendo com que estes especialistas analisem casos de teste e usando programas de computador para analisar os dados de teste e, de forma limitada, derivar regras dessa análise.
Sistemas simples utilizam uma lógica verdadeiro/falso simples para analisar os dados. Por outro lado, sistemas mais sofisticados são capazes de realizar pelo menos alguma avaliação levando em consideração incertezas do mundo real, utilizando métodos como lógica fuzzy. Tal sofisticação é de desenvolvimento difícil e ainda extremamente imperfeita.
Aplicação
Se por um lado sistemas especialistas se destacaram na pesquisa em IA por achar aplicação prática no mundo real, por outro lado essa aplicação tem sido restrita. Sistemas especialistas são notoriamente limitados no domínio do conhecimento - um exemplo interessante e divertido é aquele onde um pesquisador de IA utilizou o sistema especialista de "doença de pele" para diagnosticar sarampo em seu carro enferrujado - e portanto propenso a cometer erros que um especialista humano facilmente detectaria. Além disso, uma vez que a mística em torno do tema diminuiu, vários programadores perceberam que sistemas especialistas simples eram essencialmente versões ligeiramente mais elaboradas de programas procedurais que eles já vinham utilizando há bastante tempo. Sendo assim, algumas das técnicas de sistemas especialistas podem ser encontradas em vários programas complexos sem qualquer alarde em relação a isso.
Sistemas especialistas versus sistemas de solução de problemas
A principal diferença entre um sistema especialista e um programa tradicional está na maneira como o conhecimento sobre o domínio do problema é codificado. Em aplicações tradicionais, o conhecimento sobre o domínio do problema é codificado tanto nas instruções propriamente ditas quanto nas estruturas de dados.
Já na abordagem de sistema especialista, todo o conhecimento relativo ao domínio do problema é codificado exclusivamente nas estruturas de dados. Nenhum conhecimento é armazenado nas instruções ou nos programas propriamente ditos. Vários benefícios surgem imediatamente dessa estratégia.
Um exemplo pode ajudar a destacar a diferença entre a abordagem procedural tradicional e a abordagem de sistemas especialistas, como o exemplo do problema da declaração de imposto de renda.
Na abordagem tradicional, as estruturas de dados armazenam as informações do contribuinte e das alíquotas de imposto, e um programa representa o conhecimento necessário para a declaração de imposto de renda, contendo os comandos que relacionam as informações do contribuinte com as alíquotas e os cálculos necessários para realizar a declaração. É essa representação do conhecimento que é difícil para um especialista em impostos compreender ou modificar.
Na abordagem de sistema especialista, a informação sobre o contribuinte e as alíquotas, bem como os cálculos necessários, estão novamente armazenadas em estruturas de dados, mas o conhecimento que descreve o relacionamento entre elas também é armazenado nas estruturas de dados. O programa de um sistema especialista é independente do conhecimento do domínio do problema ( no nosso exemplo, do conhecimento das alíquotas e rendas do contribuinte e do relacionamento entre elas, os cálculos ) e serve para processar estruturas de dados independente da natureza do problema que essas estruturas descrevem.
Por exemplo, há programas interativos específicos para capturar descrição de dados, programas para capturar e organizar as descrições, programas para processar as declarações que representam relacionamentos semânticos dentro do domínio do problema e um algorítimo para controlar a sequência de processamento e o foco.
A arquitetura geral de um sistema especialista compreende dois componentes principais : um conjunto de declarações totalmente dependentes do domínio do problema e que é chamado de base de conhecimento ou base de regras, e um programa independente do domínio do problema ( apesar de altamente dependente das estruturas de dados ) chamado de motor de inferência.
Bibliografia:
Professor Bosco
Assinar:
Postagens (Atom)