pesquisar livros bruce eckel e doug rosenberg.


http://www.iconixsw.com/UMLBook.html

J2EE e Web Services

A plataforma Java 2, Enterprise Edition (J2EE) foi concebida para simplificar problemas complexos no desenvolvimento, disponibilizarão e gerenciamento de soluções multicamadas. J2EE é uma especificação padrão, e é o resultado de uma grande iniciativa liderada pela Sun Microsystems. O objetivo das especificações J2EE é oferecer aos clientes a chance de escolha de um fornecedor de produtos e ferramentas, encorajando a competição entre esses fornecedores por oferecer produtos de alta qualidade.

Já é conhecido que o J2EE foi concebido para arquitetura baseada do lado do servidor pela linguagem de programação Java. Pode ser utilizado para construção de tradicionais web sites à componentes de software. O J2EE foi estendido para suportar a construção de web services baseados em XML. Esses web services podem possuir interoperabilidade com outros web services que podem ou não ter sido escritos com o padrão J2EE.

A tecnologia J2EE através da API JAX-RPC permite a interoperabilidade com Java. JAX-PRC significa API Java para PRC baseado em XML, é uma tecnologia para construir serviços e clientes de Web Services que utilizam chamadas de procedimento remoto e XML. Freqüentemente usados em um modelo cliente-servidor distribuído, um mecanismo RPC habilita os clientes a executar procedimentos em outros sistemas.

Em JAX-RPC, uma chama de procedimento remoto é representada por um protocolo baseado em XML, como SOAP, por exemplo.

Embora as mensagens SOAP sejam complexas, a API JAX-RPC oculta esta complexidade para o desenvolvedor da aplicação. No lado do servidor, o desenvolvedor especifica os procedimentos remotos definindo método em uma interface Java. Uma ou mais classes que implementam essa interface também precisam ser codificadas. No lado cliente, a API JAX-RPC também fornece uma forma bem definida de encapsular a complexidade da execução de um Web Services.

Com JAX-RPC, clientes e Web Services têm uma grande vantagem, a independência de plataforma da linguagem de programação Java . Além disso, JAX-RPC não é restritivo, ou seja, um cliente JAX-RPC pode acessar um Web Services que não esteja rodando na plataforma Java, e vice-versa. Essa flexibilidade é possível por JAX-RPC utiliza tecnologias definidas pela World Wide Consortion (W3C) – HTTP, SOAP e WSDL.

Tipos suportado por JAX-RPC

A API JAX-RPC mapeai os tipos da linguagem de programação Java para definições XML/WSDL. Po exemplo, JAX-RPC mapeia a classe java.lang.String para o tipo de dado XML xsd:string. O desenvolvedor do aplicativo na precisa saber os detalhes destes mapeamentos, mas devem estar conscientes de nem toda classe da plataforma Java (J2SE) pode ser usada como parametro de metodo ou tipo de retorno em JAX-RPC.

Os seguintes tipos Java são suportados por JAX-RPC:

Classes

• java.lang.Boolean

• java.lang.Byte

• java.lang.Double

• java.lang.Float

• java.lang.Integer

• java.lang.Long

• java.lang.Short

• java.lang.String

• java.math.BigDecimal.

• java.math.BigInteger

• java.net.URI

• java.uitl.Calendar

• java.uitl.Date

Primitivos

• boolean

• byte

• double

• float

• int

• long

• short

Arrays

JAX-RPC também suporta arrays que possuam membros de tipos suportados por JAX-RPC. Exemplos de arrays suportados são int[] e String[]. Arrays multidimencional, tais como BigDecimal[][], também sao suportados.

Componentes JavaBeans

JAX-RPC também suporta componentes JavaBeans, que devem obedecer ao mesmo conjunto de regras, como as classes de aplicativos. Além disso, um componente JavaBean deve possuir um metodo getter e um setter para cada propriedade do bean. O tipo de propriedade do bean deve ser um tipo JAX-RPC suportado.

Tecnologias J2EE para Web Services

Graças ao fato de XML e Java trabalharem de maneira tão coesa juntas, ambas tecnologias aos poucos se tornaram um ponto central para os Web services. Em Java, já na versão J2EE 1.3, já se era encontrado todos os recursos necessários para infraestrutura de Web Services. A versão atual apresenta integração nativa com Web Services.

A disseminação no uso de web services nos últimos anos incentivou o mercado e a comunidade Java a oferecer uma grande variedade de ferramentas e aplicações para prover suporte a essa tecnologia. Atualmente, as principais plataformas para web services, Sun Microsystems, IBM, BEA, Oracle, Apache fornece uma leque diversificado aplicações para criar, manipular e executar Web services.

A IBM é um fornecedor altamente diversificado de tecnologias e ferramentas para web services e servidores de aplicação. O IBM WebSphere Software Developer Kit for Web Services (WSDK V5.0.1) é um conjunto de ferramentas para a criação, busca, invocação e testes para web services. O WSDK versão 5.0.1 encontra-se em conformidade com as últimas versões das especificações para web services incluindo WS-Security, SOAP, WSDL e UDDI. Entre as principais ferramentas de desenvolvimento, podem ser citadas o WebSphere Studio Application Developer (IDE), Web Services Gateway, Web Services Invocation Framework e o UDDI Explorer.

O Java Web Services Developer Pack (Java WSDP) é um conjunto de ferramentas integradas e gratuitas que permite desenvolvedores Java implementarem e testarem aplicações web com XML e web services. O Java WSDP engloba as APIs de Java para XML, Java Architecture for XML Binding (JAXB), JavaServer Faces, Web Services Interoperability Sample Application, Web Services Security, JavaServer Pages Standard Tag Library (JSTL) e Java WSDP Registry Server. As ferramentas Ant Build Tool e Apache Tomcat container também fazem parte deste pacote distribuído pela Sun. O servidor de aplicação da Sun é o Sun ONE™ Application Server 7.

Saindo de sistemas proprietarios e entrando em sistemas do Web Services abertos e desenvolvidos pela comunidade Java, encontramos o servidor de Web Services Apache Axis. Apache Axis é um projeto open source para um servidor e cliente SOAP. Axis é considerado basicamente um SOAP engine – um framework para a construção de processadores de mensagens SOAP. Atualmente está implementado apenas na linguagem Java, mas uma versão para cliente C++ está em andamento.

Interoperabilidade

Interoperabilidade é a capacidade de um sistema de se comunicar de forma transparente (ou o mais próximo disso) com outro sistema (semelhante ou não). Para um sistema ser considerado interoperável, é muito importante que ele trabalhe com padrões abertos.

A interoperabilidade entre sistemas de informação está se tornando fundamental para o compartilhamento da informação em ambientes corporativos, onde normalmente diversos sistemas são usado para armazenar dados e objetos de negócio, em sistemas computacionais distintos e em regiões geograficamente distribuídas. Devido à diversidade existente entre estes sistemas, a integração as vezes torna-se difícil. Os problemas de interoperabilidade podem ser técnicos, onde os componentes de computação dos sistemas não permitem a cooperação devido às diferenças nos protocolos de comunicação ou semânticos, ocasionados devido à diversidade de representação da informação transmitida.

Web Services são na essência interoperabilidade conectando programas e aplicações a outros programas e aplicações, especialmente quando estes são desenvolvidos usando diferentes linguagens, ferramentas ou plataformas. A tecnologia chave para esse fim, o XML, tem todo um potencial de implementação e integração com a tecnologia J2EE. Outros padrões como SOAP, UDDI, WSDL fornecem uma base para interoperabilidade entre serviços.

Para construir sistemas baseados em web services, existem mais requisitos que os seus olhos podem ver. Seus web services deverão ser confiáveis, ter alta disponibilidade, tolerante a falhas e escaláveis. Essas necessidades não são diferentes das mesmas existentes em outras aplicações corporativas. Todos esses requisitos são suportados e podem ser implementados com Java e a tecnologia J2EE.

Os diagramas da UML não precisam ser completos

Um diagrama provê uma parcial representação do sistema. Ele ajuda a compreender a arquitetura do sistema em desenvolvimento. A UML não é um método de desenvolvimento, o que significa que ela não diz para você o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicação entre objetos.

Dessa forma a UML nos permite ignorarmos alguns detalhes de sintaxe na descrição dos diagramas, desde que os diagramas mantenham o foco na especificação, construção, visualização, e documentação dos artefatos de um software

Diagramas de estados são distintos de diagramas de atividades

Os diagramas de atividade e de estado especificam o comportamento de uma entidade só, seja um objeto instância de uma classe, uma operação ou um sistema. Um diagrama começa ao estado inicial que marca o começo da operação ou do sistema, a criação do objeto, etc. A ”execução” vai seguir as transições de estados em estados (de atividade ou de ação). Um diagrama pode não ter de estado final enquanto não a fim prevista à vida do objeto.

O objetivo do diagrama de atividades é mostrar o fluxo de atividades em um único processo. O diagrama mostra como uma atividade depende uma da outra. É essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra. Comumente isso envolve a modelagem das etapas seqüenciais em um processo computacional. Os diagramas de atividade não são importantes somente para a modelagem de aspectos dinâmicos de um sistema ou um fluxograma, mas também para a construção de sistemas executáveis por meio de engenharia de produção reversa.

O objetivo do diagrama de estado ilustra os eventos e os estados interessantes de um objeto e o comportamento de um objeto em reposta a um evento, mostrando o ciclo de vida de um objeto, os eventos pelos quais ele passa, as suas transições e os estados em que ele está entre estes eventos.

Cada classe deve poCada classe deve possuir responsabilidades bem definidasssuir responsabilidades bem definidas

Existem muitas atividades e artefatos possiveis na analise e no projeto, bem como um rico conjunto de principios e diretrizes. Num sistema orientado a objetos a habilidade individual mais importante na analise do projeto é a atribuição de responsabilidade dos componentes do software. Pois é esta atividade que deve ser executada, inevitavelmente, e que tem o efeito mais profundo sobre robustez, a facilidade de manutenção e a re-usabilidade dos componentes do software. Num segundo nivel de importancia, mas nao menos importante, identificar os objetos e abstrações adequadas são fundamentais num processo de desenvolvimento de software orientado a objetos.

Mesmo num processo de desenvolvimento onde o desenvolvedor nao executa as atividades de analise ou projeto, o chamado processo de desenvolvimento do tipo “corrida para codificação”, a atribuição de responsabilidades é inevitável.

A ordem de realização das atividades em um processo de software é importante

Para se criar um software de qualidade que atenda as espectativas do cliente é necessário uma descrição do problema e de seus requisitos, o que é problema e o que o sistema tem que fazer. A análise enfatiza uma investigação do problema, de como uma solução é definida. Também é necessário ter uma descrição de alto nivel e descrição detalhada da solução e de como ela atende os requisitos e as restrições. Após todos esses passos de analise, seguir uma boa metodologia de desenvolvimento, escolher adequadamente a tecnologia junto a aplicação de patterns.

Durante a analise orientada a objetos, há uma enfase na descoberta e na descrição do objetos, ou conceitos, do dominio do problema. Por exemplo, no caso de um sistema de informação para biblioteca, alguns conceitos incluem Livro, Biblioteca e Usuário.

Durante o projeto orientado a objeto existe uma enfase na definição de elementos lógicos de software. Estes objetos de softwares tem atributos e metodos. Seguindo o exemplo, o objeto Livro pode ter um atributo título e um metodo imprimir.

Finalmente, durante a construção do programação, os componentes do projeto são implementados, tais como uma classe Livro em C++, Java, C#, etc.

A ordem que estas atividades são realizadas está fortemente ligada a qualidade final do produto entregue ao cliente. Por isso a importancia de realizar numa derminada ordem as atividades.

Diagramas de casos de uso possuem um foco abrangente e de poucos detalhes enquanto diagramas de seqüência possuem um foco mais restrito e detalhado.

Compreender os requisitos, em parte, compreender os processos do dominio externo de uma forma mais abrangente, mostrar como o sistema interage com seu meio ambiente e descrever as operações que o sistema deve cumprir, são funções de um diagrama de caso de uso. Por serem de facil compreensão, tanto por desenvolvedores e por pessoas da área de negócio, são uma excelente ponte entre o desenvolvedor e os usuários do software. Casos de uso não são um artefato exclusivo da orientação a objeto, e por sua vez podem ser usados num projeto que não usa orientação a objeto. Assim a abrangencia de um caso de uso é maior no ponto de vista funcional, deixando os detalhes de implementação serem demonstrados pelos diagramas de sequencia, que representam as interações entre o sistema e seus atores e promove as funcionalidades ou serviços do sistema numa maneira mais restrita.

Um bom sistema possui uma estrutura de classes com baixo acoplamento e alta coesão

Quando nos referimos a um sistema de classes com baixo acoplamento estamos medindo a interligação entre diferentes classes em um sistema [12 pág. 18], ou seja, quanto uma classe conhece e dependente de outra. Classes com baixo acoplamento são mais fáceis de serem entendidas, testadas, reusadas e mantidas, porque podem ser isoladas e trabalhadas individualmente. Além de todas as vantagens, um sistema com classes de baixo acoplamento promove o paralelismo na implementação do sistema, diminuindo o tempo de desenvolvimento e aumenta a produtividade da equipe.

Por outro lado, um caso extremo de baixo acoplamento é quando não existe ou existe muito pouco acoplamento entre as classes. Isso não é desejável porque uma metáfora central da tecnologia de objetos é um sistema composto de objetos conectados que se comunicam através de mensagens. Se o acoplamento baixo é aplicado em excesso, leva a um projeto fraco, porque conduz a uns poucos objetos ativos, sem coesão, inchados e complexos que efetuam todo trabalho. Ao mesmo tempo existirão muitos objetos praticamente passivos, com acoplamento zero, que funcionem como simples repositórios de dados.

Já quando falamos em coesão estamos medindo o quão relacionadas ou focadas estão as responsabilidades da classe [12 pág. 19]. Uma classe com baixa coesão assume responsabilidades que pertencem a outro contexto, com isso torna-se mais difícil de ser entendida, reusada e mantida. Classes de coesão baixa representam, geralmente, uma abstração de grande granularidade ou, então, assumiriam responsabilidades que deveriam ter sido delegadas a outros objetos.

Grady Booch descreve a coesão funcional alta como algo que existe quando os elementos de um componente (tal como uma classe) “trabalham todos em conjunto, para fornecer algum comportamento bem-delimitado” [14].

Uma série de benefícios é relacionada com a coesão alta, como a clareza e a facilidade de compreensão do projeto aumenta, a manutenção e as melhorias são simplificadas, freqüentemente o baixo acoplamento é favorecido, e a granularidade de funcionalidades altamente relacionadas suporta o aumento do potencial de reutilização, porque uma classe altamente coesiva pode ser usada para uma finalidade muito especifica.

Como exemplo, considere o seguinte diagrama de classe parcial de uma aplicação de venda. Suponha que necessitamos criar uma instância de Pagamento de associá-la a Venda.

Qual classe deveria ser responsável por criar Pagamento? Se a classe POST for responsável em criar o Pagamento, a instância de POST poderia, então, enviar uma mensagem acrescentar pagamento para Venda, passando junto um novo Pagamento como parâmetro

Esta atribuição de responsabilidade acopla a classe POST a conhecimento da classe Pagamento. Neste exemplo isolado, isso é aceitável, porém se continuarmos a fazer a classe POST responsável por realizar algum trabalho ou a maior parte dele, o qual esta relacionada cada vez mais operações do sistema, ela se tornará progressivamente mais carregada com tarefas e perderá sua coesão e conseqüentemente o acoplamento será desfavorecido.

Uma solução alternativa para criar Pagamento e associá-lo à Venda é mostrada na próxima figura:

No que diz respeito ao acoplamento, o segundo exemplo ilustrado é preferível porque é mantido um acoplamento geral mais fraco. Sob o ponto de vista da coesão o segundo exemplo favorece uma coesão mais alta em POST.

Por fim, tanto o acoplamento baixo como a coesão alta são princípios a serem levados em conta em todas a decisões do projeto como padrões de avaliação, ou seja, padrões que um projetista avalia em todas as decisões de projeto.

Overriding (sobreposição)

Na programação orientada a objetos é a característica da linguagem que permitir uma subclasse implementar um método existente na superclasse. A implementação da subclasse sobrepõe o método, com mesmo nome e mesma assinatura, da classe pai. Por exemplo:

public class SuperClasse

{

public void imprimir()

{

// faz alguma coisa.

}

}

public class SubClasse extends SuperClasse

{

// este método sobrepoe o metodo definido na classe SuperClasse.

public void imprimir()

{

// faz alguma coisa.

}

}

Overloading (sobrecarga)

Se dois métodos de uma classe têm o mesmo nome, mas diferente assinatura (parâmetros de tipos diferentes) então dizemos que esse método foi sobrecarregado. O overloading é um truque de compilação que permitir usar o mesmo nome de método para executar diferentes ações dependendo dos parâmetros. Por exemplo:

public class TesteOverloading {

public void somar(int x, int y)

{

System.out.println(“soma de inteiros = ” + (x + y));

}

public void somar(double x, double y)

{

System.out.println(“soma de decimais = ” + (x + y));

}

}

Generalização e Herança

Generalização e herança são abstrações poderosas para compartilhar similaridades entre classes e ao mesmo tempo preservar suas diferenças.

Generalização é o relacionamento entre uma classe e um ou mais versões refinadas (especializadas) desta classe. A classe sendo refinada é chamada de superclasse ou classe base, enquanto que a versão refinada da classe é chamada uma subclasse ou classe derivada. Atributos e operações comuns a um grupo de classes derivadas são colocadas como atributos e operações da classe base, sendo compartilhados por cada classe derivada. Diz-se que cada classe derivada herda as características de sua classe base. Algumas vezes, generalização é chamada de relacionamento is-a (é-um), porque cada instância de uma classe derivada é também uma instância da classe base.

Generalização e herança são transitivas, isto é, podem ser recursivamente aplicadas a um número arbitrário de níveis. Cada classe derivada não apenas herda todas as características de todos seus ancestrais como também pode acrescentar seus atributos e operações específicas [10].

A generalização é um conceito aplicado no momento de criação das classes. Ela é usada na intenção de evitar que classes que possuam atributos ou métodos semelhantes sejam repetidamente criadas. Como exemplo pode-se observar as classes 'aluno' e 'professor', onde ambas possuem atributos como nome, endereço e telefone. Nesse caso pode-se criar uma nova classe chamada, por exemplo, 'pessoa', que contenha as semelhanças entre as duas classes, fazendo com que aluno e professor herdem as características de pessoa, desta maneira pode-se dizer que aluno e professor são subclasses de pessoa.

Encapsulamento

A capacidade que um objeto tem de impedir que outros objetos tenham acesso aos seus dados é denominado de encapsulamento. O encapsulamento é a técnica empregada para garantir a ocultação de informação na qual a interface e implementação de uma classe são separadas sintaticamente. Com isso, somente os métodos pertencentes a um objeto podem ter acesso aos dados encapsulados. O encapsulamento encoraja a modularidade do programa e permite que decisões de projetos fiquem “escondidas” dentro da implementação de modo a restringir possíveis interdependências com outras classes, exceto por meio da sua interface [6].

Assim como abstração, o conceito de encapsulamento não é exclusivo da abordagem de orientação a objetos. Entretanto, a habilidade de se combinar estrutura de dados e comportamento em uma única entidade torna o encapsulamento mais elegante e mais poderoso do que em linguagens convencionais que separam estruturas de dados e comportamento [11].

Um bom exemplo de encapsulamento seria um disco rígido. A interface do disco rígido deixa acessível ao computador (cliente) suas funções de leitura e escrita, os dispositivos mecânicos e eletromagnéticos que o HD utiliza para realizar tais operações não fica acessível ao seu cliente estando assim encapsulados.

Os exemplos a seguir foram escritor utilizando a linguagem Java. Entretanto, a idéia aplica-se a qualquer linguagem de programação OO. Atente ao fato de que cada linguagem de programação define os literais de palavra reservada para definir seus modificadores de acesso.

Sem encapsulamento:

class NaoEncapsulado {

//implicitamentamente há modificador, mas não é o mais restritivo.

int semProtecao;

}

public class TesteNaoEncapsulado {

public static void main(String[] args) {

NaoEncapsulado ne = new NaoEncapsulado(); //ne é uma instância de NaoEncapsulado

ne.semProtecao = 10; //acesso direto ao atributo

System.out.println("Valor sem proteção: " + ne.semProtecao); //acesso direto ao atributo

}

}

Com encapsulamento:

class Encapsulado {

//private é um modificador de acesso de restrição máxima

private int comProtecao;

public void setComProtecao(int comProtecao) {

this.comProtecao = comProtecao;

}

public int getComProtecao() {

return this.comProtecao;

}

}

public class TesteEncapsulado {

public static void main(String[] args) {

Encapsulado e = new Encapsulado(); //"e" é uma instância de Encapsulado

//acesso direto a um atributo protegido implicará em erro de compilação.

e.comProtecao = 10;

//deve-se acessar o atributos de forma indireta, encapsulado.

e.setComProtecao(10);

System.out.println("Valor com proteção: " + e.getComProtecao());

}

}

Polimorfismo

Polimorfismo é o princípio pelo qual duas ou mais classes derivadas de uma mesma superclasse podem invocar métodos que têm a mesma identificação (assinatura), mas comportamentos distintos, especializados para cada classe derivada, usando para tanto uma referência a um objeto do tipo da superclasse. A decisão sobre qual o método que deve ser selecionado, de acordo com o tipo da classe derivada, é tomada em tempo de execução, através do mecanismo de ligação tardia [7].

Quando o método a ser invocado é definido durante a compilação do programa, o mecanismo de ligação prematura (early binding) é utilizado.

Para a utilização de polimorfismo, a linguagem de programação orientada a objetos deve suportar o conceito de ligação tardia (late binding), onde a definição do método que será efetivamente invocado só ocorre durante a execução do programa. O mecanismo de ligação tardia também é conhecido pelos termos dynamic binding ou run-time binding [8].

Na programação, o polimorfismo permite uma extensão continuada do design. Quando novas classes são criadas, elas podem adicionar novos comportamentos a uma função já existente [2].

Objeto

Oficialmente, objeto significa a instancia de uma classe [2]. Mas podemos encontrar uma série de definições para objetos: “um objeto tem o estado, comportamento, e identidade; a estrutura e o comportamento de objetos similares são definidos em sua classe comum; os termos instancia e objeto são permutáveis” [4].

Objetos têm dois propósitos: promover o entendimento do mundo real e suportar uma base prática para uma implementação computacional. Não existe uma maneira “correta” de decompor um problema em objetos; esta decomposição depende do julgamento do projetista e da natureza do problema. Todos objetos têm identidade própria e são distinguíveis [1].

Todo objeto sabe a que classe ele pertence, ou seja, a classe de um objeto é um atributo implícito do objeto. Este conceito é suportado na maior parte das linguagens de programação orientada a objeto [1].

O termo objeto foi aplicado formalmente pela primeira vez na linguagem de programação Simula, e nessa linguagem objetos tipicamente existem para simular alguns aspectos da realizada [4].

Classe

Em termos gerais uma classe denota classificação e também tem um novo significado nos métodos de orientação a objetos. No contexto OO, a classe é a especificação da estrutura (atributos), comportamento (métodos), e herança (classes pai, ou estrutura recursiva e comportamento) para objetos [3]. Uma classe de objetos descreve um grupo de objetos com propriedades similares, comportamento similar, relacionamentos comuns com outros objetos e uma semântica comum. Por exemplo, Pessoa e Companhia são classes de objetos. Cada pessoa tem um nome e uma idade; estes seriam os atributos comuns da classe. Companhias também podem ter os mesmos atributos nome e idade definida. Entretanto, devido à distinção semântica elas provavelmente estariam agrupados em outra classe que não Pessoa. Como se pode observar, o agrupamento em classes não leva em conta apenas o compartilhamento de propriedades [1].

Classes e Objetos

Se observarmos nosso meio, quase tudo o que nos cerca podemos chamar de objetos. Até mesmo muitas das tarefas e ações que fazemos são executadas sobre objetos ou, são tarefas que se relacionam a objetos. Carros, livros, copos, roupas, dinheiro... Por vezes os objetos são compostos por outros objetos... Nós humanos pensamos e lidamos com objetos naturalmente. Para quase todos objetos podemos atribuir, ou reconhecer, características, como: cor, tamanho, forma etc. Para outros objetos podemos inclusive atribuir comportamentos, ou funções, como locomoção, alimentação e outras várias.

Um modelo de objetos busca capturar a estrutura estática de um sistema mostrando os objetos existentes, seus relacionamentos, e atributos e operações que caracterizam cada classe de objetos. É através do uso deste modelo que se enfatiza o desenvolvimento em termos de objetos ao invés de mecanismos tradicionais de desenvolvimento baseado em funcionalidades, permitindo uma representação mais próxima do mundo real [1].

A tecnologia da orientação a objetos permite aos designers de sistemas construir estruturas com somente de dados, dados-e-funções, ou somente funções [2]. Dessa forma reduzindo custo, diminuindo o acoplamento e permitindo um maior reaproveitamento de código.

Usando a abordagem de entendimento por exemplos, vamos imaginar que estamos diante de um monitor de computador (ou de um console de vídeo game) que mostre, por exemplo, uma tartaruga numa determinada ação, correndo, ou melhor, vagarosamente se locomovendo. Obviamente que esta deve ser uma tartaruga virtual. Vamos chamá-la de um objeto virtual, algo que foi programado, ou seja, descrito através de um software que animava e propiciava aparência (cor e forma) a este objeto, a esta tartaruga virtual.

Com base no descrito acima e, considerando que o programador usou a abordagem de orientação a objetos no desenvolvimento do seu programa, este programador descreveu em software os estados (as características) e comportamentos (as tarefas) possíveis de uma tartaruga virtual [1].

Referência Bibliográfica

[1] http://www.dca.fee.unicamp.br/cursos/POOCPP/node9.html

[2] Cockburn, Alistair, Surving Object-Oriented Projects – The Agile Software Development

[3] http://www.ipipan.gda.pl/%7Emarek/objects/faq/oo-faq-S-1.3.html#S-1.3

[4] Booch, Grady. Object-Oriented Design With Applications. Benjamin Cummings.

[5] http://dfm.ffclrp.usp.br/~evandro/ibm1030/intro_classe/clas_obj.html

[6] Vicenzi, Amauri Marcelo Rizzo. Tese do instituto de Ciências Matemáticas da Computação – ICMC-USP, maio 2004

[7] http://www.dca.fee.unicamp.br/cursos/PooJava/polimorf/index.html

[8] http://www.dca.fee.unicamp.br/cursos/PooJava/polimorf/latebind.html

[10] http://www.dca.fee.unicamp.br/cursos/POOCPP/node15.html

[11] http://www.dca.fee.unicamp.br/cursos/POOCPP/node7.html

[12] Hohmann, Luke. Beyond Software Archtecture – Creating and Sustainning Winning Solutions

[13] Larman, Graig. Yutilizando UML e Padrões – Uma introdução à análise de ao projeto orienteado a objetos.

[14] Booch, G. Object Solutions: Managing the Object-Oriented Projetc.

Supermercado Compre Bem do Largo do Cambuci

Nada pode ser mais sujo e desorganizado que o supermercado Compre Bem localizado no Lago do Cambuci, em São Paulo.

O espaço é muito desorganizado e sujo. O produtos nas prateleiras estão sempre com poeira. Eu já vi, mais de uma vez, baratas andando entre os produtos. Os legumes, frutas e verduras são de péssima qualidade e sujos.

O atendimento é péssimo. Funcionários sem paciência com os clientes e com má vontade. Já presenciei diversas cenas de descaso com clientes. Um vez no setor de frios esperei uns 2 minutos para ser atendido, os funcionários estavam de papo no depósito atrás do balcão e simplesmente esqueceram que estavam trabalhando.

Como odeio fazer compras nesse lugar. A impressão que tenho, é que esse Compre Bem é o resto do estoque e de funcionários da cadeia. Pois já comprei em outros Compre Bem, e este é o único com esses problemas.

dica de leitura

A ferro e fogo - Josué Guimarães