[Resolvido] Curso Java - Introdução à Tecnologia de Objetos e UML

[MIC_DUARTE 1]

Conceitos básicos da Tecnologia de Objeto

 

 

Onde quer que você olhe no mundo real, você vê objetos - pessoas, animais, plantas, carros, aviões, edifícios, computadores, etc.

Os humanos pensam em termos de objetos. Telefones, casas, sinais de trânsito, fornos de microondas e sistemas de refrigeração à agua são apenas mais alguns objetos que vemos ao nosso redor todos os dias. Os programas de computador, como os programas Java, também podem ser vistos como objetos, compostos de uma grande quantidade de objetos de software interativos.

 

Às vezes, dividimos objetos em duas categorias: animados e inanimados. Os objetos animados são, em certo sentido, objetos ' vivos ' - eles se movem e fazem coisas. Por outro lado, os inanimados não se movem por conta própria. Objetos de ambos os tipos, porém, têm algumas coisas em comum. Todos têm atributos (por exemplo, tamanho, forma, cor, peso) e todos exibem comportamentos (por exemplo, uma bola rola, rebate, infla e murcha; o bebê chora, dorme, engatinha, anda e pisca; um carro acelera, freia e desvia; uma toalha absorve água).

 

Nós aprendemos sobre os objetos existentes estudando seus atributos e observando seus comportamentos. Diferentes objetos podem ter atributos semelhantes e podem exibir comportamentos semelhantes. É possível fazer comparações, por exemplo, entre bebês e adultos e entre humanos e animais.

 

O projeto orientado a objetos (OOD - Object-Oriented Design) modela software em termos semelhantes àqueles que as pessoas utilizam para descrever objetos do mundo real. Ele tira proveito de relacionamentos de classe, em que os objetos de certa classe, como uma classe de veículos, têm as mesmas características, por exemplo: carros, caminhões, patins.

O OOD também tira proveito dos relacionamentos de herança, dos quais as classes de objetos novas são derivadas absorvendo-se características de classes existentes e adicionando-se características únicas dessas mesmas classes. Um objeto de classe 'conversível' certamente tem as características da classe mais geral 'automóvel', e mais especificamente, seu capô sobe e desce.

 

O OOD encapsula (isto é, empacota) atributos e operações (comportamentos) em objetos - os atributos e as operações de um objeto estão intimamente ligados. Os objetos têm a propriedade de ocultamento de informações. Isso significa que os objetos podem saber como se comunicar com outros por meio de interfaces bem definidas, mas normalmente eles não têm permissão para saber como os outros objetos são implementados - os detalhes de implementação são ocultados dentro dos próprios objetos. Na verdade podemos dirigir um carro, por exemplo, sem conhecer os detalhes de como motores, transmissões, freios e sistemas de escapamento funcionam internamente - contanto que saibamos utilizar o acelerador, o freio, e assim por diante. O ocultamento de informações, como veremos, é crucial para a boa engenharia de software.

 

Linguagens como Java são orientadas a objeto. A programação nessa linguagem é chamada programação orientada a objetos - POO (OOP - Object-Oriented Programming), e permite aos programadores de computador implementar um projeto orientado a objetos como um sistema funcional.

 

Linguagens como C são procedurais, isto é, a programação tende a ser orientada para a ação. No C, a unidade de programação é a função. Grupos de ações que realizam alguma tarefa comum são reunidos em funções e as funções são agrupadas para formar programas. No Java, a unidade de programação é a classe a partir da qual os objetos eventualmente são instanciados (criados). Classes Java contêm métodos (que implementam operações e são semelhantes a funções na linguagem C) bem como campos (que implementam atributos).

 

Programadores em Java concentram-se na criação de classes. Cada classe contém campos e o conjunto de métodos que manipulam os campos e fornecem serviços aos clientes (isto é, outras classes que utilizam a classe). O programador utiliza classes existentes como blocos de construção para construir novas classes.

 

As classes estão para os objetos assim como as plantas arquitetônicas estão para as casas. Podemos construir muitas casas a partir de uma planta, logo, podemos instanciar (criar) muitos objetos a partir de uma classe. Você não pode fazer refeições na cozinha de uma planta; isso só é possível em uma cozinha real.

 

As classes podem ter relacionamentos com outras classes. Por exemplo, em um projeto orientado a objetos de um banco, a classe 'caixa de banco' precisa se relacionar com a classe 'cliente', a classe 'gaveta de dinheiro', a classe 'cofre', etc. Esses relacionamentos são chamados de associações.

 

Empacotar software como classes possibilita que os sistemas de software futuros reutilizem as classes. Grupos de classes relacionadas são frequentemente empacotados como componentes reutilizáveis. Assim, como corretores de imóveis costumam dizer que os três fatores mais importantes que afetam o preço dos imóveis são 'localização, localização e localização', as pessoas na comunidade de software costumam dizer que os três fatores mais importantes que afetam o futuro de desenvolvimento de software são 'reutilização, reutilização e reutilização'. A reutilização de classes existentes ao construir novas classes e programas economiza tempo e esforço. A reutilização também ajuda os programadores a construir sistemas mais confiáveis e eficientes, porque classes e componentes existentes costumam passar por extensos testes, depuração e ajuste de desempenho.

 

De fato, com a tecnologia de objetos, você pode construir grande parte do software necessário combinando classes, exatamente como fabricantes de automóveis combinam partes intercambiáveis. Cada nova classe criada terá o potencial de se tornar um valioso ativo de software que você e outros programadores podem utilizar para acelerar e aprimorar a qualidade de seus esforços futuros no desenvolvimento de software.

 

 

Introdução ao processo de análise e ao projeto orientado a objetos (object-oriented analysis and design - OOAD)

 

Para criar as melhores soluções, você deve seguir um processo detalhado para analisar os requisitos do seu projeto (isto é, determinar o que o sistema deve fazer) e desenvolver um projeto que atenda esses requisitos (isto é, decidir como o sistema deve fazê-lo). Seria ideal passar por esse processo e revisar cuidadosamente o projeto (ou ter seu projeto revisado por outros profissionais de software) antes de escrever qualquer código. Se esse processo envolve analisar e projetar o sistema de um ponto de vista orientado a objetos, ele é chamado de processo de análise e projeto orientado a objetos (OOAD - object-oriented analysis and design). Programadores profissionais sabem que a análise e o projeto podem poupar muitas horas ajudando a evitar uma abordagem de desenvolvimento de sistemas precariamente planejados que têm de ser abandonados no meio do caminho da implementação, possivelmente desperdiçando tempo, dinheiro e esforço consideráveis.

 

O OOAD é o termo genérico para o processo de análise de um problema e desenvolvimento de uma abordagem para resolvê-lo. Pequenos problemas não exigem um processo exaustivo de OOAD. Escrever pseudocódigo pode ser suficiente antes de começarmos a escrever o código Java - o pseudocódigo é uma maneira informal de expressar a lógica do programa. Na realidade, o pseudocódigo não é uma linguagem de programação, mas pode ser utilizado como um esboço de orientação ao escrever o código.

 

Uma vez que os problemas e os grupos de pessoas que os resolvem aumentam em tamanho, os métodos OOAD tornam-se mais adequados do que o pseudocódigo. Idealmente, um gupo deveria estabelecer um acordo comum sobre um processo rigorosamente definido para resolver seu problema e sobre uma maneira uniforme de comunicar os resultados desse processo para os outros. Embora existam muitos processos OOAD diferentes, uma única linguagem gráfica para comunicar os resultados de qualquer processo OOAD veio a ser amplamente utilizada. Essa linguagem, conhecida como Unified Modeling Language (UML), foi desenvolvida em meados da década de 1990 sob a direção inicial de três metodologistas de software: Grady Booch, James Rumbaugh e Ivar Jacobson.

 

 

História da UML

 

Na década de 1980, um número crescente de empresas começou a utilizar POO para construir seus aplicativos e percebeu-se a necessidade de um processo-padrão OOAD. Muitos metodologistas - inclusive Booch, Rumbaugh e Jacobson - produziram e promoveram individualmente processos separados para satisfazer essa necessidade. Cada processo tinha sua própria notação ou 'linguagem' (na forma de diagramas gráficos), para transportar os resultados de análise e de projeto.

 

Por volta do início de 1990, diferentes empresas, e até divisões dentro de uma mesma empresa, estavam utilizando seus próprios processos e notações. Ao mesmo tempo também queriam utilizar ferramentas de software que suportassem seus processos particulares. Os fornecedores de software acharam difícil fornecer ferramentas para tantos processos. Claramente, uma notação-padrão e processos-padrão eram necessários.

 

Em 1994, James Rumbaugh associou-se a Grady Booch na Rational Software Corporation (agora uma divisão da IBM) e os dois começaram a trabalhar para unificar seus populares processos. Logo associaram-se a Ivar Jacobson. Em 1996, o grupo liberou as primeiras versões da UML para a comunidade de engenharia de software e feedback solicitado. Mais ou menos na mesma época, uma organização conhecida como Object Management Group (OMG) solicitou idéias e sugestões para uma linguagem de modelagem comum. O OMG é uma organização sem fins lucrativos que promove a padronização de tecnologias orientadas a objetos publicando diretrizes e especificações, como a UML.

 

Várias corporações - como HP, IBM, Microsoft, Oracle e Rational Software - já tinham reconhecido a necessidade de uma linguagem de modelagem comum. Em resposta à solicitação de propostas do OMG, essas empresas formaram o UML Partners - o consórcio que desenvolveu a UML versão 1.1 e a sugeriu para o OMG. O OMG aceitou a proposta e, em 1997, assumiu a responsabilidade pela manutenção e revisão constantes da UML. Em março de 2003, o OMG lançou a UML versão 1.5. A UML versão 2, marca a primeira revisão importante da UML, desde a versão 1.1 padrão de 1997. Em da adoção da UML 2 pelo OMG e do fato de que muitos livros, ferramentas de modelagem e especialistas do mercado estarem utilizando a UML 2, apresentamos a terminologia e a notação da UML 2.

 

 

O que é a UML?

 

A Unified Modeling Language é agora o esquema de representação gráfica mais amplamente utilizado para modelar sistemas orientados a objetos. Ela de fato unificou os vários esquemas de notação populares. Aqueles que projetam sistemas utilizam a linguagem (na forma de diagramas) para modelar seus sistemas.

 

Um recurso atraente da UML é sua flexibilidade. A UML é extensível (isto é, capaz de ser aprimorada com novos recursos) e é independente de qualquer processo OOAD particular. Os modeladores de UML são livres para utilizar vários processos para projetar sistemas, e agora todos os desenvolvedores podem expressar seus projetos com um conjunto padrão de notações gráficas.

 

A UML é uma linguagem gráfica complexa e rica em recursos.