Resumo POO

RESUMO EAGS SIN BIBLIOGRAFIA POO
Merda de POO... A infeliz PARTE 1... L vamos ns ESTADO: O estado de um objeto o significado combinado das variveis internas do objeto. VARIVEL: Uma varivel interna um valor numrico dentro de um objeto.
2008
IMPLEMENTAO: A implementao define como algo feito. Em termos de programao, implementao o cdigo DOMNIO: o espao onde um problema reside. O domnio o conjunto de conceitos que representam os aspectos importantes do problema que voc est tentando resolver. OCULTAO DE IMPLEMENTAO: Significa que o caixa no v dados brutos ao totalizar um pedido. O caixa interage com o objeto ITEM, ele sabe perguntar quanto custa o item, ao invs de procurar em certas posies da memria, 1 nmero de item e outra varivel para cupom. OBJETO: Um objeto uma construo de software que encapsula estado e comportamento. Os objetos permitem que voc modele seu software em termos reais e abstraes. CLASSE: Define os atributos e comportamentos comuns compartilhados por um tipo de objeto. Os objetos de certo tipo ou classificao compartilham comportamentos e atributos. Voc usa uma classe para criar ou instanciar objetos. ATRIBUTOS: So as caractersticas de uma classe visveis externamente. A cor dos olhos e a cor dos cabelos so exemplos de atributos. COMPORTAMENTO: uma ao executada por um objeto quando passada uma mensagem ou em resposta a uma mudana de estado: algo que um objeto faz. Um objeto pode exercer o comportamento do outro, executando uma operao sobre esse objeto. Voc pode ver os termos: chamada de mtodo, chamada de funo ou passar uma mensagem, usados em vez de executar uma operao. CONSTRUTORES: Construtores so mtodos usados para inicializar objetos durante sua instanciao. Voc chama a criao de objetos de instanciao porque ela cria uma instncia do objeto da classe. >>>> PUBLIC ITEM (STRING ID, STRING DESCRIPTION, INT \\\\QUANTITY, DOUBLE PRICE) ACESSORES: Os acessores do acesso aos dados internos do objeto. Entretanto, os acessores ocultam o fato de os dados estarem em uma varivel, em uma combinao de variveis ou serem calculados. Os acessores permitem que voc mude ou recupere o valor e tem efeitos colaterais sobre o estado interno. >>>>> GETADJUSTEDTOTAL() MUTANTES: Permitem que voc altere o estado interno de um objeto. >>>>> SETDISCOUNT( ), GETDESCRIPTION( ) MENSAGENS: Os objetos se comunicam uns com os outros atravs de mensagens. As mensagens fazem com que um objeto realize algo. VANTAGENS E OBJETIVOS DA POO [6]: NATURAL MANUTENVEL OPORTUNO EXTENSVEL REUTILIZAVEL CONFIAVEL NATURAL: Os programas naturais so mais inteligveis. Em vez de programar em termos de regies de memria, voc pode programar usando a terminologia de seu problema particular. Voc no precisa se aprofundar nos detalhes do computador enquanto projeta seu programa. Em vez de ajustar seus programas para a linguagem do mundo dos computadores, a OO o libera para que expresse seu programa nos termos dos seu problemas. A POO permite que voc modele um problema em um nvel funcional e no em nvel de implementao. Voc precisa saber como um software funciona, para us-lo: voc simplesmente se concentra no que faz. CONFIVEL: Para criar software til, voc precisa criar software que seja to confivel quanto outros produtos, como geladeiras e televises. Quando foi a ltima vez que seu microondas quebrou? Programas OO, bem projetados e cuidadosamente escritos so confiveis. A natureza modular dos objetos permite que voc faa alteraes em uma parte de seu programa, sem afetar outras partes. Os objetos isolam o conhecimento e a responsabilidade de onde pertencerem.
Por Mariana Florncio
2008
Uma maneira de aumentar a confiabilidade atravs de testes completos. A OO aprimora os testes, permitindo que voc isole conhecimento e responsabilidade em um nico lugar. Tal isolamento permite que voc teste e valide cada componente independentemente. Uma vez que tenha validado um componente, voc pode reutiliz-lo com confiana. REUTILIZVEL: Um construtor inventa um novo tipo de tijolo cada vez que constri uma casa? Um engenheiro eletricista inventa um novo tipo de resistor cada vez que projeta um circuito? Ento, por que os programados continuam reinventando a roda? Uma vez que um problema esteja resolvido, voc de v reutilizar a soluo. Voc pode reutilizar prontamente classes orientadas a objetos bem feitas. Assim como os mdulos, voc pode reutilizar objetos em muitos programas diferentes. Ao contrrio dos mdulos, a POO introduz a herana para permitir que voc estenda objetos existentes e o polimorfismo, para que voc possa escrever cdigo genrico. A OO no garante cdigo genrico. Criar classes bem feitas uma tarefa difcil que exige concentrao e ateno abstrao. Os programadores nem sempre acham isso fcil. Atravs da POO voc pode modelar idias gerais e usar essas idias para resolver problemas especficos. Embora voc 2 v construir objetos para resolver um problema especfico, freqentemente construir esses objetos utilizando partes genricas. MANUTENIVEL: O ciclo de vida de um programa no termina quando voc o distribui. Em vez disso, voc deve manter sua base de cdigo. Na verdade, entre 60% e 80% do tempo gasto trabalhando em um programa para manuteno. O desenvolvimento representa apenas 20% da equao. Um cdigo orientado a objetos bem projetado manutenvel. Para corrigir um erro, voc simplesmente corrige o problema em um lugar. Como uma mudana na implementao transparente, todos os outros objetos se beneficiaro automaticamente do aprimoramento. A linguagem natural do cdigo deve permitir que outros desenvolvedores tambm o entendam. EXTENSVEL: Assim como voc deve manter um programa, seus usurios exigem o acrscimo de nova funcionalidade em seu sistema. Quando voc construir uma biblioteca de objetos, tambm desejar estender a funcionalidade de seus prprios objetos. A POO trata dessas realidades. O software no esttico. Ele deve crescer e mudar com o passar do tempo, para permanecer til. A POO apresenta ao programador vrios recursos para estender cdigo. Esses recursos incluem herana, polimorfismo, sobreposio, delegao e uma varivel de padres de projetos. OPORTUNO: O ciclo de vida do projeto de um software moderno freqentemente medido em semanas. A POO ajuda nesses rpidos ciclos de desenvolvimento. A POO diminui o tempo do ciclo de desenvolvimento, fornecendo software confivel, reutilizvel, e facilmente extensvel. O software natural simplifica o projeto de sistemas complexos. Embora voc no possa ignorar o projeto cuidadoso, o software natural pode otimizar os ciclos de projetos, pois voc pode se concentrar no problema que est tentando resolver. Quando voc divide um programa em vrios objetos, o desenvolvimento de cada parte pode ocorrer em paralelo. Vrios desenvolvedores podem trabalhar nas classes independentemente. Tal desenvolvimento em paralelo leva a tempo de desenvolvimento menores. Encapsulamento Parte 2
Os trs pilares da programao orientada a objetos: ENCAPSULAMENTO, HERANA E POLIMORFISMO.
ENCAPSULAMENTO: O encapsulamento permite que voc divida o programa em vrias partes menores e independentes. Cada parte possui implementao e realiza seu trabalho independentemente das outras partes. a caracterstica da OO de ocultar partes independentes da implementao. O encapsulamento permite que voc construa partes ocultas da implementao do software, que atinjam uma funcionalidade e ocultam os detalhes de implementao do mundo exterior.
OS 3 NVEIS DE ACESSO: PBLICO: Garante o acesso a todos os objetos PROTEGIDO: Garante o acesso instancias, ou seja, para aquele objeto, e para todas as subclasses PRIVADO: Garante acesso somente para a instancia, ou seja, para aquele objeto. Todo comportamento que voc queira tornar visvel para o mundo, precisa ter acesso pblico. Tudo que voc quiser ocultar do mundo exterior precisa ter acesso protegido ou pblico.
MDULO, COMPONENTE ou BEAN: So termos que podem ser usados em vez de software encapsulado.
2008
INTERFACE: Lista os servios fornecidos por um componente. A interface um contrato com o mundo exterior, que define exatamente o que uma entidade externa pode fazer com o objeto. Uma interface o painel de controle do objeto.
As trs -
caractersticas do ENCAPSULAMENTO EFICAZ so: ABSTRAO OCULTAO DE IMPLEMENTAO DIVISO DE RESPOSABILIDADE
ABSTRAO: o processo de simplificar um problema difcil. Quando comea a resolver um problema, voc no se preocupa com cada detalhe. Em vez disso, voc o simplifica, tratando apenas dos detalhes pertinentes a uma soluo.
FIFO: First in First Out >>> Primeiro a entrar o primeiro a sair. LIFO: Last in First Out >>>> ltimo a entrar o primeiro a sair.
TAD (Tipo Abstrato de Dados): Uma TAD um conjunto de dados e um conjunto de operaes sobre esses dados. Os TADs permitem que voc defina novos tipos na linguagem, ocultando dados internos e o estado, atrs de uma interface bem definida. Essa interface apresenta o TAD como uma nica unidade atmica.
TIPOS: Os tipos definem as diferentes espcies de valores que voc pode usar em seus programas. Um tipo define o domnio a partir do qual seus valores vlidos podem ser extrados. Para inteiros positivos, so os nmeros sem partes fracionarias e que so maiores ou iguais a 0. Para tipos estruturados, a definio mais complexa. Alm do domnio, a definio de tipo inclui quais operaes so vlidas no tipo e quais so seus resultados.
OBJETO DE PRIMEIRA CLASSE: aquele que pode ser usado EXTERNAMENTE da mesma maneira que um tipo interno. OBJETO DE SEGUNDA CLASSE: um tipo de objeto que voc pode definir, mas no necessariamente usar, como faria com um tipo interno.
CDIGO FRACAMENTE ACLOPADO: independente da implementao de outros componentes
2008
CDIGO FORTEMENTE ACLOPADO: fortemente vinculado implementao de outros componentes. CDIGO DEPENDENTE: dependente da existncia de um determinado tipo. O cdigo dependente inevitvel. Entretanto, existem graus para a dependncia aceitvel e para a superdependncia.
ENCAPSULAMENTO EFETIVO: a abstrao mais ocultao de implementao mais responsabilidade. Captulo 2 e 3 ENCAPSULAMENTO 1. Os trs pilares da programao orientada a objetos
4
Como a POO baseada neles, os trs pilares so semelhantes a uma torre de blocos; remova o bloco inferior e tudo mais vir abaixo. O encapsulamento uma pea extremamente importante do quebra-cabea, pois ele forma a base de herana e do polimorfismo. ENCAPSULAMENTO HERANA POLIMORFISMO
2. Encapsulamento Em vez de programar como uma nica entidade grande e monoltica, o encapsulamento permite que voc o divida em vrias partes menores e independentes. Cada parte possui implementao e realiza seu trabalho independentemente das outras partes. O encapsulamento mantm essa independncia, ocultando os detalhes internos, ou seja, a implementao de cada parte, atravs de uma interface externa. NOVO TERMO: O encapsulamento a caracterstica da OO de ocultar partes independentes da implementao do software, que atinjam uma funcionalidade e ocultam os detalhes de implementao do mundo exterior. BIZU: Mdulo, Componente ou Bean so termos que so sinnimos de software encapsulado. Uma vez encapsulado, voc pode ver uma entidade de software como uma caixa preta. Voc sabe o que a caixa preta faz, pois conhece sua interface externa. Voc simplesmente envia mensagens para a caixa preta. Voc no se preocupa com o que acontece dentro da caixa; voc s se preocupa com o fato de que isso acontea.
2008
NOVO TERMO: Uma interface lista os servios fornecidos por um componente. A interface um contrato com o mundo exterior, que define exatamente o que uma entidade externa pode fazer com o objeto. Uma interface o painel de controle do objeto. 3. Pblico, privado, protegido Pblico Garante acesso a todos os objetos Protegido Garante acesso instancia, ou seja, para aquele objeto, e para todas as sub-classes. Privado Garante acesso apenas para a instncia, ou seja, para aquele
objeto.
5
4. Por que voc deve encapsular? Quando usado cuidadosamente, o encapsulamento transforma seus objetos em componentes plugveis. Para que outro objeto use seu componente, ele s precisa saber como usar a interface pblica do componente. Tal independncia tem 3 vantagens: - Independncia significa que voc pode reutilizar o objeto em qualquer parte. Quando voc encapsular corretamente seus objetos, eles no estaro vinculados a nenhum programa em particular. Em vez disso, voc pode us-los sempre que seu uso fizer sentido. Para usar o objeto em qualquer lugar, voc simplesmente exerce sua interface - O encapsulamento permite que voc torne transparentes as alteraes em seu objeto. Desde que voc no altere sua interface, todas as alteraes permanecero transparentes para aqueles que estiverem usando o objeto. O encapsulamento permite que voc atualize seu componente, fornea uma implementao mais eficiente ou corrija erros tudo isso sem ter de tocar nos outros objetos de seu programa. Os usurios de seu objeto se beneficiaro automaticamente de todas as alteraes que voc fizer. - Usar um objeto encapsulado no causar efeitos colaterais inesperados entre o objeto e o restante do programa. Como o objeto tem implementao independente, ele no ter nenhuma outra interao com o restante do programa, alm de sua interface. Voc viu que o encapsulamento permite escrever componentes de software com implementaes independentes. As 3 caractersticas do encapsulamento eficaz so: Abstrao Ocultao de Implementao Diviso de Responsabilidade
5. Abstrao Abstrao o processo de simplificar um problema difcil. Quando comea a resolver um problema, voc no se preocupa com cada detalhe. Em vez disso, voc o simplifica, tratando apenas dos detalhes pertinentes a uma soluo. A abstrao tem 2 vantagens: - Ela permite que voc resolva um problema facilmente - Mais importante, a abstrao o ajuda a obter reutilizao. Muitas vezes, os componentes de software so demasiadamente especializados. Essa especializao, combinada com uma interdependncia desnecessria entre os componentes, torna difcil reutilizar um cdigo existente em outra parte. Quando possvel, voc deve se esforar por criar objetos que possam resolver um domnio inteiro de problemas. A abstrao permite que voc resolva um problema uma vez e depois use essa soluo por todo o domnio desse problema. A fila de um banco e a esteira que leva os hamburgeres so o esquema de funcionamento chamado FIFO (First In First Out), onde o primeiro hamburger a entrar na esteira o primeiro a sair da esteira. Cada domnio um exemplo de fila do tipo FIFO. No importa quais tipos de elementos apaream na fila. O que importa que os elementos entram no final da fila e saem dela a partir da frente. Abstraindo os domnios, voc pode criar uma fila uma vez e reutiliz-la em qualquer problema que modele um domnio onde exista uma ordenao FIFO de elementos.
2008
6. Guardando seus segredos atravs da ocultao de implementao A abstrao apenas uma caracterstica do encapsulamento eficaz. Voc pode escrever cdigo abstrato que no encapsulado. Em vez disso, voc tambm precisa ocultar as implementaes internas de seus cdigos.] A ocultao de implementao tem 2 vantagens: Ela protege seu objeto de seu usurio Ela protege os usurios de seu objeto do prprio objeto
Protegendo seu objeto atravs do TAD (Abstract Data Type Tipo abstrato de dados) NOVO TERMO: Um TAD um conjunto de dados e um conjunto de operaes sobre esses dados. Os TADs permitem que voc defina novos tipos na linguagem, ocultando dados internos e o estado, atravs de uma interface bem definida. Essa interface apresenta o TAD como uma nica unidade atmica.
O que um TIPO? Quando programas, voc criar diversas variveis e atribuir valores para elas. Os tipo definem as diferentes espcies de valores que esto disponveis para seus programas. Exemplos de alguns tipos comuns so integers (inteiros), longs (inteiros longos) e floats (reais). Essas definies de tipo informam exatamente quais espcies de tipo esto disponveis, o que os tipos fazem e o que voc pode fazer com eles. NOVO TERMO: Tipos definem as diferentes espcies de valores que voc pode usar em seus programas. NOVO TERMO: Objeto de primeira classe aquele que pode ser usado exatamente da mesma maneira que um tipo interno. NOVO TERMO: Objeto de segunda classe um tipo de objeto que voc pode definir, mas no necessariamente usar, como faria com um tipo interno.
7. Protegendo outros de seus segredos atravs da ocultao de implementao NOVO TERMO: Cdigo Fortemente Acoplado independente da implementao de outros componentes. NOVO TERMO: Cdigo Fortemente Acoplado fortemente vinculado implementao de outros componentes. NOVO TERMO: Cdigo Dependente dependente da existncia de um determinado tipo. O cdigo dependente inevitvel. Entretanto, existem graus para a dependncia aceitvel e para a superdependncia. O cdigo fortemente acoplado anula o objetivo do encapsulamento: criar objetos independentes e reutilizveis. A ocultao de implementao permite que voc escreva cdigo que independente e fracamente acoplado com outros componentes. O cdigo fracamente acoplado menos frgil e mais flexvel para alterar. Um cdigo flexvel facilita a reutilizao e o aprimoramento, pois as alteraes em uma parte do sistema no afetar outras partes no relacionadas.
8. Diviso de Responsabilidade A ocultao de implementao apenas um passo na direo da escrita de cdigo fracamente acoplado. Para ter realmente cdigo fracamente acoplado, voc tambm deve ter uma diviso de responsabilidade correta. Diviso de responsabilidade correta significa que cada objeto deve executar uma funo sua responsabilidade e execut-la bem. A diviso de responsabilidade correta tambm significa que o objeto coesivo. Em outras palavras, no faz sentido encapsular muitas funes aleatrias e variveis. Elas precisam ter um forte vnculo conceitual entre si. Todas as funes devem trabalhar no sentido de uma responsabilidade comum. NOVO TERMO: Encapsulamento Efetivo abstrao + ocultao de implementao + responsabilidade.
2008
Retire a abstrao e voc ter um cdigo que no reutilizvel. Retire a ocultao de implementao e voc ficar com um cdigo fortemente acoplado e frgil. Retire a responsabilidade e voc ficar com um cdigo centrado nos dados, procedural, fortemente acoplado e descentralizado. Sem todas as 3 partes, voc no pode ter um encapsulamento efetivo, mas a falta de responsabilidade o deixa com a pior situao de todas: programao procedural em um ambiente OO. NOVO TERMO: Construtores NOARGS, so construtores que no recebem nenhum tipo de argumento. NOVO TERMO: Um objeto imutvel aquele cujo estado no muda, uma vez construdo. NOVO TERMO: Uma linguagem orientada a objetos pura suporta a noo de que tudo um objeto. NOVO TERMO: Uma linguagem orientada a objetos no considera tudo um objeto
7
Por exemplo, a linguagem Java declara diversos valores de primitivas. As primitiva no so consideradas objetos na linguagem Java. Essas primitivas compreendem boolean, char, byte, short, int, float, long e double. NOVO TERMO: Um pacote um objeto cujo nico propsito conter outro objeto ou primitiva. Um pacote fornecer qualquer nmero de mtodos para obter e manipular o valor possudo. NOVO TERMO: Variveis de classe so variveis que pertencem classe e no a uma instancia especifica. As variveis de classe so compartilhadas entre todas as instancias da classe. NOVO TERMO: Mtodos de classe so mtodos que pertencem classe e no a uma instancia especfica. A operao executada pelo mtodo no dependente do estado de qualquer instancia.
Captulo 4 e 5 Herana 1. Herana de Implementao NOVO TERMO: Herana um mecanismo que permite voc basear uma nova classe na definio de uma classe previamente existente. Usando herana, sua nova classe herda todos os atributos e comportamentos presentes na classe previamente existente. Quando uma classe herda de outra, todos os mtodos e atributos que aparecem na interface da classe previamente existente aparecero automaticamente na interface da nova classe. public classe Employee { private String first_name; private String last_name; private double wage; public Employee( String first_name, String last_name, double wage) { this.first_name = first_name; this.last_name = last_name; this.wage = wage; } public double getWage() { return Wage; } public String getFirstName() { return first_name; } public String getLastName() { return last_name; } }
2008
Instancias de uma classe como Employee podem aparecer em um aplicativo de banco de dados de folha de pagamento. Agora, suponha que voc precisasse modelar um funcionrio comissionado. Um funcionrio comissionado tem um salrio-base, mais uma pequena comisso por venda. Alm desse requisito simples, a classe CommissionedEmployee exatamente igual classe Employee. Afinal, um objeto CommissionedEmployee um objeto Employee. Usando-se o encapsulamento direto, existem duas maneiras de escrever a nova classe CommissionedEmployee. Voc poderia simplesmente repetir o cdigo encontrado em Employee e adicionar o cdigo necessrio para controlar comisses e calcular o pagamento. Entretanto, se voc fizer isso, ter de manter duas bases de cdigo separadas, mas semelhantes. Se voc precisar corrigir um erro, ter de faz-lo em cada lugar. Voc poderia ter uma varivel Employee dentro da classe CommissionedEmployee e delegar todas as mensagens, como getWare() e getFirstName(), instancia de Employee.
8
NOVO TERMO: Delegao o processo de um objeto passar uma mensagem para outro objeto, para atender algum pedido. Entretanto, a delegao ainda obriga a redefinir todos os mtodos encontrados na interface de Employe para passar todas as mensagens. Assim nenhuma dessas opes satisfatria. Vamos ver como a herana pode corrigir esse problema: public class CommissionedEmployee extends Employee { private double commission; //o custo por unidade private int units; //controle do nmero de unidades vendidas public CommissionedEmployee(String first_name, String last_name, double wage,double commission) { super( first_name, last_name, wage); //chama o construtor original para inicializar corretamente o valor da comisso this.commission = commission; } public double calculatePay() { return getWage() + ( commission * units ); } public void addSales( int units ) { this.units = this.units + units; } public void resetSales() { units = 0; } } Aqui, CommissionEmployee baseia sua definio na classe Employee j existente. Como CommissionEmployee herda de Employee, getFirstName(), getLastName(), getWage(), first_name, last_name e wage se tornaro todos parte de sua definio.
2. um versus tem um: aprendendo quando usar herana Conforme voc viu, a herana de implementao permite que suas classes herdem a implementao de outras classes. NOVO TERMO: um descreve o relacionamento em que uma classe considerada do mesmo tipo de outra. Para usar um, voc diz a si mesmo: um objeto CommissionEmployee um Employee? Essa declarao verdadeira e voc saberia imediatamente que a herana vlida nessa situao. NOVO TERMO: Tem um descreve o relacionamento em que uma classe contm uma instncia de outra classe.
2008
NOVO TERMO: Composio significa que uma classe implementada usando-se variveis internas (chamadas de variveis membro), que contm instancias de outras classes.
3. Aprendendo a navegar na teia emaranhada da Herana NOVO TERMO: Uma hierarquia de herana um mapeamento do tipo rvore de relacionamentos que se formam entre classes como resultado da herana.
A herana define a nova classe, a filha, em termos de uma classe antiga, a progenitora (me). Esse relacionamento filha-progenitora ou filha-me o relacionamento de herana mais simples. Na verdade, todas as hierarquias de herana comeam com uma progenitora e uma filha. NOVO TERMO: A classe filha a classe que est herdando; tambm conhecida como SUBCLASSE. NOVO TERMO: A classe progenitora a classe da qual a filha herda diretamente; ela tambm conhecida como SUPERCLASSE. NumberFormat a progenitora das duas filhas: ChoiseFormat e DecimalFormat.
NOVO TERMO: Herana um mecanismo que permite estabelecer relacionamentos um entre classes. Esse relacionamento tambm permite que uma subclasse herde os atributo e comportamentos de sua progenitora. NOTA: Quando uma filha herdar de uma progenitora, a filha obter todos os atributos e comportamentos que a progenitora possa ter herdados de outra classe. A uma filha s permitido aumentar a funcionalidade e adicionar funcionalidades. Uma filha nunca pode remover funcionalidades. Se voc verificar que uma filha precisa remover funcionalidade, isso ser uma indicao de que ela deve aparecer antes da progenitora na hierarquia de herana. Uma filha pode redefinir um comportamento herdado de sua progenitora.
4. Mecnica da Herana Quando uma classe herda de outra, ela herda implementao, comportamentos e atributos. Isso significa que todos os mtodos e atributos disponveis na interface da progenitora aparecero na interface da filha. Uma classe construda atravs de herana pode ter at trs tipos importantes de mtodos e atributos:
2008
- Sobreposto: A nova classe herda o mtodo ou atributo da progenitora, mas fornece uma nova definio - Novo: A nova classe adiciona um mtodo ou atributo completamente novo - Recursivo: A nova classe simplesmente herda um mtodo ou atributo da progenitora. public class TwoDimensionalPoint { private double x_coord; private double y_coord; public TwoDimensionalPoint( double x, double y ){ setXCoordinate( X ); setYCoordinate( Y ); } public double getXCoordinate(){ return x_coord } public void setXCoordinate( double x ) { x_coord = x; } public double getYCoordinate(){ return Y_coord } public void setYCoordinate( double Y ) { Y_coord = Y; } public String toString() { return "I am a 2 dimensional point.\n " + "My x coordinate is: " + getXCoordinate() + "\n" + "My y coordinate is: " + getYcoordinate(); } } public class ThreeDimensionalPoint extends TwoDimensionalPoint { private double z_coord; public ThreeDimensionalPoint( double x, double y, double z ) { super (x,Y); // inicializa os atributos herdados chamando o construtor progenitor setZcoordinate (z); } public double getZCoordinate(){ return Z_coord } public void setZCoordinate( double Z ) { Z_coord = Z; } public String toString() { return "I am a 3 dimensional point.\n " + "My x coordinate is: " + getXCoordinate() + "\n" "My y coordinate is: " + getYcoordinate() + "\n" "My z coordinate is: " + getzcoordinate(); } } Aqui, TwoDimensionalPoint contm coordenadas x e y. A classe define mtodos para obter e configurar os pontos, assim como para criar uma representao de String da instncia do ponto. ThreeDimensionalPoint herda de TwoDimensionalPoint. ThreeDimensionalPoint acrescenta a coordenada Z, assim como um mtodo para recuperar o valor e para configurar o valor. A classe tambm fornece um mtodo para obter uma representao de String da instancia. Como ThreeDimensionalPoint herda de TwoDimensionalPoint, ela tambm tem os mtodos contidos dentro de TwoDimensionalPoint.
10
4. 1 Mtodos e atributos Sobrepostos
2008
A herana permite que voc pegue um mtodo ou atributo previamente existente e o redefina. A redefinio de um mtodo permite que voc mude o comportamento do objeto para esse mtodo. Um mtodo ou atributo sobreposto aparecer na progenitora e na filha. ThreeDimensionalPoint redefine o mtodo toString() que aparece em TwoDimensionalPoint: // de TwoDimensionalPoint public String toString() { return "I am a 2 dimensional point.\n" + "My x coordinate is: "+ getXcoordinate() "My Y coordinate is: "+ getYcoordinate(); } TwoDimensionalPoint define um mtodo toString() que identifica a instancia como um ponto bidimensional e imprime
11 suas duas coordenadas.

ThreeDimensionalPoint redefine o mtodo toString() para identificar a instancia como um ponto tridimensinal e imprime suas trs cordenadas: // de ThreeoDimensionalPoint public String toString() { return "I am a 3 dimensional point.\n" + "My x coordinate is: "+ getXcoordinate() "My Y coordinate is: "+ getYcoordinate() "My Z coordinate is: "+ getZcoordinate(); } NOVO TERMO: Sobrepor o processo de uma filha pegar um mtodo que aparece na progenitora e reescrev-lo para mudar o comportamento do mtodo. A sobreposio de um mtodo tambm conhecida como redefinio de um mtodo.
Novos mtodos e atributos Um novo mtodo ou atributo que aparece na filha, mas no aparece na progenitora. A filha acrescenta o novo mtodo ou atributo em sua interface. Voc viu novos mtodos no exemplo ThreeDimensionalPoint, que acrescenta os novos mtodos getZcoordinate() e setZcoordinate.
Mtodos e atributos recursivos Um mtodo ou atributo recursivo definido na progenitora ou em alguma outra ancestral, mas no na filha. Voc viu mtodos recursivos no cdigo-fonte de TwoDimensionalPoint e ThreeDimensionalPoint. getXcoordinate() um exemplo de mtodo recursivo, pois ele definido por TwoDimensionalPoint e no por ThreeDimensionalPoint.
5. Tipos de Herana Ao todo, existem trs maneiras principais de usar herana: - Reutilizao de Implementao - Para diferena - Para Substituio de tipo
5.1 Herana para Implementao Em vez de recortar e colar cdigo ou instanciar e usar um componente atravs de composio, a herana torna o cdigo automaticamente disponvel, como parte da nova classe. Como mgica, sua nova classe nasce com funcionalidades. 5.2 Herana para Diferena NOVO TERMO: Programao por diferena significa herdar uma classe e adicionar apenas o cdigo que torne a nova classe diferente da classe herdada.
2008
Assim quando programa pela diferena, voc escreve cdigo mais correto em um espao de tempo mais curto. Assim como a herana de implementao, voc pode fazer essas alteraes incrementais sem alterar o cdigo.
5.2.1 ESPECIALIZAO NOVO TERMO: Especializao o processo de uma classe filha ser projetada em termos de como ela diferente de sua progenitora. Quando tudo estiver dito e feito, a definio de classe da filha incluir apenas os elementos que a tornam diferente de sua progenitora. Uma classe filha se especializa em relao sua progenitora, adicionando novos atributos e mtodos previamente existentes. A adio de novos mtodos ou a redefinio de mtodos j existentes permite que a filha expresse comportamentos que so diferentes de sua progenitora.
12
Um ThreeDimensionalPoint uma especializao de um TwoDimensionalPoint e um TwoDimensionalPoint uma generalizao de um ThreeDimensionalPoint. Quando voc percorre uma hierarquia para baixo, voc se especializa. Quando voc percorre uma hierarquia para cima, voc generaliza.
NOVO TERMO: Dada alguma filha, uma ANCESTRAL uma classe que aparece na hierarquia de classes antes da progenitora. Format uma ancestral de DecimalFormat.
NOVO TERMO: Dada uma classe, toda classe que aparece depois dela na hierarquia de classes uma descendente da classe dada. DecimalFormat uma descendente de Format. Digamos que tivssemos a hierarquia de herana de classes. Dizemos que OneDimensionalPoint progenitora de TwoDimensionalPoint e ancestral ThreeDimensionalPoint e de FourDimensionalPoint. Tambm podemos dizer que TwoDimensionalPoint, ThreeDimensionalPoint e FourDimensionalPoint so todas descendentes de OneDimensionalPoint. Todos os descendentes compartilham os mtodos e atributos de seus ancestrais.
2008
NOVO TERMO: A classe raiz ou classe base a classe superior da hierarquia de herana. OneDimensionPoint
13 uma classe raiz, base.

NOVO TERMO: Uma classe folha uma classe sem filhas. DecimalFormat uma classe folha. NOVO TERMO: Em todos os exerccios voc viu herana simples. Algumas implementaes de herana permitem que um objeto herde diretamente de mais de uma classe. Tal implementao de herana conhecida como HERANA MLTIPLA.
5.3 Herana para substituio de tipo A substituio de tipo permite que voc descreva relacionamentos com capacidade de substituio. Um relacionamento com capacidade de substituio significa que voc pode passar para o construtor qualquer objeto que herde. Usando a capacidade de conexo, voc pode adicionar novos subtipos em seu programa, a qualquer momento. NOVO TERMO: Um SUBTIPO um tipo que estende outro tipo atravs de herana. NOVO TERMO: Um mtodo declarado, mas no implementado, chamado de MTODO ABSTRATO. Somente classes abstratas podem ter mtodos abstratos. Polimorfismo Tipos de Polimorfismo - de Incluso ( polimorfismo puro) - Paramtrico - de Sobreposio - de Sobrecarga ( ad-hoc ) NOVO TERMO: Polimorfismo > Ter muitas formas. Em termos de programao, muitas formas significa que um nico nome pode representar um cdigo diferente, selecionado por algum mecanismo automtico. Assim, o polimorfismo permite que um nico nome expresse muitos comportamentos diferentes. Toda essa conversa sobre expressar comportamentos diferentes pode parecer um pouco abstrata. Pense no termo abrir. Voc pode abrir uma porta, uma caixa, uma janela e uma conta no banco. A palavra abrir pode ser aplicada a muitos objetos diferentes no mundo real. Cada objeto interpreta abrir de sua prpria maneira. Entretanto, em cada caso, voc pode simplesmente dizer abrir, para descrever a ao. Nem todas as linguagens suportam polimorfismo. Uma linguagem que suporta polimorfismo uma LINGUAGEM POLIMRFICA. Em contraste, uma LINGUAGEM MONOMRFICA, no suporta polimorfismo e, em vez disso, restringe tudo a um e apenas um comportamento esttico, pois cada nome estaticamente vinculado a seu cdigo. NOVO TERMO: PERSONALITIES um exemplo de varivel polimrfica. Uma varivel polimrfica uma varivel que pode conter muitos tipos diferentes. Em uma linguagem tipada, as variveis polimrifcas esto restritas a conter valores especficos. Em uma linguagem dinamicamente tipada, uma varivel polimrfica pode conter qualquer valor.
2008
1. Polimorfismo de Incluso O polimorfismo de incluso, s vezes chamado de POLIMORFISMO PURO, permite que voc trate objetos relacionados genericamente. O polimorfismo de incluso (polimorfismo puro) til porque diminui a quantidade de cdigo que precisa ser escrito. BIZU: O polimorfismo de incluso permite que um objeto expresse muitos comportamentos diferentes, em tempo de execuo.
14
2. Polimorfismo Paramtrico O polimorfismo paramtrico permite que voc crie mtodos e tipos genricos. Assim como o polimorfismo de incluso (polimorfismo puro), os mtodos e tipos genricos permitem que voc codifique algo uma vez e faa isso trabalhar com muitos tipos diferentes de argumentos. BIZU: Do mesmo modo, o polimorfismo paramtrico permite que um objeto ou mtodo opere com vrios tipos de parmetros diferentes.
3. Polimorfismo de Sobreposio A sobreposio permite que voc sobreponha um mtodo e saiba que o polimorfismo garantir que o mtodo correto sempre ser executado. Os mtodos abstratos so freqentemente referidos como MTODOS ADIADOS, pois voc retarda a definio para as classes descendentes.
4. Polimorfismo de Sobrecarga A sobrecarga tambm conhecida como POLIMORFISMO AD-HOC, permite que voc use o mesmo nome de mtodo para muitos mtodos diferentes. Cada mtodo difere apenas do nmero e no tipo de seus parmetros. BIZU: A sobrecarga permite que voc declare o mesmo mtodo vrias vezes. Cada declarao difere simplesmente no nmero e no tipo de argumento.
5. Converso A converso e sobrecarga andam lado a lado. A converso tambm pode fazer com que um mtodo parea como se fosse polimrfico. A converso ocorre quando um argumento de um tipo convertido para o tipo esperado, internamente. Considere a definio: public float add ( float a, float b); add() recebe dois argumentos: float e soma O segmento de cdigo a seguir cria algumas variveis internas e chama o mtodo add(): int iA = 1; int iB = 2; add (iA , iB); Entratanto o mtodo add() solicita dois argumentos float. a que a converso entra em ao. Quando voc chama add() com argumentos int, os argumentos so convertidos em valores floar pelo compilador. Isso significa que, antes que os argumentos int sejam passados para add(), primeiro eles so convertidos em valores flaot. Assim a converso faz o mtodo add() parecer polimrfico, pois o mtodo parece funcionar para valores float e int. Conforme voc viu, tambm seria possvel ter um mtodo add sobrecarregado, da forma: public int add (iA , iB);
2008
Nesse caso, add(iA , iB) no resultaria em converso. Em vez disso, o mtodo add() corretamente sobrecarregado seria chamado.
UML (Unfied Modeling Language) Captulo 8
1. Introduo UML A UML uma linguagem de modelagem padro. A linguagem consiste em vrias notaes grficas que voc pode usar 15 para descrever a arquitetura interna de seu software. Os programadores, arquitetos e analistas de software usam linguagens de modelagem para descrever graficamente o projeto do software. NOVO TERMO: Uma linguagem de modelagem uma notao grfica para descrever projeto de software. A linguagem tambm inclui vrias regras para distinguir entre desenhos corretos e incorretos. So essas regras que tornam a UML uma linguagem de modelagem e no apenas um punhado de smbolos para desenho. Uma linguagem de modelagem no igual a um processo ou metodologia. Uma metodologia diz a voc como projetar o software. Em vez disso, uma linguagem de modelagem ilustra o projeto que voc criar enquanto segue uma metodologia. NOVO TERMO: Uma metodologia define um procedimento para projetar software. As linguagens de modelagem capturam esse projeto graficamente. NOVO TERMO: A UML uma linguagem de modelagem padro. A UML consiste na notao para descrever cada aspecto de um projeto de software. importante notar que uma linguagem de modelagem no diz nada a respeito de como chegar a seu projeto. Metodologias ou processos que mostram as diretrizes de como analisar e projetar software. NOVO TERMO: Uma metodologia ou processo descreve como projetar software. Uma metodologia freqentemente contm uma linguagem de modelagem.
2. Modelando suas classes Embora o cdigo seja a documentao mais completa do seu projeto, pode ser extremamente difcil para outros mexerem nele. A documentao tambm til para algum que no conhea a linguagem de implementao. Em vez disso, voc precisa de uma notao que lhe permita documentar seu projeto, para que outros possam entendlos imediatamente. Desse modo, outros podero ver a estrutura de classes de alto nvel e apenas se aprofundar nos detalhes, quando isso for necessrio. De certa forma, uma notao grfica o isola dos detalhes, para que voc possa exprimir-se de entender a estrutura de alto nvel de um programa. Uma maneira pela qual a UML o ajuda a transmitir seu projeto fornecendo um rico conjunto de notao para descrever suas classes. Usando essa notao, outros podem ver facilmente as principais classes que compe o projeto de seu programa. Conforme voc ver, a UML permite definir as classes, assim como descrever os relacionamentos de alto nvel entre as classes.
3. Notaes bsicas de classe A UML fornece um rico conjunto de notao para modelar classes. Na UML, uma caixa representa a classe. A caixa superior sempre contm o nome da classe. A caixa do centro contm todos os atributos e a inferior contm as operaes. Notas sobre seu modelo aparecem em caixas com cantos dobrados. NOTA: A UML faz diferena entre operaes e mtodos. Na UML, uma operao um servio que voc pode solicitar de qualquer objeto de uma classe, enquanto um mtodo uma implementao especfica da operao.
2008
16
Dentro do modelo, voc pode usar os caracteres: +, #, -. Esses caracteres transmitem a visibilidade de um atributo ou de uma operao. Hfen ( - ): Privado Tralha ( # ): Protegido Adio ( + ): Pblico
s vezes, uma nota ajudar a transmitir um significado que, de outro modo, ficaria perdido ou seria ignorado.
4. Notao avanada de classe A UML tambm define algumas notaes, mais avanadas. O uso correto dessa notao o ajuda a criar modelos mais descritivos. A UML ajuda a ser mais descritivo, permitindo que voc amplie o vocabulrio da prpria linguagem, atravs do uso de esteritipos. NOVO TERMO: Um esteritipo um elemento da UML que permite que voc amplie o vocabulrio da prpria linguagem UML. Um esteritipo consiste em uma palavra ou frase includa entre sinais de maior e menor duplos ( << >> ). Voc coloca um esteritipo acima ou ao lado de um elemento existente.
2008
A UML fornece uma notao para transmitir que uma classe abstrata: o nome da classe abstrata escrito em ITLICO.
17
5. Modelando um relacionamento de classe As classes no existem no vcuo. Em vez disso, elas tm relacionamentos complexos entre si. Esses relacionamentos descrevem como as classes interagem umas com as outras. NOVO TERMO: Um relacionamento descreve como as classes interagem entre si. Na UML, um relacionamento uma conexo entre dois ou mais elementos da notao. A UML reconhece trs tipos de relacionamento de objetos: - Dependncia - Associao - Generalizao
Dependncia Dependncia o relacionamento mais simples entre objetos. A dependncia indica que um objeto depende da especificao de outro objeto. NOTA: Especificao uma maneira diferente de dizer interface ou comportamento. NOVO TERMO: Em um relacionamento de dependncia, um objeto dependente da especificao de outro objeto. Se a especificao mudar, voc precisar atualizar o objeto dependente.
Associao Os relacionamentos de associao vo um pouco mais fundo do que os relacionamentos de dependncia. As associaes so relacionamentos estruturais. Uma associao indica que um objeto contm, ou que est conectado a, outro objeto.
A figura mostra que uma pessoa empresta de um banco. Na notao UML, toda associao tem um nome. Neste caso, a associao chamada de empresta de. A seta indica a direo da associao. NOVO TERMO: O nome da associao um nome que descreve o relacionamento.
NOVO TERMO: Na associao, o papel de pessoa devedor e o papel do banco credor. NOVO TERMO: O papel da associao a parte que um objeto desempenha um relacionamento. NOVO TERMO: A multiplicidade indica quantos objetos podem tomar parte na instncia de uma associao.
2008
NOTA: Voc indica multiplicidade atravs de um nico nmero, uma lista ou com um asterisco (*). Um nico nmero significa que determinado nmero de objetos no mais e no menos podem participar da associao. Assim, por exemplo, um 6 significa que 6 objetos e somente 6 objetos podem participar da associao. * significa que qualquer nmero de objetos pode participar. Uma lista que define um intervalo de objetos que podem participar da associao, por exemplo, 1..4 indica que de 1 a 4 objetos podem participar da associao. 3 .. * indica que 3 ou mais objetos podem participar. NOTA: Quando voc deve modelar associaes? Voc deve modelar associaes quando um objeto contiver outro objeto o relacionamento tem um. Uma associao 18 permite que voc modele quem faz o que em um relacionamento. A UML define dois tipos de associao: Agregao e Composio. Esses dois subtipos de associao o ajudam a refinar mais seus modelos. 5.2.1 Agregao Uma agregao um tipo especial de associao. Uma agregao modela um relacionamento TEM UM (ou parte de) entre pares. Esse relacionamento significa que um objeto contm outro. Pares significa que um objeto no mais importante do que outro. NOVO TERMO: Um relacionamento parte/todo descreve o relacionamento entre objetos onde um objeto contm outro. NOVO TERMO: Uma agregao um tipo especial de associao que modela o relacionamento TEM UM de relacionamentos todo/parte entre pares. Importncia, no contexto de uma agregao, significa que os objetos podem existir independentemente uns dos outros. Nenhum objeto importante do que o outro no relacionamento.
Voc v que um banco pode conter qualquer numero de objetos Cliente. O losango aberto ajuda seu modela a indicar qual objeto o todo e qual a parte. Aqui, o losango diz que Banco o todo. Banco o objeto que TEM UM no relacionamento. Banco contm objetos clientes. Como Banco e Cliente so independentes, eles so pares. Voc pode dizer que o objeto Banco e o objeto Cliente so pares, porque os objetos Cliente podem existir independentemente do objeto Banco. Isso significa que, se o banco encerrar suas operaes, os clientes no desaparecero com o banco. Em vez disso, os clientes podem se tornar clientes de outro banco. Do mesmo modo, um cliente pode sacar seus fundos e o banco continuar. NOTA: Quando voc deve modelar a agregao? Voc deve modelar uma agregao quando o objetivo de seu modelo for escrever a estrutura de um relacionamento de pares. Uma agregao mostra explicitamente o relacionamento estrutural todo/parte.
5.2.2 Composio A composio um pouco mais rigorosa do que a agragao. A composio no um relacionamento entre pares. Os objetos no so independentes uns dos outros.
2008
Aqui, voc v que Banco pode conter muitos objetos FILIAL. O losango fechado diz que esse um relacionamento de composio. O losango tambm diz quem TEM UM. Neste caso, banco TEM UM, ou contm, objetos filial. Como esse um relacionamento de composio, os objetos filial no podem existir independentemente do objeto banco. A composio diz que, se o banco encerrar suas atividades, as filiais tambm fecharo. Entretanto, o inverso no necessariamente verdade. Se uma filial fechar, o banco poder permanecer funcionando. NOTA: Quando voc deve modelar uma composio? Ao contrario da agregao,a composio no modela relacionamentos todo/parte de pares. Em vez disso, a parte dependente do todo.
Generalizao
19
Um relacionamento de generalizao um relacionamento entre o geral e o especfico. a herana. NOVO TERMO: Um relacionamento de generalizao indica um relacionamento entre o geral especfico. Se voc tem um relacionamento de generalizao, ento sabe que pode substituir uma classe filha pela classe progenitora. A generalizao incorpora o relacionamento UM. Os relacionamentos UM permitem que voc defina relacionamentos com capacidade de substituio. Uma linha cheia com uma seta fechada e vazada indica um relacionamento de generalizao
Captulo 9 Anlise Orientada a Objetos 1. O processo de desenvolvimento de software Existem tantas maneiras de desenvolver software quanto existem desenvolvedores. Entretanto, uma equipe de desenvolvimento de software precisa de uma estratgia unificada para desenvolver software. Nada ser feito, se cada desenvolvedor fizer sua prpria atividade. As metodologias de software definem uma maneira comum de encarar o desenvolvimento de software. Uma metodologia freqentemente conter uma linguagem de modelagem (como a UML) e um processo. NOVO TERMO: Um processo de software mostra os vrios estgios do desenvolvimento de software.
Um exemplo familiar de processo de software e o PROCESSO DE CASCATA.
2008
Quando segue o processo de cascata, voc vai de um estgio para o prximo. Entretanto, uma vez que voc complete um estgio, no h volta. O processo de cascata tenta evitar alteraes, proibindo mudar quando um estgio esta concludo. Tal estratgia protege os desenvolvedores de requisitos que mudam constantemente. Entretanto, tal processo rgido freqentemente resulta em software que no o que voc ou seu cliente quer. Quando voc analisa um problema, projeta uma soluo e comea a implementar, seu entendimento do problema continuamente aprofundado. O melhor entendimento de seu problema pode muito bem invalidar uma anlise ou projeto anterior. Os requisitos podem at mudar enquanto voc desenvolve (talvez um concorrente tenha acrescentado um novo recurso em seu produto). Infelizmente, o processo de cascata no pode enfrentar a realidade do moderno desenvolvimento de software requisitos que mudam constantemente.
20
O PROCESSO INTERATIVO O processo interativo o oposto do processo de cascata. O processo interativo permite alteraes em qualquer ponto do processo de desenvolvimento. O processo permite alterao adotando uma estratgia INTERATIVA e INCREMENTAL para o desenvolvimento de software. NOVO TERMO: Um processo interativo uma estratgia interativa e incremental para desenvolvimento de software. Outro modo de pensar a respeito do processo como uma estratgia evolutiva. Cada interao aperfeioa e elabora gradualmente um produto bsico em um produto amadurecido.
1.1.1 UMA ESTRATGIA INTERATIVA Ao contrrio do processo de cascata, o processo interativo permite que voc continuamente volte e refine cada estgio do desenvolvimento. Por exemplo, se voc descobrir que o projeto simplesmente no funciona ao executar a implementao, pode voltar e fazer um projeto adicional e uma nova anlise. esse refinamento contnuo que torna o processo interativo.
1.1.2 ESTRATGIA INCREMENTAL Ao seguir um processo interativo, voc no conclui simplesmente uma interao grande que constri o programa inteiro. Em vez disso, o processo interativo divide o trabalho de desenvolvimento em vrias interaes pequenas. Abaixo a figura dessa estratgia incremental.
2008
21
Cada interao do processo introduz uma pequena melhoria incremental no programa. Essa melhoria pode ser um novo recurso ou um refinamento de um recurso j existente. De qualquer modo, a interao tem um objetivo especfico e, no final da interao, voc tem uma melhoria notvel na funcionalidade. Imagine que voc esteja criando um MP3 player. Durante uma interao do projeto, voc pode terminar o componente que reproduz um arquivo MP3. Para determinar se o componente funciona, voc pode codific-lo de modo que abra e reproduza um arquivo de musica especifico. Na prxima interao, voc pode adicionar a capacidade de escolher qual arquivo vai ser reproduzido. Em cada interao, voc tem um progresso mensurvel. No final da primeira interao, voc pode ouvir o componente reproduzir uma msica. No final da interao seguinte, voc tem um mecanismo que permite escolher dinamicamente uma msica para tocar. Seguindo uma estratgia interativa, voc v o progresso constantemente. Por outro lado, se voc tentar fazer tudo simultaneamente, poder ser difcil ver qualquer forma mensurvel de progresso. Em vez disso, o projeto parecer constantemente atolado em um nico lugar nunca h qualquer resultado. Se um projeto nunca for adiante, a moral vai baixar e se tornar difcil determinar o que precisa ser feito em seguida. Moral baixa e confuso sobre o que fazer em seguida fragmentar e matar um projeto. O progresso constante fornece a voc retorno constante. Voc pode usar esse retorno como o modo de garantir se est no caminho certo. Se voc tentar completar o projeto inteiro de uma vez, no saber se criou a soluo correta at terminar. Voltar e corrigir algo que no foi feito corretamente, ser muito mais dispendioso se voc precisar voltar e reescrever o programa inteiro! A interao, por outro lado, torna muito mais barato voltar e corrigir algo. Como voc recebe retorno constante, mais provvel que identifique o problema mais cedo. Se voc identificar seus problemas mais cedo, ser mais fcil refazer uma interao ou duas para corrigi-lo. sempre mais desejvel reescrever uma interao do que reescrever um programa inteiro! Se voc mantiver suas interaes pequenas, no perder muito tempo, caso tenha de se desfazer de alguma delas. Se um problema chegar base da interao original, uma estratgia interativa no poder salv-lo. Tal problema fundamental pode ser dispendioso demais para corrigir e pode danificar a qualidade do produto.
1.1.3 UMA METODOLOGIA DE ALTO NVEL A metodologia seleciona e escolhe as tcnicas que se mostram eficazes a partir de outras metodologias. A metodologia consiste em um processo interativo, no qual uma interao tem 4 estgios. - Anlise de Requisitos

- Projeto - Implementao - Teste Aps o estgio de teste, voc tambm pode ter estgios de: - Lanamento - Manuteno Esses estgios so importantes no ciclo de vida de um projeto de software.
2008
2. AOO (Anlise Orientada a Objetos) AOO o processo usado para entender o problema que voc est tentando resolver. Aps completar a anlise, voc dever entender os requisitos do problema, assim como o vocabulrio do domnio do problema.
22 NOVO
TERMO: Anlise Orientada a Objetos um processo que usa uma estratgia orientada a objetos para ajud-lo a entender o problema que est tentando resolver. No final da anlise voc dever entender o domnio do problema e seus requisitos em termos de classes e interaes de objetos. Para projetar uma soluo para um problema, voc precisa entender como os usurios utilizaro o sistema. A resposta dessa pergunta so os requisitos do sistema. Os requisitos informam o que os usurios querem fazer com o sistema e quais tipos de respostas eles esperam receber. NOVO TERMO: Sistema o termo da AOO para um conjunto de objetos que interagem. Voc pode dizer que esses objetos constituem um sistema modelo do problema. Esses objetos so instancias de classes derivadas de objetos concretos ou abstratos no domnio do problema que est sob estudo. A anlise tambm o ajuda a se familiarizar com o domnio do problema. Estudando o domnio do problema voc comea a identificar os objetos de que precisa para modelar corretamente o sistema. A AOO, conforme o nome sugere, uma estratgia orientada a objetos para anlise de requisitos. A AOO utiliza uma estratgia baseada em OO, modelando o problema atravs de objetos e suas interaes. Existem dois modelos principais. - MODELO DE CASO DE USO: descreve como um usurio interage com o sistema. - MODELO DE DOMNIO: captura o vocabulrio principal do sistema. Usando o modelo de domnio, voc comea a identificar os objetos que pertencem ao seu sistema. Um modelo de domnio corretamente construdo pode resolver muitos problemas no mesmo domnio.
3. Usando Casos de Estudo para descobrir o uso do sistema Ao comear a analisar um problema, voc primeiro precisa entender como seus usurios utilizaro ou interagiro com o sistema. Esses usos compreendem os requisitos do sistema e prescrevem o sistema que voc cria. Atendendo os requisitos de seus usurios, voc produz um sistema til. NOVO TERMO: Os requisitos so recursos ou caractersticas que o sistema deve ter para resolver determinado problema. NOVO TERMO: Um modo de descobrir esses usos atravs da anlise de casos de uso. Atravs da anlise voc definir vrios casos de uso. Um caso de uso descreve como um usurio vai interagir com o sistema. NOVO TERMO: Anlise de casos de uso o processo de descoberta de casos de uso atravs da criao de cenrios e histrias com usurios em potencial ou existentes em um sistema. NOVO TERMO: Um caso de uso descreve a interao entre o usurio do sistema e o sistema como o usurio utilizar o sistema do seu prprio ponto de vista. A criao de casos de uso um processo interativa. Existem vrios passos que voc deve dar durante cada interao, para formalizar seus casos de uso. Para definir seus casos de uso, voc deve:
1. 2. 3. 4.
Identificar Atores Criar uma lista preliminar de casos de uso Refinar e nomear os casos de uso Definir a seqncia de eventos de cada caso de uso

5. Modelar seus casos de uso
2008
Voc no cria casos de uso no vcuo! Enquanto deriva seus casos de uso, voc deve consultar aqueles que utilizaro o sistema seus clientes. A participao do cliente absolutamente fundamental para se descobrir os casos de uso (a no ser que voc esteja escrevendo o software para si mesmo). Seus clientes so os especialistas do domnio. Eles conhecem bem seu espao de atuao e sabem do que precisam em seu software. Sempre certifique-se de contar com o conhecimento deles e us-lo para orientar os requisitos de seu software. Fazer os usurios comporem histrias sobre o dia ideal de interao com o sistema pode ser uma boa maneira de quebrar o gelo nessa atividade.
23
+ IDENTIFIQUE OS ATORES O primeiro passo na definio de seus casos de uso definir os atores que usaro o sistema. NOVO TERMO: Um ator tudo que interage com o sistema. Pode ser um usurio humano, outro sistema de computador ou um chimpanz. Voc precisa pedir aos seus clientes para que descrevam os usurio do sistema. As perguntas podem incluir as seguintes: - Quem principalmente utilizar o sistema? - Existem outros sistemas que usaro o sistema? Por exemplo, existem quaisquer usurios que no so seres humanos? - O sistema se comunicar com qualquer outros sistema? Por exemplo, h um banco de dados j existente que voc precise integrar? - O sistema responde ao estmulo gerado por algum que no seja usurio? Por exemplo, o sistema precisa fazer algo em certo dia do ms? Um estimulo pode ser proveniente de fontes normalmente no consideradas ao se pensar do ponto de vista puramente do usurio. Considere uma loja da WEB. Uma loja on-line permite que usurios convidados naveguem pelo catlogo de produtos, verifique o preo e solicite mais informaes. A loja tambm permite que usurios registrados comprem itens, assim como controla seus pedidos e mantm informaes dos usurios. A partir dessa breve descrio, voc pode identificar dois atores: usurios convidados e usurios registrados. Cada um desses dois atores interage com o sistema. Abaixo a figura mostra a notao UML para um ator: um desenho de pessoa com um nome. Voc deve dar a cada um de seus atores um nome no ambguo.
importante notar que um determinado usurio do sistema pode assumir o papel de muitos atores diferentes. Um ator um papel. Por exemplo, um usurio poderia entrar no site como convidado mas posteriormente se conectar com registrado para poder fazer uma compra. Um usurio pode assumir muitos papis diferentes enquanto interage com um sistema. Um ator descreve o papel que o usurio pode assumir enquanto interage com o sistema.
+ CRIE UMA LISTA PRELIMINAR DE CASOS DE USO Para definir seus casos de uso, voc precisa fazer algumas perguntas. Comece com sua lista de atores conhecidos. Voc precisa perguntar o que cada ator faz com o sistema. No caso da loja WEB, voc tem usurio convidados e usurios registrados. O que cada um desses atores faz? Os usurios convidados podem fazer o seguinte: 1. Navegar pelo catlogo de produtos 2. Pesquisar o catalogo de produtos

3. Procurar um item especifico 4. Pesquisar o site 5. Adicionar itens em um carrinho de compras e especificar a quantidade 6. Ver o preo dos itens selecionados 7. Mudar a quantidade de itens em seu carrinho 8. Ver a lista de produtos popular e nova 9. Navegar pela lista de itens desejados de outros usurios 10 Solicitar mais informaes sobre o produto Os usurios registrados podem fazer o seguinte: 1. Tudo que o usurio convidado pode fazer 2. Fazer uma compra 3. Adicionar itens em sua lista de itens desejados 24 4. Ver uma lista personalizada recomendada 5. Manter sua conta 6. Assinar notificaes 7. Tirar proveito de ofertas especiais personalizadas 8. Controlar seus pedidos 9. Assinar vrias listas de distribuio 10. Cancelar um pedido
2008
Quando tentar identificar casos de uso, voc tambm devera fazer a pergunta: Como um usurio muda seu papel? No caso da loja on-line um usurio convidado pode se tornar um usurio registrado, das seguintes maneiras: - O usurio convidado pode se conectar com o site - O usurio convidado pode se registrar no site Um usurio registrado se torna um usurio convidado, como segue: - Um usurio registrado pode se desconectar do site At aqui, essas perguntas so orientadas pela interao. Voc tambm pode adotar uma estratgia orientada por resultados para a descoberta. Por exemplo: voc pode dizer que um usurio registrado recebe uma notificao. Um segundo ponto de vista pode ajud-lo a descobrir casos de uso que voc poderia ter ignorado, se simplesmente ficasse com o primeiro ponto de vista. Finalmente considere as vrias entidades que os usurios manipulam. Aqui, voc v produtos, informaes sobre conta e varias listas de produtos e descontos. Como todoas essas entidades entram no sistema? Quem adiciona novos produtos e edita ou exlui produtos antigos? Esse sistema precisar de um terceiro ator, o administador. Passando pelo processo anteriormente delineado, voc pode verificar que os administradores podem fazer o seguinte: 1. Adicionar, editar e excluir produtos 2. Adicionar, editar e excluir incentivos 3. Atualizar informaes de conta As perguntas podem levar a outras perguntas. Por exemplo, quem atualiza a lista de produtos populares? Quem envia notificaes e correspondncias para as listas de distribuio? Um quarto ator, o prprio sistema, executa todas essas aes. + REFINE E NOMEIE OS CASOS DE USO Agora que voc tem uma lista preliminar de casos de uso, precisa refinar a lista. Em particular, voc desejar procurar oportunidades de dividir ou combinar casos de uso. ++ DIVIDINDO CASOS DE USO Cada caso de uso deve executar um objetivo principal. Quando voc encontrar um caso de uso que estiver fazendo muita coisa, desejar dividi-lo em dois ou mais casos de uso. Considere o caso de uso a seguir: Os usurios convidados podem adicionar itens em um carrinho de compras e especificar a quantidade Voc deve dividir esse caso de uso em dois: - Os usurios convidados podem adicionar itens em um carrinho de compras - Os usurios convidados podem especificar a quantidade de um item Voc pode fazer a diviso de casos de uso, devido maneira como eles se relacionam entre si. Os casos de uso so muito parecidos com as classes. Um caso de uso pode conter outro. Assim, se uma instancia de caso de uso exige que outra faa seu trabalho, ela pode us-la.
2008
Um caso de uso tambm pode estender o comportamento de outro caso de uso. Como resultado, voc pode colocar comportamento comum em um caso de uso e, ento, desenvolver outros casos de uso que sejam especializaes do original. Pegue o exemplo os usurios registrados podem fazer uma compra. Um caso de uso pode especializar o pedido, criando um caso de uso pedido para presente. Um pedido para presente poderia ser entregue sem recibo. ++ COMBINANDO CASOS DE USO Voc no quer casos de uso redundantes. Um modo de evitar a dedundancia ficar atento s variantes do caso de uso. Quando voc as encontrar, dever combinar as variantes em um nico caso de uso. NOVO TERMO: Variante de um caso de uso uma verso especializada de outro caso de uso mais geral. Considere os dois casos de uso a seguir:
25 - Os usurios convidados podem pesquisar o catlogo de produtod

- Os usurios convidados podem procurar um item especifico Aqui, o segundo simplesmoente uma variante do primeiro caso de uso mais geral. Neste caso, o segundo caso de uso difere apenas nos paramentros de pesquisa. melhor ter simplesmente um caso de uso e documentar a variante nos modelos de caso de uso que voc construira posteriormente. ++ OS CASOS DE USO RESULTANTES Aps concluir o refinamento de seus casos de uso, voc deve nomear cada caso de uso. Assim como na atribuio de nomes de atores, voc deve se esforar por nomear seus casos de uso de maneira que evite confuso. Aqui esto os casos de uso resultantes para usurios convidades e usurios registrados, aps a diviso e a combinao: 1. Navegar pelo catalogo de produtos 2. Pesquisar o catalogo de produtos 3. Pesquisar o site 4. Adicionar item no carrinho de compras 5. Ver o preo dos itens 6. Mudar a quantidade de item 7. Ver a lista de produtos destacada 8. Navegar em uma lista de itens desejados 9. Solicitar informaes sobre o produto 10. Pedir 11. Manter o pedido 12. Adicionar itens na lista de itens desejados 13. Ataulizar a conta 14. Assinar correspondncia 15. Aplicar incentivos 16. Conectar 17 Desconectar 18. Registar Neste ponto voc tem uma lista de casos de uso bem desenvolvida. Agora basta especificar totalmente cada caso de uso. + DEFINA A SEQUENCIA DE EVENTOS DE CADA CASO DE USO A breve lista de casos de uso s informa parte da histria. Internamente, muito mais poderia estar ocorrendo dentro de um caso de uso. Pegue um pedido como exemplo. Um usurio no pode fazer um pedido em um passo. Em vez disso, ele deve usar uma seqncia de passos pra concluir um pedido com xito (como fornecer um mtodo de pagamento). A sequencia de passos que um usurio usa para completar um caso de uso conhecida como cenrio. Um caso de uso contitudo de vrios cenrios. NOVO TERMO: Um cenrio uma seqncia ou fluxo de eventos entre o usurio e o sistema. Como parte de sua anlise de casos de uso, voc deve primeiro especificar os cenrios de cada caso de uso. Vamos desenvolver o caso de uso pedido. Primeiro, comece descrevendo o caso de uso em um pargrafo: O usuario registrado prossegue com a totalizao e pagamento, para adquirir os itens de seu carrinho de compras. Uma vez na pgina de totalizao e pagamento, o usurio fornce informaes de entrega. Uma vez fornecidas, o sistema totaliza e apresenta o pedido. Se tudo estiver correto, o cliente poder optar por continuar com o pedido. Quando usurio continua com o pedido, o sistema consulta suas informaes de pagamento. Uma vez fornecidas, o sistema
2008
autoriza o pagamento. Ento, ele exibe uma pgina de conformao de pedido final para os registros do usurio, e envia um e-mail de confirmao. Existem alguns aspectos interessantes nesse caso de uso. Primeiro, ele no diz nada sobre a implementao subjacente. Segndo, voc pode us-la para identificar as condies previas e posteriores do caso de uso. NOVO TERMO: CONDIES PREVIAS so aquelas condies que devem ser satisfeitas para que um caso de uso comece. CONDIES POSTERIORES so os resultados de um caso de uso. Aqui, a condio prvia que o usurio j colocou itens no carrinho. O caso de uso pedido pede os itens do carrinho. A condio posterior um pedido. Aps completar o caso de uso, o sistema conter um pedido para usurio. + DIAGRAMAS DE CASOS DE USO
26 Assim como a UML fornce uma maneira de documentar e transmitir projeto de classe, tambm existem maneiras formais
de capturar seus casos de uso. De especial interesse so: - DIAGRAMAS DE CASO DE USO - DIAGRAMA DE INTERAO - DIAGRAMA DE ATIVIDADE Cada um ajuda a visualizar os vrios casos de uso. Os diagramas de caso de uso modelam os relacionamentos entre casos de uso e os relacionamentos entre casos de uso e atores. Embora a descrio textual de um caso de uso possa ajud-lo a entender um caso de uso isolado, um diagrama o ajuda a ver como os casos de uso se relacionam uns com os outros. A notao UML para um caso de uso: uma elipse rotulada
Coloque um ator e um caso de uso juntos no mesmo diagrama e voc ter um diagrama de caso de uso. Esse diagrama muito simples; entretanto, examinando-o, voc pode ver que os usurios registrados executam o caso de uso PEDIDO.
Os diagramas podem ser um pouco mais complicados. O diagrama tambm pode mostrar os relacionamentos existentes entre os prprios casos de uso. Conforme j foi dito, um caso de uso pode conter e usar outro.
UM RELACIONAMENTO USA

UM RELACIONAMENTO ESTENDE
2008
V recomendaes de produtos estende a genrica consulta a lista de produtos destacada, apresentando ao usurio registrado um lista de produtos personalizados para suas preferncias de compreas. A normal v recomendaes de produtos, vonforme vista por um usurio convidado pode simplemsnete mostrar os itens mais vendidos ou mais solicitados. Essa extenso apresenta ao usurio produtos nos quais seu perfil sugere que ele poderia estar interessado. Assim como nas classes, possvel ter um caso de uso abstrato. Um caso de uso abstrato um caso de uso que outros casos de uso utilizam ou estendem, mas nunca usado diretamente por um ator em si. As abstraes normalmente so descobertas aps voc ter feito sua anlise de caso de uso inicial. Enquanto voc estuda seus casos de uso, pode encontrar meios de extrair caractersticas comuns e coloc-las em casos de uso abstratos. + DIAGRAMAS DE INTERAO diagramas de caso de uso ajudam a modelar os relacionamentos entre casos de uso. Os diagramas de interao ajudam a capturar as interaes entre vrios atores participantes do sistema. Vamos expandir os casos de uso que vimos anteriormente. Vamos adicionar um novo ator, o representante de servio ao cliente. Freqentemente um usurio registrado pode se esquecer de sua senha. O representante de servio ao cliente est l para ajudar o usurio a reaver o acesso sua conto. Vamos criar um novo caso de uso: SENHA ESQUECIDA Um usurio registrado liga para o representante de servioes ao clinete e informa ao representante que perdeu sua senha. O representante de servios ao cliente pega o nome completo do usurio e extrai as informaes de conta do usurio. O representante de servios ao cliente faz ento vrias perguntas ao usurio registrado, para estabelecer sua identidade. Aps passar por vrias interpelaes, o representante de servio ao cliente exclui a senha antiga e cria uma nova. Ento, o usurio recebe a nova senha por e-mail. Esse caso de uso tambm pode ser descrito como segue: - Senha esquecida 1. O usurio registrado liga para o representante de servio ao clinete 2. O usurio registrado fornece o nome completo 3. O representante de servio ao cliente recupera as informaes do cliente 4. O usurio registrado responde a vrias perguntas de identificao 5. O representante de servio ao cliente cria uma nova senha 6. O usurio recebe a nova senha por e-mail - condies prvias 1. O usurio esqueceu a senha - condies posteriores 1. uma nova senha enviada por e-mail ao usurio
27 Os
- alternativa: a identificao falhou 1. o usurio pode falhar em responder corretamente as perguntas de identificao no passo 4. se assim for, a chamada terminar - alternativa: o usurio no encontrado No passo 2, o nome forncecido pode no ser de um usurio conhecido. Se assim for, o representante de servio ao cliente se oferecer para registrar o usurio chamador. Existem 2 tipos de diagramas de interao: - diagrama de seqncias - diagramas de colaborao ++ Diagrama de Seqncia Um diagrama de seqncia modela as interaes entre o usurio registrado, o representante, com o passar do tempo. Voc deve usar diagramas de seqncia quando quiser chamar a ateno para a seqncia de eventos de um caso de uso, com o passar do tempo.
2008
28
Conforme voc pode ver na ilustrao, um diagrama de seqncia representa os eventos entre cada ator e o sitema (site web). Cada participante do caso de uso representado no inicio do diagrama como uma caixa ou como um desenho de pessoa (mas voc pode chamar ambos de caixa). Uma linha tracejada, conhecida com linha da vida, sai de cada caixa. A linha da vida representada o tempo de vida da caixa durante o caso de uso. Assim, se um dos atores fosse embora durante o caso de uso, a linha terminaria na ultima seta que termina ou se origina no ator. Qunado um ator deixa um caso de uso, voc pode dizer que seu tempo de vida trminou. NOTO TERMO: Uma linha da vida uma linha tracejada que sai de um diagrama de seqncia. A linha da vida representa o tempo de vida do objeto representado pelo caixa. As setas se originam na linha da vida para indicar que o ator enviou uma mensagem para outro ator para o sistema. Quando voc desce na linha da vida, pode ver as mensagens conforme elas se seqencialmente, com o passar do tempo. O tempo corre de cima para baixo em um diagrama de seqncia. Assim, subindo na linha da vida, voc pode reproduzir a seqncia de eventos de trs para frente. ++ DIAGRAMA DE COLABORAO Voc deve usar o diagrama de seqncias se tiver a inteno de chamar a ateno para a seqncia de eventos com o passar do tempo. Se voc quiser modelar os relacionamentos entre os atores e o sistema, ento deve criar um diagrama de colaborao.
2008
Em um diagrama de colaborao, voc modela uma interao conectando os participantes com uma linha. Acima da linha, voc rotula cada evento que as entidas geram, junto com a direo do evendo. ++ DIAGRAMA DE ATIVIDADE Os diagramas de interao modelam as aes seqenciais. Entratanto, eles no podem modelar processos que podem ser executador em paralelo. Os diagramas de atividade o ajudam modelar processos que podem ser executador em paralelo. Considere o caso PESQUISA. Esse caso de uso pesquisa o site web e o catlogo de produtos simultanemaente, usando o caso de uso PESQUISA o CATALOGO DE PRODUTOS e o caso de uso PESQUISA O SITE. No h motivo pelo qual essas duas pesquisas no possam ser executadas simultaneamente. O usurio ficaria impaciente se tivesse de esperar que todas as pesquisas terminassem seqencialmente.
29
Uma elipse representa cada estado do processo. A barra preta grossa representa um ponto onde os processos devem ser sincronizados ou reunidos 0 antes que o fluxo de execuo possa ser retomado. Aqui, voc v que as duas pesquisas so executadas em paralelo e depois reunidas, antes que o site possa exibir os resultados.
+ CONSTRUINDO O MODELO DE DOMNIO Atravs da anlise de casos de uso, voc captura as interaes do sistema. Entretanto, os casos de uso tambm o ajudam a capturar o vocabulrio do sistema. Esse vocabulrio controi o domnio do problema. O vocabulrio do domnio identifica os principais objetos do sistema. O modelo de domnio lista os objetos que voc precisara para modelar corretamente o sistema. Pegue a loja on-line. Atravs dos casos de uso, voc pode identificar muitos objetos.
Abaixo segue o relacionamento dos objetos do domnio
2008
30 independentemente
O modelo de domnio importante por vrios motivos. Primeiro, o modelo de domnio modela seu problema de quaisquer preocupaes com implementao. Em vez disso, ele modela o sistema em um nvel conceitual. Essa independncia proporciona a flexibilidade para usar o modelo de domnio que voc controi para resolver muitos problemas diferentes dentro do domnio. Segundo, o modelo de domnio controi a base do modelo de objeto que, finalmente, se tornar seu sitema. A implementao final pode adicionar novas classses e remover outras. Entretanto, o domnio, fornce algo para que voc comece e contrua seu projeto um esqueleto. Finalmente, um modelo de domnio bem definido estabelece claramente um vocabulrio comum para seu problema. Encontrando-se um vocabulrio comum, todos os envolvidos no projeto podero encara-lo a partir de uma posio e um entendimento iguais. REQUISITOS: Informam o que o usurio quer fazer com o sistema e quais tipos de respostas eles esperam receber. So recursos ou caractersticas que o sistema deve ter para resolver determinado problema. SISTEMA: o termo da AOO para um conjunto de objetos que interagem. Esse conjunto de objetos constituem o SISTEMA MODELO DO PROBLEMA. MODELO DE CASOS DE USO: Descreve como o usurio interage com o sistema. MODELO DE DOMNIO: Captura o vocabulrio principal. Comea a capturar os objetos que pertencem ao sistema. CASOS DE 1. 2. 3. 4. 5. USO: Descreve a interao entre o usurio do sistema e o sistema. um processo interativo Identificar atores Criar lista de casos de uso Refinar e nomear os casos de uso Descrever a seqncia de eventos Criar modelo de casos de uso
ATOR: tudo que interage com o sistema. Um ator descreve que papel o usurio pode assumir enquanto interage com o sistema. VARIANTE: uma verso especializada de um caso de uso mais geral. CENRIO: a seqncia de passos que um usurio usa para completar um caso de uso. a seqncia ou fluxo de eventos entre o usurio e o sistema. CONDIES PRVIAS: a condio que devem ser satisfeitas para um caso de uso comear. CONDIES POSTERIORES: So os resultados de um caso de uso.
DIAGRAMA DE CASOS DE USO DIAGRAMA DE INTERAO DIAGRAMA DE SEQUENCIA DIAGRAMA DE COLABORAO DIAGRAMA DE ATIVIDADE DIAGRAMA DE CASOS DE USO: Modela os relacionamentos entre os atores e os casos de uso ou relacionamentos entre casos de uso, onde esses podem usar ou estender outro caso de uso.
2008
CASO DE USO ABSTRATO: um caso de uso que outros casos de uso estendem ou usam, mas nunca usado diretamente por um ator. DIAGRAMA DE INTERAO: Ajuda a capturar as interaes entre os vrios atores participantes do sistema. DIAGRAMA DE SEQUENCIA: Usado quando quiser chamar a ateno para a seqncia de eventos de um caso de uso com o passar do tempo. Utiliza uma linha vertical chamada linha da vida. DIAGRAMA DE COLABRAO: Quando quiser modelar o relacionamento entre os atores e o sistema. DIAGRAMA DE ATIVIDADE: Ajuda a modelar processos que podem ser executados em paralelo. MODELO DE DOMNIO: Lista os objetos que voc precisar para modelar corretamente o sistema.
31
Captulo 10 POO (Projeto Orientado a objetos) 1. Introduo O POO o ajuda a pegar o domnio que voc encontrou na AOO e a projetar uma soluo. Enquanto o processo da AOO o ajudou a descobrir muitos dos objetos de domnio do problema, o POO o ajuda a descobrir e projetar os objetos que aparecero na soluo especfica do problema.
2. POO (Projeto Orientado a Objetos) NOVO TERMO: POO o processo de construir o modelo de uma soluo. Dito de outra maneira, POO o processo de dividir uma soluo em vrios objetos constituintes. NOVO TERMO: O modelo de objeto o projeto dos objetos que aparecem na soluo de um problema. O modelo final de objeto pode conter muitos objetos no encontrados no domnio. O modelo de objeto descrever as vrias responsabilidades, relacionamentos e estruturas do objeto. O processo de POO o ajuda a descobrir como voc vai implementar a anlise que completou durante a AOO. Principalmente, o modelo que conter as classes principais do projeto, suas responsabilidades e uma definio de como elas vo interagir e obter suas informaes. Um PROCESSO DE PROJETO FORMAL o ajuda a determinar quais objetos aparecero em seu programa e como eles vo interagir ou se encaixar. O projeto indicar a estrutura de seus objetos e um processo de projeto o ajudar a descobrir muitos dos problemas de projeto que voc encontrar ao codificar. No leve o projeto ao extremo. Exatamente como a AOO pode sofrer de paralisia da anlise, o POO pode sofrer de paralisia do projeto. Como voc sabe quais aspectos de seu sistema so arquitetonicamente significativos? As partes significativas so os aspectos do sistema onde uma deciso diferente alteraria completamente a estrutura ou comportamento do sistema.
3. Como voc aplica POO (Projeto Orientado a Objetos)? O POO um processo interativo que identifica os objetos e suas responsabilidades em seu sistema, e como esses objetos se relacionam. Voc refina continuamente o modelo de objetos, quando faz a interao pelo processo de projeto. Cada interao deve dar uma idia mais aprofundada do projeto e talvez at do prprio domnio.

Existem vrios passos pouco definidos que voc deve seguir para construir seu modelo de objetos. 1. Gerar uma lista inicial de objetos 2. Refinar as responsabilidades de seus objetos 3. Desenvolver os pontos de interao 4. Detalhar os relacionamentos entre objetos 5. Construir seu modelo
2008
PASSO 1: Gere uma lista inicial de objetos Quando comea a projetar seu sistema, voc precisa comear com o domnio que definiu durante a anlise. Cada objeto do domnio e cada ator deve se tornar uma classe em seu novo modelo de objetos. Voc ver que alguns dos objetos de domnio no tero lugar em seu novo modelo de objetos final; entretanto, neste ponto, voc no pode ter certeza de qual ter; portanto, voc precisa incluir todos eles.
32 Ao procurar a lista de classes inicial, voc tambm desejar considerar todos os eventos que possam afetar seu sistema.
Cada um desses eventos deve aparecer inicialmente como uma classe. O mesmo pode ser dito para todos os relatrios, telas e dispositivos. Todos esses elementos devem ser transformados em uma classe.
PASSO 2: Refine as responsabilidades de seus objetos Uma lista de objetos um bom ponto de partida, mas apenas uma pequena parte de seu projeto global. Um projeto completo capturar as responsabilidades de cada objeto, assim como a estrutura e os relacionamentos do objeto. Um projeto mostrar como tudo se encaixa. Para ter esse entendimento, voc precisa identificar o que cada objeto faz. Existem dois aspectos que voc precisa explorar para que possa responder pergunta: O que o objeto faz? Primeiro, voc precisa explorar a responsabilidade. Atravs do encapsulamento, voc sabe que cada objeto deve ter um nmero pequeno de responsabilidades. Durante o projeto, voc precisa identificar as responsabilidades de cada objeto e dividir o objeto, quando ele comear a fazer coisas demais. Voc tambm precisa certificar-se de que cada responsabilidade aparea apenas uma vez e esse conhecimento espalhado igualmente entre todos os objetos. Em seguida, voc precisa explorar o modo como cada objeto faz seu trabalho. Os objetos freqentemente delegaro trabalho para outros objetos. Atravs de seu projeto, voc precisa identificar essas colaboraes. NOVO TERMO: Um objeto delega trabalho para colaboradores. NOVO TERMO: Colaborao o relacionamento onde os objetos interagem para realizar o mesmo propsito. Em um nvel prtico, as responsabilidades sero transformadas em mtodos. Os relacionamentos sero transformados em estruturas, entretanto, um entendimento global da responsabilidade o ajudar a dividir a responsabilidade eficientemente entre os objetos. Voc precisa evitar ter um pequeno conjunto de objetos grandes. Atravs do projeto, voc ter a certeza de dividir as responsabilidades. O QUE SO CARTES CRC? Uma maneira de distribuir responsabilidades e colaboraes atravs do uso de cartes CRC (classe responsabilidade colaborao). Conforme o nome sugere CRC nada mais do que uma ficha de arquivo 4 x 6 linhas. Os cartes CRC ajudam a definir o propsito de um objeto, chamando a ateno para as responsabilidades do objeto. Quando usa cartes CRC, voc simplesmente cria um carto para cada classe. Voc escreve o nome da classe no inicio do carto e, em seguida, divide o carto em duas sees. Liste as responsabilidades no lado esquerdo e, no lado direito, liste todos os outros objetos que o carto precisa para executar suas responsabilidades.
NOME DA CLASSE
RESPONSABILIDADES
COLABORAES
Os cartes CRC so intencionalmente de baixa tecnologia. Voc intencionalmente limitado pelo tamanho do carto. Se voc achar que o carto no grande o suficiente, so boas as chances de que preciso dividir a classe. Uma grande vantagem dos cartes CRC que voc no fica preso a um computador. Acredite se quiser, ter de projetar diante de um
2008
computador nem sempre desejvel. O projeto no um exerccio solitrio e pode exigir conversas e discusses entre os projetistas. Os cartes CRC liberam voc e seus colegas projetistas para projetar quando e onde quiserem. COMO VOC APLICA CARTES CRC? Voc inicia uma sesso escolhendo vrios casos de uso. Quando voc escolher os casos de uso, identifique as classes principais e crie um carto para cada uma. Quando tiver os cartes, divida-os entre os projetistas e, em seguida, inicie a sesso. Durante a sesso, voc investigar o cenrio de cada caso de uso. medida que voc percorrer o cenrio, cada projetista dever se concentrar nas responsabilidades e colaboraes de sua classe. Quando sua classe for necessria no cenrio, notar seu uso e dir a todos os outros projetistas se precisa delegar para um outro objeto. UM EXEMPLO DE CARTO CRS Vamos considerar o caso de uso PEDIDO e ver como voc poderia usar cartes CRC para atribuir responsabilidades para 33 ele. - Pedido O usurio registrado passa para a totalizao do pagamento O usurio registrado fornece informaes de entrega O sistema mostra o total do pedido O usurios registrado fornece informaes de pagamento O sistema autoriza o pagamento O sistema confirma o pedido O sistema envia um e-mail de confirmao - Condies Prvias Um carrinho de compras no vazio - Condies Posteriores Um pedido no sistema - Alternativa: Cancelar o pedido Durante os passos 1 a 4, o usurio opta por cancelar o pedido. O usurio volta para a home page - Alternativa: A autorizao Falhou No passo 5, o sistema falha em autorizar as informaes de pagamento. O usurio pode introduzir novamente as informaes ou cancelar o pedido Comece identificando as classes. Imediatamente, voc ver: Usurio Registrado, Pedido, Pagamento, Confirmao de Pedido, Carrinho de Compras, Informaes de Entrega. Talvez voc tambm queira incluir Sistema. Comece lendo os passos do cenrio. Aqui, o sistema autoriza o pagamento, exibe e confirma o pedido. O sistema tambm cria e introduz o pedido. Voc pode comear dividindo o sistema em Funcionrio, Mostra Pedido e Terminal de Pagamento. Funcionrio Usurio Registrado
Usurio Registrado
O prximo passo percorrer cada passo do cenrio e identificar responsabilidades. O passo 1 o usurio registrado passa para a totalizao e pagamento, simplesmente um clique em um link na interface. Por simplicidade, vamos ignorar a interface. O passo 2 o usurio registrado fornece informaes de entrega. Aqui voc v que o usurio registrado responsvel por fornecer suas informaes de entrega para o funcionrio. Usurio Registrado Fornece informaes de entrega Informaes de Entrega
2008
O passo 3 o sistema exibe o total do pedido, um pouco mais complicado. Antes que o sistema possa exibir algo, o funcionrio deve introduzir o pedido, ver o preo dele e totalizar o pedido. O funcionrio usar o carrinho de compras para recuperar os itens e o mostra pedido para exibir o pedido resultante; entretanto, o funcionrio provavelmente no deve ser responsvel tambm por ver o preo ou por totalizar o pedido. Essas tarefas so melhores delegadas para outro objeto. Lembre-se de que um objeto s deve ter um pequeno nmero de responsabilidades.
34 Ao
QUANTAS RESPONSABILIDADES POR CLASSE desenvolver seus cartes CRC, voc precisa garantir que cada classe tenha apenas duas ou trs responsabilidades principais. Se voc tiver mais responsabilidades, dever dividir a classe em duas ou mais classes separadas. Ao trabalhar com cartes CRC, voc tambm precisa lembrar que eles atendem um propsito especifico: definir responsabilidades e relacionamentos de colaborao simples. No use cartes CRC para descrever relacionamentos complexos. LIMITAES DO CARTO CRC Assim como toda boa ferramenta, os cartes CRC tem seus usos, bem como suas limitaes. Entretanto, os cartes CRC so difceis de usar quando o prjeto se torna mais complicado. Pode ser difcil controlar interaes complexas entre os objetos, simplesmente atravs do uso de cartes CRC.
PASSO 3: Desenvolva os pontos de interao Quando tiver completado seus cartes CRC para um conjunto de casos de uso, voc precisar desenvolver os pontos de interao. Um ponto de interao qualquer lugar onde um objeto use outro. NOVO TERMO: Ponto de interao qualquer lugar onde um objeto use outro. INTERFACES: Voc precisa de uma interface bem definida, onde um objeto usa outro. Voc quer ter certeza de que uma alterao em um implementao no v danificar o outro objeto. AGENTES: Um AGENTE faz a mediao entre dois ou mais objetos para atingir algum objetivo. TRANSFORMAES DE DADOS: Durante o projeto, voc pode encontrar lugares onde precisa transformar dados, antes de passa-los para outro objeto. Normalmente, voc delegaria tal transformao de dados para outro objeto; se precisar alterar a transformao, voc s precisar atualizar a classe de transformao. Essa prtica tambm ajuda a dividir responsabilidades.
PASSO 4: DETALHE OS RELACIONAMENTOS ENTRE OS OBJETOS Quando voc tiver estabelecido os relacionamentos de responsabilidade e colaborao bsicos, precisar detalhar os relacionamentos complexos entre as classes. a que voc define as dependncias, associaes e generalizaes. Detalhar esses relacionamentos um passo importante, pois isso define como os objetos se encaixam. Isso tambm define a estrutura interna dos vrios objetos. Comece com os cartes CRC. Embora eles no capturem cada relacionamento, eles capturam a colaborao.
PASSO 5: CONSTRUA SEU MODELO Quando chegar ao passo 5, voc ter modelado o sistema formalmente. Um modelo completo consistir em diagramas de classe e diagramas de interao. Esses diagramas descrevero a estrutura e o relacionamento das vrias classes do sistema. A UML tambm define modelos para modelar interaes, transio de estado e atividades. O modelo pedido ilustra todos os relacionamentos importantes entre pedidos e as classes que exibem o pedido. Concebivelmente, voc tambm ter modelos que ilustram os relacionamentos entre funcionrios, pedidos e usurio registrado.
2008
Novamente, voc quer apenas modelar o que faz sentido os componentes arquitetnicos interessantes. Lembre-se de que voc est tentando transmitir informaes especificas atravs de seus modelos e no simplesmente apresentar modelos por questes de documentao.
35
Voc tambm pode criar diagramas de seqncia e colaborao para modelar as interaes importantes do sistema. Quando tiver terminado de criar os modelos, voc dever ter descries de todas as principais estruturas e interaes encontradas no sistema. Esses modelos dizem como os vrios objetos esto estruturados, como eles se relacionam e como eles se encaixam para modelar a soluo do problema elaborado durante a anlise. RESUMO: O POO continua o trabalho da AOO, pegando o domnio e transformando-o em uma soluo para seu problema. Atravs do processo de POO, voc pega seu modelo de domnio e constri o modelo de objetos de sua soluo. O modelo de objetos descreve os aspectos arquitetonicamente significativos de seu sistema, como a estrutura e os relacionamentos dos objetos como os objetos se encaixam. No final do POO, voc dever ter uma boa idia do que implementar no cdigo. Existem 5 passos interativos que voc pode seguir, enquanto realiza o POO. 1. 2. 3. 4. 5. criar lista de objetos refinar os objetos desenvolver pontos de interao detalhar os relacionamentos entre os objetos construir seu modelo
Padres Avanados de Projeto - Abstact Factory - Singleton - Typesafe Enum * * * Interator (Cursor) Adapter Proxy (Wraper) (Surrogate)
O Padro Abstarct Factory Os relacionamentos com capacidade de conexo da herana, combinados com o polimorfismo, permitem que voc conecte novos objetos em seu programa, a qualquer momento; entretanto, h um inconveniente. Para que seu programa possa instanciar esses novos objetos, voc deve entrar no cdigo e alter-lo para que ele instancie os novos objetos, em vez dos antigos (e voc precisar fazer isso em todos os lugares onde os objetos antigos so instanciados!). No seria timo se houvesse um modo mais fcil de conectar seus novos objetos? O padro abstract Factory resolve esse problema atravs da delegao. Em vez de instanciar objetos atravs de seu programa, voc pode delegar essa responsabilidade para um objeto chamado factory. Quando um objeto precisar criar outro objeto, ele solicitar que o factory faa isso. Usando um factory, voc pode isolar toda a criao de objeto em um nico local. Quando voc precisar introduzir novos objetos em seu sistema, s precisar atualizar o factory, para que ele crie uma instancia de suas novas classes. Os objetos factory nunca sabero a diferena. O padro Abstract Factory usa herana e capacidade de conexo. A classe base de factory define todos os mtodos de criao de objeto e cada subclasse factory define quais objetos cria, sobrepondo os mtodos. NOVO TERMO: Um analisador de XML pega um documento XML e o transforma em uma representao de objeto.
2008
LEMBRE-SE: Um empacotador um adaptor. Um empacotador converte a interface de um objeto em uma interface alterantiva. Normalmente, voc usa um empacotador para converter a interface em uma interface esperada pelo seu programa. O padro FACTORY METHOD est intimamente relacionado ao padro Abstract Factory. Na verdade, um Abstract Factory pode usar Factory Method para criar os objetos que retorna. Um mtodo Factory nada mais do que um mtodo que cria objetos, createPARSER( ) um exemplo de mtodo Factory. Class.newInstance ( ) um exemplo de mtodo Factory. Um mtodo Factory pode aparecer em uma classe normal ou em uma Factory Abstrata. Em qualquer caso, ele cria objetos, ocultando assim a classe real do objeto criado.
36
Quando usar o padro Abstract Factory: - Voc quiser ocultar o modo de como um objeto criado - Voc quiser ocultar a classe atual do objeto criado - Voc quiser um conjunto de objetos usados juntos. Isso evita que voc use objetos incompatveis. - Voc quiser usar diferentes verses de uma implementao de classe. Um Abstract Factory permite que voc troque essas diferentes verses em seu sistema. Nome do Padro: Abstract Factory Precisa de uma maneira de trocar objetos plugveis de forma transparente Fornecer uma interface abstrata que providencie mtodos para instanciar objetos Permite que voc troque facilmente novos tipos de classe em seu sistema; entretanto, dispendioso adicionar tipos no relacionados.
Problema:
Soluo:
Consequncias:
O Padro Singleton Quando projetar seus sistemas, voc ver que algumas classes deveriam ter logicamente apenas uma instancia, como um factory ou um objeto que acesse algum recurso no compartilhado. Nada, entretanto, impedir que um objeto intancie outro. Como voc impe seu projeto. O padro Singleton fornece a resposta dessa pergunta. O padro Singleton impe seu projeto colocando a responsabilidade da criao e da intermediao do acesso instancia no prprio o objeto. Fazer isso garante que apenas uma instancia seja criada, alm de fornecer um nico ponto de acesso para essa instancia. Quando usar o padro Singleton: Use o padro Singleton quando voc quiser restringir uma classe a ter apenas uma instncia.
Nome: Problema:
Soluo
Consequencia:
Singleton Deve existir apenas uma instancia de um objeto no sistema em determinado momento. Permitir que o objeto gerencie sua prpria criao e acesso atravs de um mtodo de classe. Acesso controlado instancia do objeto. Tambm pode dar acesso a um nmero definido de instncias (como apenas 6 instancias, com uma ligeira alterao no padro. um pouco mais difcil herdar um singleton.
2008
O padro Typesafe Enum Quando usar o padro Typesafe Enum: - Voc se achar escrevendo numerosas primitivas pblicas ou constantes de string. - Voc se achar impondo identidade em um valor, em vez de derivar a identidade do prprio valor. Nome: Problema: Typesafe Enum As constantes inteiras so limitadas
37
Soluo:
Criar uma classe para cada tipo de constante e depois fornecer instncias de constantes para cada valor de constante. Constantes OO extensveis. Constantes teis que tm comportamento. Voc ainda precisa atualizar cdigo para usar as novas constantes, quando elas forem adicionadas. Exige mais memria do que uma contante simples.
Consequencias:
Captulo 11 Reutilizando projetos atravs de padres avanados 1. Reutilizao de projeto Um objetivo importante da POO a reutilizao de cdigo. Quando reutiliza cdigo, voc ganha tranqilidade, sabendo que seu software est construdo em uma base de cdigo confivel e testada. Alm disso, voc sabe que o cdigo reutilizado resolver seu problema. Tal tranqilidade tima, mas quanto tranqilidade enquanto projeta? Como voc sabe se seu projeto bom? Felizmente, os padres de projeto podem ajudar a dirimir muitas das dvidas que voc encontrar ao projetar. medida que o tempo passa, muitos projetistas e programadores tm notado os mesmos elementos de projeto aparecem repetidamente em todos os seus projetos. A comunidade de OO resolveu identificar, nomear e descrever esses conceitos de projeto recorrentes. O resultado uma lista sempre crescente de padres de projeto. NOVO TERMO: Padres de projeto um conceito de projeto reutilizvel. Quando usa padres de projeto, voc sabe que baseou seu projeto em projetos confiveis comprovados pelo uso. Tal reutilizao permite que voc saiba se est na trilha certa para uma soluo confivel. Quando voc reutiliza um padro de projeto, est usando um projeto que outros usaram com xito, muitas vezes anteriormente.
2. Padres de Projeto Um padro de projeto consiste em 4 elementos: Nome do padro Problema Soluo Conseqncias
NOME DO PADRO Um nome identifica exclusivamente cada padro de projeto. Assim como a UML fornece linguagem de projeto comum, os nomes dos padres fornecem um vocabulrio comum para descrever os elementos de seu projeto para outros. Outros desenvolvedores podem entender seu projeto rpida e facilmente, quando voc usa um vocabulrio comum. PROBLEMA
2008
Cada padro de projeto existe para resolver algum conjunto distinto de problemas de projetos e cada padro de projeto descreve o conjunto para o qual foi feito para resolver. Desse modo, voc pode usar a descrio do problema para determinar se o padro se aplica ao problema especifico. SOLUO Descreve como o padro de projeto resolve e identifica os objetos arquitetonicamente significativos na soluo, assim como as responsabilidades e relacionamentos que esses objetos compartilham. CONSEQUENCIAS sempre importante documentar suas decises de projeto, assim como as conseqncias resultantes. Ter essas decises documentadas ajuda os outros a entender as escolhas que voc fez e a determinar se o projeto pode ajudar a resolver seus prprios problemas. Do mesmo modo, as conseqncias do padro de projeto pesaro bastante em suas decises de usar o padro. Se um padro deve usa-lo, mesmo que ele possa resolver seu problema.
38
Os padres so: - Projetos reutilizveis que provaram funcionar no passado - Solues abstratas para um problema de projeto geral - Solues para problemas recorrentes - Um modo de construir um vocabulrio de projeto - Um registro pblico da experincia do projeto - Uma soluo para um problema Os padres no so - Uma soluo para um problema especifico - A resposta mgica para todos os seus problemas - Uma muleta, voc mesmo ainda precisa fazer seu projeto funcionar - Classes concretas, bibliotecas, solues prontas
3. O padro ADAPTER Para poder se conectar com o seu programa, um objeto deve fazer parte da hierarquia com capacidade de substituio. Ento, o que voc faria se quisesse conectar um objeto em seu programa, mas ele no pertencesse hierarquia correta? O padro Adapter apresenta uma soluo alternativa que resolve o problema da incompatibilidade, transformando a interface incompatvel naquela que voc precisa. O padro adapter funciona empacotando o objeto incompatvel dentro de um objeto adaptador compatvel. O objeto adaptador contm uma instancia do objeto e expe o objeto atravs da interface que se encaixa em seu programa. Como a classe adaptadora empacota, s vezes esse padro referido como PADRO EMPACOTADOR. NOVO TERMO: Um ADAPTADOR um objeto que transforma a interface de outro objeto. O padro adapter til quando voc quer usar um objeto que tem uma interface incompatvel. O padro adapter permite que voc reutiliza diretamente objetos que, de outro modo, precisaria alterar ou jogar fora. Os adaptadores tambm so teis no sentido de uma ao preventiva. Nome padro: Problema: do Adapter, Wrapper
Como reutilizar objetos incompatveis Fornecer um objeto que interface incompatvel compatvel converta a em uma
Soluo:
Tornar incompatvel objetos compatveis; resulta em classes extras talvez muitas Conseqncias: , se voc usar herana ou precisar manipular cada subclasse de uma forma diferente
2008
4. O padro PROXY Normalmente, quando um objeto quer interagir com outro, ele faz isso atuando diretamente sobre o outro objeto. Na maioria dos casos, essa estratgia direta a melhor estratgia, mas existem ocasies em que voc desejar controlar o acesso entre seus objetos de forma transparente. O padro PROXY trata desses casos.
39 Listenets
registram seu interesse nos eventos gerados por um EventGenerator. Quando o EventGenerator gera um evento, ele colocar o evento em cada um de seus objetos Listeners. Embora essa soluo funcione, ela coloca uma grande carga sobre o evento EventGenerator. O padro proxy apresenta uma soluo para esse problema. Em vez de conter seus listeners diretamente, o EventGenerator pode conter um ListenerProxy. Quando o gerador precisa disparar um evento, ele o dispara para o Proxy. Ento fica por conta do Proxy controlar e atualizar todos os Listeners.
Um proxy um substituto ou lugar reservado que intermdia o acesso ao objeto de interesse real. Voc pode usar o proxy em qualquer lugar onde precise de um substituto ou lugar reservado para outro objeto. Em vez de usar um objeto diretamente, voc usa o proxy. O proxy cuida de todos os detalhes da comunicao com o objeto (ou objetos) real.
NOVO TERMO: Um proxy um substituto ou lugar reservado que intermdia o acesso ao objeto de interesse real. Para todos os efeitos indistinguvel do objeto real que intermedia.
Um substituto intermedia o acesso a um objeto subjacente de forma transparente. Voc pode considerar um substituto como um modo de enganar seus objetos.
Poder enganar seus objetos uma capacidade importante. Um substituto permite que voc coloque responsabilidades nele, sem ter de incorporar essas responsabilidades no usurio do substituto. Mais importante, seu substituto pode executar todas as responsabilidades sem que os outros objetos saibam o que voc esta fazendo.
As responsabilidades que voc pode colocar no substituo so infinitas. Entretanto, o uso comum inclui adicionar otimizaes, realizar tarefas de limpeza, fazer recursos remotos parecerem locais e adiar operaes dispendiosas.

4.1 Quando usar o Proxy Use substitutos quando:
2008
- Voc quiser adiar uma operao dispendiosa
- Voc quer proteger de forma transparente o modo como um objeto usado
- O objeto real existe remotamente, atravs de uma rede ou processo
40
- Quando voc quer executar aes adicionais de forma transparente, ao usar um objeto.
Nome do Padro:
Proxy, Surrogate Precisa objeto controlar o acesso a um
Problema:
Soluo:
Fornecer um objeto que intermedie o acesso a outro objeto de forma transparente Introduz um nvel de procedimento indireto no uso do objeto.
Conseqncias:
5. O padro Interator Voc precisar de um mtodo para o lao para frente e outro para o lao inverso. Se voc quiser fazer um lao aleatoriamente pelas cartas, ento precisar de um terceiro mtodo (e um para cada tipo de coleo). Voc no precisar apenas de vrios mtodos, como tambm precisar implementar novamente a lgica de navegao, sempre que definir um lao. Infelizmente, tal duplicao de lgica um sintoma de responsabilidade confusa. A lgica de navegao deve aparecer em um e apenas um lugar.
Felizmente, o padro INTERATOR resolve muitos dos problemas de forte acoplamento e confuso de responsabilidade, colocando a lgica do lao ou interao em seu prprio objeto.
A interface Interator fornece uma interface genrica para interagir sobre uma coleo. Em vez de escrever laos e mtodos para usar uma coleo especfica, voc pode simplesmente programar a interface genrica do Interator. A interface oculta completamente a implementao da coleo subjacente.
Apenas porque um objeto passa de volta um interador, no significa que o objeto realmente armazena seus itens dentro do interador. Em vez disso, um interador dar acesso ao contedo do objeto.
Existem 3 vantagens em usar um interador para percorrer uma coleo:
2008
- Um interador no o vincular a uma coleo especfica. Todos os mtodos originais fariam lao sobre implementaes especficas da coleo. Como resultado, cada mtodo diferiria apenas nos mtodos que chama na coleo. Se esses mtodos fizessem um lao sobre um interador, voc s precisa escrever um mtodo deckTostring ().
- O interador pode retornar seus elementos em qualquer ordem que achar conveniente. Isso significa que uma implementao do interador poderia retornar os elementos em ordem. Outro interador poderia retornar os elementos na ordem inversa. Usando um interador, voc pode escrever a lgica de navegao uma vez e fazer com que ela aparea em apenas um lugar: no prprio interador.
41 -
Um interador torna simples mudar a coleo subjacente, quando isso for necessrio. Como voc no programou para uma implementao especfica, pode trocar para uma nova coleo a qualquer momento, desde que a coleo saiba como retornar uma instancia de Interator.
Existem vrias razoes para usar o padro Interator: - Voc pode usar um interator quando quiser ocultar a implementao de uma coleo
- Voc pode usar um interator quando quiser fornecer diferentes tipos de lao sobre uma mesma coleo.
- Voc pode usar um interator para manter a interface de uma coleo simples
- Voc pode definir uma classe de coleo base que retorne um interador.
Os interadores tambm so teis para fornecer acesso otimizado s colees. Interator, Cursor Fazer lao sobre uma coleo sem se tornar dependente da implementao Fornecer um objeto que manipule os detalhes da interao, ocultando assim os detalhes do usurio Navegao desacoplada, interface de coleo mais simples, lgicas de laos encapsuladas
Nome do Padro:
Problema:
Soluo:
Conseqncias:
Construindo Software Confivel Atravs de Testes Captulo 14 (LTIMO) O teste a ltima etapa de uma interao. (anlise, projeto, implementao e teste). Os testes realizados antes de sair de uma interao so frequentemente referidos como: - TESTES FUNCIONAIS OU - TESTES DE ACEITAO Aps corrigir um erro, no suficiente apenas testar o erro corrigido. Em vez disso, voc precisa realizar todos os testes. Ao corrigir um erro, voc pode introduzir facilmente um ou mais erros novos! Para testar um sistema, voc precisa escrever e executar CASOS DE TESTE. Cada caso de teste testar um aspecto especfico do sistema.
2008
NOVO TERMO: Um CASO DE TESTE um bloco de construo bsico do processo de teste. O processo de teste executa vrios casos de teste para poder validar completamente um sistema. Cada caso de teste consiste em um conjunto de entradas e sadas esperadas. O teste executar um caminho especfico atravs do sistema (CAIXA BRANCA) ou testar algum comportamento definido (CAIXA PRETA). Um caso de teste exercita uma funcionalidade especfica para ver se o sistema se comporta como deveria. Se o sistema se comportar conforme o esperado, o caso de teste passa. Se o sistema no se comportar conforme o esperado, o caso de teste falha. Um caso de teste falho indica que existe um erro no sistema. Todo teste deve passar ou voc no poder continuar seu trabalho. Existem duas maneiras de basear seus casos de teste: teste de caixa preta e de caixa branca. Uma estratgia de teste eficaz ter uma mistura de casos de teste baseados em caixa preta e em caixa branca.
42 NOVO TERMO: O teste de caixa preta
testa se o sistema funciona conforme o esperado. Dada uma entrada especfica, o teste de caixa preta testa se a sada ou comportamento correto, vsivel externamente, resulta conforme definido pela especificao da classe ou do sistema. NOVO TERMO: No teste de caixa branca, os testes so baseados unicamente na implementao de um mtodo. Os testes de caixa branca tentam atingir 100% de cobertura do cdigo. Ao testar classes individuais, o teste de caixa preta baseado nos requisitos funcionais da classe. Ao testar o sistema inteiro, o teste de caixa preta baseado nos casos de uso. Em qualquer caso, o teste de caixa preta verifica se um objeto ou sistema se comporta conforme o esperado. O teste de caixa branca baseado na implementao de um mtodo. Seu objetivo garantir que cada desvio do cdigo seja executado. O teste de caixa preta avaliado para cobrir apenas de um tero metade do cdigo real. Com o teste de caixa branca, voc projeta seus testes de modo a exercitar cada desvio e na esperana de eliminar todos os erros latentes.
FORMAS DE TESTES No todo, existem 4 formas importantes de teste. Esses testes variam de testes de nvel mais baixo, que examinam os objetos individuais, at os testes de nvel mais alto, que examinam o sistema inteiro. A execuo de cada um ajudar a garantir a qualidade global de seu software.
1. TESTE DE UNIDADE O teste de unidade a unidade de nvel mais baixo dos testes. Um teste de unidade examina apenas um recurso por vez. NOVO TERMO: Um teste de unidade o dispositivo de teste de nvel mais baixo. Um teste de unidade envia uma mensagem para um objeto e depois verifica se ele recebe o resultado esperado do objeto. Um teste de unidade verifica apenas um recurso por vez. Voc deve basear os testes de unidade no teste de caixa preta e branca. Voc deve escrever o caso de teste antes de escrever a classe.
2. TESTE DE INTEGRAO Os sitemas OO so constitudos de objetos que interagem. Enquanto os testes de unidade examinam cada classe de objeto isoladamente, os testes de integrao verificam se os objetos que compes o sistema interagem corretamente. O que poderia funcionar isoladamente pode no funcionar quando combinado com outros objetos! NOVO TERMO: Um teste de integrao verifica se 2 ou mais objetos funcionam em conjunto corretamente. Assim como os testes de unidade, os testes realizados durante os testes de integrao podem ser baseados nos conceitos de caixa branca e de caixa preta. Voc deve ter um teste de integrao para cada interao importante no sistema.
3. TESTE DE SISTEMA
2008
Os testes de sistema verificam se o sistema inteiro funciona conforme descrito pelos casos de uso. Enquanto executa testes de sistema, voc tambm deve testar o sistema de maneiras no descritas pelos casos de uso. Fazendo isso, voc pode verificar se o sistema manipula e se recupera de condies imprevistas. - Teste de ao aleatria: Consiste em tentar executar operaes em ordem aleatria. - Teste de banco de dados vazio: Garante que o sistema pode falhar normalmente, caso exista um problema maior no banco de dados. - Caso de uso mutante: Transforma um caso de uso vlido em um caso de uso invlido e garante que o sistema possa se recuperar corretamente da interao. NOVO TERMO: Um teste de sistema examina o sistema inteiro. Um teste de sistema verifica se o sistema funciona
43 conforme mencionado nos casos de uso e se ele pode manipular normalmente situaes incomuns e inesperadas.
Os testes de sistema tambm incluem testes de esforo e de desempenho. Esses testes garantem que o sistema satisfaa quaisquer requisitos de desempenho e possa funcionar sob as cargas esperadas. Os testes de sistema verificam unidades funcionais inteiras simultaneamente, de modo que um nico teste pode mexer com muitos objetos e subsistemas diferentes. Para sair de uma interao, o sistema deve passar nesses testes com exito.
4. TESTE DE REGRESSO Um teste vlido apenas enquanto o que for testado no mudar. Quando um aspecto do sistema mudar, essa parte dever ser novamente testada. Teste de regresso o processo de repetio dos testes de unidade, integrao e de sistema aps as alteraes serem feitas. NOVO TERMO: Os testes de regresso examinam as alteraes nas partes do sistema que j foram validadas. Quando uma alterao feita, a parte que foi alterada assim como todas as partes dependentes deve ser novamente testada. Para executar o teste de regresso basta executar novamente seus testes de unidade, integrao e sistema.
Combinando desenvolvimento e teste Voc precisa aprender a comear a testar enquanto desenvolve. Para testar enquanto desenvolve, voc precisa escrever testes de unidade para cada classe que criar.
Por que voc deve escrever testes de unidade O teste de unidade sua primeira linha de defesa contra erros. A captura de um erro em nvel de unidade muito mais fcil de manipular que tentar rastrear um erro durante o teste de integrao ou de sistema. Uma classe est pronta quando todos os testes passam!
Escrevendo testes de unidade Escrever testes de unidade desde o incio para cada classe, pode se tornar demorado. Imagine um sistema onde voc precise escrever centenas de casos de teste. Se escrever cada teste de unidade desde o incio, voc acabar fazendo muito trabalho redundante. Voce precisa criar ou reutilizar uma estrutura de teste. NOVO TERMO: Uma ESTRUTURA um modelo de domnio reutilizvel. A estrutura contm todas as classes comuns a um domnio inteiro de problemas e serve como a base para um aplicativo especfico no domnio. A classe de uma estrutura define o projeto geral de um aplicativo. Em uma estrutura de teste, a estrutura define um esqueleto que voc pode reutilizar para escrever e executar testes de unidade. Uma estrutura de teste permite que voc escreva testes de unidade rpida e convenientemente, eliminando trablaho redundante e propenso a erros.

A Junit uma estrutura gratuita.
2008
JUNIT A Junit fornece classes para escrever testes de unidade. A Junit fornece a voc vrias opes para a execuo de seus casos de teste. Essas opes caem em duas categorias: - Estticas - Dinmicas Na linguagem JAVA, o modo mais conveniente escrever uma classe annima para que voc no precise criar uma
44 classe separada para cada teste que queira executar.

As classes anonimas so convenientes porque elas permitem que voc sobreponha um mtodo ao instanciar um objeto, tudo sem ter de criar uma classe nomeada em um arquivo separado. NOVO TERMO: Uma CLASSE ANNIMA uma classe que no tem nome. As classes anonimas no tem nome porque elas so simplesmente definidas ao serem instanciadas. Elas no so declaradas em um arquivo serparado ou como uma classe inteira. Um ACESSRIO de teste define o conjunto de objetos sobre os quais um teste operar. Estabelecer um acessrio de teste pode consumir a maior parte do tempo que leva para escrever casos de teste. NOVO TERMO: O acessrio de teste prepara o conjunto de objetos sobre os quais um caso de teste atuar. Os acessrios tambm so convenientes, pois eles permitem que voc compartilhe o mesmo acessrio dentre um conjunto inteiro de casos de teste, sem ter de duplicar cdigo. NOVO TERMO: Um OBJETO FALSIFICADO um substituro simplista de um objeto real. Ele chamado de objeto falsificado porque o objeto foi falsificado para propsito de teste. Embora o objeto falsificado possa ter uma implementao simplista, ele pode conter funcionalidade extra para ajudar nos testes. Objetos Falsificados tambm so chamados de SIMULADORES. O substituto no aparecer no sistema real, apenas no cdigo de teste.
Escrevendo cdigo excepcional Um erro e uma condio de erro no so a mesma coisa. Um erro um defeito. Uma condio de erro uma falha previsivel que acontece sob certas circunstancias no domnio. As linguagens JAVA e C++ empregam um mecanismo conhecido como EXCEES para sinalizar condies de erro. Escrevendo documentao eficaz H mais um passo que voc pode dar para melhorar a qualidade de seu trabalho: document-lo. - Cdigo-fonte como documentao O cdigo fonte, at seus teste de unidade, uma forma de documentao. Quando outras pessoas precisam pegar e manter seu cdigo, importante que ele seja legvel e bem organizado. O cdigo fonte a forma mais importante de documentao, pois a nica documentao em que voce tem de manter. - Convenes de codificao + Os nomes de classes sempre devem comear com uma letra maiuscula.

+ + + + Os nomes de mtodos sempre devem comear com uma letra minuscula. Os nomes de varivel sempre devem comear com uma letra minscula. As constantes devem sempre aparecer em MAIUSCULAS. As variveis normais devem aparecer em minusculas.
2008
- Constantes As constantes tambm podem servir como uma forma de documentao. Use constantes quando voc se achar utilizando um valor codificado. Uma constante bem nomeada pode dar uma idia do objeto de seu cdigo. - Comentrios Assim como constantes bem colocadas, nada ajuda a tornar o cdigo mais inteligivel do que um comentrio bem colocado.
45 This.id = id
// configura id
- Nomes Primeira palavra minuscula e a segunda palavra iniciando com letra maiuscula. testCase Ou ento utilizando o hfen. Test-case - Cabealhos de mtodos e classe Quando voc escrever uma classe ou um mtodo, sempre se certifique de incluir um cabealho. Um cabealho de mtodo incluir uma descrio, uma lista de argumentos, uma descrio do retorno, assim como condies de uma execuo e efeitos colaterais. Um cabealho pode at incluir condies prvias. Um cabealho de classe normalmente incluir uma descrio, o nmero da verso, a lista de autores e o histrico da reviso.

Resumo POO

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Resumo POO

Transféré par

Droits d'auteur :

Formats disponibles

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Os trs pilares da programao orientada a objetos: ENCAPSULAMENTO, HERANA E POLIMORFISMO.

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

caractersticas do ENCAPSULAMENTO EFICAZ so: ABSTRAO OCULTAO DE IMPLEMENTAO DIVISO DE RESPOSABILIDADE

CDIGO FRACAMENTE ACLOPADO: independente da implementao de outros componentes

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

4. 1 Mtodos e atributos Sobrepostos

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

11 suas duas coordenadas.

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

13 uma classe raiz, base.

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

UML (Unfied Modeling Language) Captulo 8

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Um exemplo familiar de processo de software e o PROCESSO DE CASCATA.

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

25 - Os usurios convidados podem pesquisar o catlogo de produtod

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO

Por Mariana Florncio

RESUMO EAGS SIN BIBLIOGRAFIA POO