Current revision |
Your text |
Line 1: |
Line 1: |
- | 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 <br>[[User:Pmarcotti|Prof. Paulo Marcotti]] | + | 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. [[User:Pmarcotti|Paulo Marcotti]] |
- | ==Jogo de Análise-[[Projeto RPG de análise|RPG]]==
| + | <br>Emails: |
- | Será feito este semestre uma análise e projeto de um sistema integrado de gerenciamento de informações para gestão empresarial.
| + | *[mailto:pmarcotti@sarmac.com.br pmarcotti@sarmac.com.br] ou |
| + | *[mailto:pmarcotti@hotmail.com pmarcotti@hotmail.com] |
| | | |
- | Será apresentado o site da [[ACME Corporation]] e escolhido um projeto que o qual [[nossa empresa]] vai concorrer com um produto de software.
| + | Jogo de [[RPG]] - Análise e Projeto de um Sistema Integrado de Gerenciamento de Informações para Gestão Empresarial |
- | 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 [[mestre (RPG)|coordenadores/mestres]] do jogo [[RPG]] devem criar um nome do projeto ou das empresas holding e um logotipo. Ou podem delegar a suas [[equipes]]. | + | Apresentar site da ACME Corporation e escolher um projeto que 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). |
| | | |
- | Deverão também os coordenadores solicitar currículos individuais especificando: | + | Os [[mestre (RPG)|coordenadores/mestres]] do jogo [[RPG]] devem criar um nome do projeto ou da empresas holding e um logotipo. Ou podem delegar a suas equipes. |
- | #Área preferencial de atuação
| + | |
- | #* [[logística]]
| + | Deverão solicitar currículos individuais especificando: |
- | #* [[expedição]]
| + | Área preferencial de atuação ([[logística]], [[expedição]] ou coordenador de prestadores de serviços, [[financeiro]], [[fiscal]], [[contabilidade]] ou [[administrativo]], [[produção], [[compras]], [[recebimento]], coordenação de produção para prestadores de serviço ou [[marketing]], [[vendas]], [[contratos]]; |
- | #* 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; | | Explicitar suas qualidades para o cargo, e realizações (mensuráveis) em empregos anteriores; |
| Salário pretendido (explicar [[pontos (RPG)|pontos]] que são salários posteriormente); e | | Salário pretendido (explicar [[pontos (RPG)|pontos]] que são salários posteriormente); e |
Line 29: |
Line 18: |
| | | |
| [[Category:Disciplina de SI]] | | [[Category:Disciplina de SI]] |
- |
| |
- | Sugestão para aprender UML [http://www.omg.org/gettingstarted/what_is_uml.htm 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 Tipos, Classes e Objetos, Herança, Polimorfismo, Encapsulamento e Mensagens.
| |
- |
| |
- | ===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 [[http://www.voxxel.com.br/deboni/]] 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.
| |
- |
| |
- | ===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.
| |
- |
| |
- | ===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.
| |
- |
| |
- | ===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.
| |