MindView Inc.

Pensando em Java, 3ª ed. Revisão 4.0


[ Viewing Hints ] [ Book Home Page ] [ Free Newsletter ]
[ Seminars ] [ Seminars on CD ROM ] [ Consulting ]

Anterior Próximo Página Inicial Índice Conteúdo

16: Analysis and Design



O paradigma orientado a objetos é modo novo e diferente de pensar sobre programação.



Muitas pessoas tem dúvidas a primera vista de como se aproximar de um projeto POO. Agora que você entende os conceitos de objeto, e como você aprendeu a pensar mais num estilo orientado a objeto, você pode criar inicialmente um “bom” design que tome vantagens de todos os benefícios que POO tenha a oferecer. Este capítulo introduz a ídeia de analise, design e alguns caminhos para transformar os problemas de desenvolvimento em bons programas orientados a objeto numa quantidade de tempo razoável.Comentários (em inglês)

Metodologia



Uma metodologia (às vezes simplesmente chamada um método) é um conjunto de processos e heurísticas usados para diminuir a complexidade de um problema de programação. Muitas metodologias OO têm sido formuladas desde o advento da programação orientada a objetos. Esta seção lhe dará uma idéia do que você está tentando alcançar quando usa uma metodologia.Comentários (em inglês)



Especialmente em POO, a metodologia é um campo de muitos experimentos, pois é importante entender qual o problema que ela está tentando resolver, antes de considerar a adoção de uma. Isto é verdade em Java, na qual a linguagem de programação tem o propósito de reduzir a complexidade envolvida (comparada com C) quando estamos expressando um programa. Isto pode realmente eliminar a necessidade de metodologias cada vez mais complexas. Em vez disso, metodologias simples podem ser suficientes em Java para a maioria das classes de problemas, ao contrário dos problemas que você poderia estar lidando ao utilizar metodologias com linguagens procedurais.Comentários (em inglês)



Também é importante perceber que o termo "metodologia" é normalmente grandioso e promete demais. Não importa o quê você faz quando projeta e escreve um programa - isto é uma metodologia. Pode ser a sua própria metodologia, e você não está consciente de que está utilizando-a, mas é um processo que você segue enquanto cria. Se é um processo efetivo, pode ser necessário apenas um pequeno ajuste para trabalhar com Java. Se você não está satisfeito com a sua produtividade e com a forma como seus programas são produzidos, você deverá considerar a adoção de uma metodologia formal, ou escolher pedaços de outras metodologias. Comentários (em inglês)



Quando você está seguindo o processo de desenvolvimento, a questão mais importante é: Não se perca! Isto é fácil de acontecer. Muitas das metodologias de análise e projeto têm a intenção de resolver a maioria dos problemas. Lembre-se que boa parte dos projetos não se encaixam nesta categoria, pois você normalmente tem sucesso na análise e no projeto, com um conjunto relativamente menor do que a metodologia recomenda.[102]Mas, alguns tipos de processos, não interessa se pequenos ou limitados, colocarão você no caminho correto, de uma maneira mais certa do que simplesmente começar a codificar.Comentários (em inglês)



É muito fácil torna-se preso, caindo na "paralisia da análise", onde você se sente como se não pudesse ir adiante enquanto não esmiuçasse todo pequeno detalhe do estágio atual. Lembre-se, não importa quanta análise você faz, existem algumas coisas sobre um sistema que não irão se revelar em tempo de projeto, e mais coisas ainda não serão reveladas até que você as codifique, ou até que um programa esteja no ar e rodando. Por causa disso, é crucial mover-se rapidamente entre a análise e o projeto, e implementar um teste do sistema proposto.Comentários (em inglês)



Este ponto merece ser enfatizado. Devido ao histórico que tivemos com as linguagens procedurais, é louvável que uma equipe deseje avançar cuidadosamente e entender cada detalhe antes de mover-se para o projeto e a implementação. Certamente, quando criamos um Sistema de Gerenciamento de Base de Dados (SGDB), é prudente entender as necessidades do cliente de forma bem pensada. Mas um SGDB está situado em uma classe de problemas que é muito bem entendida; em muitos programas deste tipo, a estrutura da base de dados é o problema a ser atacado. A classe de problemas de programação discutida neste capítulo é do tipo "wild-card" (meu termo), na qual a solução não é simplesmente reformatar uma solução bem conhecida, mas, em vez disso, envolver um ou mais "fatores wild-card´s" - elementos que não possuem uma solução prévia bem entendida, e na qual uma pesquisa é necessária. [103] Voltados para analisar de forma pensada um problema do tipo wild-card, antes de entrar no projeto e na implementação, pode resultar em "paralisia de análise", porque você não tem a informação suficiente para resolver este tipo de problema durante a fase de análise. Resolver estes problemas requer iteração ao longo de todo o ciclo, e isto requer um comportamento de assumir riscos (o que faz sentido, porque você está tentando fazer algo novo e as recompensas em potenciais são altas). Pode parecer que o risco é maior ao se "apressar" uma implementação preliminar, mas ao invés disso, pode-se reduzir o risco em um projeto do tipo wild-card, pelo fato que você está descobrindo antecipadamente que uma abordagem em particular para o problema é viável. O desenvolvimento de um produto significa gerenciamento de riscos.Comentários (em inglês)



Freqüentemente é proposto que você "construa algo para liberar". Com a POO, você pode liberar parte de algo, pois devido ao código ser encapsulado em classes, durante o primeiro passo você irá inevitavelmente produzir alguns projetos de classes úteis e desenvolver algumas idéias que irão valer a pena, sobre o projeto do sistema que não é preciso liberar. Assim, o primeiro passo rápido no problema não produz apenas informação crítica para os próximos passos da análise, do projeto e da implementação, como também cria uma fundação para a codificação. Comentários (em inglês)



Dito isto, se você está procurando uma metodologia que contém muitos detalhes e sugere muitos passos e documentos, é difícil saber quando parar. Tenha em mente que você está tentando descobrir:Comentários (em inglês)

  1. Quais são os objetos? (Como você particiona seu projeto em componentes?)
  2. Quais são as suas interfaces? (Quais mensagens você precisa enviar para cada objeto?)


Se você vier com nada mais do que objetos e suas interfaces, você ainda poderá escrever um programa. Por muitas razões, você irá precisar de mais descrições e documentos para fazer isto, mas não irá a lugar algum apenas com eles.Comentários (em inglês)



O processo pode ser compreendido em cinco fases, e uma fase 0 é apenas o compromisso inicial para utilizar algum tipo de estrutura.Comentários (em inglês)

Fase 0: Faça um plano



Você primeiro decide que passos estará dando em seu processo. Isto parece simples (de fato, tudo isso parece simples), embora as pessoas freqüentemente não tomem esta decisão antes de começar a codificar. Se o seu plano é "vamos pular isso e começar a codificar", tudo bem (Às vezes isto é apropriado quando você tem um problema bem entendido). Pelo menos você tem que concordar que este é o seu plano.Comentários (em inglês)



Você também poderá decidir nesta fase que alguma estrutura de processo adicional é necessária, mas não a estrutura inteira. Compreensivelmente, alguns programadores gostam de trabalhar no "modo de férias", no qual nenhuma estrutura é imposta no processo de desenvolvimento de seu trabalho; "Ele ficará pronto quando estiver pronto". Isto pode parecer apelativo, mas eu descobri que ter poucos milestones ao longo do caminho ajuda a focar e galvanizar seu esforço para eles, ao invés de ficar preso ao simples objetivo de "terminar o projeto". Adicionalmente, isso divide o projeto em pedaços menores e os faz parecer mais fáceis de tratar (ainda mais, os milestones oferecem mais oportunidades para comemoração). Comentários (em inglês)



Quando eu comecei a estudar estrutura da história (um dia eu irei escrever uma novela), eu estava inicialmente resistente à idéia da estrutura, sentindo que eu escrevia melhor quando simplesmente deixava fluir as idéias para a página. Mas, eu percebi mais tarde que quando eu escrevo sobre computadores, a estrutura é clara o suficiente para mim, que eu não precisava pensar muito sobre isso. Eu continuo estruturando o meu trabalho de forma semiconsciente em minha mente. Mesmo se você pensar que o seu plano é apenas para começar a codificação, você continuará de algum modo pensando nas fases subsequentes enquanto pergunta e responde certas questões.Comentários (em inglês)

A declaração de Missão



Qualquer sistema que você constrói, não interessa o quão complicado ele seja, tem um propósito fundamental - O negócio que é intrínseco a ele e as necessidades que ele satisfaz. Se você olhar além da interface com o usuário, o hardware ou detalhes específicos do sistema, a codificação dos algoritmos e os problemas de eficiência, você eventualmente encontrará a essência para torná-los simples. Da mesma forma que o chamado high concept de um filme de Hollywood, você pode descrevê-la em uma ou duas sentenças. Esta descrição pura é o ponto de partida. Comentários (em inglês)



Este conceito de alto nível é importante porque ajusta o tom de seu projeto; é uma declaração de missão. Você não precisa fazê-la certo da primeira vez (você poderá estar em uma fase posterior de seu projeto antes dela tornar-se completamente clara), mas continue tentando até que ela pareça correta. Por exemplo, em um sistema de controle de tráfego aéreo, você deverá tentar começar com um conceito de alto nível focado no sistema que está construindo: "O programa da torre mantém contato com as aeronaves". Mas considere o que acontece quando você submete o sistema a um pequeno campo de pouso; talvez exista apenas um único controlador humano, ou até mesmo nenhum. Um modelo mais útil não irá preocupar-se com o modelo que você criou, da forma como ele descreve o problema: "A aeronave chega, descarrega, realiza o serviço, carrega e depois se afasta". Comentários (em inglês)

Fase 1: O quê nós estamos fazendo?



Na geração anterior de design de programas (chamada de design procedural), isto é conhecido como "criação da análise de requisitos e especificação do sistema". Estes, sem dúvida, são lugares para se perder; documentos com nomes que intimidam, que poderiam tornar-se grandes projetos por si próprios. A intenção era boa, entretanto. A análise de requisitos diz para "Fazer uma lista com as diretrizes que nós iremos usar, para saber quando o trabalho estará feito e o usuário satisfeito". [104] A especificação do sistema diz "Aqui é a descrição do quê o programa irá fazer (não como) para satisfazer os requisitos". A análise de requisitos é realmente um contrato entre você e o cliente (mesmo se o cliente trabalha para a sua companhia, ou é algum outro tipo de objeto ou sistema). A especificação do sistema é a exploração de mais alto nível do problema, e de alguma maneira, uma descoberta do que pode ser feito e quanto tempo irá levar. Como ambos requerem consenso entre as pessoas (e devido à elas mudarem ao longo do tempo), creio que é melhor mantê-las o mais vazio possível - idealmente em listas e diagramas básicos - para economizar tempo (isto está alinhado com a metodologia Extreme Programming, que prega uma documentação mínima, voltada para pequenos e médios projetos). Você poderá ter outras restrições que irão requerer a expansão em documentos maiores, mas mantendo o documento inicial pequeno e conciso, ele pode ser criado em poucas sessões de um grupo de brainstorm, com um líder que dinamicamente cria a descrição. Isso não apenas requer participação de todos, como também fomenta um compromisso inicial de todos da equipe. Talvez, mais importante ainda, ele pode iniciar um projeto com muito de entusiasmo.Comentários (em inglês)



É necessário manter o foco no coração do que você está tentando executar nesta fase: Determinar o que o sistema supostamente faz. A ferramenta mais valiosa para isso é uma coleção do que chamamos de "usos de casos", ou em Extreme Programming, "histórias de uso". Casos de usos identificam aspectos chave do sistema que irão revelar algumas das classes fundamentais que você irá usar. Eles são, essencialmente, respostas descritivas para as seguintes perguntas:[105] Comentários (em inglês)

  • "Quem irá usar este sistema?"
  • "O quê estes atores farão com o sistema?"
  • "Como este ator faz o quê com este sistema?"
  • "Como deverá ser este trabalho se alguém o fizesse, ou se o mesmo ator tivesse um objetivo diferente?" (para revelar variações)
  • "Que problemas poderão acontecer enquanto o sistema é feito?" (para revelar exceções)


Se você está projetando um caixa eletrônico de um banco, por exemplo, o caso de uso para um aspecto em particular da funcionalidade do sistema, é a capacidade de descrever o quê o caixa faria em cada situação possível. Cada uma destas "situações" é referenciada como um cenário, e um caso de uso pode ser considerado como uma coleção de cenários. Você pode pensar em um cenário como uma pergunta que começa com: "O que o sistema faria se ...?". Por exemplo, "O quê faria o caixa eletrônico se um cliente depositou um cheque nas últimas 24 horas, e não existe saldo suficiente na conta, sem o cheque ter sido compensado, para que seja realizado um saque?" Comentários (em inglês)



Diagramas de uso de caso são intencionalmente simples para preveni-lo de descer em detalhes de implementação prematuramente:

PEJ337.png



Cada figura indicando uma pessoa representa um "ator", que é tipicamente um humano ou algum tipo de agente livre (podendo ser outro sistema, como o "ATM" no caso acima). A caixa representa a fronteira de seu sistema. As elipses representam os casos de uso, que são descrições do trabalho efetivo que pode ser feito com o sistema. As linhas entre os atores e os casos de uso representam as interações entre eles.Comentários (em inglês)



Não importa como o sistema está implementado realmente, mas como ele é do ponto de vista do usuário.Comentários (em inglês)



Um caso de uso não precisa ser extremamente complexo, mesmo se o sistema possuir complexidade. Ele tem apenas a intenção de mostrar como o sistema parece para o usuário. Por exemplo: Comentários (em inglês)

PEJ338.png



Os casos de uso produzem as especificações dos requerimentos, através da determinação de todas as interações que o usuário possa ter com o sistema. Você tentará descobrir um conjunto completo de todos os casos de uso para o seu sistema, e uma vez concluído, você terá a essência do que o sistema supostamente fará. Uma coisa boa sobre manter o foco em casos de uso é que eles sempre trazem você de volta para a essência e o mantém afastado de aspectos que não são críticos para o término de seu trabalho. Isto é, se você tem um conjunto completo dos casos de uso, você pode descrever o seu sistema e passar para a próxima fase. Você provavelmente não conseguirá capturar tudo perfeitamente na primeira tentativa, mas isto é normal. Tudo se revela por si próprio ao longo do tempo, e se você demanda uma especificação perfeita do sistema, neste ponto você irá ficar preso.Comentários (em inglês)



Se ficar preso, poderá começar esta fase usando uma ferramenta de aproximação: Descreva o sistema em poucos parágrafos e depois olhe os substantivos e os verbos. Os substantivos podem sugerir os atores, contexto para os casos de uso (por exemplo, "lobby"), ou artefatos manipulados no caso de uso. Os verbos podem sugerir interações entre os atores e os casos de uso, e especificar passos dentro deles. Você irá também descobrir que os substantivos e os verbos produzem objetos e mensagens durante a fase de projeto (e note que como os usos de caso descrevem interações entre subsistemas, a técnica de "substantivos e verbos" pode ser usada como uma ferramenta de brainstorming, pelo fato dela não gerar os casos de uso). [106] Comentários (em inglês)



A fronteira entre um uso de caso e um ator pode apontar a existência de uma interface com o usuário, mas ela não define uma interface. Para um processo de definir e criar as interfaces com o usuário, veja Software for Use de Larry Constantine e Lucy Lockwood, (Addison-Wesley Longman, 1999), ou acesse www.ForUse.com. . Comentários (em inglês)



Embora isso seja pura arte, neste ponto, algum tipo básico de cronograma é importante. Você agora tem uma visão geral sobre o que está construindo, e provavelmente será capaz de ter alguma idéia de quanto tempo irá levar. Muitos fatores aparecem aqui. Se você estimar um cronograma muito longo, pode ser que a companhia decida não construí-lo (e utilize os recursos em algo mais razoável - o que é uma coisa boa). Ou então um gerente já tinha decidido quanto tempo o projeto deveria durar e irá tentar influenciar a sua estimativa. Mas é melhor ter um cronograma honesto desde o início e lidar com as decisões difíceis previamente. Têm existido muitas tentativas com propostas de técnicas de montagem de cronogramas mais precisas (da mesma forma que as técnicas para prever o comportamento do mercado de ações), mas provavelmente, a melhor abordagem é contar com a sua experiência e intuição. Estime quanto tempo irá realmente levar, dobre a estimativa e acrescente 10 porcento. Sua estimativa está provavelmente correta; você pode produzir algo trabalhando neste tempo. "Dobrar" irá fazer da estimativa algo decente, e os 10 porcento irão lidar com os acabamentos e detalhes finais. [107] De alguma forma você gostaria de explicar isso, e apesar das queixas e lamentações que acontecem quando você revela um cronograma, parece resolvido a fazer desta forma.[108]

Fase 2: Como nós iremos construir?



Nesta fase deve vir à tona um projeto que descreva como as classes se parecem e como elas irão interagir. Uma excelente técnica para a determinação das classes e suas interações é o cartão de Classe-Responsabilidade-Colaboração (CRC). Parte do valor desta ferramenta é que ela é de baixa tecnologia: Você começa com um conjunto de cartões 3 X 5 em branco, e você vai escrevendo neles. Cada cartão representa uma classe simples, e no cartão você escreve:Comentários (em inglês)

  1. O nome da classe. É importante que este nome capture a essência do quê a classe faz, para que ela faça sentido à primeira vista. Feedback
  2. As "responsabilidades" da classe: O quê ela deverá fazer. Isto pode ser feito apenas declarando os nomes dos métodos (em um bom projeto, estes nomes deverão ser bem descritivos), mas isso não exclui outras anotações. Se você estiver iniciando este processo, olhe o problema do ponto de vista de um programador preguiçoso: Que objetos você gostaria que aparecesse magicamente para resolver seu problema? Feedback
  3. As "colaborações" da classe: Quais as outras classes que irão interagir com ela? "Interagir" é intencionalmente um termo vasto; ele pode significar agregação ou simplesmente que existe algum outro objeto que irá fornecer serviços para um objeto da classe. Colaborações deverão considerar o público-alvo desta classe. Por exemplo, se você criar uma classe Firecracker, quem irá observá-la, uma classe Chemist ou uma classe Spectator? A primeira irá querer saber quais são os elementos químicos que foram utilizados na construção, e a segunda irá responder sobre as cores e as figuras desenhadas quando ela explode. , Feedback


Você deve pensar que os cartões deverão ser grandes, devido à toda informação que você gostaria de colocar neles. Entretanto, eles são intencionalmente pequenos, não apenas para manter as suas classes pequenas, mas também para prevenir você da colocação de muitos detalhes precipitadamente. Se você não consegue encaixar tudo o que precisa saber sobre uma classe, em um pequeno cartão, então a classe é complexa demais (também você poderá estar detalhando demais, ou então deveria criar mais de uma classe). A classe ideal deverá ser compreensível à primeira vista. A idéia dos cartões CRC é ajudá-lo no primeiro esboço do projeto, para que você possa obter uma grande imagem dele e depois refiná-lo. Comentários (em inglês)



Um dos grandes benefícios dos cartões CRC está na comunicação. Ele é escrito melhor em tempo real, em um pequeno grupo, sem computadores. Cada pessoa toma a responsabilidade por diversas classes (as quais inicialmente não possuem nomes ou outro tipo de informação). Você faz uma simulação, resolvendo um cenário por vez, decidindo quais são as mensagens enviadas para os vários objetos que satisfazem cada cenário. Conforme você avança neste processo, você descobre as classes que precisará mais adiante, com as suas responsabilidades e colaborações, e você preenche os cartões enquanto faz isso. Quando você passar por todos os casos de uso, você deverá ter um rascunho razoável de seu projeto.Comentários (em inglês)



Antes de eu começar a usar os cartões CRC, as mais bem sucedidas experiências de consultoria que eu tive, quando estava começando o desenho inicial de um projeto, foi ficar em frente à uma equipe - que não tinha trabalhado com POO antes - e desenhar os objetos em um quadro branco. Nós falamos sobre como os objetos deveriam se comunicar entre eles, e apagamos alguns deles, para em seguida os trocarmos por outros objetos. Efetivamente eu estava gerenciando todos os "cartões CRC" diretamente no quadro. A equipe (que já sabia o quê o projeto supostamente deveria fazer) realmente criava o projeto; eles se "apropriaram" do projeto antes de o terem dado a eles. Tudo o que eu estava fazendo era guiando o processo, fazendo as perguntas certas, tentando fazer suposições, e obtendo o retorno do time para modificar estas suposições. A verdadeira beleza deste processo foi que a equipe aprendeu como fazer um projeto orientado a objeto, não através de exemplos abstratos, mas trabalhando no único design que era mais interessante para eles naquele momento: o deles.Comentários (em inglês)



Depois que você concluiu o trabalho com o conjunto de cartões CRC, você poderá querer criar uma descrição mais formal de seu projeto, utilizando UML.[109] Você não precisa usar UML, mas ela pode ser útil, especialmente se você quiser colocar um diagrama na parede para todo mundo meditar sobre ele, o que é uma boa idéia (existe uma vasta gama de ferramentas para diagramação UML disponível). Uma alternativa à UML é uma descrição textual dos objetos e suas interfaces, ou, dependendo de sua linguagem de programação, do próprio código em si.[110] Comentários (em inglês)



UML também provê uma notação adicional para diagramação, utilizada na descrição do modelo dinâmico de seu sistema. Isto é útil em situações onde o estado das transições de um sistema ou subsistema é dominante o suficiente, fazendo com que eles necessitem de seus próprios diagramas (como um sistema de controle, por exemplo). Você também poderá precisar descrever as estruturas de dados, para os sistemas ou subsistemas nos quais os dados são um fator dominante (como uma base de dados, por exemplo). Comentários (em inglês)



Você sabe que terminou com a Fase 2 quando tem descrito os objetos e suas interfaces. Bem, pelo menos a maioria deles. Existem normalmente alguns poucos objetos que escaparam e não irão tornar-se conhecidos até a Fase 3. Mas isto é normal. O que é importante é que você descubra eventualmente todos os seus objetos. É legal descobri-los o mais cedo possível no processo, mas a POO provê estrutura o bastante para que não seja tão ruim encontrá-los mais tarde. De fato, o projeto de um objeto tende a acontecer em cinco estágios, ao longo do processo de desenvolvimento. Comentários (em inglês)

Os cinco estágios do design de objetos



O ciclo de vida do desenho de um objeto não está limitado ao tempo no qual você passa escrevendo o programa. Em vez disso, o design de um objeto aparece em uma seqüência de estágios. É bom ter esta perspectiva em mente, pois você irá parar de ter uma expectativa de perfeição; ao invés disso, você se dá conta que a compreensão sobre o quê um objeto faz e como ele deveria parecer, acontece ao longo do tempo. Esta visão também se aplica ao projeto de vários tipos de programas; o padrão para um tipo particular de programa emerge lutando repetidas vezes com o problema (o que é mostrado no livro Thinking in Patterns (with Java) em www.BruceEckel.com). Objetos também têm os seus padrões, que emergem através da compreensão, uso e reuso. Comentários (em inglês)



1. Descoberta do objeto.Este estágio ocorre durante a análise inicial de um programa. Os objetos podem ser descobertos olhando-se para fatores e fronteiras externas, duplicação de elementos no sistema, e para as menores unidades conceituais. Alguns objetos são óbvios, se você estiver lidando com um conjunto de biblioteca de classes. Comportamento comum entre classes, sugerem classes básicas, e a herança poderá aparecer mais adiante, durante o processo de design.Comentários (em inglês)



2. Montagem do objeto.Ao longo da construção de um objeto você irá descobrir a necessidade de novos membros que não tinham aparecido durante a descoberta. As necessidades internas do objeto podem requerer outras classes para suportá-lo. Comentários (em inglês)



3. Construção do sistema.Mais uma vez, requerimentos para um objeto podem aparecer neste estágio mais avançado. Como você aprendeu, você evolui com os seus objetos. A necessidade de comunicação e interconexão com outros objetos no sistema poderá mudar as necessidades de suas classes ou requerer novas classes. Por exemplo, você poderá descobrir as necessidades para classes facilitadoras ou de ajuda, como uma lista encadeada, que contém pouca ou nenhuma informação de estado e que simplesmente tem a função de ajudar outras classes. Comentários (em inglês)



4. Extensão do sistema.Conforme você adiciona novas características ao sistema, poderá descobrir que o seu projeto anterior não suporta facilmente a extensão do sistema. Com esta nova informação, você pode reestruturar partes de seu sistema, possibilitando a adição de novas classes ou hierarquia de classes. Esta também é uma boa hora para considerar a retirada de características de um projeto. Comentários (em inglês)



5. Reuso do objeto. Este é o verdadeiro teste de stress para uma classe. Se alguém tenta reutilizar a classe em uma nova solução, irá provavelmente encontrar algumas falhas. Conforme você as muda para adaptação a novos programas, os princípios gerais da classe irão tornar-se mais claros, até que você tenha um tipo verdadeiramente reusável. Entretanto, não espere que muitos objetos de um sistema sejam projetados para serem reutilizáveis - é perfeitamente aceitável para a maior parte dos objetos que são específicos do sistema. Tipos reusáveis tendem a ser menos comuns, e eles devem resolver mais problemas gerais, para que possam ser reusáveis.Comentários (em inglês)

Diretrizes para o desenvolvimento de objetos



Estes estágios sugerem algumas diretrizes sobre o desenvolvimento de suas classes: Comentários (em inglês)

  1. Deixe um problema específico gerar uma classe, e depois deixe a classe crescer e tornar-se madura durante a solução de outros problemas. Feedback
  2. Lembre-se, a descoberta das classes que você precisa (e suas interfaces) é a maior parte do projeto de um sistema. Se você já possui estas classes, este pode ser um projeto fácil. Feedback
  3. Não se obrigue a saber tudo desde o início. Aprenda conforme você avança. Isso irá acontecer de qualquer jeito. Feedback
  4. Comece programando. Obtenha alguma coisa funcionando, para que você possa aprovar ou desaprovar o seu projeto. Não tenha medo em achar que você acabará utilizando o estilo de código procedural - código espaguete - as classes particionam os problemas e ajudam a controlar a anarquia e a entropia. Classes ruins não "quebram" classes boas. Feedback
  5. Mantenha-os sempre simples. Objetos Pequenos e "limpos", com utilidade óbvia, são melhores que grandes interfaces complicadas. Quando precisar tomar uma decisão, use a abordagem da Navalha de Ockham: [111] Considere todas as escolhas e selecione aquela que é a mais simples, pois classes simples são sempre as melhores. É fácil adicionar métodos, mas quando o tempo avança, é difícil removê-los de uma classe. Feedback

Fase 3: Construir o núcleo



Esta é fase da conversão inicial do rascunho do projeto em um corpo de compilação e execução que pode ser testado, e especialmente que irá aprovar ou desaprovar a sua arquitetura. Isto não é um processo de apenas um passo, mas o começo de uma série de passos que irá iterativamente construir o sistema, como você verá na Fase 4. Comentários (em inglês)



Sua meta aqui é encontrar o núcleo da arquitetura de seu sistema que precisa ser implementado, para que ser gerado um sistema que possa ser executado, não interessa o quão incompleto este sistema esteja neste passo inicial. Você está criando um framework que pode ser construído através de iterações adicionais. Você também está fazendo a primeira de muitas integrações e testes do sistema, e dando aos acionistas o retorno sobre como o sistema deles irá parecer e como ele está progredindo. Idealmente, você está expondo alguns dos riscos críticos. Você provavelmente descobre mudanças e melhorias que podem ser feitas à sua arquitetura original - coisas que você não teria aprendido sem implementar o sistema.Comentários (em inglês)



Parte da construção do sistema inclui a checagem da realidade que você obteve a partir dos testes, em comparação com a sua análise de requisitos e a especificação do sistema (independente da forma em que eles existam). Assegure que os seus testes verifiquem os requerimentos e casos de uso. Quando o núcleo do sistema estiver estável, você está pronto para avançar e adicionar mais funcionalidade.Comentários (em inglês)

Fase 4: Iterar os casos de uso



Uma vez que o framework está rodando, cada conjunto de características que você adiciona é um pequeno projeto por si próprio. Você adiciona um conjunto de características durante uma iteração, um razoável e curto período de desenvolvimento. Comentários (em inglês)



Quão grande é uma iteração? Idealmente, cada iteração leva de uma a três semanas (isto pode variar dependendo da linguagem de implementação). No final deste período, você tem um sistema testado e integrado, com mais funcionalidade do que tinha antes. Mas o que é particularmente interessante é a base para a iteração: um simples caso de uso. Cada caso de uso é um pacote de funcionalidades relacionadas que você construiu no sistema de uma só vez, durante uma iteração. Ela não apenas dá a você uma melhor idéia do que um escopo de um caso de uso deveria ser, como também dá mais validade à idéia de um caso de uso, desde que o conceito não seja descartado depois da análise e projeto. Ao invés disso, ele é uma unidade fundamental de desenvolvimento ao longo do processo de contrução do software.Comentários (em inglês)



Você pára a iteração quando cumpre a sua meta de funcionalidade ou quando um prazo externo chega ao seu limite e o cliente pode estar satisfeito com a versão atual (lembre-se, software é um negócio de assinatura). Pelo fato do processo ser iterativo, você tem muitas oportunidades de entregar um produto muito antes dele ter sido efetivamente concluído; projetos de código aberto trabalham exclusivamente com uma iteração, em um ambiente de alto nível de feedback, o que os torna bem sucedidos.Comentários (em inglês)



Um processo de desenvolvimento iterativo é valioso por muitas razões. Você pode revelar e resolver riscos críticos previamente, os clientes têm ampla oportunidade de mudar o seu pensamento, a satisfação do programador é maior, e o projeto pode ser conduzido com maior precisão. Mas um importante benefício adicional é o feedback para os acionistas, que podem ver o estado atual do produto, exatamente onde ele se encontra. Isto pode reduzir ou eliminar a necessidade de reuniões de avaliação de status e aumentar a confiança e apoio dos acionistas.Comentários (em inglês)

Fase 5: Evolução



Este é o ponto do ciclo de desenvolvimento que tem sido tradicionalmente chamado de "manutenção", um termo geral que pode significar tudo, desde "fazer o trabalho que deveria supostamente ter sido feito em primeiro lugar" até "adicionando características que o cliente esqueceu de mencionar", passando pelo tradicional "corrigindo os erros que apareceram" e "adicionando novas características que a necessidade impôs". Como muitas idéias erradas têm sido aplicadas ao termo "manutenção", ele tem tido um conceito decrescente de qualidade, em parte devido ao fato que ele sugere que você realmente construiu um programa primitivo e tudo o que você precisa fazer é mudar as peças, colocar óleo nelas, e mantê-las distantes da ferrugem. Talvez exista um termo melhor para descrever o que está ocorrendo.Comentários (em inglês)



Eu irei usar o termo evolução.[112] Isto é, "Você não irá fazer certo da primeira vez, então dê a você mesmo a chance de aprender, voltar atrás e fazer as mudanças". Você irá precisar fazer muitas mudanças enquanto aprende e entende o problema mais profundamente. A elegância com que você irá produzir, ao evoluir até ter a coisa certa, irá valer à pena, a curto e longo prazo. Evolução é onde seu programa vai de bom a explêndido, e onde aquelas características que você realmente não entendia no primeiro passo tornam-se claras. Ela também é o lugar onde suas classes podem evoluir de simples recursos sendo utilizados no projeto para recursos efetivamente reusáveis.Comentários (em inglês)



"Fazer certo" não significa apenas que o programa trabalha de acordo com os requerimentos e casos de uso. Também significa que a estrutura interna do código faz sentido para você, se encaixa perfeitamente, sem uma sintaxe desajeitada, objetos mau dimensionados, ou bits de código desajeitadamente expostos. Adicionalmente, você deverá ter em mente que a estrutura do programa irá sobreviver às mudanças que inevitavelmente irão ser feitas ao longo de seu ciclo de vida, e que estas mudanças possam ser feitas de forma fácil e limpa. Isto não é uma façanha pequena. Você deve não apenas entender o que está construindo, mas também como o programa irá evoluir (o que eu chamo de vetor de mudança). Felizmente, as linguagens de programação orientadas a objeto são particularmente adeptas ao suporte deste tipo contínuo de modificações - as fronteiras criadas pelos objetos são o que tendem a previnir as avarias da estrutura. Elas também permitem que você faça as mudanças - aquelas que iriam parecer drásticas em um programa procedural - sem causar um terremoto dentro de seu código. De fato, o suporte para a evolução deverá ser o mais importante benefício da POO.Comentários (em inglês)



Com a evolução, você cria algo que se aproxima daquilo que você pensou que estava construindo, e então você faz uma revisão, compara com os seus requerimentos, e vê onde aconteceram falhas. Em seguida você pode voltar atrás e corrigi-las através do redesenho e reimplementação de partes do programa que não estão funcionando corretamente.[113] Você realmente irá precisar resolver um problema, ou um aspecto de um problema, muitas vezes antes de atirar na solução correta (Um estudo de Padrões de Projetos é útil neste ponto. Você pode encontrar mais informação em Thinking in Patterns (with Java) em www.BruceEckel.com) Comentários (em inglês)



A evolução também ocorre quando você constrói um sistema, vê que ele se adequa aos seus requerimentos, e então descobre que não era aquilo que você realmente queria. Quando você vê o sistema em operação, você pode encontrar o que realmente queria para resolver um problema diferente. Se você pensar que este tipo de evolução está para acontecer, então você deverá construir sua primeira versão o mais rápido possível, para que possa se verificar se é isso realmente que você quer.Comentários (em inglês)



Talvez a coisa mais importante para lembrar é que por default - por definição, na verdade - se você modifica uma classe, suas super e subclasses continuarão funcionando. Você não deve ter medo de modificações (especialmente se você tem um conjunto montado de testes de unidade para verificar a corretude de suas modificações). A modificação não irá necessariamente quebrar o programa, e qualquer mudança no resultado será limitada às subclasses e/ou colaboradores específicos da classe que você está mudando.Comentários (em inglês)

Planos valem à pena



É claro que você não irá construir uma casa sem um monte de planos cuidadosamente desenhados. Se você está construindo um deck ou uma casa de cachorro, seus planos não serão tão elaborados, mas você provavelmente ainda irá começar com algum tipo de esboço para guiar o seu trabalho. Desenvolvimento de software tem ido aos extremos. Por um longo tempo, as pessoas não tinham muita estrutura em seus desenvolvimentos, mas em seguida os grandes projetos começaram a falhar. Em reação, nós abandonamos metodologias que tinham uma quantidade intimidante de estruturas e detalhes, inicialmente voltadas para grandes projetos. Estas metodologias eram muito assustadoras para se usar - parecia que você teria que gastar todo o seu tempo escrevendo documentos e nenhum tempo programando (isto era frequentemente o que acontecia). Eu espero que o que nós temos mostrado para você aqui sugira um caminho do meio - uma escala móvel. Use uma abordagem que se encaixe em suas necessidades (e em sua personalidade). Não importa se a aborgadem que você escolheu é pequena, algum tipo de plano irá fazer uma grande melhoria para seu projeto, ao contrário de não planejar nada. Lembre-se, que de acordo com muitas estimativas, mais de 50 porcento dos projetos fracassam (algumas estimativas falam de 70 porcento!). Comentários (em inglês)



Seguindo um plano - preferencialmente aquele que é simples e curto - e fazendo o projeto da estrutura antes de codificar, você irá descobrir que as coisas fracassam juntas mais rapidamente do que se você mergulhar e começar a fuçar. Você também obtém muita satisfação neste processo. É minha experiência que aumenta ao trazer uma solução elegante; em um nível um pouco diferente, se aproxima mais da arte do que da tecnologia. E a elegância sempre vale à pena; ela não é uma meta frívola. Não apenas dá a você um programa mais fácil de se construir e depurar, mas também mais fácil de entender e manter, e é neste ponto onde o valor financeiro reside.Comentários (em inglês)

Extreme Programming



Eu tenho estudado técnicas de análise e design, em uso ou não, desde que estava na faculdade. O conceito de Extreme Programming (XP) é o mais radical, e encantador, que eu já vi. Você pode encontrá-lo na crônica Extreme Programming Explained por Kent Beck (Addison-Wesley, 2000) e na Web em www.xprogramming.com. Addison-Wesley também informam estarem editando um novo livro da série XP a cada mês ou dois; o objetivo parece ser convencer a todos a mudar de rumo e usar seus livros de peso (geralmente, contudo, estes livros são pequenos e prazerosos de ler). Comentários (em inglês)



XP é tanto uma filosofia de programação quanto um conjunto de regras para fazê-la. Algumas destas regras estão refletidas em outras metodologias recentes, mas as duas mais importantes e distintas contribuições, em minha opinião, são “escreva os testes primeiro” e “programação em pares.” Embora ele argua fortemente pelo processo inteiro, Beck mostra que se você adotar somente estas duas práticas você aumentará grandemente sua produtividade e confiança. Comentários (em inglês)

Escreva os testes primeiro



Testes são tradicionalmente relegados para a última parte de um projeto, depois de você ter “conseguido tudo funcionando, mas só para estar seguro.” Eles tem tido implicitamente uma prioridade baixa, e pessoas que se especializam neles não tem recebido a porção de status e tem frequentemente sido escondidas em um porão, longe dos “programadores reais.” Equipes de teste tem respondido a altura, indo além de usar roupa preta e cacarejar em coro sempre que eles quebram algo (para ser honesto, Eu mesmo tenho tido esta sensação quando quebro compiladores). Comentários (em inglês)



XP revoluciona completamente o conceito de teste dando a ele igual (ou talvez maior) prioridade que o código. De fato, você escreve os testes antes de você escrever o código que será testado, e os testes acompanham o código para sempre. Os testes devem ser executados sucessivamente toda vez que você fizer a construção de um projeto (que é frequente, algumas vezes mais de uma vez por dia). Comentários (em inglês)



Escrever testes primeiramente causa dois efeitos extremamente importantes. Comentários (em inglês)



Primeiro, força a definição clara da interface de uma classe. Eu tenho sugerido frequentemente que as pessoas “imaginem a classe perfeita para resolver um problema em particular” como um artifício quando tentando projetar um sistema. A estratégia de teste da XP vai mais além então pois especifica exatamente como a classe deve procurar parecer, para o usuário da classe, e exatamente como a classe deve se comportar. Com nenhuma condição incerta. Você pode escrever tudo em prosa, ou criar todos os diagramas que quiser, descrevendo como a classe deveria se comportar e como deve se parecer, mas nada é tão real quanto um conjunto de testes. O formulário é uma lista de necessidades, mas os testes são um contrato que é forçado pelo compilador e pelo framework de teste. É difícil imaginar uma descrição mais concreta de uma classe que os testes. Comentários (em inglês)



Enquanto cria os testes, você é forçado a idealizar completamente a classe e frequentemente descobrirá funcionalidades necessárias que podem ter sido esquecidas durante as análises experimentais de diagramas UML, cartões CRC, casos de uso, etc. Comentários (em inglês)



O segundo efeito importante de escrever os testes primeiro vem de rodar os testes todas as vezes que você constrói seu software. Esta atividade lhe dá a outra metade dos testes que é executada pelo compilador. Se você olhar a evolução das linguagens de programação desta perspectiva, você verá que as melhorias reais na tecnologia tem sido resolvidas ao redor dos testes. A linguagem Assembly é verificada somente pela sintaxe, mas C impôs algumas restrições semânticas, e estas o previnem de fazer certos tipos de erros. Linguagens OO impôem ainda mais restrições semânticas, as quais se você analisar são atualmente formas de teste. “Está este tipo de dados sendo usado apropriadamente?” e “Está este método sendo chamado apropriadamente?” são os tipos de testes que estão sendo executados pelo compilador ou systema de execução. Nós temos visto os resultados destes testes construidos dentro da linguagem: Pessoas tem sido habilitadas a escrever sistemas mais complexos, e conseguido colocá-los para trabalhar, com muito menos tempo e esforço. Eu tenho me surpreendido com o porque disto, mas agora eu acredito que se tratam dos testes: Você faz algo errado, e a rede de segurança de teste do construtor diz a você que há um problema e aponta onde ele está para você.Comentários (em inglês)



Mas os testes embutidos e fornecidos pelo projeto da linguagem só podem ir até uma parte. Em algum ponto, você deve entrar e adicionar o resto dos testes que produzem um conjunto completo (em cooperação com o compilador e o sistema de execução) que verificam tudo de seu programa. E, como se houvesse um compilador espiando sobre seu ombro, você não quereria estes testes o ajudando a corrigir desde o princípio? Este é o porque de você escrevê-los primeiro, e rodá-los automaticamente como toda construção de seu sistema. Seus testes tornam-se uma extensão da rede de segurança providenciada pela linguagem. Comentários (em inglês)



One of the things that I’ve discovered about the use of more and more powerful programming languages is that I am emboldened to try more brazen experiments, because I know that the language will keep me from wasting my time chasing bugs. The XP test scheme does the same thing for your entire project. Because you know your tests will always catch any problems that you introduce (and you regularly add any new tests as you think of them), you can make big changes when you need to without worrying that you’ll throw the whole project into complete disarray. This is incredibly powerful. Comentários (em inglês)



In this third edition of this book, I realized that testing was so important that it must also be applied to the examples in the book itself. With the help of the Crested Butte Summer 2002 Interns, we developed the testing system that you will see used throughout this book. The code and description is in Chapter 15. This system has increased the robustness of the code examples in this book immeasurably. Comentários (em inglês)




Programando em par



Pair programming goes against the rugged individualism that we’ve been indoctrinated into from the beginning, through school (where we succeed or fail on our own, and working with our neighbors is considered “cheating”), and media, especially Hollywood movies in which the hero is usually fighting against mindless conformity.[114] Programmers, too, are considered paragons of individuality—“cowboy coders,” as Larry Constantine likes to say. And yet XP, which is itself battling against conventional thinking, says that code should be written with two people per workstation. And that this should be done in an area with a group of workstations, without the barriers that the facilities-design people are so fond of. In fact, Beck says that the first task of converting to XP is to arrive with screwdrivers and Allen wrenches and take apart everything that gets in the way.[115] (This will require a manager who can deflect the ire of the facilities department.) Comentários (em inglês)



The value of pair programming is that one person is actually doing the coding while the other is thinking about it. The thinker keeps the big picture in mind—not only the picture of the problem at hand, but the guidelines of XP. If two people are working, it’s less likely that one of them will get away with saying, “I don’t want to write the tests first,” for example. And if the coder gets stuck, they can swap places. If both of them get stuck, their musings may be overheard by someone else in the work area who can contribute. Working in pairs keeps things flowing and on track. Probably more important, it makes programming a lot more social and fun. Comentários (em inglês)



I’ve begun using pair programming during the exercise periods in some of my seminars, and it seems to significantly improve everyone’s experience. Comentários (em inglês)

Strategies for transition



If you buy into OOP, your next question is probably, “How can I get my manager/colleagues/department/peers to start using objects?” Think about how you—one independent programmer—would go about learning to use a new language and a new programming paradigm. You’ve done it before. First comes education and examples; then comes a trial project to give you a feel for the basics without doing anything too confusing. Then comes a “real world” project that actually does something useful. Throughout your first projects you continue your education by reading, asking questions of experts, and trading hints with friends. This is the approach many experienced programmers suggest for the switch to Java. Switching an entire company will of course introduce certain group dynamics, but it will help at each step to remember how one person would do it. Comentários (em inglês)

Guidelines



Aqui são algumas regras a considerar quando fizer a transição para POO e Java: Comentários (em inglês)

1. Treinando



The first step is some form of education. Remember the company’s investment in code, and try not to throw everything into disarray for six to nine months while everyone puzzles over unfamiliar features. Pick a small group for indoctrination, preferably one composed of people who are curious, work well together, and can function as their own support network while they’re learning Java. Comentários (em inglês)



An alternative approach is the education of all company levels at once, including overview courses for strategic managers as well as design and programming courses for project builders. This is especially good for smaller companies making fundamental shifts in the way they do things, or at the division level of larger companies. Because the cost is higher, however, some may choose to start with project-level training, do a pilot project (possibly with an outside mentor), and let the project team become the teachers for the rest of the company. Comentários (em inglês)

2. Low-risk project



Try a low-risk project first and allow for mistakes. Once you’ve gained some experience, you can either seed other projects from members of this first team or use the team members as an OOP technical support staff. This first project may not work right the first time, so it should not be mission-critical for the company. It should be simple, self-contained, and instructive; this means that it should involve creating classes that will be meaningful to the other programmers in the company when they get their turn to learn Java. Comentários (em inglês)

3. Model from success



Seek out examples of good object-oriented design before starting from scratch. There’s a good probability that someone has solved your problem already, and if they haven’t solved it exactly you can probably apply what you’ve learned about abstraction to modify an existing design to fit your needs. This is the general concept of design patterns, covered in Thinking in Patterns (with Java) at www.BruceEckel.com. Comentários (em inglês)

4. Use existing class libraries



An important economic motivation for switching to OOP is the easy use of existing code in the form of class libraries (in particular, the Standard Java libraries, which are covered throughout this book). The shortest application development cycle will result when you can create and use objects from off-the-shelf libraries. However, some new programmers don’t understand this, are unaware of existing class libraries, or, through fascination with the language, desire to write classes that may already exist. Your success with OOP and Java will be optimized if you make an effort to seek out and reuse other people’s code early in the transition process. Comentários (em inglês)

5. Don’t rewrite existing code in Java



It is not usually the best use of your time to take existing, functional code and rewrite it in Java. If you must turn it into objects, you can interface to the C or C++ code using the Java Native Interface or Extensible Markup Language (XML). There are incremental benefits, especially if the code is slated for reuse. But chances are you aren’t going to see the dramatic increases in productivity that you hope for in your first few projects unless that project is a new one. Java and OOP shine best when taking a project from concept to reality. Comentários (em inglês)




Management obstacles



If you’re a manager, your job is to acquire resources for your team, to overcome barriers to your team’s success, and in general to try to provide the most productive and enjoyable environment so your team is most likely to perform those miracles that are always being asked of you. Moving to Java falls in all three of these categories, and it would be wonderful if it didn’t cost you anything as well. Although moving to Java may be cheaper—depending on your constraints—than the OOP alternatives for a team of C programmers (and probably for programmers in other procedural languages), it isn’t free, and there are obstacles you should be aware of before trying to sell the move to Java within your company and embarking on the move itself. Comentários (em inglês)




Startup costs



The cost of moving to Java is more than just the acquisition of Java compilers (the Sun Java compiler is free, so this is hardly an obstacle). Your medium- and long-term costs will be minimized if you invest in training (and possibly mentoring for your first project) and also if you identify and purchase class libraries that solve your problem rather than trying to build those libraries yourself. These are hard-money costs that must be factored into a realistic proposal. In addition, there are the hidden costs in loss of productivity while learning a new language and possibly a new programming environment. Training and mentoring can certainly minimize these, but team members must overcome their own struggles to understand the new technology. During this process they will make more mistakes (this is a feature, because acknowledged mistakes are the fastest path to learning) and be less productive. Even then, with some types of programming problems, the right classes, and the right development environment, it’s possible to be more productive while you’re learning Java (even considering that you’re making more mistakes and writing fewer lines of code per day) than if you’d stayed with C. Comentários (em inglês)

Performance issues



A common question is, “Doesn’t OOP automatically make my programs a lot bigger and slower?” The answer is, “It depends.” The extra safety features in Java have traditionally extracted a performance penalty over a language like C++. Technologies such as “hotspot” and compilation technologies have improved the speed significantly in most cases, and efforts continue toward higher performance. Comentários (em inglês)



When your focus is on rapid prototyping, you can throw together components as fast as possible while ignoring efficiency issues. If you’re using any third-party libraries, these are usually already optimized by their vendors; in any case it’s not an issue while you’re in rapid-development mode. When you have a system that you like, if it’s small and fast enough, then you’re done. If not, you begin tuning with a profiler, looking first for speedups that can be done by rewriting small portions of code. If that doesn’t help, you look for modifications that can be made in the underlying implementation so no code that uses a particular class needs to be changed. Only if nothing else solves the problem do you need to change the design. If performance is so critical in that portion of the design, it must be part of the primary design criteria. You have the benefit of finding this out early using rapid development.



Chapter 15 introduces profilers, which can help you discover bottlenecks in your system so you can optimize that portion of your code (with the hotspot technologies, Sun no longer recommends using native methods for performance optimization). Optimization tools are also available. Comentários (em inglês)

Common design errors



When starting your team into OOP and Java, programmers will typically go through a series of common design errors. This often happens due to insufficient feedback from experts during the design and implementation of early projects, because no experts have been developed within the company, and because there may be resistance to retaining consultants. It’s easy to feel that you understand OOP too early in the cycle and go off on a bad tangent. Something that’s obvious to someone experienced with the language may be a subject of great internal debate for a novice. Much of this trauma can be skipped by using an experienced outside expert for training and mentoring. Comentários (em inglês)

Summary



This chapter was only intended to give you concepts of OOP methodologies, and the kinds of issues you will encounter when moving your own company to OOP and Java. More about Object design can be learned at the MindView seminar “Designing Objects and Systems” (see “Seminars” at www.MindView.net).




[102] Um excelente exemplo disto éUML Essencial, 2a. edição, porMartin Fowler (Bookman 2000), que reduz o, ás vezes, imenso processo UML em um subconjunto gerenciável.



[103] Minha regra de uso para estimar estes projetos: Se há mais que um "wild-card" (fatores e problemas desconhecidos e variáveis), nem mesmo tente planejar quanto tempo levará ou quanto irá custar até você criar um protótipo operacional.



[104] An excellent resource for requirements analysis is Exploring Requirements: Quality Before Design, by Gause & Weinberg (Dorset House 1989).



[105] Thanks for help from James H Jarrett.



[106] More information on use cases can be found in Use Case Driven Object Modeling with UML by Rosenberg (Addison-Wesley 1999) . A good overview of user stories is found in Planning Extreme Programming, by Beck & Fowler (Addison-Wesley 2001).



[107] My personal take on this has changed lately. Doubling and adding 10 percent will give you a reasonably accurate estimate (assuming there are not too many wild-card factors), but you still have to work quite diligently to finish in that time. If you want time to really make it elegant and to enjoy yourself in the process, the correct multiplier is more like three or four times, I believe. See PeopleWare, by DeMarco & Lister (Dorset House 1999) for studies of the effect of schedule estimates on productivity and a debunking of “Parkinson’s Law.”



[108] Planning Extreme Programming (ibid.) has some valuable insights on planning and time estimation.



[109] For starters, I recommend the aforementioned UML Distilled, 2nd edition.



[110] Python (www.Python.org) is often used as “executable pseudocode.”



[111] “What can be done with fewer ... is done in vain with more ... the mind should not multiply things without necessity.” William of Ockham, 1290-1349.



[112] At least one aspect of evolution is covered in Martin Fowler’s book Refactoring: Improving the Design of Existing Code (Addison-Wesley 1999), which uses Java examples exclusively.



[113] This is something like “rapid prototyping,” in which you were supposed to build a quick-and-dirty version so that you could learn about the system, and then throw away your prototype and build it right. The trouble with rapid prototyping is that people didn’t throw away the prototype, but instead built upon it. Combined with the lack of structure in procedural programming, this often leads to messy systems that are expensive to maintain.



[114] Although this may be a more American perspective, the stories of Hollywood reach everywhere.



[115] Including (especially) the PA system. I once worked in a company that insisted on broadcasting every phone call that arrived for every executive, and it constantly interrupted our productivity (but the managers couldn’t begin to conceive of stifling such an important service as the PA). Finally, when no one was looking I started snipping speaker wires.


Anterior Próximo Página Inicial Índice Conteúdo