sábado, 18 de outubro de 2008

Projeto Orientado a Objetos

Por ECP360 e BSI360 2008/2

1. Introdução a POO

A programação orientada a objetos veio para solucionar vários problemas que a programação comum não conseguia ou resolvia de forma incompleta. Trata-se de uma linguagem robusta com uma característica de reaproveitamento de código, melhor organização, desta forma facilitando a vida de programadores e analistas graças às facilidades que este tipo de linguagem proporciona.
Temos hoje no mercado diversas ferramentas para programação da POO, mas nem todas são exploradas ao máximo ou da forma correta, muito ainda neste setor existe para ser explorado, descoberto e desenvolvido.

Claro que mesmo sendo tão eficiente e tendo tantos recursos a POO ainda tem pontos de falha e que devem ser tratados. Não apenas as limitações podem trazer problemas para o desenvolvimento, mas ainda existe a limitação de quem desenvolve, sendo que muitas vezes algumas pessoas não estão preparadas e não tem conhecimento suficiente da estrutura orientada a objeto e acaba fazendo o mau uso da mesma e neste caso uma codificação ruim pode ser fatal para o programa.

Este é um assunto muito abrangente e causa muitas discussões, porém sempre é importante debater assuntos deste nível. Sempre é importante estudar um pouco mais sobre um assunto tão abrangente e tentar entender cada vez mais seus conceitos e fundamentos.

Objetos:

Objetos são elementos como na vida real, eles tem propriedades, estados, ações e partes. Um exemplo é um carro que possui quatro rodas que formam as partes do mesmo ou fazem parte de outros objetos, propriedades como potência do motor, estados como ligado/desligado e ações como acelerar.

Na POO, os objetos seguem a mesma linha, com objetos possuindo propriedades, outros objetos internos, como o exemplo do carro e métodos que definem seu comportamento.

Classes:

A classe pode ser definida como uma família onde todos os elementos contidos nesta seguem uma estrutura e funções definidas. Em relação à programação, a classe define os atributos e funções do objeto, então, ela descreve um conjunto de objetos semelhantes.

Todo objeto criado a partir de determinada classe é uma instância dessa classe, pois todas as informações contidas no objeto serão estruturadas de acordo com a classe.

A existência da classe proporciona uma organização e reusabilidade do código, caso não houvesse a classe em cada nova criação do objeto haveria a necessidade de descrever toda a estrutura desse novo objeto, assim, com o uso de classes pode-se padronizar os objetos.

Vantagens:

Reuso de código: É sem dúvida a maior vantagem da POO, pois permite que programas sejam escritos rapidamente garantindo que os mesmos estejam livres de erros, pois já foram testados anteriormente. Esta técnica é possível através de mecanismos de herança e interface.

Escalabilidade: É a capacidade de uma aplicação crescer sem aumentar sua complexidade ou comprometer seu desempenho. Graças à estrutura de objetos e classes, cada entidade do sistema agrupa suas funcionalidades específicas e se comunica com outras partes por mensagens.

Manutenção Fácil: É seguro, portanto mais fácil de manter. O encapsulamento ajuda a proteger as informações de cada classe, de modo que apenas seus objetos tenham acesso às informações que quando disponibilizadas externamente necessitam do consentimento do criador.

Apropriação: Polimorfismo permite tornar o programa mais enxuto, já que um método pode receber uma referência genérica e executar operações genéricas dessa classe. Graças ao mecanismo de interface e herança o sistema, fica em termos de manutenção, mais fácil de ser entendido e modificado.

Desvantagens:

Apropriação: É tanto uma vantagem quanto desvantagem. O mecanismo de interfaces e heranças quando utilizado de maneira errada, pode mais prejudicar do que ajudar sua aplicação. Na vida real é muito fácil dividir o mundo em categorias e grupos, na POO essa associação nem sempre é tão simples.

Fragilidade: Se os relacionamentos entre as classes mudam, muitas vezes é necessário remodelar o código e reprojetar uma nova hierarquia de classes. Se existir alguma falha durante esse processo, pode ser que o mesmo não seja tão facilmente identificado.

Linearidade de Desenvolvimento: O desenvolvimento precisa seguir uma linha e passar por todas as etapas de um projeto possível. Precisa que cada processo faça sua parte bem feito, porque uma é altamente dependente da outra. Além disso, a POO necessita de um projeto cuidadoso de hierarquia de classes, um erro aqui pode comprometer o bom desenvolvimento de toda uma aplicação.

2. UML (Unified Modeling Language)

História
A UML teve inicio após uma tentativa de Jim Rumbaugh e Grady Booch de relacionar dois métodos populares de modelagem orientada a objeto. O primeiro método é o Booch e o segundo é OMT (Object modeling language), esta união ocorreu no ano de 1994. Logo após essa parceria no ano de 1996 o criador do método Objectory juntou-se aos dois formatos (Booch e OMT), formando assim a primeira versão da linguagem UML(Unified Modeling Language).

Objetivos da UML
A UML tem como objetivos a modelagem de sistemas usando conceitos da orientação a objetos. Outro critério é estabelecer uma união com métodos conceituais que sejam executáveis.
A criaçao de uma linguagem de modelagem usável tanto pelo homem quanto pela máquina também é um dos objetivos da UML.

Futuro da UML
Pelo fato da UML ter como base técnicas antigas e marcantes da orientação de objetos, outras linguagens influenciarão as novas versões.
Técnicas avançadas de modelagem também podem ser definidas usando como base UML, estendendo-a, sem necessidade de redefinir a estrutura interna.
A UML tem integrado muitas idéias, e esta integração contribui para o desenvolvimento de softwares orientados a objetos.

Conceito UML
UML é uma linguagem que presa pela gestão visual para modelar um sistema orientado a objeto. Prezando por três perspectivas:
• Diagrama de classses – (dados estruturais);
• Diagramas de caso de uso – (operaões funcionais);
• Diagramas de seqüência, atividades e transição de estados – (eventos temporais);

Ele utiliza dos diagrmas para estar explicando um sistema. Onde tem como partes fundamentais os Atores e os Use Cases. Que por sua vez fazem toda a interação do sistema.
Temos assim os atores como as partes interativas do sistema (pessoas, dispositivos e outros). Já os use cases são as ações que interagem os atores.
Fica assim modelado o uso dos use case e os atores nos diagramas para uma apresentação detalhada do sistema.

O uml possui esses e outros elementos para criar os diagramas, para poder representar uma determinada parte do sistema ou um ponto de vista do sistema. Temos os seguintes diagramas:
- Caso de uso que vem mostrar os atores e seus relacionamentos;
- Classe que mostra o relacionamento entre as classes;
- Seqüência mostra os objetos e uma sequencia das chamadas do método feito para outros objetos;
- Colaboração mostra os objetos e seus relacionamentos, dando enfase aos que trocam mensagens;
- Estado mostra a mudança de estado e eventos num objeto ou parte do sistema;
- Atividade mostra as atividades ou troca de atividades em uma parte do sistema;
- Componente mostra a programação de alto nível;
- Distribuição mostra a instância dos componentes e seus relacionamentos;

Elementos da UML
De estrutura:
Modelação de estrutura ou Structure Modeling são as partes estáticas de um modelo, representando elementos conceituais ou físicos.
É neste modelo que entram os conceitos de:
• Classe
• Interface
• Componente
• Colaboração
• Nó

De comportamento:
É a modelação do comportamento (o estado) e troca de mensagens de vários tipos de sistemas, é usado, geralmente, para criar ferramentas para estudar estes comportamentos em situações extremas, sem ter que aplicar estas condições pelo fato de, por exemplo, ser muito caro este tipo de teste. Dentro deste Modelo podem ser aplicados os diagramas de Sequência, colaboração, transição de dados e atividades.

É neste modelo que entram os:
• Casos de uso
• Interação
• Máquina de estados

De agrupamento:
Modelação de agrupamento é a organização da UML do projeto em grupos.
Neste modelo entram os conceitos de:
• Pacote
• Modelo
• Subsistema
• Framework

De anotação:
Modelação por anotação são todas as partes explicativas do UML, neste modelo são utilizados todos os comentários que foram feitos e documentados no decorrer do projeto para descrever, detalhar e remarcar todos os elementos no modelo.
Neste modelo entra o conceito de:
• Notas

Relacionamentos
• Dependência
• Associação (bidirecional ou unidirecional)
• Generalização
• Agregação
• Composição

Uma dependência indica a ocorrência de um relacionamento entre dois ou mais elementos do modelo, onde uma classe cliente é dependente de alguns serviços da classe fornecedora, mas não tem uma dependência estrutural interna com esse fornecedor.Por exemplo, Uma mudança no elemento independente irá afetar o modelo dependente. Como no caso anterior com generalizações, os modelos de elementos podem ser uma classe, um pacote, um use-case e assim por diante.

Quando uma classe recebe um objeto de outra classe como parâmetro, uma classe acessa o objeto global da outra. Nesse caso existe uma dependência entre estas duas classes, apesar de não ser explícita.

Associação são relacionamentos estruturais entre instâncias e especificam que objetos de uma classe estão ligados a objetos de outras classes.

A associação pode existir entre classes ou entre objetos. Uma associação entre a classe Professor e a classe disciplina (um professor ministra uma disciplina) significa que uma instância de Professor (um professor específico) vai ter uma associação com uma instância de Disciplina. Esta relação significa que as instâncias das classes são conectadas, seja fisicamente ou conceitualmente.

Generalização é a capacidade de se criar superclasses que encapsulam estrutura e/ou comportamento comuns a várias subclasses. Os procedimentos para se obter a generalização são:
• Identificar similaridades de estrutura/comportamento entre várias Classes.
• Criar a superclasse para encapsular a estrutura/comportamento comum.
• As classes originais passam a ser subclasses da nova superclasse criada.

Uma maneira relativamente fácil de se entender isso, é comparando com a nossa herança genética: Você possui algumas características de seus Pais. Mas seus Pais não possuem suas características. Pois bem, você seria uma subclasse.

Agregação é uma forma especializada de associação na qual um todo é relacionado com suas partes. Também conhecida como relação de conteúdo.

É representada como uma linha de associação com um diamante junto à Classe agregadora. A multiplicidade é representada da mesma maneira que nas associações.

Composição é uma agregação onde uma classe que está contida na outra "vive" e constitui a outra. Se o objeto da classe que contém for destruído, as classes da agregação de composição serão destruídas juntamente, já que as mesmas fazem parte da outra.
É representada como uma linha de associação com um diamante preenchido junto à Classe agregadora. A multiplicidade é representada da mesma maneira que nas associações.

3. Comunicação de objetos

RPC
Chamada de procedimento remoto (ou RPC, Remote Procedure Call) é uma tecnologia de comunicação entre processos que permite um programa de computador chamar um procedimento em outro espaço de endereçamento. O programador não se preocupa com detalhes de implementação dessa interação remota. O metodo remoto é invocado da mesma maneira que um metodo local.

RPC é uma tecnologia popular para a implementação do modelo cliente-servidor de computação distribuída. Uma chamada de procedimento remoto é iniciada pelo cliente enviando uma mensagem para uma servidor remoto para executar um procedimento específico. Uma resposta é retornada ao cliente. Uma diferença importante entre chamadas de procedimento remotas e chamadas de procedimento locais é que, no primeiro caso, a chamada pode falhar por problemas da rede. Nesse caso, não há nem mesmo garantia de que o procedimento foi invocado.

RMI
O RMI (Remote Method Invocation) é uma interface de programação que permite a execução de chamadas remotas no estilo RPC em aplicações desenvolvidas em Java. É uma forma de implementar um sistema distribuído em plataforma Java. A grande vantagem do RMI em relação ao RPC se dá ao fato de ser possível invocar métodos de objetos remotos e transferir objetos entre estes.

Herança
É o mecanismo pelo qual uma classe herda os atributos/métodos de outras. Assim, uma característica implementada em uma classe pode ser "copiada" para a outra sem reescrever o código.
Utilizando herança, têm-se os seguintes relacionamentos:

• Subclasse: É a classe “filha” que herda de uma ou mais classes suas caracteristicas.
• Superclasse: É a classe “pai”, da qual outras classes irão herdar as características
Herança Simples x Herança Múltipla
• Quando uma classe é subclasse de apenas uma superclasse, essa é uma herança simples.
• Quando uma subclasse herda de duas ou mais superclasses, essa é uma herança múltipla.

Problemas Herança Múltipla
Apesar de ser mais "poderosa" que a herança simples, por permitir que uma classe herde as características de diversas classes, a herança múltipla traz alguns problemas: O que fazer quando as superclasses têm características "conflitantes"?
Isso é chamado de problema diamante.

Interface
É um “contrato” no qual todas as classes que o programam devem seguir. Descreve as características externas (publicas) que uma classe tem. Nelas contem as assinaturas de métodos (nome, parâmetros e valor de retorno). Dessa forma, todas as classes que implementam uma interface, devem implementar os métodos nela contidos.

Polimorfismo
O polimorfismo permite que uma classe seja tratada como uma de suas superclasses ou como uma interface que ela implementamodelo das classes a qual foi concretas a qual foi referenciada. Assim, um mesma classe pode apresentar várias formas. O termo polimorfismo tem o significado de "muitas formas" (poli = muitas, morphos = formas).

Digamos que exista uma classe responsável por caracterizar um objeto GERENTE, porem o objeto Gerente herda caracteristicas do objeto EMPREGADO que o mesmo herda de PESSOA. O Polimorfismo nos oferece a mobilidade de lidar com nosso objeto GERENTE em qualquer formato de objeto do qual foi herdado, tanto com seus atributos como com seus metodos.

Associação
São relações entre classes, representando a possibilidade de relação entre os objetos, permitindo que um objeto utilize os recursos de outro, podendo existir mais de uma associação.
Por exemplo: uma pessoa abre a porta; a maçaneta faz parte da porta.

Coesão
Coesão é uma medida de integridade conceitual de uma classe - o objetivo, nesse caso, é o de maximizar a coesão para assegurar agrupamento de operações e com isso reduzir esforços de manutenção.

Encapsulamento
Um dos pontos da POO é o de esconder dados dentro de Objetos, os quais são manipulados por funções(Métodos). Estas estruturas não devem ser visíveis para outros objetos, apenas pelos métodos dentro do objeto à que ele pertence, aos outros objetos somente aparecem os métodos existentes. Na classe são criados atributos(Estruturas de dados) para o armazenamento de uma maneira privada e são implementados métodos (públicos) que manipulam estas estruturas.

Acoplamento
O acoplamento é uma medida de quanto uma classe esta ligada a outras classes, tendo conhecimento das mesmas ou sendo dependente delas.
Uma classe com baixo (fraco) acoplamento não depende de muitas outras.
Uma classe com alto (forte) acoplamento é:

• Mais difícil de compreender isoladamente;
• Mais difícil de reutilizar (seu uso depende da reutilização das outras classes da qual ela depende);
• Sensível a mudanças nas classes associadas

4. Tipos de objetos

Servidores: O objeto servidor tem a função de servir a um outro objeto que possa se fazer necessário em um determinado momento. Enquanto um objeto servidor não está servindo a um outro objeto sua execução é interrompida até que esse se torne necessário novamente. Um exemplo que podemos usar é: um determinado objeto tem um método de impressão, ele só se fáz necessário no momento em que o usuário deseja imprimir algum documeto. Quando esta necessidade existe este objeto é chamado e utilizado, porém enquanto ninguém necessitar o seu uso ele continua parado.

Objetos concorrentes: Objetos concorrentes são quando dois objetos estão executando processos de forma simultânea, e inclusive podem se comunicar-se um com o outro. Porém eles são independentes e executam as suas atividades de forma separada. Um exemplo seria o uso de threads, onde é possível criar dois processos concorrentes que executem duas tarefas diferentes em um mesmo programa, e ainda uma esperando uma determinada resposta da outra quando necessário.

Objeto Ativo: é o objeto que executa as atividades, ele é o objeto responsável pela linha de execução. É ele que executa as tarefas quando estimulado.Ele sempre está em modo de execução, ao contrário do objeto do tipo servidor pois está sempre sendo executado.

Objeto Passivo: o objeto que é desprovido de capacidade de execução, sua função é basicamente enviar estímulos a objetos ativos para que eles por sua vez executem alguma atividade. Um exemplo seria um sensor que recebe um sinal de temperatura alta indicando um incêndio. Porém o sensor em sí não tem capacidade de apagar o fogo, assim ele estimula o
sistema anti-chamas a fazer a extinção do fogo.

5. Rational Unified Process (RUP)

É um processo proprietario de engenharia de software criado pela Rational Software Corporation posteriormente adquirido pela IBM. Trata-se de uma metodologia utilizada para gerenciar grandes projetos de software, utilizando uma abordagem de orientação de objetos e a notação UML para sua documentação.

Características:
• Uso de iterações para evitar o impacto de mudanças no projeto,
• Gerenciamento de mudanças e
• Abordagens dos pontos de maior risco o mais cedo possível.

Fases do projeto:
• Concepção - entendimento da necessidade e visão do projeto,
• Elaboração - especificação e abordagem dos pontos de maior risco,
• Construção - desenvolvimento principal do sistema,
• Transição - ajustes, implantação e transferência de propriedade do sistema

O RUP se baseia nos 4 P’s
• Pessoas
• Projeto
• Produto
• Processo

As fases do projeto são compostas de uma ou mais iterações, sendo semelhante ao modelo espiral. As iterações são definidas em um determinado período de tempo geralmente curtos.
Conteúdo do RUP

Workflows: Cada workflow é descrito em detalhe, apresentando passo a passo as tarefas, subprodutos a serem gerados e papéis de profissionais envolvidos.

Tarefas: Cada tarefa é descrita em detalhe, incluindo que papel é responsável por ela, a qual workflow ela pertence e quais são os subprodutos de entrada e saída.

Modelo de equipe: Os diversos papéis necessários no projeto são descritos em detalhe, cada papel pode ser representado por mais de uma pessoa, ou uma pessoa pode ter mais de um papel, dependendo da carga de trabalho necessário.

Modelos de documentos: O RUP apresenta modelos e exemplos para os diversos documentos (artifacts) gerados ao longo do projeto. Os documentos são totalmente compatíveis com a UML, o que reforça a questão de padronização.

Análise de risco – Consiste em analizar os possiveis riscos durante o projeto, procurando metodos para evita-los ou trata-los.

Gestão de mudança – a gestão de mudança visa lidar com as mudanças de requisitos ao longo do projeto.

6. Identificação de Objetos

Identificação de objetos é o processo de análise para identificação e modulação dos objetos e classe de um sistema. Esta tarefa não é fácil, pois requer que o projetista tenha habilidade e experiência sobre os processo que envolvem a utilização do sistema, além de não ter um método específico, mas apenas um conceito.

Abaixo é descrito um exemplo que servirá de base para o entendimento do assunto.
"Uma empresa solicita o desenvolvimento de um software que faça o gerenciamento do Recursos Humanos da empresa. Para isto, foram determinados certas regras, na qual o empregado possui uma identidade própria, seu nome. Possui também propriedades como: endereço, idade, dependentes, salário, cargo. Neste sistema também são encontrados avaliações que os empregados realizam. O RH organiza eventos da empresa para seus colaboradores, dependentes e a sociedade. No sistema o comportamento pode ser determinado por operações como: aumentar salário, listar dependentes e alterar cargo. As propriedades somente podem ser manipuladas através das operações definidas na interface do objeto, de modo que a forma de armazenamento das propriedades e a implementação das operações são desconhecidas pelas outras entidades externas."

Para identificamos objetos ao um sistema é interessante enxergamos o primeiramente mundo real assim como na história acima o mundo real é o setor de recursos humanos, então deve-se olhar os processos envolvidos no RH.

Pode-se identificar no exemplo acima o objeto Empregado, na qual carrega as seguintes propriedades: endereço, idade, dependentes, salário. Também é identificado o objeto Avaliação que pode carregar as seguintes propriedades: nome, tipo de avaliação, pré-requisitos.

Alguns objetos são considerados abstratos, pois não são objetos palpáveis. Estes objetos são mais difíceis de enxergar, no exemplo citado existe dois objetos abstratos: Evento e Cargo, onde as propriedades para Evento são: nome do evento, tipo de evento, freqüência, quantidade de convidados; e para Cargo: nome do cargo, nível do cargo, salário base do cargo.

7. Modelos de Projeto

Os modelos de projetos mostram as classes de objetos e as relações entre elas. São divididos em modelos estáticos e modelos dinâmicos.

Os modelos estáticos descrevem basicamente a estrutura estática do sistema e como elas se relacionam.

Os modelos dinâmicos por sua vez, descrevem a interação dos objetos em tempo de execução.

Eles não precisam ser necessariamente UML, podem ser modelos RUP ou modelos próprios.

Exemplos de modelos UML:

Modelo de caso de uso (estático):

Modelo de Subsistema (estático): Mostra como o projeto é organizado em grupos de objetos relacionados.

Modelo de sequência (dinâmico): modelam a seqüência das interações entre os objetos.



Modelo de Estado (dinâmico): mostram os estados dos objetos individuais.

Modelo de transição (estático): é uma representação do estado ou situação em que um objeto pode se encontrar no decorrer da execução de processos de um sistema.



Modelo de atividades (dinâmico)

Diagrama de colaboração (dinâmico)

Nenhum comentário: