Projeto Orientado a Objetos

1. Projeto Orientado a Objetos

O Projeto Orientado a Objeto é desenvolvido adotando uma nova estratégia que procura analisar o sistema como se suas partes fossem coisas que estariam sendo interligadas por intermédio das funções que cada uma deveria desempenhar.

Essas coisas seriam os objetos que são desenvolvidos independentemente, mas que em um período mais avançado do projeto eles se ligariam e formariam o projeto como um todo. Para que o Projeto Orientado a Objeto seja relevante é necessário o pensamento em termos de Orientação a Objeto, seja desenvolvida desde o inicio do processo de desenvolvimento do software.

Pensando-se em termos de desenvolvimento de software orientado a objeto temos três etapas importantes, que irão contribuir para o sucesso na criação de um novo software, são elas:

A Analise Orientada a Objeto é a primeira desse processo e esta relacionada com analise dos requisitos que software vai ter, dividindo esses requisitos em objetos no qual os mesmos devem apresentar seus problemas.

O Projeto Orientado a Objeto é a fase em que se procura organizar melhor os objetos, de formar que se consiga solucionar seus problemas, para que se possa fazer a interligações entre os objetos que estão dispostos ao longo do projeto.

A Programação Orientada a Objetos é a fase de implementação desses objetos propriamente dita em que também é utilizada uma linguagem de programação orientada a objetos, como o JAVA.

Para que uma etapa seja finalizada e se de inicio a próxima etapa é necessário que a etapa passada seja, muito bem feita de forma que tudo que seja necessário para o software seja adicionado ao projeto, deixando o mesmo mais completo conforme cada etapa vai sendo concluída.

Quando se pensa em aspectos ligados a manutenção do software este processo se torna simples, pois é possível fazer uma alteração em alguma parte do objeto sem afetar os outros objetos que fazem parte do sistema, podendo assim ser acrescentado novas características aos objetos e também se pode criar novos objetos para serem interligados ao sistema e poderem desempenhar novas funções.

Uma importante vantagem de sistemas desenvolvidos com aspectos orientados a objetos é o fato de se poderem reutilizar partes do mesmo sistema para a criação ou aperfeiçoamento de outras partes do sistema.

1.1. Objetos e classes de objetos

Se tratando do desenvolvimento de sistemas orientados a objetos, temos é claro os objetos que nada mais é do que o encapsulamento de suas características, ou seja, dentro de um objeto existem atributos que irão descrever as características do mesmo alem de apresentar as funcionalidades que o objeto pode desempenhar.

Podemos pegar como exemplo um objeto carro que apresentam em sua estrutura algumas características como, o seu comprimento, largura, altura, cor, peso, etc e algumas funcionalidades como a possibilidade de se locomover, de parar, de virar para o lado esquerdo e direto, etc. Essas características não estão estampadas no objeto carro mais sim estão encapsuladas internamente a esse objeto.

Quando se cria um objeto de um determinado tipo suas características estão sendo criadas conforme um modelo pré-definido que são chamadas de classes de objetos. É nessas classes que são descritas todas as características que um objeto dessa classe deve ter.

A classe de objeto seria como um protótipo de um objeto, que teria a função de descrever todos os requisitos que os desenvolvedores acharam necessários para o desenvolvimento desse objeto.

Como foi citado anteriormente o desenvolvimento orientado a objeto apresentada a vantagem de se poder utilizar códigos que estão presentes em outras classes de objetos sem a necessidade de re-escrever novamente um código que já existe. Neste caso podemos usar o conceito de herança que está presente nesse tipo de desenvolvimento.

A herança nada mais é do que a possibilidade de se estar utilizando de classes já prontas para se desenvolver uma classe que apresente as mesmas características da classe pronta e mais alguns atributos e funcionalidades exclusivas dessa nova classe.

Um exemplo muito comum é a classe de objeto Funcionário que apresenta as mesmas características que um objeto da classe Pessoa tem, mas também possui outras características que é exclusiva do objeto Funcionário.

1.2. Objetos concorrentes

Os objetos dentro de um sistema podem ser executados ao mesmo tempo para que os mesmo possam vir a desenvolver atividades diferentes dentro do software, ou seja, enquanto um objeto realiza um calculo, por exemplo, os outros podem estar obtendo informações do ambiente ou estarem até se comunicando com o usuário propriamente dito.

A capacidade de se poder executar mais de uma tarefa ao mesmo tempo permite que o software não se prenda na realização de uma única tarefa o que poderia acarretar um baixo rendimento do sistema podendo levar o software a sua completa inutilidade por falta de produtividade.

Existem dois tipos de implementação de objetos simultâneos, são eles:

Os servidores que podem realizar tarefas das mais variadas características permitindo que vários processos ou objetos sejam executados ao mesmo tempo, no caso desse tipo de implementação não é possível haver o controle sobre o tempo que é necessário para executar uma determinada tarefa, pois isso vai depender da quantidade e complexidade dos processos que o servidor vai estar trabalhando durante um determinado período, ou seja, pode haver momento em que o servidor esta mais sobre carregado do que em outros momentos, causando essa variação no tempo de execução de tarefas.

O outro tipo de implementação de objetos simultâneos é os objetos ativos que apresentam essa simultaneidade na realização de tarefas internas do sistema, ou seja, existem mais tarefas especificas do sistema que devem estar sendo executadas ao mesmo tempo.

Podemos citar o caso do transponder de um avião, que precisa estar constantemente buscando a posição da aeronave e alem disso precisa estar se comunicando com o piloto e realizando as tarefas que o piloto lhe ordenou.

Na linguagem JAVA temos o thread que realizam essa função dentro do sistema. Para se estar utilizando desse beneficio temos que herdar a classe Thread para a classe que necessitamos que fosse executada simultaneamente com outras classes e objetos.

1.3. Processo de Projeto Orientado a Objeto

Para que se possa realizar o desenvolvimento de um sistema trabalhando com Orientação a Objeto é preciso que após a Analise Orientada a Objeto esteja concluída já se inicie o processo de Projeto Orientado a Objeto, onde o mesmo deve ser desenvolvido seguindo etapas pré-definidas, são elas:

· Compreender e definir o contexto e os modos de utilização do sistema

· Projetar a arquitetura do sistema

· Identificar os principais objetos do sistema

· Descrever os modelos de projeto

· Especificar as interfaces dos objetos

Essas etapas não podem ser vistas como estágios, ou seja, para que se possa progredir para outra etapa não é necessário que a etapa passada esteja completamente concluída. É possível que essas etapas sejam realizadas concorrentemente de modo que todas ou parte delas sejam desenvolvidas em conjunto com outras partes.

Para demonstrar o Projeto Orientado a Objetos estaremos citando como exemplo um sistema de mapeamento meteorológico e como parte fundamental do desenvolvimento orientado a objetos temos a analise orientada a objeto citada logo abaixo.

O nosso sistema de mapeamento meteorológico necessita gerar mapas meteorológicos frequentemente, através da coleta de dados de estações meteorológicas remotas. Essas informações devem ser transmitidas aos computadores que solicitam a analise do tempo no caso. Esse sistema deve analisar os dados obtidos de várias estações meteorológicas antes de enviar o resultado para o usuário que solicitou o serviço, alem de ter que armazenar as informações obtidas em seu banco de dados.

Podemos perceber que só lendo a analise desenvolvida sobre esse sistema notamos que existe nesse sistema uma sequência a ser seguida até que o processo seja totalmente concluído, verificando isso podemos desenvolver esse software na forma de camada, onde cada camada de ser concluída para que o processo passe para a próxima camada.

A primeira camada após a solicitação da informação pelo usuário seria a coleta dos dados da estação meteorológica, depois será a analise desses dados entre dados obtidos em outras estações e dados gravados pelo sistema, o próximo passo seria o armazenamento dos dados e por fim a organização dos dados para serem enviados para o usuário.

1.4. Contexto do sistema e modelos de uso

Para que seja possível trabalhar com um Processo de Software Orientado a Objeto é necessário que seja definido a forma e o estilo de comunicação com o ambiente externo ao software, ou seja, é preciso definir como o usuário vai se comunicar com o sistema e quais as funcionalidades que o sistema deve oferecer para o usuário.

Conhecendo essas informações é possível definir dois tipos de relação entre o ambiente e o sistema, veja eles:

O primeiro trata o sistema como um modelo estático onde são descritos todos os outros subsistemas que envolvem o sistema propriamente dito, de forma que é possível ter mais detalhes sobre as características que cada subsistema apresenta, podem assim ter uma visão mais ampla do que pode ser oferecido para o usuário.

O segundo diz respeito a o sistema como um modelo dinâmico onde são realmente citadas todas as formas de comunicação entre o usuário e o sistema em si, como no exemplo da estação meteorológica temos as seguintes funcionalidades que podem ser controladas pelo usuário:

O usuário poderá iniciar, desativar, relatar, calibrar e testar o sistema, cada uma dessas operações fornecidas pelo sistema ao usuário desenvolvem tarefas especificas que são realizadas por diversos subsistemas que estão presentes dentro do sistema de mapeamento meteorológico.

1.5. Projeto de Arquitetura

Após realizar a forma de comunicação do sistema com o usuário fica fácil começar a representar as camadas que foram citadas lá no inicio do Projeto, demonstrando o desenvolvimento do projeto de arquitetura do software, ou seja, é possível que se possa ter uma idéia mais verdadeira em relação à estrutura que o sistema esta se moldando a cada processo que e concluído.

Já definimos conceitos sobre a camada de interface com o usuário, a camada de coleta de dados e a camada de instrumento que são capazes de realizar a coleta das informações.

A arquitetura em si deve ser desenvolvida tentando descrever o sistema da forma mais simples possível, não havendo mais do que sete entidades fundamentais relacionadas incluídas no modelo de arquitetura, ou seja, devemos procurar dividir o problema em no máximo sete camadas.

                  

                  1.6. Identificação de Objetos

Conforme os estágios do desenvolvimento do sistema vão evoluindo vai surgindo a necessidade da implantação de novos objetos que teriam a função de atribuir novas funcionalidades ao sistema ou teriam a função de prever e solucionar alguns erros que por ventura podem vir a ocorrer no sistema.

Mas até o momento estamos utilizados o termo objeto que não deve ser caracterizado dessa forma, mas sim como resultado de classes, pois são nelas que são definidas atributos e funcionalidades para o objeto.

Voltando para a identificação de classes de objetos podemos citar varias formas de se identificar em um sistema a necessidade de se criar novas classes de objetos, como:

A utilização gramatical, utilização de entidades tangíveis, utilização de uma abordagem comportamental do sistema e uma analise baseada em cenários criados. Cada forma de analise procura identificar as classes de objetos que podem ser inseridas no sistema, para que o mesmo possa desenvolver sua tarefa de forma eficaz.

                  1.7. Modelos de Objetos

Os modelos de objetos mostram os objetos ou classes de objetos contidos em um sistema e quando apropriado as diferentes maneiras e tipos de relações entre os mesmos. Os modelos são essencialmente o próprio projeto em si, pois é aqui que traçamos uma ponte entre o que é necessário no sistema e a implementação dessas necessidades no sistema. Os modelos devem ser abstratos de modo que em hipótese alguma detalhes desnecessários não ocultem uma relação entre os objetos e os requisitos do sistema. Mas em controversa eles devem incluir detalhes suficientes para que os programadores possam tomar as devidas decisões de implementações quando necessárias.

Uma etapa importante no processo de desenvolvimento do projeto é decidir quais modelos são mais viáveis e úteis para o sistema alem do nível de detalhes que iram possuir. Para tomada dessa decisão deve-se levar em conta o tipo de sistema que deverá ser produzido, pois diferentes tipos de sistemas necessitam de diferentes modelos de projeto. Existem poucos sistemas que necessitam de todos os modelos, e minimizar o número de modelos economiza custos de implementação alem do tempo gasto para essa implementação.

Para descrever um projeto orientado a objetos existem dois tipos de modelos que devem ser produzidos que são os estáticos e os dinâmicos que já vimos a definições dos mesmos em tópicos anteriores.

Para gerar a documentação dos projetos usa-se a UML que fornece um grande numero de modelos estáticos e dinâmicos. Booch et al. (1999) propõem nove tipos de diferentes diagramas para representar esses modelos, mas nesse momento abordaremos apenas três:

1.7.1. Modelos de Subsistemas

Mostram os objetos logicamente agrupados em subsistemas, que são apresentados em forma de diagrama de classe em que cada subsistema é abordado como um pacote. É um os modelos estáticos mais usados, pois mostra como os objetos podem ser organizados em grupos e mostram também as diferentes formas de relações entre subsistemas diferentes.

1.7.2. Modelos de Seqüência

Mostram a seqüência das interações dos objetos, são apresentadas em forma de diagrama de seqüência, é um dos modelos dinâmicos mais úteis, pois documenta, para cada interação a seqüência de interações de objetos que iram acontecer.

As características básicas desse modelo são:

· Os objetos são organizados horizontalmente com uma linha vertical ligada a cada objeto.

· O tempo é representado verticalmente, de modo que a progressão se da para baixo, dando uma visão de cima para baixo conforme as relações acontecem, possibilitando uma fácil interpretação do modelo.

· As interações entre os objetos se dão por setas rotuladas que ligam as linhas verticais, onde diferentes tipos de setas representam diferentes tipos de interações, onde pode haver objetos concorrentes ou ativos, lembrando que a cada interação a linha do tempo abaixa.

· A cada interação o objeto passa para o próximo o titulo de controlador do sistema, que é obtido quando o mesmo esta efetuando seu trabalho, quando terminado o trabalho ele passa para o próximo o resultado junto com o titulo de controlador, que é representado por um retângulo fino anexado na linha do tempo.

1.7.3. Modelos de Máquinas de Estado

Mostram como objetos individuais mudam seu estado em resposta aos eventos de interação. Eles são representados em UML com o uso de um diagrama statechart, são modelos dinâmicos e funcionam da seguinte maneira:

Um objeto tem seu estado inicial definido pelo usuário conforme a sua necessidade, quando um objeto interage com outro esse objeto vai efetuar a solicitação que lhe foi pedida, essa tarefa é composta por varias interações entre objetos, e esse modelo tem por objetivo descrever essas interações. Exemplo, se o usuário pede uma coleta de dados, quais serão as interações necessárias para concluir essa coleta, o statechart mostra todas essas interações interligadas, onde cada solicitação tem suas interações independentes das outras.

                 1.8. Especificação de Interface entre Objetos

No projeto orientado a objetos, uma parte bastante importante é a definição das interfaces que irá completar os objetos. Essas interfaces servem para fazer com que os objetos que possuem as mesmas ações, sejam devidamente implementadas, ou seja, suponhamos que uma classe motorAutomovel tem uma ação de ligar(); só que o motorEletrico também tem a função de ligar(); daí é que provém a necessidade de se criar uma interface para que ambos tenham a obrigação de ser implementado.

Um exemplo mais utilizado é as interfaces em linguagem JAVA. Como no JAVA os objetos não aceitam a herança múltipla, esse fator é contornado com as interfaces, que um objeto pode implementar quantas interfaces for necessário. As interfaces têm a característica de poder ser personalizado de acordo com a necessidade que o objeto necessita, mas lembrando que a implementação dos métodos no devido objeto é obrigatório.

Para vermos como uma interface faz uma grande influência no objeto seguiremos o exemplo de uma fila e uma lista de estrutura de dados, ambas estáticas. A forma de declaração é simples, que nada mais é que um array[ ] do tipo de dados que é a estrutura e um ponteiro que marca o final da estrutura, o fator que muda em ambas é os tipos de implementação dos métodos, ou seja, os métodos possui os mesmos nomes e tipos, mas o que muda é algumas maneiras que estão contidas no interior desse método. Outro exemplo bem prático é os objetos avião e ave, ambos voam, mas voam de maneiras diferentes, é aí que há necessidade de uma implementação de uma interface.

Sua representação pode ser muito simples, pode ser feita em UML, como um diagrama de classe, a única diferença é que o nome deverá ser precedido do prefixo interface, e não constará atributos em seu escopo. Outro método de representar uma interface é escrevendo ela de modo comum. Sua declaração é bem simples onde deverá ser especificado interface precedido do seu nome definido pela equipe de desenvolvimento, e logo a baixo a assinatura dos métodos que será só descrito o escopo, sem que eles possuam blocos de instruções definidos.

Por base podemos inferir que uma classe ao implementar uma interface, automaticamente ela deverá descrever todos os métodos de maneira personalizada. Vejamos um exemplo dos dois modos de como declarar uma interface e sua aplicação.

                 1.9. Evolução do Projeto

       

              Toda vez que se pensa em desenvolver um projeto de software, sempre há complicações quanto à introdução de novos campos em determinadas áreas do projeto. No projeto orientado a objeto, essa dificuldade já não é tão dificultada assim, e quando há uma inserção de um novo campo ou método no projeto, há uma grande facilidade de se lidar com isso sem que esta inserção afete parte do programa. Suponhamos que estamos desenvolvendo um projeto orientado a objetos, e o objeto do tipo Pessoa que estamos definindo precisa inserir o campo dataNascimento, sem muita complicação automaticamente no objeto do tipo Funcionárioserá incluído o campo dataNascimento, devido à interligação que um objeto tem com outro. Percebe-se pelo exemplo a robustez deste projeto, pois o projeto não foi afetado em nenhuma parte devido à inserção desse campo.

      Acesso em: http://es1uenp.blogspot.com.br/2011/10/projeto-orientado-objetos.html

     Postado por: Vagner de Souza da Silva