Análise e Projeto Orientados à Objeto

From Sistemas2a

(Redirected from APOO)

Esta página foi desenvolvida visando possibilitar acessos, recuperações e apresentações de informações da disciplina "Análise e Projeto Orientados à Objeto", que está sendo ministrado no primeiro semestre de 2006, pelo
Prof. Paulo Marcotti

Contents

[edit] Jogo de Análise-RPG

Será feito este semestre uma análise e projeto de um sistema integrado de gerenciamento de informações para gestão empresarial.

Será apresentado o site da ACME Corporation e escolhido um projeto que o qual nossa empresa vai concorrer com um produto de software. Os gerentes devem se reunir (virtualmente, remotamente ou pessoalmente) e adaptar a situação real de empresas de desenvolvimento de software e criar um único programa de trainnes para contratar supervisores das 3 áreas de negócio que nossa holding (Serviços, Indústria e Comércio).

Os coordenadores/mestres do jogo RPG devem criar um nome do projeto ou das empresas holding e um logotipo. Ou podem delegar a suas equipes.

Deverão também os coordenadores solicitar currículos individuais especificando:

  1. Área preferencial de atuação

Explicitar suas qualidades para o cargo, e realizações (mensuráveis) em empregos anteriores; Salário pretendido (explicar pontos que são salários posteriormente); e Sugestões de treinamento que considera que devam ser oferecidos para seu perfil profissional.

Sugestão para aprender UML What's is UML?


[edit] Paradigmas da Orientação a Objetos

Os Paradigmas são normas. Como um código de conduta - qualquer semelhança é mera coincidência - são seguidas à risca. Os paradigmas diferem o que parece ser um objeto do que realmente é um objeto. Uma programação procedural orientada a eventos, se feita modularmente, pode enganar novatos. Um objeto só será um objeto se puder satisfazer essas normas. Os Paradigmas são Tipos, Classes e Objetos, Herança, Polimorfismo, Encapsulamento e Mensagens.

[edit] Tipo Classe e Objeto

Orientar nossos projetos a Objetos não é simplesmente brincar de Deus e dizer "que se faça var x;", acredito que ainda não é assim. Para criar objetos, precisa-se dizer tudo o que um objeto pode ou não fazer; precisa-se falar tudo o que ele tem de características abstraídas e criar uma classe que possa criar esse objeto. E por que não criar um objeto diretamente? Oras, e se eu precisar de dois? Simplesmente se declara dois objetos de uma mesma classe que você construiu. Bom, esse declarar é nossa instanciação. Quando se cria uma classe, se é genérico. Se fossemos criar um humano - o latino diria "aiai..." nesse momento - ele teria que possuir características e métodos comuns. Então vamos lá: -uma cabeça, dois olhos, um nariz, uma boca,dentes na boca, duas orelhas, cabelo; -um tronco com dois braços, duas mãos, cinco dedos por mão e duas pernas, dois pés, cinco dedos por pé; Esqueçamos detalhes muito profundos... mas seria isso. Quando um ser humano é instanciado - não o primeiro, não posso falar dele aqui - ele normalmente vem com todas essas características, mas algumas como "dentes na boca" vem com um .status=false, sacaram? Brincando agente está falando de um objeto instanciado, pertencente à classe humana. Os métodos são as coisas que nosso humano poderia fazer. Andar, pular, virar, mirar, atirar, usar itens... O marcote não falou de tipo. Se alguém googlar e puder comentar aqui, à vontade, prefiro não criar suposições: elas podem nos confundir e muuuito! O MARCOTTI falou mesmo de "Tipo, Classe e Objeto" .. mas não me lembrava onde se encaixava no contexto o Tipo .. mas voltando ao material de consulta dessa aula e revendo os conceitos com o grande mestre José Eduardo Zindel Deboni [[1]] autor do livro "Modelagem orientada a objetos com a UML" da Editora Futura, e citando um parágrafo do livro: "Esses objetos seguem a mesma estrutura e definem o que se chama de um TIPO abstrado de dados (TAD, ou no inglês ADT Abstract Data Type). Um tipo é uma estrutura de dados com um conjunto de definições de operações que afetam essa estrutura. No tipo não existe a preocupação de implementar essas operações, ele serve apenas para definir um padrão no modelo, reduzindo a complexidade da modelagem. A implementação de um TIPO é uma CLASSE." Então, em marcottez .. Tipo vem de Tipo Abstrato de Dados, da teoria de estrutura de dados, antes dos objetos, antes das classes, antes até do banco de dados. Para implementar uma Classe, precisa primeiramente ter criado um tipo de dado. Inteiro é um tipo de dado. Data é um tipo de dado (que pode ser implementado com 3 inteiros, ou um long integer). Pessoa pode ser abstraido como um tipo de dado.

[edit] Herança

Herança é a partir de uma classe você criar outra classe, sem começar do zero, aproveitando todos os atributos e métodos da classe anterior, conhecida como classe Pai - por favor, sem discussões sobre porque A classe (feminino) é Pai(masculino). Quando o grande Desenvolvedor criou o Homem e a Mulher, ele utilizou herança em ambas a partir da classe Humano; no homem ele colocou juízo e na mulher livre arbítrio, sabe, coisas do tipo? Ambos tem uma cabeça com coisas e coisas, um trocon com coisas e coisas - umas diferentes, graças ao grande Desenvolvedor! - e enfim, quando se instanciam, são objetos filhos de uma mesma classe pai - Humanos - mas pertencentes a classes diferentes - Homem e Mulher. Sendo mais realista, imaginel uma classe "usuário", simples assim: username e password; ela pode ser classe pai de um aluno e um cliente, pois apesar de serem diferentes, possuem nome e uma senha de acesso. Essa reusabilidade gerada pela herança permite atualizações e adaptações rápidas e mais eficazes. Imaginando que você ainda tenha outras derivações como funcionários, e outras 10~15 derivações (!), caso haja a necessidade de uma alteração comum a todas, ao modificar-se a classe pai - "usuário" - TODAS as outras classes derivadas passariam a possuir aquelas modificações.

[edit] Polimorfismo

Algo que é polimórfico tem várias formas. Um objeto possui polimorfismo, que nada mais é que assumir em uma dada situação o papel de outro objeto pertencente a outra classe. Sua instanciação permanece a mesma, somente seu comportamente muda. Um objeto só pode assumir o comportamente de outra classe se essa lhe for ancestral, ou seja, "em nome do meeeeu P'Ai", sacaram? Bom, como tem muita ligação com herança, coloquei assim em seguida para dar o exemplo: nosso "aluno" é filho da classe "usuário", assim como "funcionário" ou "cliente"; num caso de precisar-se de uma função de verificação de username e password, o argumento poderia ser um ponteiro da classe "usuário", e nessa função eu posso passar como argumento qualquer filho de "usuário" que ele vai saber agir "em nome do pai". Isso se aplica à chamada dos métodos de uma classe também.

[edit] Encapsulamento

Encapsular é esconder. Existem uma série de rotinas complexas por trás de uma simples validação de campos. Esse é o ponto, pois parece errado dizer que existe algo complexo em uma coisa simples. O usuário do seu sistema deve ver, sentir, perceber algo simples e isso acontece porque as rotinas estão bem encapsuladas. Analogia: quando você se alimenta, come qualquer coisa, existem vários processos, como morder, mastigar, engolir, digerir e absorver. Eu sou leigo em questões fisiológicas, e digo que isso é o suficiente para mim! Agora, esses processos que são claros escondem - encapsulam - uma série de ações de químicas e enzimas, com nomes funções específicas, conhecidas por um especialista. No desenvolvimento de sistemas, você é esse especialista, deve montar tudo de forma que você saiba o que está acontecendo, e o usuário perceba que está funcionando. Para encapsular processos, utilizamos também de interfaces, visuais ou não, para tornar mais simples e intuitivo o uso do sistema. São parte de uma interface símbolos como minimizar, maximizar e fechar, setas à esquerda e direita como voltar e avançar, respectivamente, e outros.

[edit] Mensagens

Os Objetos de um sistema possuem métodos e atributos que devem ser particulares. Assim, nunca um objeto pode interfirir, modificar ou controlar métodos e atributos de outros objetos. Em uma primeira vista um leigo poderia pensar que os objetos não se relacionam, mas outra característica - norma - de objetos é que eles podem se comunicar. Assim, "educadamente um objeto pede a outro" que dispare um método ou informe sobre algum atributo. Imaginemos uma rotina que envolva um jogador e um servidor de jogos; o usuário, em primeiro instante, ainda não é o jogador-objeto; ao informar na tela de login seu username e sua senha, um método será disparado para logar esse usuário; as informações trocadas entre a tela de login e o servidor são mensagens. Imagine mais ainda: "olha servidor, tem um cara aqui que quer jogar, disse que o username é 'kruk' e a senha é 'kurk'" e o servidor ao receber a mensagem com esses parâmetros ativa seus métodos. A partir daí, de uma mensagem, o jogador poderia ser instanciado e virar um objeto jogador e se relacionar com o sistema.

Retrieved from "http://editthis.info/sistemas2a/An%C3%A1lise_e_Projeto_Orientados_%C3%A0_Objeto"
Personal tools