excerto disponibilizado pelo · pdf fileramentas fundamentais na bagagem de um bom...

Centro Atlântico

Licença

Excerto disponibilizado pelo Editor.

JOÃO HUGO MIRANDA

JOSÉ ANTÓNIO ALMEIDA

Desenvolvimento orientado por objectos

Domain-Driven Design, Testes Unitários e Refactoring

Portugal/2005

Reservados todos os direitos por Centro Atlântico, Lda. Qualquer reprodução, incluindo fotocópia, só pode ser feita com autorização expressa dos editores da obra.

DESENVOLVIMENTO ORIENTADO POR OBJECTOS – DOMAIN-DRIVEN DESIGN, TESTES UNITÁRIOS E REFACTORING

Colecção: Tecnologias

Autores: João Hugo Miranda

José António Almeida

Direcção gráfica: Centro Atlântico

Revisão técnica: Vitor Pereira (Prof. Auxiliar, Univ. Lusíada)

Capa: Paulo Buchinho

© Centro Atlântico, Lda., 2005

Av. Dr. Carlos Bacelar, 968 – Escr. 1 – A 4764-901 V. N. Famalicão

© Rua da Misericórdia, 76 – 1200-273 Lisboa

Portugal Tel. 808 20 22 21

[email protected]

www.centroatlantico.pt

Impressão e acabamento: Inova

1ª edição: Outubro de 2005

ISBN: 989-615-013-3

Depósito legal: 234.045/05

Marcas registadas: Todos os termos mencionados neste livro conhecidos como sendo marcas registadas de produtos e serviços foram apropriadamente capitalizados. A utilização de um termo neste livro não deve ser encarada como afectando a validade de alguma marca registada de produto ou serviço.

O Editor e os Autores não se responsabilizam por possíveis danos morais ou físicos causados pelas instruções contidas no livro nem por endereços Internet que não correspondam às Home-Pages pretendidas.

Índice 1 INTRODUÇÃO ............................................................................... 11

1.1 Objectivos e temática .........................................................................11

1.1.1 Objectivos ................................................................................................11

1.1.2 Algumas considerações...........................................................................12

1.2 Audiência ............................................................................................13

1.3 Motivação ...........................................................................................13

1.3.1 O Desenho Planeado ..............................................................................14

1.3.2 O Desenho Emergente ............................................................................16

1.3.3 Um Programador Completo.....................................................................17

1.4 Organização .......................................................................................20

PARTE I

2 O OBJECTO................................................................................. 21

2.1 A História e a Filosofia dos Objectos..................................................21

2.1.1 Simula ......................................................................................................22

2.1.2 Smalltalk ..................................................................................................23

2.1.3 C++ ..........................................................................................................24

2.1.4 Java .........................................................................................................25

2.1.5 .Net ..........................................................................................................26

2.2 O que são Objectos?..........................................................................28

2.2.1 Pensar em Objectos ................................................................................29

2.3 Conceitos fundamentais .....................................................................33

2.3.1 Objecto.....................................................................................................33

2.3.2 Responsabilidade ....................................................................................34

2.3.3 Mensagem ...............................................................................................35

2.3.4 Interface ...................................................................................................36

2.3.5 Encapsulamento ......................................................................................37

2.3.6 Polimorfismo ............................................................................................37

2.4 Pontos-chave......................................................................................38

8 CENTRO ATLÂNTICO – COLECÇÃO TECNOLOGIAS – DESENVOLVIMENTO ORIENTADO POR OBJECTOS

3 DOMAIN-DRIVEN DESIGN ..............................................................39

3.1 Compreender o domínio do problema............................................... 39

3.1.1 Comunicação eficiente ............................................................................ 40

3.1.2 A importância da Comunicação .............................................................. 43

3.2 Linguagem Ubíqua ............................................................................ 46

3.2.1 Uma linguagem omnipresente ................................................................ 47

3.2.2 Uma língua comum em todo o Projecto .................................................. 50

3.2.3 Linguagem Ubíqua e Documentação...................................................... 51

3.3 Elementos do domínio da solução..................................................... 51

3.3.1 Entidades (Entity) .................................................................................... 52

3.3.2 Objectos-Valor (Value Objects) ............................................................... 56

3.3.3 Serviços (Services).................................................................................. 60

3.3.4 Associações ............................................................................................ 63

3.3.5 Módulos ................................................................................................... 67

3.4 Pontos-chave..................................................................................... 70

PARTE II

4 DESENVOLVIMENTO TEST-DRIVEN .................................................71

4.1 Testes Unitários ................................................................................. 71

4.1.1 Granularidade dos testes ........................................................................ 72

4.1.2 Quando implementar os testes? ............................................................. 73

4.1.3 Reforço positivo....................................................................................... 74

4.2 O que é Desenvolvimento Test-Driven?............................................ 75

4.2.1 Um teste simples ..................................................................................... 76

4.2.2 Mais um teste .......................................................................................... 87

4.2.3 Alterações ao processo de desenvolvimento.......................................... 93

4.3 Pontos-chave..................................................................................... 93

5 DESENVOLVIMENTO TEST-DRIVEN AVANÇADO................................95

5.1 Mock Objects ..................................................................................... 95

5.1.1 Pesquisa de livros através de um web service. ...................................... 97

5.2 Injecção de dependências ............................................................... 104

5.2.1 Injecção de dependências através do construtor.................................. 105

5.2.2 Injecção de dependências através de uma propriedade ...................... 106

5.2.3 Injecção de dependências através de injecção de interfaces............... 106

5.3 Mock Objects estáticos.................................................................... 109

5.3.1 Persistência de livros............................................................................. 109

5.4 Quando utilizar Mock Objects?........................................................ 115

5.5 Pontos-chave................................................................................... 116

ÍNDICE 9

6 DESENVOLVIMENTO DE INTERFACES DE UTILIZAÇÃO..................... 119

6.1 Interfaces de Utilização ....................................................................119

6.2 Model View Controller ......................................................................119

6.3 Implementação de clientes Web ......................................................121

6.3.1 Page Controller ......................................................................................121

6.4 Implementação de clientes ricos ......................................................129

6.4.1 Model View Presenter............................................................................129

6.5 Pontos-chave....................................................................................137

7 INTRODUÇÃO AO REFACTORING .................................................. 139

7.1 O que é o Refactoring? ....................................................................139

7.1.1 Refactorings mais comuns ....................................................................143

7.1.2 As origens ..............................................................................................145

7.1.3 Pré-requisitos.........................................................................................145

7.1.4 Refactoring Automático .........................................................................148

7.2 Refactoring no Processo de Desenvolvimento ................................150

7.2.1 Refactoring e Desenho ..........................................................................150

7.2.2 Refactoring e Performance....................................................................152

7.2.3 Refactoring e Aplicações Legadas ........................................................154

7.2.4 Refactoring e Paradigmas não Orientados-a-Objectos.........................155

7.3 Pontos-chave....................................................................................157

8 REFACTORING APLICADO ........................................................... 159

8.1 A aplicação Catálogo de Livros ........................................................159

8.2 Corrigindo Código Doente ................................................................161

8.2.1 Métodos demasiado grandes ................................................................161

8.2.2 Comentários...........................................................................................163

8.2.3 Eliminando Métodos Longos e Comentários.........................................164

8.2.4 Código duplicado ...................................................................................168

8.2.5 Classes demasiado grandes .................................................................169

8.2.6 Eliminando Código Duplicado e Classes grandes.................................170

8.2.7 Alterações divergentes ..........................................................................173

8.2.8 Eliminando alterações divergentes........................................................174

8.2.9 Longas listas de parâmetros..................................................................179

8.2.10 Blocos de dados ...............................................................................181

8.2.11 Eliminando longas listas de parâmetros e blocos de dados.............182

8.2.12 “Inveja” ..............................................................................................186

8.2.13 Eliminando as “Invejas”.....................................................................187

8.2.14 Classe de Dados...............................................................................190

8.2.15 Eliminando Classes de Dados ..........................................................191

8.2.16 Obsessão por Primitivas ...................................................................193

8.2.17 Eliminando a obsessão por Primitivas ..............................................194

8.2.18 Alterações Transversais ...................................................................196


8.2.19 Eliminando alterações transversais.................................................. 197

8.2.20 Switches ........................................................................................... 201

8.2.21 Eliminando Switches......................................................................... 203

8.2.22 Generalização especulativa ............................................................. 208

8.3 Pontos-chave................................................................................... 209

9 CONCLUSÕES E PASSOS FUTUROS ..............................................211

9.1 O que aprendemos .......................................................................... 211

9.1.1 Os Objectos........................................................................................... 211

9.1.2 Domain-Driven Design .......................................................................... 213

9.1.3 Desenvolvimento Test-Driven ............................................................... 215

9.1.4 Refactoring ............................................................................................ 219

9.2 Próximos passos.............................................................................. 220

9.2.1 Beber das fontes originais ..................................................................... 220

9.2.2 Padrões de Desenho e Refactoring ...................................................... 221

9.3 Palavras finais.................................................................................. 224

REFERÊNCIAS ...................................................................................225

ÍNDICE REMISSIVO .............................................................................229

1 Introdução

1.1 Objectivos e temática

Este projecto nasceu no Microsoft DevDays, a partir de duas apresenta-ções que realizámos nesse evento. As apresentações foram sobre Desenvolvimento Test-Driven e Refactoring, duas práticas que apesar de não serem propriamente recentes só agora começam a ser adopta-das pela comunidade de programadores e a ser encaradas como fer-ramentas fundamentais na bagagem de um bom programador.

1.1.1 OBJECTIVOS

Quando a editora nos propôs que considerássemos a edição de um livro, estabelecemos alguns objectivos que nos ajudaram a definir quais os temas que pretendíamos incluir.

Em primeiro lugar, o livro teria de abordar o Desenvolvimento Test- -Driven e o Refactoring, como é natural. O momento pareceu-nos ade-quado pois estes temas começam a obter uma exposição considerável, mas no contexto português estas práticas ainda se encontram muito pouco disseminadas.

Em segundo lugar, pretendíamos abordar um conjunto de temáticas pouco abordadas na literatura técnica portuguesa. Quem pretenda estudar estes temas, apenas podia recorrer à literatura anglo-saxónica.

Em terceiro lugar, queríamos discutir temas considerados de nível intermédio-avançado de uma forma simples e natural, muito pragmática, tentando apresentá-los a uma audiência mais alargada e com pouco contacto com as abordagens mais recentes nas metodologias e práticas de desenvolvimento.

Finalmente, definimos como objectivo relacionar o paradigma dos objectos com estas práticas de programação e demonstrar como a aná-lise, o desenho e a codificação de um sistema de informação não devem ser actividades separadas, como é muito usual acontecer. Este


objectivo é importante porque é muito difícil encontrar na literatura um ponto de entrada para todas as temáticas que abordaremos neste texto. Quem as quiser estudar tem de recorrer a múltiplas referências dife-rentes, o que pode constituir um factor de desmotivação.

1.1.2 ALGUMAS CONSIDERAÇÕES

As práticas e teorias descritas neste texto não são novas e alguns dos seus mais conhecidos proponentes, como Ward Cunningham, Martin Fowler ou Kent Beck, não pretendem apresentá-las desse modo. Aliás, a maior parte dos temas abordados são conhecidos há muito anos. A novidade está em dois factores principais:

• Só recentemente é que estas práticas deixaram de ser encara-das como factores secundários das metodologias de desenvol-vimento. Foi com o advento das metodologias ágeis que práticas como o Desenvolvimento Test-Driven e o Refactoring foram ele-vados a elementos fundacionais de metodologias de desenvol-vimento.

• Só agora estas práticas começam a sair dos seus nichos e adoptadas pela comunidade em geral. Este é um dos aconteci-mentos definidores do sucesso ou fracasso da maior parte das ideias. A questão é que existem muitas ideias e práticas, muitas delas válidas e úteis, que não conseguem dar este salto, man-tendo-se confinadas aos meios académicos e a profissionais de topo, por um conjunto variado de razões. A discussão deste assunto é muito interessante, mas não faz parte dos objectivos deste livro, que pretende ser tão pragmático quanto possível.

Os diversos temas serão apresentados por si, não existindo um estudo comparativo com possíveis alternativas. Por exemplo, o capítulo sobre Domain-Driven Design descreve este método de desenvolvimento, demonstrando como se adequa a um conjunto variado de situações. Naturalmente que existem alternativas a este método, mas ao concen-trarmo-nos apenas no Domain-Driven Design tentamos que o leitor fique com uma ideia clara dos seus princípios. Desta forma, o leitor fica melhor habilitado a decidir como integrar este método nos seus próprios métodos de trabalho, se assim o decidir. Como todos sabemos, não existe uma única solução e o leitor é instado a encontrar uma síntese

CAPÍTULO 1 – INTRODUÇÃO 13

das diversas abordagens existentes e que se adeqúe às suas neces-sidades.

Em resumo, nesta obra são discutidas um conjunto de práticas, com-provadas em múltiplos projectos empresariais de desenvolvimento de software em todo o mundo, nos quais se incluem projectos em que os autores participaram. Este texto pretende apresentar essas práticas de forma integrada, permitindo ao leitor uma compreensão global que lhe permita aplicá-las no seu dia-a-dia.

1.2 Audiência

Este livro é sobretudo dirigido a programadores profissionais e estu-dantes, como é natural. Espera-se que o leitor possua conhecimentos de programação e algumas noções básicas de programação orientada-a-objectos. Esta obra apresenta o paradigma orientado-a-objectos e descreve os seus principais conceitos, descrevendo também uma abor-dagem de desenho de programas orientados-a-objectos, o Domain- -Driven Design. Deste modo, não são exigidos ao leitor conhecimentos aprofundados sobre objectos.

Parte do texto também é recomendado a gestores de projecto, analistas ou responsáveis técnicos, especialmente os primeiros capítulos que estabelecem o enquadramento conceptual das temáticas debatidas ao longo dos restantes capítulos.

Os exemplos são em C#, mas qualquer pessoa com conhecimentos mínimos de programação deverá poder segui-los sem dificuldade. Ao longo do texto são incluídos diversos diagramas UML, pelo que se recomenda alguns conhecimentos básicos a este nível, embora isso não seja estritamente necessário.

1.3 Motivação

Nos nossos dias, existem duas grandes correntes de pensamento no que diz respeito a metodologias de desenvolvimento de software. Uma das correntes defende que a análise e o desenho devem ser actividades separadas do processo de construção de software. Esta corrente, mais


formal, inspira-se fortemente na metáfora da engenharia civil para enquadrar e justificar os seus princípios. Uma outra corrente, defende que a análise e o desenho de software é diferente de planear infra-estruturas físicas. Nesta corrente, a análise e o desenho são profunda-mente iterativos.

1.3.1 O DESENHO PLANEADO

O desenho planeado é uma forma de controlar a entropia natural do processo de desenvolvimento e, em particular, do processo de desenho ad-hoc de software. As suas raízes vêm do ramo da engenharia, onde a metáfora mais comum é a da construção de uma casa. Neste tipo de abordagem não é possível simplesmente ir desenhando a casa à medida que a construímos. É necessário efectuar o desenho da casa e da sua infra-estrutura antecipadamente, recorrendo a códigos de cons-trução. Na verdade, estes códigos são um conjunto de regras baseadas em experiência passada e que indicam o que funciona e o que não fun-ciona, contando naturalmente com um forte apoio da Matemática, da Física e outras ciências de base. Quando se considera o desenho con-cluído, este é entregue a uma outra equipa que constrói a casa de acordo com a especificação.

O mesmo princípio pode ser aplicado à construção de software. Um grupo de analistas conceptualiza o software usando ferramentas e lin-guagens de modelação, como por exemplo o UML, que os abstrai das questões mais técnicas de implementação, permitindo-lhes trabalhar a um nível mais conceptual, próximo da linguagem do cliente. Contudo, esta abordagem levanta algumas questões de difícil resolução.

Em primeiro lugar, a qualidade e eficácia do desenho resultante estão directamente associadas ao conhecimento técnico dos analistas. Se os analistas apenas desenham e não programam, rapidamente se tornam ineficazes e o desenho que produzem é tão desfasado da realidade tecnológica que os programadores terão necessidade de o contornar, introduzindo entropia no software e contribuindo para a sua deteriora-ção. O facto é que são também necessários conhecimentos técnicos profundos e actualizados, ou seja, as capacidades analíticas de um analista não são condição suficiente para obter um bom desenho de software.


No entanto, a maior falha do desenho planeado é não ser resistente a alterações de requisitos, um facto incontornável no desenvolvimento de sistemas de software, dadas as barreiras existentes na comunicação entre cliente, analista e programador. Uma forma de contornar esta situação passa por introduzir flexibilidade no desenho, tirando proveito das características inerentes ao paradigma dos objectos, como polimor-fismo ou herança. Contudo, para o conseguir de forma eficaz é neces-sário uma clara percepção do tipo de alterações que serão expectáveis. No entanto, existirão sempre alterações inesperadas e que não foram tidas em conta no desenho. Tipicamente, a abordagem consiste em isolar áreas de maior volatilidade. Porém, não é fora do comum haver requisitos que são considerados estáveis e definitivos mas que acabam por ser alterados sem aviso prévio, quer porque a realidade que o sis-tema pretende espelhar mudou, quer por qualquer outra razão.

Analisando estas duas questões, é possível reconhecer um dos proble-mas fundamentais da análise e desenho planeados: a perda de conhe-cimento acerca do domínio na transição entre as várias fases do pro-cesso.

Quando o programador recebe o desenho do analista é muito provável que ainda quase não tenha tido contacto com o domínio do problema. Este contacto faz-se através do desenho do sistema, necessariamente uma abstracção do domínio da responsabilidade do analista. Este tipo de contacto não seria problemático se o desenho fosse perfeito e imutá-vel, o que na prática não acontece. Quando o programador encontra algum problema no desenho, a tendência é para o resolver munido dos conhecimentos que possui acerca do domínio. No entanto estes conhe-cimentos são pouco aprofundados, pelo que a solução do programador para o problema tem uma grande probabilidade de estar errada e em desacordo com os requisitos do cliente.

Quanto às alterações mais ou menos constantes de requisitos, a solu-ção do desenho planeado – a flexibilização especulativa – é muito falí-vel e pode induzir à realização de muito trabalho desnecessário. Dado que o programador não conhece o domínio, todo o trabalho criativo tem de ser realizado pelo analista. Se a flexibilização for introduzida nos módulos errados, o que é natural dada a volatilidade dos requisitos, o programador é confrontado com becos aparentemente sem saída. Esta situação leva a que o programador contorne o desenho e o perverta


dado que não possui o conhecimento do domínio necessário à correcta adaptação do desenho.

Se pensarmos na filosofia subjacente ao paradigma dos objectos, facil-mente reconhecemos que este tipo de processos dificilmente é compa-tível com os objectos, a sua dinâmica e flexibilidade. A perda de conhe-cimento e a inexistência de feedback leva à criação de software que não modela correctamente o domínio e, logo, não cumpre um dos pilares mais importantes do paradigma orientado-a-objectos.

1.3.2 O DESENHO EMERGENTE

Nos últimos anos tem vindo a ganhar popularidade um método alterna-tivo de análise e desenho: o desenho emergente. Neste método, o desenho é como que um produto da construção do sistema de software. O desenho emerge, ou evolui, a partir do processo de construção. O desenho emergente deriva duma família de metodologias, as iterativas, que são advogadas há muito tempo e que nos nossos dias são mais conhecidas por metodologias ágeis. Teoricamente os processos iterati-vos são adoptados em inúmeras organizações mas na prática o velho modelo de cascata, Waterfall, ainda é o mais usado. Não tão raro como poderíamos pensar, a situação ainda é pior: não existe nenhum método, o desenvolvimento é puramente ad-hoc.

As metodologias associadas ao desenho emergente têm o potencial para criar software mais flexível e eficaz na resposta às necessidades do utilizador, ao mesmo tempo que aumentam a produtividade da equipa de desenvolvimento e resolvem os problemas mais graves do desenho planeado. Estas metodologias utilizam iterações de desenvol-vimento muito curtas, entre uma semana a um mês. Em cada iteração definem-se – frequentemente redefinem-se – os requisitos a cumprir no âmbito desta, realizando-se a análise e adaptando-se o desenho a esses requisitos. Cada requisito é corporizado em pequenos cenários de uso (use cases ou user stories) e testes de aceitação, que são depois executados e criados pela equipa de desenvolvimento.

Praticar consistentemente o desenho emergente não é fácil e exige algumas práticas próprias. É necessário que exista um conjunto de regras bem definidas que permita ao desenho evoluir de forma contro-lada. A íntima relação com a dinâmica da implementação pode ter efei-


tos negativos caso não seja constantemente acompanhada, podendo desaguar num sistema anárquico e em software com muitas falhas. Assumindo que a construção de software é um processo evolutivo, o desenho existe de modo a criar as condições necessárias para uma fácil integração das alterações necessárias ao longo do tempo, alte-rando-se e adaptando-se à medida que o software também evolui. Por alguma razão se chama ao software, software. Ele deve ser macio (soft) e devemos tirar partido dessa propriedade única no campo das enge-nharias e inovar, procurando técnicas e práticas novas, específicas à engenharia informática.

1.3.3 UM PROGRAMADOR COMPLETO

A organização e filosofia de uma equipa que adopte uma metodologia ágil é bastante diferente de uma equipa que adopte uma metodologia mais formal. A primeira apoia-se fortemente nas pessoas e na comuni-cação: a segunda confia em ferramentas e processos. Enquanto que a primeira funciona mais em rede, ou em matriz, a segunda é mais hierar-quizada.

Numa estrutura hierárquica, o elemento do nível superior toma decisões que depois são seguidas pelos seus subordinados. Este tipo de organi-zações tem algumas vantagens importantes, como a clareza do pro-cesso de decisão e o facto de ser a pessoa teoricamente mais qualifi-cada que toma as decisões importantes. Tem a desvantagem de tender a desresponsabilizar os elementos hierárquicos de níveis mais baixos (embora não intencionalmente), a impedir a aquisição de conhecimento e a dificultar a comunicação.

No contexto da engenharia informática, tradicionalmente, o analista toma as decisões e o programador executa-as. Do nosso ponto de vista esta é uma falha grave e fonte de múltiplos problemas, como já discutimos.

A alternativa do funcionamento em rede resolve alguns dos problemas mas introduz outros. Numa rede, os seus elementos têm poderes mais equilibrados, pelo que o processo de decisão é mais desconcentrado, mas a aquisição de conhecimento e a comunicação entre os seus ele-mentos mais eficaz. Esta solução tem muito potencial, mas exige uma muito maior responsabilização dos seus elementos e um leque mais alargado de competências.


É nossa convicção que o programador não pode ser isolado das subtile-zas do domínio do problema e o analista não pode deixar-se desactuali-zar do ponto de vista tecnológico. A solução é a fusão dos dois papéis que devem ser desempenhados por uma só pessoa. Esta deve ter boas capacidades analíticas e comunicativas para poder interagir com o cliente, mas ao mesmo tempo boas capacidades técnicas de modo a conciliar as necessidades do cliente com o potencial e as restrições tecnológicas ao seu dispor. Para que mantenha ambas as competên-cias, o (analista-)programador deve participar em todas as tarefas, desde a análise de requisitos com o cliente até à codificação do sistema de software, num carrossel contínuo e frutuoso.

A motivação deste livro é precisamente ajudar a criar as competências necessárias de modo a que o leitor possa assumir responsabilidades acrescidas e ser um elemento mais produtivo da equipa em que se insere. Neste livro são descritas diversas técnicas que têm como objec-tivo dotar o leitor de fortes capacidades analíticas, mas também conhe-cimentos técnicos que lhe permitam compreender tanto o domínio do problema como o domínio da solução.

Cliente e programador não são os únicos elementos da equipa

É muito importante realçar que não estamos a sugerir que o programa-dor deve ser um super-herói, com uma mentalidade “Eu e o Código!”. Nada mais longe da verdade. O que defendemos é que o programador deve ter um papel mais activo do que o tradicional no decurso de um projecto de software, assumindo plenamente o papel de analista e não concentrar-se apenas nas questões técnicas. Também podemos ver o assunto do outro lado: o analista deve descer do seu pedestal e envol-ver-se activamente na construção do software.

Mesmo numa organização tendencialmente em rede, existem sempre elementos com funções específicas e alguma hierarquia. Com a even-tual excepção de micro-projectos (duas a três pessoas), a inexistência de hierarquia é o caminho garantido para o fracasso do projecto dado que é necessário que exista alguém que possa dar a última palavra em situações que não geram consenso.


E a dimensão dos projectos?

Por vezes, é alegado que as metodologias ágeis não funcionam com projectos de média-grande dimensão. Esta é uma questão que se enquadra nas famosas “discussões religiosas” que são tão queridas da comunidade informática.

Capers Jones, Chief Scientist na Software Productivity Research, reali-zou um estudo1 que sumariza 20 anos de pesquisa. Esse estudo baseia-se em milhares de projectos, que foram divididos em três gran-des grupos: Sistemas Empresariais, como sites, Intranets, jogos ou ERP; Sistemas Críticos, como algum tipo de software embebido ou fer-ramentas de software (como IDE); Sistemas Críticos Embebidos, como sistemas médicos, aviónicos ou sistemas operativos.

As conclusões foram interessantes. No caso dos Sistemas Empresa-riais, as metodologias recomendadas são as ágeis, como o Extreme Programming ou o Scrum. No caso dos Sistemas Críticos, são reco-mendadas metodologias um pouco mais formais, com algum desenho de arquitectura mais formal. Finalmente, nos Sistemas Críticos Embebi-dos, são recomendadas metodologias puramente formais.

Estas conclusões são intuitivas se atendermos ao contexto de cada tipo de projecto. Os Sistemas Empresariais encontram-se em constante mutação, motivados pelas alterações induzidas pela concorrência entre competidores, pelo que necessitam de ser sistemas ágeis e extrema-mente flexíveis. Os Sistemas Críticos Embebidos têm como preocupa-ção principal a segurança, pois muitas vezes existem vidas a depender destes sistemas e a sua actualização é complicada ou impossível dada a natureza deste tipo de sistemas.

Mas o mais relevante e que mais nos interessa no contexto deste livro, é que em todas as situações é recomendado o Desenvolvimento Test- -Driven, pelo que os temas aqui debatidos deverão ser úteis em todas as situações que envolvam a construção de um sistema de software.

1 Jones, Capers (2003). Variations in Software Development Practices. IEEE Software. November/December 2003. 22-27.


1.4 Organização

O livro encontra-se dividido em duas partes, uma mais conceptual e outra mais prática.

A primeira parte é constituída por dois capítulos. O primeiro, “O Objecto”, apresenta a história dos objectos, descreve o que é um objecto e apresenta alguns conceitos associados a este. O segundo capítulo “Domain-Driven Design”, parte do primeiro capítulo para intro-duzir um método de análise e desenho baseado neste paradigma, des-crevendo o processo de análise que permite modelar o domínio do pro-blema e definindo um conjunto de conceitos que permitem construir os blocos básicos de um desenho orientado-a-objectos.

A segunda parte é constituída por cinco capítulos e é eminentemente prática, descrevendo o Desenvolvimento Test-Driven e o Refactoring. Na “Introdução ao Refactoring” introduzimos o Refactoring, explicando as suas origens e como se integra no processo de desenvolvimento. Em “Refactoring Aplicado” descrevemos um conjunto de heurísticas, conhe-cidas como Code Smells, que permitem identificar e corrigir violações no código e no desenho ao paradigma orientado-a-objectos. No “Desenvolvimento Test-Driven” iniciamos o estudo desta prática, come-çando por descrever os Testes Unitários seguido de um exemplo prático da aplicação do Desenvolvimento Test-Driven. O capítulo “Desenvolvi-mento Test-Driven Avançado” introduz os Mock Objects, uma técnica que permite criar testes unitários para uma classe evitando as depen-dências externas, e um conjunto de técnicas auxiliares ao Desenvolvi-mento Test-Driven. Finalmente, na “Desenvolvimento de Interfaces de Utilização” descrevemos como realizar testes unitários no desenvolvi-mento de interfaces homem-máquina, mais conhecidas pelo acrónimo inglês UI, de User Interfaces. Este é um tema raramente discutido na literatura, mas que qualquer programador encontra na prática, pelo que se nos afigurou importante abordar o assunto.

Finalmente, no capítulo “O Presente e o Futuro” oferecemos ao leitor algumas indicações que permitem aprofundar os temas debatidos no livro assim como algumas áreas a explorar uma vez dominados os prin-cípios do Domain-Driven Design, do Desenvolvimento Test-Driven e do Refactoring.

excerto disponibilizado pelo · pdf fileramentas fundamentais na bagagem de um bom...

Documents