Aula 30 - Spring

Spring

Spring possui uma arquitetura baseada em interfaces e POJOS (Plain Old Java Objescts), oferendo aos POJOS características como mecanismos de segurança e controle de transações. Também facilita testes unitários e surge como uma alternativa à complexidade existente no uso de EJBs.
Ele foi criado para endereçar a complexidade de desenvolvimento de aplicativos enterprise.
Uma assunto legal para endentemos melhor Spring saber também que é Framework é uma estrutura de suporte definida em que um outro projeto de software pode ser organizado e desenvolvido. Um framework pode incluir programas de suporte, bibliotecas de código, linguagens de script e outros softwares para ajudar a desenvolver e juntar diferentes componentes de um projeto de software.
Frameworks são projetados com a intenção de facilitar o desenvolvimento de software, habilitando designers e programadores a gastarem mais tempo determinando as exigências do software do que com detalhes de baixo nível do sistema.

Bibliografia: Conhecimento apresentado na sala de aula pelo Professor João Bosco e www.javafree.org/wiki/Spring

Aula 29 - XP – Extreme Programing

XP – Extreme Programing

É uma metodologia de desenvolvimento de software, nascida nos EUA ao final da década de 90 e a parti desse momento que ela surgiu ela esta fazendo muito sucesso.
Mas que é XP – Extreme Programing?
Ou seja, e uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos realização de vários pequenos ajustes durante o desenvolvimento de software.

Extreme Programming, ou XP, é um processo de desenvolvimento de software 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 a ser implementado logo no início do projeto e vai ganhando novas funcionalidades ao longo do tempo.

Os quatro valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback e coragem. A partir desses valores, possui como princípios básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade.
Vejamos alguns valores XP deles:

- Comunicação: O cliente de um projeto de software tem um conjunto de problemas que deseja solucionar com o sistema em desenvolvimento e possui algumas idéias sobre que funcionalidades podem resolvê-los. Por sua vez, desenvolvedores possuem conhecimento sobre aspectos técnicos que influenciam a forma de solucionar o problema do cliente. Para que os desenvolvedores compreendam o que o cliente deseja e este último entenda os desafios técnicos que precisam ser vencidos, é preciso que haja comunicação entre as partes.

- Coragem: Costuma-se dizer que a única constante em um projeto de software é a mudança. Clientes mudam de idéia com freqüência, mesmo quando fecham contratos nos quais, teoricamente, assumem o compromisso de não alterar o que está na especificação. Eles mudam porque aprendem durante o projeto e descobrem problemas mais prioritários a serem solucionados ou formas mais apropriada de resolvê-los. Embora isso seja natural, gera uma preocupação para a equipe de desenvolvimento que, de tempos em tempos, precisa alterar partes do sistema que já estavam prontas, correndo o risco de se quebrar o que já vinha funcionando.

- Feedback: Algumas pessoas seriam capazes de caminhar na beirada de um precipício com os olhos fechados, ou colocar a maior parte do seu dinheiro em um investimento com elevada chance de prejuízo sem acompanhá-lo de perto. Entretanto, a maioria das pessoas provavelmente manteria os olhos bem abertos em ambos os casos. Isso é particularmente verdade no caso de equipes trabalhando com XP. Elas acreditam que projetos de software são iniciativas freqüentemente caras, arriscadas e com um histórico repleto de falhas, o que as leva a simples conclusão de que provavelmente o projeto em que estão envolvidas também enfrentará falhas e problemas, como é habitual na área de software.

- Simplicidade: Programar apenas o que é necessário hoje.

Bibliografia: Apostila,pt.wikipedia.org/wiki/Programação_extrema

Aula 28 - Variação Protegida

Variação protegida

Solução:

Identificar pontos de variação, ou seja, atribuir responsabilidade para criar interface estável em torno deles.

Pois este padrão tem um princípio básico da VP é manter a flexibilidade e proteção nas aplicações dos sistemas.

Pois um pode citar alguns de seus mecanismos de VP que são:

Projetos dirigidos por dados: eles são usados para mudar o comportamento do sistema ou talvez impondo padrões em tempo de execução. Ex – XML e WEB-XML.

Pesquisa de serviço: Inclui técnicas como o uso de serviços de atribuição de nomes, um bom exemplo disso é o SOA (Analise Orientada a Serviços).

Projetos dirigidos por interpretador: são projetos baseados em regras de uma fonte externa, ou seja, é uma máquina virtual onde se coloca regras dentro dela e ela toma decisões em cima daquelas regras.

Projetos reflexivos ou meta-dados: funciona como uma substituição de métodos.

Acesso uniforme: ele valida as denominações dos tipos no código de qualquer maneira.

Pois existem também os agentes que são conhecidos como brokess e as máquinas virtuais.

Bibliografia: Livro: UTILIZANDO UML E PADRÕES - Craig Larman

Aula 27 - Indireção - Exemplo

Indireção


Um exemplo que podemos mostra:
Comunicação entre a classe Serviço de Autorização de crédito e o modem (dispositivo): criar a classe modem







Bibliografia: Apostila.

Aula 27 - Indireção

Indireção

Ola galera!

Então o tema que vamos falar agora vai ser sobre Indireção.
Indireção?

Suponha que a sua aplicação precisa manipular um modem para ter autorização de credito
Será que essas operações deveriam estar nas classes de domínio?
Na indireção você consegue evitar o acoplamento direto da seguinte forma atribuir a responsabilidade a um objeto intermediaria que faz a mediação entre os outros componentes, ou serviços.

Bibliografia: Fonte matéria mostrada em sala de aula e apostila

Aula 26 - Invenção Pura

Invenção Pura

É processo unificado que usa classes de domínio para programar.
Que suporta acoplamento fraco, reutilização, coesão alta. Pois ela atribui as responsabilidades principalmente ao especialista pode levar os problemas com acoplamento e coesão.

Problema se consiste em atribuir a responsabilidades quando as classes do domínio não são adequadas não se querem violar os princípios da Coesão Alta e do Acoplamento Fraco? Como criar componentes de software conectava?

Solução seria você atribuir um conjunto de responsabilidades altamente coeso a uma classe arterial-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).

Mas por lado a invenção Pura com ela você ter uma melhora no acoplamento e coesão, cria-se objetos mais genéricos e reutilizáveis e um ponto bem legal que ela é considerada como parte da camada de serviços de alto nível de Orientação a Objeto em uma arquitetura.

Bibliografia: Apostila GRASP

Aula 25 - Inversão de Controle e Injeção de Dependência

Inversão de Controle e Injeção de Dependência

É estamos chegando à reta final!

Agora iremos falar sobre a Inversão de Controle e Injeção de Dependência.

Injeção de Dependência ele é utilizado quando é necessário manter baixo o nível de acoplamento entre diferentes módulos de um sistema, pois nisso os módulos não são definidas programaticamente, mas sim pela configuração de uma infra-estrutura de software (container) que é responsável por injetar em cada componente suas dependências declaradas.
É um padrão que serve para resolver seguintes problemas como desacoplar os componentes de uma aplicação.

Um exemplo disso seria:

Imagine uma aplicação contendo apenas dois componentes: Titulo pulcio e preciifcador. Nessa aplicação, existe uma interface TituloPublico, que descreve operações que podem ser realizadas com TiuloPublico, como vender, comprar, etc. Para essa interface, existe um conjunto de classes que programam essa interface, tais como CDB, etc. Existe também uma interface chamada Precificador. A responsabilidade dessa interface é determinas um preço um determinado título. Essa divisão entre TituloRendaFixa e Precificador corresponde a um padrão de projeto chamado Estratégia, em que criamos uma hierarquia de classes separada para os algoritmos que manipulam os objetos de uma outra hierarquia de classes. Nesse exemplo, a interface Precificador descreve as várias estratégias possíveis de serem utilizadas no cálculo de preço de um determinado título. Como exemplo de algoritmos de precificação diferentes tem: preço de mercado, preço na curva, etc.
Veja que descrevemos tanto TituloRendaFixa como Precificador como interfaces. Uma classe que programe a interface TituloRendaFixa, como a classe TituloNTN não precisa depender diretamente de uma outra classe que programa a interface Precificador, como a classe PrecificadorMercado. TituloNTN deve ser dependente apenas da interface Precificador. A classe PrecificacorMercado também deve ser apenas dependente da interface TituloRendaFixa. Essa técnica de evitar dependências entre classes corresponde a um princípio de projeto, uma boa prática de projeto denominada “Inversão de Dependência”, que não deve ser confundida com “Inversão de Controle”.
Se, no modelo estático, não há dependências entre classes, no modelo de execução, em algum momento, um objeto da classe TituloNTN terá de receber uma referência para um objeto da classe PrecificadorMercado. Esse é o problema que a “Inversão de Controle” resolve: como injetar as dependências entre os objetos (classes), em tempo de execução? Como se trata de injetar dependências entre os objetos em tempo de execução, alguns preferem denominar o pattern “Injeção de Dependência”.

Fonte: Exemplo visto neste site www.alessandroribeiro.com/

Mas também temos Inversão de Controle é onde a seqüência de chamadas dos métodos não é determinada pelo programador. Este controle é delegado a uma infra-estrutura de software muitas vezes chamada container. Esta é uma característica comum aos frameworks.

A diferença entre os dois seria que a Inversão de Controle que da o primeiro sinal, ou seja, ela chama sendo então que você não precisa localizar ela para chamar e Injeção de dependência estimula o uso de abstrações em vez de uma classe concreta.

Bibliografia: Exemplos do site www.alessandroribeiro.com e material exibido na sala de aula.

Aula 24 - Padrão Polimorfismo

Padrão Polimorfismo


E capacidade de um objeto decidir qual método aplicara a si mesmo, dependendo de onde se encontra na hierarquia de herança, e chamada de polimorfismo. O polimorfismo funciona como uma ligação adiada, ou seja, compilador não gera o código para chamar um método com um objeto, o compilador gera o código para calcular qual método chamara,usando assim informação de tipo do objeto.

Os benefícios dele são:

- Ter uma 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 em que o novo servidor suporte as operações polimórficas esperadas pelo cliente.





Bibliografia: Apostila Padrões GRASP.

Aula 23 Padrão MVC

MVC

È um Padrão de arquitetura MVC é uma combinação de padrões centradas no padrão Observer.
O Padrão MVC que significa Model – View – Controller (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 desde padrão foi desenvolvida para mapear as tarefas tradicionais de entrada, processamento e saída para o modelo de interação com o usuário. Nesse padrão MVC ele representa os dados de aplicação e as regras do negócio e fornece ao controlador a capacidade de acessar as funcionalidades da aplicação encapsuladas pelo próprio modelo.


Ele consiste de três participantes que são:

* Model: 1 – modificar a view quando sofrer a alteração “Padrão observer”.
2 – armazenar o estado da aplicação
3 – responsável por armazenar regras de negócios

* View: 1 – enviar os dados para frame, ou seja, mostrar os dados.
2 - receber os dados do frame, mas não só os dados, mas também as ações.
3 - ao ser notificado solicita o controller a atualização de dados.

* Controller: 1- tratar os eventos da view. “Todos os casos de usos no sistema”.
2 – selecionar o que mostra na view.



Bibliografia: Apostila Mt Digital 2008 e opiniões próprias.

Aula 22 - Command

Padrão Command

O polimorfismo nos permite encapsular uma solicitação como um objeto: estabelecer a assinatura de um método a chamar e variar a implementação desse método.
Pois o padrão command nos permite encapsular uma solicitação, ou seja, um request como um objeto, com isso permitindo assim que clientes usem diversas solicitações diferentes, filas, façam logs e suportem operações de rollback.
Este padrão e conhecido também como action ou Transaction

Podemos ultilizar este Padrão Command quando você precisar usar as seguintes maneiras de aplicação:


- Parametrizar objetos por uma ação a ser executada
- Especificar, enfileirar e executar solicitações em tempos diferentes. Um objeto Command
Poder ter o ciclo de vida independente da requisição do cliente.
- Suporte para desfazer operações. A operação "execute" do Command, pode armazenar.
Estados para reverter seus efeitos no próprio comando. Basta acrescentar na interface
Command uma operação chamada "Unexecute", que terá a responsabilidade de desfazer a.
Operação realizada pelo "execute". Os comandos realizados podem ser armazenados em lista
Histórica.
- Estruturar um sistema em torno de operações de alto nível, como transações, por exemplo. Uma transação encapsula um conjunto de mudanças nos dados. O padrão
Command provê uma maneira de modelar transações. O Command tem uma interface comum,
Assim podemos chamar todas as transações do mesmo jeito.
- Reduzir acoplamento entre as requisições dos clientes e os objetos que as executam.

Bibliografia: Conteudo na sala de aula.

Aula 21 - Observer

Observer

Dependência de um-para-muitos entre objetos para que quando um objeto mudar de estado, todos os seus dependentes sejam notificados e atualizados automaticamente.

Vejamos bem este padrão pelo o nome já diz ele observa as mudanças ocorridas pelas classes e notificam os objetos sobre as mudanças que aconteceram.
Pois no observer temos que ter cuidado com o relacionamento (bidirecional) implica alto acoplamento que isso pode ser um do risco que Observer tem.
Mas por outro lado o Observer nos permite delinear a responsabilidade entre objetos de negócios e um Gui, o que nos possibilita estabelecer um projeto MVC, que permite criar camadas fracamente acopladas.

Algumas Vantagens:

· Tanto observadores quando sujeitos observados podem ser reutilizados e tiver sua interface implementação alteradas sem afetas o sistema
· O acoplamento forte implicado pelo relacionamento bidirecional é reduzido com o uso de interfaces classes abstratas


Desvantagens

· O Abuso pode causar serio impacto na performance.
· Sistemas onde todos notificam todos a cada mudança ficam inundados de requisições, ou seja, tempestade de eventos.

Bibliografia: Aposila e conteudo mostra em sala de aula.

Aula 20 - Padrão Singleton

Padrão singleton

E um padrão que garante a existência de apenas uma instancia de uma classe, mantendo um ponto global de acesso.

Algumas Vantagens do Singleton:

Pode vir a possuir subclasses , devido à utilização de métodos estáticos.

- Acesso a vários objetos

Desvantagens

- A sua implementação depende da linguagem utilizada

- Difícil de ser implementar em um ambiente distribuído

- Difícil de implementar em ambiente multithreaded

- De difícil teste , pois pode haver momentos em que suas aplicações dependam de uma instância extra.

Um exemplo de aplicação em Java em Singleton usado log de dados

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(); }}

Bibliografia: pt.wikipedia.org/wiki/Singleton.

Aula 19 - Padrão GOF(Gang of Four).

Padrão gof

Para endentemos bem este padrão temos que primeiramente sabe o que é padrão?

Padrão podemos dizer que é maneira de documentada de alcançar um objetivo qualquer, ou seja, padrões são comuns em varias áreas da engenharia.
Pois na para área de informática em desenvolvimento temos que endenter bem esta estudo sobre padrão Gof.

Pois cada padrão descreve um problema que ocorrem repetidas vezes em nosso ambiente, então descreve o núcleo da solução para aquele problema, de tal maneira que pode ser usado uma solução milhões de vezes sem nunca faze-la da mesma forma duas vezes.
Pois a necessita de aprender este padrão e muito importante a através do conhecimento que você pode adquirir sobre ele, porque em alguns casos você precisara resolver certos problemas em que se tiver um conhecimento amplo e certo neste assunto você consegue identificar problemas comuns em engenharia de software e utilizar soluções testadas e bem documentadas.
E tem muito, mas com isso você pode desenvolver software de melhor qualidade.
Mas por outro também você adquiri um amplo conhecimento sobre polimorfismo, herança, modular idade, composição e abstração com esta base você consegue desenvolver software de uma qualidade excelente.

Padrão Adapter

Converter a interface de uma classe em outra interface esperada pelos clientes. Abater permite a comunicação entre classes que não poderiam trabalhar juntas devido à incompatibilidade de suas interfaces.

Bibliografia: Apostila,www.javafree.org, conteudo mostrado em sala de aula.

Aula 16,17 e 18 - Padrão Controlador

Padrão Controlador

Este padrão atribui a responsabilidade de tratar um evento do sistema para uma classe controladora, pois ele e representado como um sistema como um todo, ou seja, controlador fachada, um negocio ou organização com um todo, uma coisa ou papel de uma pessoa do mundo real envolvida diretamente com a tarefa e por ultimo um tratador que pode ser conhecido como “handler”, ou seja, ele é um artificial para todos os eventos de um caso de uso que resumidamente quer dizer um controlador do caso de uso.
Também no padrão Controlador seus benefícios são maior chance de reuso e outro seria melhor controle sobre o estado do caso de uso. Mas também por outro lado temos que ter cuidados para utilizar este padrão como não sobrecarregar controlador com um numero excessivo de eventos, responsabilidades ou atributos, pois para evitar isso temos que adicionar, mas controladores ou delegar responsabilidades;
Outro ponto interresante seria evitar que o controlador seja representado como papeis de seres humanos, ou seja, que ocupa espaço ou faço coisa que esta delegada para os seres humanos, pois se isso acontecer o risco de baixa coesão; responsabilidades devem ser delegadas para objetos contendo a informação necessária como o padrão Especialista.

Aulas 14 e 15 - Coesão

Alta coesão

Problema e como gerenciar a complexidade: a coesão mede quão focada ou relacionada estão os módulos de uma classe.
Uma classe com baixa coesão faz muitas coisas não relacionadas. Tais classes são indesejáveis, pois sofrem dos seguintes problemas que são difíceis de compreender, difícil de reutilizar, difícil de manter e delicadas, ou seja, constantemente afetadas pelas mudanças.
As classes de coesão baixa geralmente representam um grau de abstração muito alto e de grande granularidade, ou então assumiram responsabilidades que deceriam ter sido delegadas a outros objetos.
Temos 4 tipos de coesão funcional que são:

Coesão muito baixa: uma única classe é responsável por muitas coisas em áreas funcional muito diferente.

Coesão Baixa: uma classe é a única responsável por uma tarefa não complexa em uma área funcional.

Coesão Alta: Uma classe tem responsabilidades moderadas e, uma área funcional e colabora com outras classes para realizar tarefas.

Coesão moderada: uma classe tem peso leve e responsabilidades exclusivas em algumas áreas logicamente relacionadas ao conceito da classe, mas não uma com a outra.

Coesão coincidental

Não existe nenhuma coesão entre os módulos, eles se agrupam por coincidências.

Coesão Lógica

Neste padrão tem que ser respeitado como um baixo acoplamento, pois a alta coesão deve ser mantida dentro do método.

Coesão Temporal

Os módulos estão coesos, por algum evento temporal.

Coesão comunicação

São os métodos que agem sobre o mesmo dado, mas isso não significa que sejam métodos coesos, portanto não deveriam estar juntos.

Coesão seqüencial

Nela os módulos estão juntos apenas porque a saída de um é à entrada do outro.

Coesão Funcional

Os módulos estão coesos de tal forma a trabalhar num mesmo objetivo, ou seja, todos os métodos estão focados em um único objetivo.
Coesão Procedural

Faz com que os módulos se agrupem por procedimentos, mesmo não sendo coesos.

Aulas 12 e 13 - Acoplamentos

Acoplamento de controle

Ocorre quando se quer flags de controle entre objetos de forma em que um controla o outro objeto.
Neste acoplamento uma classe tem o pode ser de controlar o comportamento de outra classe.

Acoplamento de dados globais

Ocorre quando dois ou mais objetos compartilham os mesmos dados.

Acoplamento de dados internos

Um objeto altera os dados locais de outro objeto
Dados protected e públicos em Java

Aula 10 e 11 - Acoplamento Fraco

Nestas aulas apreendemos sobre acoplamento fraco que é uma forma de atribuir uma responsabilidade de maneira que o acoplamento permaneça fraco. O acoplamento fraco é um principio a ser levado em conta em todas as decisões de projeto. Ele e tipo um objeto que deve estar sempre em mente
O acoplamento fraco estimula a atribuição de uma responsabilidade de maneira que a sua colocação não aumente o acoplamento ate um nível que conduza aos resultados negativos de um acoplamento forte. Mas o acoplamento fraco favorece o projeto de classes que são mais independente, o que reduz o impacto das mudanças. Ele não pode ser considerado isoladamente de outros padrões como especialistas e a coesão alta, mas em vez disso precisa ser incluído como um entre vários princípios de projetos que influenciam uma escolha na atribuição de umas responsabilidades. Existe um extremo de acoplamento fraco que é queda não existe acoplamento entre as classes, ou seja, não é desejável porque a metáfora da tecnologia de objetos é que um sistema é composto de objetos conectados que se comunica por mensagens. Por isso caso se o acoplamento fraco for aplicado em demasia, levará há um projeto pobre, com poucos objetos ativos, sem coesão.

Aula 8 e 9- Padrão Criador

Nestas aulas compreendi que os métodos Set e Get eles tem como característica de transforma os dados que estão privados em public.
Como neste exemplo:

public class Produto
private Integer idProduto;
private String descricao;
private Double valorUnitario;

public String getDescricao( ){
Return descrição;
}public void setDescricao (String descricao){
This.descricao= descricao;
}

Também foi falado sobre os probelmas da rain que é ela tem 3 dimensões e não pode ser aumentado. Outra coisa foi que as interface não pode ser instanciadas.

Aula 6 e 7 - Padrão Criador

A criação de objetos e uma das atividades, mas comuns em um sistema. O padrão criador guia a atribuição de responsabilidades relacionadas com a criação de objetos, uma tarefa muito comum. Tem um objeto básico que é encontra um criador que garante um acoplamento fraco. Mas também algumas vezes um criador e encontrado ao olhar a classe que tem os dados inicias que serão passados na criação. Esse é na realidade um exemplo do padrão especialista. Dados de iniciação são passados durante a criação por meio de algum método de iniciação, como um construtor em Java, ou seja, um que contém parâmetros. Um exemplo disso seria uma instância de pagamento recente a ser iniciada, quando o criada com o total de venda. Uma vez que a venda sabe o total, é uma candidata à criadora do Pagamento.
Para utilizar o padrão criador não fácil, porque muitas vezes a criação é uma tarefa complexa que exige uso de instâncias recicladas por motivo de desempenho, eventualmente criando uma instância de uma família de classes similares com base no valor de alguma propriedade externa, e assim por diante. Nesses casos, é aconselhável delegar a criação para uma classe auxiliar chamada Fábrica, em vez de usar a classe sugerida pelo criador.
Mas por outro lado o padrão criador favorece o acoplamento Fraco, e o que implica em menor desempenho para a manutenção e maiores oportunidades de reutilização.

Aula 5 Grasp

Nesta aula aprendemos sobre GRASP que é Projetos de Objetos atribuição de responsabilidades.Nele você pode define os padrões e saber como usar os cinco padrões GRASP.Com isso podemos define a responsabilidade e métodos que serão usados, pois a responsabilidade se deve as obrigações dos objetos em termos de comportamento e nisso temos dois tipos de obrigação há de conhecer (saber), ou seja, nada, mas é que a obrigação de saber os objetos relacionados que serão usados como;
- Ter conhecimento sobre informações que ela pode calcular ou derivar e também conhecimento sobre os dados privados, ou seja, dados encapsulados;
E a outra forma de obrigação e de fazer esta obrigação deve ser trata da seguinte forma nela temos que pensar da seguinte maneira quando estamos fazendo algo que temos executar e nisso em que se encaixa está obrigação, pois nela temos os seguintes aspectos como:
- Fazer algo tal como criar um objeto (executar em calculo); controlar os objetos; iniciar uma ação nos outros objetos.
A responsabilidade sempre está relacionada ao saber, pois como vimos em que a obrigação tem dois tipos a responsabilidade também possui diferentes granularidades e nesse caso temos há granularidades de alta e baixa a diferença de ambas e que a de alta envolve e pode ter várias classes ou vários métodos ao contraria da baixa que pode ter alguns métodos. Com isso analisamos que as responsabilidades não e a mesma coisa que método porem são criados para satisfazer as responsabilidades.
Nos padrões Grasp temos cinco primeiros fundamentos de projetos baseados em objetos e atribuição, pois eles são: especialista ,criador,coesão,acoplamento e controlador. No especialista informação temos que observa bem pois podemos tratar os problemas pois encima deles teremos que acha a solução correta pois estamos tratado isso como uma informação necessária para obtermos o total. Com isso podemos dizer que o problema será?
Qual é o principio básico da atribuição de responsabilidades o objetos?
Aquém cabe qual responsabilidade?
A solução seria atribuir a responsabilidades ao especialista; a classe que tem a informação necessária para satisfazer a responsabilidade.

Diagramas de Interação Colaboração e Sequência

Nesta aula aprendemos como que as mensagens interagem entre os objetos, pois entre nessa interação existe dois diagramas um de colaboração e outro de seqüência. O diagrama de colaboração mostra como a mensagem trafega em um gráfico ou rede, para que podemos estabelecer qualquer lugar para eles, tipo, você escolhe o lugar na onde os dados estão trafegando. Ao contrario do diagrama de seqüência que mostrado em um formato semelhante a raias não como o diagrama de colaboração que mostra em grafo ou rede, com isso no formato de raias cada objeto novo é colocado sempre à posição do lado direito. Ele e colocado à direita devido o formato que as raias forma. Mas este diagrama tem seus Pontos fortes e fracos. No diagrama de colaboração os pontos fortes: é a economia de espaço, ou seja, flexibilidade de adicionar novos objetos em duas dimensões e outra ele melhor para ilustrar ramificações complexas. Os pontos fracos: são ele e difícil ver a seqüência de mensagens e a notação mais complexa isso no diagrama de colaboração.E no diagrama de Seqüência os pontos fortes: são a capacidade de mostra há clareza na ordem temporal e simplicidade e os pontos fracos são que ele exige consumo do espaço horizontal e uma ferramenta gráfica.Com isso podemos analisar através dos pontos fortes e fracos de ambos são diagramas de interação que o mas fácil de ser implementado e do seqüência, pois ele mas fácil de ser analisar e de compreender.Na confecção dos diagramas você deve ser fiel em que você vai programar, pois se você não seguir a sua implementação a analisa com isso a sua implementação não será feita da maneira correta. Com isso os padrões de projeto e de codificação bem como os princípios devem ser aplicados para melhorar a qualidade do projeto. Na notação específica para diagramas de colaboração, pois como de Ligação que é a conexão entre dois pontos objetos que indica a existência de alguma de navegação e de visibilidade entre o objetos. Uma ligação é uma instancia de uma associação.
(trecho da apostila de de requisitos)

Aulas 2 e 3 ...Requisitos para projeto-Iteração 1

Na aula dois aprendemos sobre os requisitos para o projeto Iteração um no qual tivemos a oportunidade de saber sobre Objetivos que são muito importantes, pois nele em que são tratadas as atividades de projeto, pois com isso podemos tratar a e diferencia as importantes a habilidades de projetar os objetos e dar uma notação UML. Outro aspecto que foi abordado na sala de aula foi sobre requisitos em que podemos obter uma analise, ou seja, podemos investigar os requisitos como que eles são implementados, saber os seus conceitos que são utilizados e usados nos requisitos. Para que tudo isso seja compreendido de uma forma correta, ou seja, que acha uma compreensão sobre os objetivos, às regras que existentes e as restrições que existe. Mas não só sobre analise que temos que saber os requisitos, pois também temos que analisar o projeto em sim para que possam obter uma interação entre ambas, ou seja, entre o projeto e analise. Pois o projeto em requisitos para interação um pouco, mas delicada em que analise, pois há investigação um pouco, mas delicada, ou seja, mas profunda para que não acha erros, pois ao contrario da analise o projeto expressa em termos de objetivos de software que interagem entre si. Pois em projeto você não pode pensar que este projeto tem que satisfazer você, mas sim ele tem que esta de acordo com os requisitos da analise que foram implementados e com os requisitos do projeto que foi solicitado, ou seja, de acordo com apostila “fazer certo a coisa”.

Introdução

Como foi visto na sala de aula esta disciplina Projetos Orientados a Objetos orientados a objeto fala um usa o Java como ferramenta com isso ira fazer parte desta matéria. No caso do da UML a orientação objeto vai detalhar mas simplificadamente os assuntos ,ou seja, nesta matéria vamos fazer um Uml já sabe como será feito o código fonte, ou seja , a programação pelo desenvolvedor do sistema..Pois com isso podemos obter um certo tipo de conhecimentos estaremos tratando os dois tipos de conteúdos juntos com isso podemos obter um bom sucesso na aprendizagem e na nossa formação acadêmica..

Imagem do livro JAVA:como programar

Autor(es):DEITEL, H. M.; DEITEL, P. J

Jullian Figueiredo