Análise e Projeto Orientados à Objeto
From Sistemas2a
Line 51: | Line 51: | ||
==Mensagens== | ==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. | 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 | + | 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. |
Revision as of 20:57, 21 February 2006
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. Contatos:
Contents |
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:
- Área preferencial de atuação
- logística
- expedição
- coordenador de prestadores de serviços
- financeiro
- fiscal
- contabilidade
- administrativo
- produção
- compras
- recebimento
- coordenação de produção para prestadores de serviço
- marketing
- vendas ou
- contratos
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?
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 Encapsulamento, Mensagens, Tipos, Classes e Objetos, Herança e Polimorfismo.
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.
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.