Análise E Projeto Orientado A Objetos; Processos De Desenvolvimento

PARTE 1

Introdução

1.1 UMI

1

Anâlise e Projeto Orientados a Objetos

A mudança do foco (para padrões) terá um efeito profundo e duradouro sobre o modo como escrevemos programas.

- Ward Cunningham e Ralph Johnson

OBJETIVOS

• Comparar e contrastar análise e projeto.

• Definir análise e projeto orientados a objetos (A/POO).

• Ilustrar um breve exemplo.

1.1 UML e Padrões na AIPOO

O que significa ter um bom projeto de objetos? Este livro é uma ferramenta para ajudar desenvolvedores e estudantes a aprenderem as habilidades básicas usadas na análise e no projeto orientados a objetos (A/POO). Essas habilidades são essenciais para a criação de software bem-projetado, robusto e manutenível, usando tecnologias e linguagens orientadas a objetos, tais como Java, C++, Smalltalk e C#.

O provérbio “possuir um martelo não toma alguém um arquiteto” é particularmente verdadeiro em relação à tecnologia de objetos. Conhecer uma linguagem orientada a objetos (como lava) é um primeiro passo necessário, mas insuficiente, para criar sistemas orientados a objetos. Aprender a “pensar em termos de objetos” é fundamental.

28 UTILIZANDO LIVIL E r’ADROES

/ Esta é uma introdução ment

Este livro é uma introdução à A/POO aplicando Linguagem de Modelagem Unifica-

da (UML), padrões (patterns) e Processo Unificado. Ele não pretende ser um texto

avançado; antes, enfatiza o domínio dos fundamentos, como atribuir responsabilida- muit des a objetos, notação UML freqüentemente usada e padrões de projeto comuns. Ao a out mesmo tempo, principalmente nos capítulos posteriores, o material avança para tópicos

de nível intermediário, como projeto de umframework.

/ Aplicação da UML

O livro não trata somente da UML. A UML é uma notação padrão de diagramação.

Embora seja útil aprender a notação, há questões mais cruciais orientadas a objetos

para aprender; especificamente, como pensar em objetos - como projetar sistemas

orientados a objetos. A UML não é A/POO ou um método, é apenas uma notação. 1 Assim, não adianta aprender diagramação UML sintaticamente correta e, talvez,

uma ferramenta CASE UML, e não ser capaz de criar um excelente projeto, ou ava- j E liar e melhorar um existente. Esta é a habilidade mais difícil e de maior importância.

Conseqüentemente, este livro é uma introdução ao projeto de objetos.

Ainda assim, é necessária uma linguagem para a A/POO e para as “plantas do

software”, tanto como uma ferramenta de raciocínio quanto uma forma de comunicação.

Portanto, este livro mostra como aplicar a UML na execução de A/POO, e cobre a notação

UML freqüentemente usada. A ênfase está em ajudar as pessoas a aprender a arte e

a ciência de construir sistemas com objetos, e não na notação.

/ Aplicação de padrões e atribuição de responsabilidades

Como as responsabilidades devem ser atribuídas a classes de objetos? Como os objetos

devem interagir? Quais classes devem fazer o quê? Estas são questões importantes

no projeto de um sistema. Certas soluções consagradas para os problemas de

projeto podem ser (e têm sido) expressas na forma de princípios de melhores práticas,

heurísticas ou padrões - fórmulas para a solução de problemas que codificam

princípios exemplares de projeto. Este livro, ao ensinar como aplicar padrões, permite

um aprendizado mais rápido e o uso eficiente desses idiomas fundamentais do

projeto de objetos.

/ Um estudo de caso

Esta introdução à A/POO é ilustrada em um único estudo de caso que é discutido ao

longo de todo o livro, em cuidadosa e profunda análise e projeto, de modo que detalhes

difíceis do que deve ser considerado e solucionado em um problema real são tra- Figuri tados e resolvidos.

/ Casos de uso e análise de requisitos

Muitas outra

A/POO (e todo o projeto de software) está fortemente relacionada com a atividade

pré-requisito da análise de requisitos, a qual inclui escrever casos de uso. Portanto, Const

o estudo de caso começa com uma introdução a esses tópicos, embora eles não sejam tos, d

especificamente orientados a objetos. O proj

ocom

/ Um exemplo de um processo iterativo - o Processo Unificado

Considerando as muitas atividades possíveis, desde a análise de requisitos até a im- toplcc plementação, como deve proceder um desenvolvedor ou uma equipe de desenvolvi-

ANALISE E PROJETO ORIENTADOS A OBJETOS 29

mento? A análise de requisitos, e a A/POO precisam estar presentes no contexto de algum processo de desenvolvimento. Nesse caso, usamos como exemplo de processo de desenvolvimento iterativo o Processo Unificado (PU), no qual estes tópicos são introduzidos. Entretanto, os tópicos de análise e projeto cobertos são comuns a muitas abordagens e seu aprendizado no contexto do PU não invalida sua aplicação a outros métodos.

Concluindo, este livro ajuda um estudante ou um desenvolvedor a:

• Aplicar princípios e padrões para criar melhores projetos de objetos.

• Seguir um conjunto de atividades comuns de análise e projeto, baseando-se no PU como exemplo.

• Criar diagramas freqüentemente usados na notação UML.

Este texto ilustra isto no contexto de um único estudo de caso.

AIPOO

es_ãoUM

Tópicos e habilidades

Princípios e Análise N

diretrizes de requisitos

Desenvolvimento

interativo com o

Pu

Figura 1.1 Tópicos e habilidades cobertas.

Muitas outras habilidades são importantes

Construir software demanda muitas habilidades e passos, além da análise de requisitos, da A/POO e da programação orientada a objetos. A engenharia de usabilidade e o projeto da interface do usuário, por exemplo, são cruciais para o sucesso; o mesmo ocorre com o projeto de bancos de dados.

Entretanto, esta introdução enfatiza a A/POO, não pretendendo cobrir todos os

tópicos do desenvolvimento de software. Ela é uma parte de um todo maior.

30 UTILIZANDO UML E PADRÕES

1.2 Atribuição de Responsabilidades 1.4 C

Existem muitas atividades e artefatos possíveis na A/POO introdutórios, além de E uma vasta gama de princípios e diretrizes. Suponha que devamos escolher uma úni- r

ca habilidade prática dentre todos os tópicos discutidos aqui - uma habilidade a ser empregada em uma “ilha deserta”. Qual deveria ser ela?

o

Uma habilidade crítica fundamental em A/POO é atribuir, habilmente, responsabilidades

aos componentes de software.

o

Por quê? Porque esta é uma atividade que não pode deixar de ser executada -

seja ao desenhar um diagrama UML ou ao programar - e porque ela influencia dras ticament a robustez, a facilidade de manutenção e a reusabilidade de componentes ________

de software.

- . . conceito d

Naturalmente, existem outras habilidades necessarias na A/POO, mas a atri_______ buição de responsabilidades é enfatizada porque ela tende a ser uma habilidade difícil de ser dominada e, no entanto, de vital importância. Em um projeto real, um desenvolvedor pode não ter a oportunidade de executar quaisquer outras atividades de análise ou de projeto - um processo de desenvolvimento do tipo “corrida para codificar”. Apesar disso, mesmo nessa situação, atribuir responsabilidades é inevitável.

Conseqüentemente, os passos de projeto neste livro enfatizam princípios de atribuição de responsabilidades.

São apresentados e aplicados nove princípios fundamentais para o projeto de F objetos e atribuição de responsabilidades. Eles são organizados em um grupo,

de forma a facilitar o aprendizado, denominado padrões GRASP.

1.5 L

1.3 O Que São Análise e Projeto?

A análise enfatiza uma investigação do problema e dos requisitos, em vez de uma solução. Se desejamos um novo sistema de informação de biblioteca computadorizado, por exemplo, como ele será usado?

“Análise” é um termo de significado amplo, melhor qualificado como análise de

requisitos (uma investigação dos requisitos) ou análise de objetos (uma investigação Definir c

dos objetos do domínio). A

O projeto enfatiza uma solução conceitual que satisfaça os requisitos e não sua

implementação. Uma descrição de um esquema de banco de dados e objetos de soft war é um bom exemplo. Em última instância, projetos podem ser implementados.

Da mesma forma que na análise, o termo projeto é melhor qualificado como projeto

de objetos ou projeto de banco de dados.

A análise e o projeto foram resumidos na fasefaça a coisa certa (análise) efaça cer t a coisa (projeto).

N. de Ri O envolvimento

-

1.4 O Que são Análise e Projeto Orientados a Objetos?

Durante a análise orientada a objetos, o objetivo é encontrar e descrever os objetos

- ou conceitos - no domínio do problema. No caso do sistema de informação de uma biblioteca, por exemplo, alguns dos conceitos incluem Livro, Biblioteca e usuário*.

Durante o projeto orientado a objetos, há uma ênfase na definição dos objetos de software e como eles colaboram para a satisfação dos requisitos. No sistema da biblioteca, por exemplo, um objeto de software Livro pode ter um atributo título e um método obterCapítulo (ver Figura 1.2).

Finalmente, durante a implementação ou programação orientada a objetos, os

objetos de projeto são implementados, como uma classe Livro em Java.

1.5 Um Exemplo

Antes de aprofundar os detalhes da análise de requisitos e da A/POO, esta seção apresenta uma visão geral de uns poucos passos-chave e diagramas, usando um exemplo simples - um jogo de dados no qual um jogador lança dois dados. Se o total for sete, ele vence; caso contrário, perde.

Definir casos de uso

A análise de requisitos pode incluir uma descrição dos processos do domínio relacio1 nados; estes podem ser escritos como casos de uso.

Definir casos Definir modelo Definir diagramas

de uso de domínio de interação

Definir diagramas de classes

de projeto

*N. de R. T Os interessados em um projeto (stakeholders) são todas as pessoas da organização que têm algum tipo de envolvimento direto ou indireto com o sistema, como usuários, gerentes, clientes, patronos e financiadores.

fNAL1SE E r’ROJFIO IJRIEN lADOS A IJBJETOS 1

conceito do domínio]

Livro

lo

visualização de conceito de domínio

1

representação em uma linguagem de programação orientada a objetos

4,

public class Livro

private String título;

public Capitulo obterCapítulo(int) {...}

Figura 1.2 A orientação a objetos enfatiza a representação de objetos.

.

•.

• -

•

44

-

IZANUMLE PADRÕES

Casos de uso não são artefatos orientados a objetos - eles são simplesmente narrativas escritas. Contudo, são uma ferramenta popular para a utilização na análise de requisitos e uma parte importante do PU. Por exemplo, temos uma versão simplificada do caso de uso Jogar um logo de Dados:

Jogar um Jogo de Dados: um jogador pega e lança os dados. Se a soma do valor das faces dos dados totalizar sete, ele vence; caso contrário, perde.

Definir um modelo de domínio

A análise orientada a objetos se preocupa com a criação de uma descrição do domínio, a partir da perspectiva de uma classificação por objetos. Uma decomposição do domínio envolve a identificação dos conceitos, dos atributos e das associações que são considerados de interesse, O resultado pode ser expresso em um modelo de domínio, o qual é ilustrado em um conjunto de diagramas que mostram conceitos ou objetos do domínio.

Definir casos Definir modelo Definir diagramas Definir diagramas

de uso de domínio 1 de interação

Por exemplo, um modelo parcial de domínio é mostrado na Figura 1.3.

Esse modelo ilustra os conceitos de interesse Jogador, Dado e JogoDeDados, com suas associações e atributos.

Note que um modelo de domínio não é uma descrição dos objetos de software; é uma visualização de conceitos no domínio do mundo real.

Jogador Dado

____________________ 1 Lança 2

nome valorDaFace

1 2

Joga

JogoDeDados 1 Inclui

Figura 1.3 Modelo parcial de domínio do jogo de dados.

1

Definir diagramas de interação

ANÁLISE E PRoJE1o ORIENTADOS A OBJETOS 3.

O projeto orientado a objetos se preocupa com a definição de objetos de software e suas colaborações. Uma notação comum para ilustrar essas colaborações é o diagrama de interação. Ele mostra o fluxo de mensagens entre os objetos de software e, assim, a invocação de métodos.

Definir casos Definir modelo Definir diagramaí’ Definir diagramas

de uso de domínio de interação

Por exemplo, assuma que é desejada uma implementação de software do jogo de dados. O diagrama de interação na Figura 1.4 ilustra o passo principal do jogo, por meio do envio de mensagens a instâncias das classes JogoDeDados e Dado.

Observe que, embora no mundo real um jogador lance os dados, no projeto de software o objeto JogoDeDados “lança” os dados (isto é, envia mensagens para objetos Dado). Objetos do projeto de software e programas se inspiram, em parte, em domínios do mundo real, mas eles não são modelos diretos ou simulações do mundo real.

Figura 1.4 Diagrama de interação ilustrando mensagens entre os objetos de sottware.

Definir diagramas de classes de projeto

Além de uma visão dinâmica de objetos colaborativos mostrada nos diagramas de interação, é útil criar uma visão estática das definições de classes com um diagrama de classes de projeto. Este ilustra os atributos e métodos das classes.

1DeDados

L

jJ ado2: Da

Iançar() v 1

vf 2 := obterValorUaFaceO

34 UTILIZANDO UML E PADRÕES

Definir casos Definir modelo Definir diagramas Definir diagramas

de uso de domínio de interação de classes

de projeto

Por exemplo, no jogo de dados, uma inspeção do diagrama de interação leva ao diagrama de classes de projeto parcial mostrado na Figura 1.5. Uma vez que uma mensagem jogar é enviada para um objeto JogoDeDados, a classe JogoDeDados requer um método jogar e a classe Dado requer um método lançar e um método obter ValorDaFace Por

Ao contrário do modelo de domínio, esse diagrama não ilustra conceitos do

mundo real, mostra classes de software.

JogoDeDados Dado

dadol : Dado 1 2 valorDaFace: mI

dado2: Dado - ___________________

obterValorDaFace() : int

jogar() lançar() 1 7

Figura 1.5 Diagramas de classes de projeto parcial.

Resumo

O jogo de dados é um problema simples, apresentado com a intenção de focalizar alguns dos passos e artefatos na análise e projeto orientados a objetos. Visando manter a introdução simples, não foi explicada toda a notação UML ilustrada. Os próximos capítulos explorarão a análise, o projeto e esses artefatos em maiores detalhes.

1.6 AUML

A Linguagem de Modelagem Unificada (UML) é uma linguagem para

especificar, visualizar, construir e documentar os artefatos de sistemas

de software, bem como para modelar negócios e outros sistemas

que não sejam de software [OMGO1J.

A UML emergiu como a notação diagramática padrão para a modelagem orientada a objetos. Ela começou como um esforço conjunto de Grady Booch e Jim Rumbaugh, em 1994, para combinar as notações diagramáticas dos seus dois difundidos e populares métodos - o Booch e OMT (Object Modeling Technique). Posteriormente, se

juntou a eles Ivar Jacobson, o criador do método Objectory, e, como grupo, os três ‘O traba passaram a ser conhecidos como os três amigos. Muitos outros contribuíram para a

N. de 1

ANÁLISE E PROJETO ORIENTADOS A OBJETOS 35

UML, e talvez a contribuição mais notável tenha sido a de Cris Kobryn, um dos líderes do seu contínuo refinamento.

A UML. foi adotada, em 1997, como um padrão pelo OMG (Object Management

Group, uma instituição de criação de padrões para a indústria de software) e continua

a ser refinada em novas versões OMG UML.

Este livro não cobre minuciosamente a UML, que é uma notação enorme (alguns dizem que ela é grande demais1). Ele enfoca os diagramas mais usados, os recursos mais comuns nesses diagramas e a notação básica, que é a que tem menor possibilidade de mudar nas futuras versões da UML.

Por que em alguns capítulos não veremos muito da UML?

Este não é apenas um livro sobre a notação UML, mas sim um livro que explora o panorama da aplicação da UML, padrões e um processo iterativo no contexto do desenvolvimento de software. A UML é principalmente aplicada durante a A/POO, os quais são normalmente precedidos pela análise de requisitos. Portanto, os capítulos iniciais apresentam uma introdução aos tópicos de casos de uso e análise de requisitos, seguidos por capítulos sobre a A/POO, além de mais detalhes da UML.

1.7 Leituras Adicionais

Um resumo popular e de fácil leitura sobre a notação UML é LJML Essencial , de Martin Fowler.

Uma introdução sucinta e popular ao PU (e seu refinamento no Rational Unified Process) é The Rational Unfied Process - An Introduction, de Philippe Kruchten.

Para uma discussão detalhada da notação UML (versão 1.3), vale a pena ler The Unfied Modeling Language Reference Manual e The Unfied Modeling Language tJser Guide, de Booch, Jacobson e Rumbaugh. Observe que esses textos não têm por objetivo o aprendizado de como fazer a modelagem de objetos ou a A/POO - eles são referências para a notação de diagramas da UML.

Para uma descrição da versão em uso da UML, é necessário o documento on-line OMG Unfied Modeling Language Specfication encontrado em www.omg.org. O trabalho de revisão da UML e as versões a serem liberadas podem ser encontrados em www.celigent.com/uml.

Existem muitos livros sobre padrões de software, mas o clássico que inspirou a todos é Padrões de Projeto** de Gamma, Helm, Johnson e Vlissides. Este livro é uma leitura obrigatória para aqueles que estudam o projeto de objetos. Contudo, ele não é um texto introdutório e é melhor lê-lo após sentir-se confortável com os fundamentos do projeto e programação de objetos.

10 trabalho em andamento na UML 2.0 inclui o objetivo de simplificação e redução da notação. Este livro apresenta a UML em seus recursos mais usados, os quais provavelmente sobreviverão a futuras simplificações.

N. de RI. Publicado no Brasil pela Bookman Editora.

N. de RI Publicado no Brasil pela Bookman Editora.

2

Desenvolvimento Iterativo e o

Processo Unificado

Pessoas são mais importantes do que qualquer processo.

Pessoas capazes com um bom processo sempre superarão

pessoas capazes sem um processo, em todas as circunstâncias.

- Grady Booch

OBJETIVOS

• i-ornecer uma motivação para o conteúdo e ordem dos capítulos subseqüentes.

• Definir um processo iterativo e adaptativo.

• Definir conceitos fundamentais do PU.

Introdução

O desenvolvimento iterativo é uma abordagem competente para o desenvolvimento de software e está no cerne de como aA/POO é apresentada neste livro. O PU é um exemplo de processo iterativo para projetos que utilizam A/POO e molda a apresentação deste livro. Conseqüentemente, é importante ler este capítulo para que esses conceitos centrais e sua influência sobre a estrutura deste livro fiquem claros.

Este capítulo resume algumas idéias-chave; ver o Capítulo 37 para uma discussão mais aprofundada do PU e das práticas de um processo iterativo de desenvolvimento.

Informalmente, um processo de desenvolvimento de software descreve uma abordagem para a construção, implantação e, possivelmente, a manutenção de softzvare. O Processo Unificado (PU) [JBR99] sugiu como um processo popular para o desenvolvimento de software visando à construção de sistemas orientados a objetos. O Processo Unificado da Rational, ou RUP (de Rational Unified Process), [KruchtenOOj, um refinamento detalhado do PU, é muito adotado.

3 UTILIZANDO UML E PADRÕES

O PU combina as melhores práticas, tais como um ciclo de vida iterativo e o d senvolvimento orientado pelos riscos, em uma única e bem documentada descriçã Conseqüentemente, é utilizado neste livro como o processo-exemplo dentro do qu serão introduzidos a A/POO.

Este livro começa com uma introdução ao PU por duas razões:

1. O PU é um processo iterativo. O desenvolvimento iterativo é uma prática grande utilidade que influencia a forma deste livro apresentar a A/POO bem c

mo suas melhores práticas.

2. As práticas do PU fornecem uma estrutura-exemplo para mostrar como fazer - como aprender - a A/POO.

Este texto apresenta uma introdução ao PU, e não uma cobertura completa do mesmo. Ele destaca idéias e artefatos comuns, próprias de uma introdução à A/POO e à análise de requisitos.

E se o PU não me interessar?

O PU é usado como um processo-exemplo dentro do qual são exploradas a análi de requisitos e a A/POO, já que é necessário tratar do assunto no contexto de algui processo, e o PU (ou seu refinamento, oRUP) é relativamente bem empregado. Aléi disso, o PU apresenta atividades comuns e práticas adotadas no projeto de desenvo vimento de software. Entretanto, as idéias centrais deste livro - tais como casos de u e padrões de projeto - são independentes de qualquer processo, e aplicáveis a mu tos outros.

2.1 A Idéia mais Importante do PU: Desenvolvimento Iterativo

O PU promove várias práticas, mas uma se destaca das demais: o desenvolvimei to iterativo. Nesta abordagem, o desenvolvimento é organizado em uma série c miniprojetos, de duração fixa (por exemplo, quatro semanas) chamada iterações; produto de cada um é um sistema testado, integrado e executável. Cada iteraç inclui suas próprias atividades de análise de requisitos, projeto, implementação teste.

O ciclo de vida iterativo é baseado em refinamentos e incrementos de um sist ma por meio de múltiplas iterações, com realimentação (feedback) e adaptação cíclic como principais propulsores para convergir para um sistema adequado. O sisteir cresce incrementalmente ao longo do tempo, iteração por iteração, razão pela qu esta abordagem também é conhecida como desenvolvimento iterativo e incremei tal (ver Figura 2.1).

Inicialmente, as idéias de processos iterativos eram conhecidas como desenvo

vimento evolucionário e em espiral [Boehm88, Gi1b88].

VESENVOLVIMEN1O ITERATIVO E O F’ROCESSO UNIFICADO 39

de

o

ao

oe

Requisitos

Projeto

Implementação & Teste & Integração

& Mais Projeto

Requisitos

Projeto

Implementação & Teste & Integração

& Mais Projeto

Integração Final & Teste de Sistema

ó

Realimentação da iteração N leva ao refinamento e adaptação dos requisitos e do projeto na iteração

N+1.

Observe que, neste exemplo, não há uma corrida para codificar, nem um longo e demorado passo de projeto, o qual tenta resolver todos os problemas e detalhes do projeto antes da programação. “Algumas considerações antecipadas” são feitas com relação ao projeto, usando modelagem visual direta e rápida para esboço de diagramas UML. Essas considerações são feitas durante meio dia, ou um dia inteiro, por desenvolvedores que estão executando o trabalho de projeto em duplas.

O resultado de cada iteração é um sistema executável, mas incompleto; ele não está pronto para ser colocado em produção. O sistema pode não estar preparado para instalação e produção senão após muitas iterações, como, por exemplo, 10 ou 15 iterações.

Tempo

Integração Final & Teste de Sistema

e o. ai

de

o-

-e

•se m

olso ai-

4 semanas (por exemplo)0

Iterações são de tamanho

fixo ou limitadas pelo tempo.

Figura 2.1 Desenvolvimento iterativo e incremental.

o

O sistema cresce incrementalmante.

Exemplo

Como exemplo (e não uma receita): em uma iteração de duas semanas no meio de um projeto, talvez a segunda-feira seja gasta, principalmente, na distribuição e no esclarecimento das tarefas e dos requisitos da iteração, enquanto uma pessoa faz a engenharia reversa do código da última iteração para diagramas UML (via uma ferramenta CASE), imprime e exibe diagramas que sejam de interesse. A terça-feira é gasta em quadros brancos, fazendo trabalho de projeto em duplas, desenhando rascunhos de diagramas UML registrados em câmeras digitais e escrevendo pseudocódigo e notas de projeto. Os oito dias restantes são usados para implementação, testes (unitário, de aceitação, usabilidade, etc.), projeto adicional, integração, produção diária, teste de sistema e estabilização do sistema parcial. Outras atividades incluem demonstrações e avaliações para envolvidos no projeto do sistema, além do planejamento para a iteração seguinte.

te-

as

ai

n

- - - . - - - - - -

1

40 UTILIZANDO UML E PADRÕES

A saída de uma iteração não é um protótipo experimental ou descartável, assim

como o desenvolvimento iterativo não é prototipação. A saída é um subconjunto do

sistema final com qualidade final (e não “qualidade de protótipo”).

Embora, em geral, cada iteração contemple novos requisitos e estenda incrementalmente o sistema, uma iteração pode ocasionalmente revisitar o software já existente e melhorá-lo; por exemplo, uma iteração pode enfocar a melhoria do desempenho de um subsistema, em vez de dotá-lo de novas características.

Acolher a mudança: realimentação e adaptação

O subtítulo de um livro que discute o desenvolvimento iterativo é Embrace Change (Acolha a Mudança) [BeckOOj. Esta frase evoca a atitude-chave do desenvolvimento iterativo: em vez de combater a inevitável mudança que ocorre no desenvolvimento de software tentando (geralmente sem sucesso) especificá-lo completa e corretamente e “fazer com que todos assinem embaixo” um conjunto de requisitos e projetos congelados antes da implementação, o desenvolvimento iterativo é baseado em uma atitude de aceitar a mudança e a adaptação como fatores inevitáveis e, de fato, essenciais.

Isso não significa que o desenvolvimento iterativo e o PU encorajem um processo exageradamente baseado nas características do sistema, descontrolado e reativo. Os capítulos subseqüentes mostram como o PU equilibra a necessidade de chegar a um acordo e estabilizar um conjunto de requisitos com a realidade de mudança de requisitos, à medida que os interessados no projeto do sistema esclarecem sua visão ou ocorrem mudanças no mercado de atuação da organização.

Cada iteração exige a escolha de um pequeno subconjunto dos requisitos, além da sua rápida projeção, implementação e teste. Nas iterações iniciais, a escolha de requisitos e o projeto podem não ser exatamente o que é desejado. No entanto, o ato de executar rapidamente um pequeno passo antes de finalizar todos os requisitos, ou antes que o projeto inteiro seja especulativamente definido, leva a uma realimentação rápida - obtida a partir de usuários, desenvolvedores e testes (como testes de carga e de facilidade de uso).

Essa realimentação precoce vale ouro; em vez de especular sobre os requisitos ou projeto corretos, a realimentação a partir da construção e teste realísticos fornece uma percepção prática crucial, bem como uma oportunidade para modificar ou adaptar a compreensão dos requisitos ou do projeto. Os usuários finais podem ver um sistema parcial e dizer: “sim, foi isso que eu pedi, mas agora que o experimentei, o que eu realmente quero é algo ligeiramente diferente”. Esse processo de “sim... mas” não é um sinal de erro; na verdade, ciclos estruturados precoces e freqüentes de “sim... mas” são um modo hábil de progredir e descobrir o que é de real valor para os interessados no sistema. No entanto, como já mencionado, isto não é um endosso do desenvolvimento caótico e reativo, no qual os desenvolvedores continuamente mudam de direção - é possível um meio-termo.

Além de esclarecer requisitos, atividades como teste de carga provarão se o projeto e a implementação parciais estão no caminho certo, ou, se na iteração seguinte, será necessária uma mudança na arquitetura principal do sistema. E melhor resolver e por à prova as decisões arriscadas e fundamentais de projeto precocemente do que tardiamente - e o desenvolvimento iterativo fornece o mecanismo para isso.

1 Ou, mais provavelmente, “você não compreendeu o que eu queria!”

- -

Iterações iniciais estão longe do “verdadeiro

caminho” do sistema. Por meio de realimentação

e adaptação, o sistema converge para

os requisitos e o projeto mais adequados.

TI-

e

e,

uma iteração de projeto,

implementação, integração e teste

Figura 2.2 A realimentação e a adaptação iterativas levam ao sistema desejado. A instabilidade dos requisitos e do projeto diminuem com o tempo.

Benefícios do desenvolvimento iterativo

Os benefícios do desenvolvimento iterativo incluem:

• mitigação precoce, em vez de tardia, de altos riscos (técnicos, requisitos, objetivos,

usabilidade, etc.);

• progresso visível desde o início;

OU a realimentação, envolvimento do usuário e adaptação imediatos, levando a um

ver sistema refinado que atenda, de forma mais adequada, às reais necessidades dos

fl interessados no projeto;

de . .

fre- a a complexidade e administrada; a equipe nao e sobrecarregada pela paralisia da

re- análise” ou por passos muito longos e complexos;

ão a o aprendizado obtido em uma iteração pode ser metodicamente usado para me-

es lhorar o próprio processo de desenvolvimento, iteração por iteração.

O PU (e desenvolvedores com experiência em desenvolvimento iterativo) recomenda uma duração, para uma iteração, entre duas e seis semanas. Usar pequenos passos, obter realimentação rápida e fazer adaptações são idéias centrais no desenvolvimento iterativo; iterações longas subvertem a motivação central para o desenvolvimento iterativo e aumentam o risco do projeto. Entretanto, com muito menos tempo do que duas semanas, é difícil completar um trabalho suficiente para obtenção de

DESENVOLVIMENrO ITERATIVO E O F’ROCESSO UNIFICADO 4I

Conseqüentemente, o trabalho progride por meio de uma série de ciclos estruturados em construção-realimentação-adaptação. Não é raro que nas iterações iniciais o desvio do “caminho verdadeiro” do sistema (em termos dos seus requisitos e projeto) seja maior do que nas últimas iterações. Com o tempo, o sistema converge para esse caminho, como ilustrado na Figura 2.2.

/

Nas últimas iterações, é rara uma mudança sigificativa de requisitos, mas ela pode dar à organização uma vantagem competitiva nos negócios.

Tamanho e limitação de tempo da iteração

42 UTILIZANDO LJML E I-’ADRÕES

produtos e realimentação significativos; porém, quando se tem muito mais do que 2.3 seis ou oito semanas, a complexidade torna-se, em geral, grande e de difícil controle, e a realimentação atrasa. Uma iteração muito longa perde o objetivo do desenvolvimento iterativo. Um período curto é melhor.

Uma idéia-chave é que as iterações têm limites temporais (ocupam “janelas de tempo” de duração fixa no cronograma). Por exemplo, se é decidido que a iteração seguinte deve ter quatro semanas de duração, o sistema parcial devem estar integrado, testado e estabilizado dentro da data programada -. não é recomendável o não cumprimento dos prazos. Se acharmos que será difícil cumprir o prazo final, é recomendável remover tarefas ou requisitos da iteração e incluí-las em uma iteração futura, em vez do não cumprimento do prazo. O Capítulo 37 resume as razões para limitar o tempo.

Equipes grandes (com centenas de desenvolvedores) podem exigir iterações mais longas que seis semanas para compensar o aumento da sobrecarga de coordenação e comunicação; mas não se recomenda mais do que três a seis meses. Por exemplo, a substituição bem-sucedida, nos anos 90, do sistema de controle de tráfego aéreo canadense foi desenvolvida com um ciclo de vida iterativo e outras práticas adotadas no PU. Ela envolveu 150 programadores e foi organizada em iterações de seis meses.2 Mas note que mesmo no caso de uma iteração de projeto com um total de seis meses, a equipe de um subsistema de 10 ou 20 desenvolvedores pode dividir o seu trabalho em uma série de seis iterações de um mês.

Uma iteração de seis meses é a exceção, e não a regra, para equipes grandes.

Reiterando: o PU recomenda que normalmente uma iteração fique entre duas e seis semanas de duração.

2.2 Conceitos e Melhores Práticas Adicionais do PU

A idéia central a ser apreciada e praticada no PU é a de usar iterações curtas, com duração fixa, em um processo de desenvolvimento iterativo adaptativo.

Outra idéia implícita, mas central para o PU, é o uso de tecnologias orientadas

a objetos, incluindo A/POO e programação orientada a objetos.

Algumas das melhores práticas e conceitos-chave adicionais do PU incluem:

• enfrentar os problemas que envolvem altos riscos e alto valor já nas iterações miciais;

• envolver continuamente os usuários na avaliação, na realimentação e nos requisitos;

• construir uma arquitetura central coesa nas iterações iniciais;

• verificar continuamente a qualidade; fazer testes logo de início, com freqüência e em situações realísticas;

• aplicar casos de uso;

• modelar visualmente o software (com a UML);

• gerenciar requisitos cuidadosamente;

• usar solicitações de mudança e praticar a gerência de configuração.

Ver o Capítulo 37 para uma descrição mais detalhada destas práticas.

2 Philippe Kruchten, que também liderou o desenvolvimento do RUP, atuou como arquiteto-chefe no projeto.

LIESENVOLVIMENIO ITERATIVO E O VROCESSO IJNIFJCADO ‘13

2.3 As Fases e os Termos Relativos ao Cronograma do PU

Um projeto PU organiza o trabalho e as iterações em quatro fases principais:

1. Concepção - visão aproximada, casos de negócio, escopo e estimativas vagas.

2. Elaboração - visão refinada, implementação iterativa da arquitetura central, resolução dos altos riscos, identificação da maioria dos requisitos e do escopo e estimativas mais realistas.

3. Construção - implementação iterativa dos elementos restantes de menor risco e mais fáceis e preparação para a implantação.

4. Transição - testes beta e implantação.

Essas fases são mais bem definidas nos capítulos subseqüentes.

Este não é o antigo ciclo de vida em “cascata” ou seqüencial, no qual primeiro

temos que definir todos os requisitos para, então, fazer todo ou a maioria do projeto.

A concepção não é uma fase de requisitos; na verdade, é uma espécie de fase de

estudo de viabilidade, na qual se executa um volume suficiente de investigação para fundamentar a decisão de continuar ou parar.

Da mesma forma, a elaboração não é a fase de requisitos ou projeto; é uma fase

na qual a arquitetura central é iterativamente implementada e os problemas de alto

risco são mitigados.

A Figura 2.3 ilustra termos comuns relativos ao cronograma de um PU. Note

que um ciclo de desenvolvimento (o qual termina com a entrega de uma versão do

sistema para ser posta em produção) é composto de muitas iterações.

marco de referência

Um ponto de término de uma iteração no qual ocorre alguma decisão ou avaliação significativa.

Um subconjunto estável executável do produto final. O fim de cada iteração é uma entrega secundária.

É a diferença (deIta) entre as entregas de duas iterações subseqüentes.

entrega final para a produção

Nesse ponto, o sistema é entregue para uso na produção.

ciclo de desenvolvimento

t t

versão incremento

Figura 2.3 Termos relativos ao cronograma de um PU.

44 UTILIZANDO UML E 1-’ADROES

2.4 As Disciplinas do PU (anteriormente Fluxos de Trabalho - Workflows)

Em 2001, o antigo termo “fluxo de trabalho” do PU (UP workjlow) foi substituído pelo novo termo “disciplina”, de modo a ficar em harmonia com um esforço internacional de padronização conhecido como OMG SPEM; muitos continuam a usar o antigo termo, embora isto não seja estritamente correto. “Fluxo de trabalho” assumiu um significado novo, mas ligeiramente diferente dentro do PU: em um projeto particular, ele significa uma particular seqüência de atividades (talvez entre disciplinas) - um fluxo de trabalho.

4i adaptado do produto RUP.

No

taç nal am

O PU descreve atividades de trabalho, como redigir um caso de uso, dentro de disciplinas (originalmente chamadas fluxos de trabalho).3 Uma disciplina é um conjunto de atividades (e artefatos relacionados) em uma área relacionada com um assunto, como as atividades dentro da análise de requisitos. No PU, um artefato é o termo usado para qualquer produto do trabalho: código, gráficos para a Web, esquemas de bancos de dados, documentos em texto, diagramas, modelos e assim por diante.

Existem várias disciplinas no PU; este livro focaliza alguns artefatos nas seguintes:

• Modelagem de Negócio - Quando do desenvolvimento de uma imica aplicação, esta inclui a modelagem de objetos do domínio. Quando estamos envolvidos com a

análise de negócios ou reengenharia de processo de negócio em larga escala, inclui a

modelagem dinâmica dos processos de negócio ao longo de toda a empresa.

• Requisitos - Análise de requisitos para uma aplicação, como escrever casos de uso e identificar requisitos não funcionais.

• Projeto - Todos os aspectos relacionados com o projeto, incluindo a arquitetura geral, objetos, bancos de dados, redes e outros tópicos correlatos.

Na Figura 2.4, é mostrada uma lista das disciplinas do PU.

Disciplinas

Coi

ou na

ênf

ess bili

ilu

tão

na

de

Uma iteração de quatro semanas (por exemplo) Um miniprojeto que inclui trabalho na maioria das disciplinas, terminando com um executável estável

taç an

Amostras de Disciplinas do PU

(Modelagem de Negócio

Foco

deste -K Requisitos livro

Projeto

Implementação

Teste

Implantação

Gestão de

Configuração & Mudanças Gestão de Projeto

Ambiente

Amostra Disciplinas dc

Modelagen

Neg

Requi

Prc

Implementa

Fig

Figura 2.4 Disciplinas do PU.

Estrutura

Em Re

-

UESENVOLVIMENTO ITERATIVO E O F’ROCESSO UNIFICADO 4S

No PU, Implementação significa programação e construção do sistema, não implantação. A disciplina Ambiente se refere ao estabelecimento do instrumental e à personalização do processo para um projeto - ou seja, a preparação das ferramentas e o ambiente do processo.

DiscIplinas e fases

Como ilustrado na Figura 2.4, durante uma iteração o trabalho prossegue na maioria

ou em todas as disciplinas. Contudo, o esforço relativo no decorrer destas discipli e nas muda ao longo do tempo. As iterações iniciais naturalmente tendem a dar uma

ênfase maior aos requisitos e ao projeto, enquanto que as últimas disciplinas dão a

esses itens uma ênfase menor, à medida que os requisitos e o projeto central se esta-

a bilizam por meio de um processo de realimentação e adaptação.

Relacionando isto com as fases do PU (concepção, elaboração, etc.), a Figura 2.5

ilustra a mudança do esforço relativo em relação às fases; note que isto é uma sugestão e não deve ser tomado “ao pé da letra” como uma recomendação. Por exemplo, e na elaboração, as iterações tendem a ter uma carga de análise de requisitos e trabalho

de projeto relativamente altos, embora também tenham algum esforço de implemena tação. Durante a construção, a ênfase é mais pesada na implementação e mais leve na

análise de requisitos.

-

O esforço relativo

las disciplinas muda

ao longo das fases.

Este exemplo é uma sugestão e não deve ser tomado ao pé da letra.

elaboração construção ]

Amostras de

Disciplinas do PU

Modelagem de

Negócio

Requisitos

Projeto

Implementação

Figura 2.5 Disciplinas e fases.

Estrutura do livro e as fases e disciplinas do PU

Em relação a fases e disciplinas, qual é o foco do estudo de caso?

Resposta:

O estudo de caso enfatiza as fases de concepção e elaboração. Ele enfoca alguns artefatos nas disciplinas de Modelagem de Negócio, Requisitos e Projeto, já que é aqui que a análise de requisitos, a A/POO, os padrões e a UML são principalmente aplicados.

-

-

4

D IJ IILILANUO LJIVIL 1 £‘ADRO1S

Os capítulos iniciais introduzem atividades de concepção; os capítulos seguintes ex- Pa ploram várias iterações da elaboração. A lista a seguir e a Figura 2.6 descrevem a organização em relação às fases do PU.

1. Os capítulos relativos à fase de concepção apresentam os fundamentos da análise de requisitos.

2. A iteração 1 introduz os fundamentos da A/POO e como atribuir responsabilidades a objetos.

3. A iteração 2 enfoca o projeto de objetos, especialmente a introdução de alguns “padrões de projeto” altamente utilizados.

4. A iteração 3 introduz diversos assuntos, tais como a análise de arquitetura e o projeto deframeworks.

O Livro

Tópicos

iais

eOntaj ooendozradde ____________

Figura 2.6 A organização do livro está relacionada às fases e iterações do PU.

2.5 Personalização do Processo e a Pasta

de Desenvolvimento

Artefatos opcionais

Algumas das práticas e dos princípios do PU são invariantes, como o desenvolvimento iterativo e orientado ao controle dos riscos, bem como a verificação contínua da qualidade.

Entretanto, um aspecto-chave do PU é que todas as atividades e os artefatos (modelos, diagramas, documentos, etc.) são opcionais - bem, talvez não o código! 2 O conjunto de possíveis artefatos descritos no PU deve ser visto como um conjunto de medicamentos em uma farmácia. Da mesma forma que alguém não toma medicamentos de forma indiscriminada, mas ajusta a escolha de acordo com os sintomas, em um projeto PU a equipe deve selecionar um pequeno subconjunto de artefatos que atenda a seus problemas e necessidades. Em geral, a equipe deve se concentrar em um pequeno conjunto de artefatos que demonstrem possuir um alto valor prático.

\sãoGeraI1

A escolha de artefatos do PU para um projeto pode ser escrita em um curto documento denominado Pasta de Desenvolvimento (um artefato na disciplina Ambiente). Por exemplo, a Tabela 2.1 poderia ser a Pasta de Desenvolvimento que descreve os artefatos para o “Projeto ProxGer”, o estudo de caso explorado neste livro.

Os próximos capítulos descrevem a concepção de alguns destes artefatos, incluindo o Modelo de Domínio, o Modelo de Casos de Uso e o Modelo de Projeto.

Os exemplos de artefatos apresentados neste estudo de caso não são, de forma alguma, suficientes, ou adequados, para todos os projetos. Por exemplo, em um sistema de controle de máquinas, pode ser benéfico fazer muitos diagramas de estado. Um sistema de comércio eletrônico baseado na Web pode exigir um foco em protótipos da interface com o usuário. O desenvolvimento de um projeto em um campo totalmente novo tem necessidade de artefatos de projeto bem diferentes daqueles de um projeto de integração de sistemas.

Tabela 2.1 Amostra dos artefatos de uma Pasta de Desenvolvimento do PU

- iniciar; r - refinar

2.6 OPU Ágil

Os metodologistas se referem aos processos como pesados versus leves e preditivos versus adaptativos. Um processo pesado é um termo pejorativo que sugere um processo com as seguintes características [FowlerOO]:

• muitos artefatos criados em uma atmosfera burocrática;

;ç:4

4

Pasta de desenvolvimento

DESENVOLVIMENTO ITERATIVO E O PROCESSO UNIFIcADO 47

r

• rigidez e controle;

Disciplina Artefato lteração- Concepção Cl Elaboração E1...En Construção Transição CtI...Ctn TI...T2 r r r r r

Modelagem de Negócio Modelo de Domínio i

IRequisitos Modelo de CasosdeUso 1 r

Visão 1 r

Especificações Suplementares Glossário i i r r

Projeto Modelo de Projeto i

Documento de Ar- quitetura de Software i

Modelo de Dados i

Implementação Modelo de Implementação i

Gestão de Projeto Plano de Desenvol viment de Software i r

Teste Modelo de Teste i

Ambiente Pasta de Desenvolvimento i r

4 UTILIZANDO UIVIL E 1AUROES

• planejamento detalhado, elaborado e de longo prazo; Um esi

• preditivo, em vez de adaptativo, de softi

rativo,

Um processo preditivo é um processo que tenta planejar e prever as atividades mackO

e alocações de recursos (tais como pessoas) em detalhes, ao longo de um intervalo de

tempo relativamente longo, tal como a maior parte do projeto. Processos preditivos desem

normalmente têm um ciclo de vida “em cascata” ou seqüencial - em primeiro lugar

definindo todos os requisitos; em segundo, definindo um projeto detalhado; e, em

terceiro, fazendo a implementação. Em contraste com isso, um processo adaptativo 2.8 VocÊ

aceita a mudança como um fator inevitável e positivo, encorajando uma adaptação

flexível; estes processos geralmente têm um ciclo de vida iterativo. Um processo ágil Aqui s

implica em um processo leve e adaptativo, com respostas rápidas às necessidades de que s1

mudanças. tendid

Os autores do PU não tinham a intenção de que seu processo fosse pesado ou • Vo

preditivo, embora o grande conjunto de atividades e artefatos opcionais tenha, com- ple

preensivelmente, levado alguns a ficarem com esta impressão. Ao contrário, ele foi • V

concebido para ser aplicado no espírito de um processo ágil - PU ágil. A seguir, co m

fazer isso:

• Prefira um pequeno conjunto de atividades e artefatos PU. Alguns projetos se be- • Vo

neficiarão mais do que outros, mas, como regra geral, procure mantê-los simples. E’

• Vo

• Uma vez que o PU é um processo iterativo, requisitos e projetos não são comple- ter

tados antes da implementação. Eles surgem de forma adaptativa ao longo de uma pr

série de iterações, com base na realimentação obtida nas iterações anteriores. •

• Não há um plano detalhado para todo um projeto. Há um plano de alto nível

(chamado Plano de Fases) que estima a data de término do projeto e outros mar- • Vo

cos de referência principais, mas ele não detalha os passos de granularidade fina qu

para se atingir tais marcos. Um plano detalhado (chamado de Plano de Iteração) • Vo

somente planeja a iteração a ser feita em seguida. O planejamento detalhado é fei- de

to de forma adaptativa, de iteração para iteração. Veja no Capítulo 36 alguns co- r

mentários sobre o planejamento iterativo de projetos e as justificativas para ado çã

dessa abordagem. 1 Vo

O estudo de caso enfatiza um número relativamente pequeno de artefatos, além do

desenvolvimento iterativo, dentro do espírito de um PU ágil. rei

1 Vc

2.7 O Ciclo de Vida Seqüencia! “em Cascata” m

Contrastando com o ciclo de vida iterativo do PU, uma antiga alternativa é o ciclo de u Vc

vida seqüencial, linear ou “em cascata” [Royce7O]. Na sua forma comum de utiliza- fa

ção, ele definia passos similares aos seguintes:

1. Esclarecer, registrar e comprometer-se com um conjunto de requisitos completo e

fixo.

2. Projetar um sistema baseado nesses requisitos. além de rea1iment

despachar múltiph

3. Implementar o sistema, baseado no projeto. desses quatro fator

DESENVOLWMENEIO ITERAuVo E O PROCESSO UNIFICADO 49

Um estudo de dois anos relatado na Sloan Mana gement Review do MIT sobre projetos de software bem-sucedidos identificou quatro fatores comuns; o desenvolvimento iterativo, e não o processo em cascata, estava em primeiro lugar na lista [MacCormackol]. 5

Uma breve descrição de seus problemas e de como eles são diminuídos pelo

desenvolvimento iterativo é apresentada no Capítulo 37.

2.8 Você Sabe Que Não Compreendeu o PU Quando...

Aqui são apresentados alguns sinais que indicam quando você não compreendeu o que significa adotar o PU e o desenvolvimento iterativo segundo o espírito ágil pretendido pelo PU.

• Você pensa que concepção = requisitos, elaboração = projeto e construção = implementação (isto é, sobrepõe um ciclo de vida em cascata no PU).

• Você pensa que a finalidade da elaboração é definir completa e cuidadosamente os modelos, os quais são traduzidos em código durante a construção.

• Você tenta definir a maior parte dos requisitos antes de começar o projeto ou a implementação.

• Você tenta definir a maior parte do projeto antes da começar a implementação; tenta defini-lo completamente e se comprometer com uma arquitetura antes da

programação e de testes iterativos.

• Um “longo tempo” é gasto fazendo um trabalho de análise de requisitos ou de projeto antes que a programação comece.

• Você acredita que a duração da iteração adequada é de quatro meses, em vez de quatro semanas (exceção feita a projetos com centenas de desenvolvedores).

• Você pensa que as atividades de diagramação UML e projeto são um tempo para definir completa e precisamente projetos e modelos com grande detalhe, e vê a

programação como uma tradução simples e mecânica daqueles para código.

• Você pensa que adotar o PU significa fazer muitas das possíveis atividades e criar muitos documentos, ficando com a opinião, com relação a suas experiências com o PU, que este é um processo formal, meticuloso demais, com muitos passos a serem seguidos.

• Você tenta planejar um projeto em detalhes do começo ao fim; tenta especulativa- mente prever todas as iterações e o que deveria acontecer em cada uma.

• Você quer ter planos e estimativas confiáveis para os projetos antes de terminar a fase de elaboração.

Os outros eram: 2) pelo menos uma incorporação diária de um código novo na construção de um sistema completo, além de realimentação rápida sobre as mudanças no projeto (via testes); 3) uma equipe com experiência em liberar e despachar múltiplos produtos; e 4) um foco precoce na construção e comprovação de uma arquitetura coesiva. Três, desses quatro fatores, são práticas explícitas do PU.

50 UTILIZANDO UML E PADRÕES

2.9 Leituras Adicionais

Uma introdução de fácil leitura ao PU e seu refinamento, o RUP, é The Rational Unified Process - An Introduction, de autoria de Philippe Kruchten, arquiteto-chefe do

RUP.

Uma descrição do PU original pode ser encontrada em Unfied Software Development Process, de autoria de Jacobson, Booch e Rumbaugh. Ela vale a pena ser estudada, mas recomendamos antes a leitura da introdução de Kruchten, já que é menor e mais sucinta, e o RUP atualiza e refina o PU original.

A Rational Software vende o produto da documentação on-line do RUP baseado em Web, o qual fornece um conjunto de textos abrangentes sobre os artefatos e as atividades do RUP, bem como gabaritos para a maioria dos artefatos. Para uma breve discussão, veja o Capítulo 37. Uma organização pode executar um projeto PU usando apenas consultores e livros como recursos para o aprendizado, mas outras organizações acham o produto RUP útil como um recurso para auxiliar o aprendizado e a utilização do processo.

As atividades do PU são também genericamente descritas em uma série de livros editados por Ambler e Constantine (por exemplo, The Unfied Process: Elaboration Phase [AmblerOO]). Estes livros contêm reimpressões de artigos publicados ao longo dos anos na revista Software Development, categorizados por sua respectiva fase e atividade em termos da nomenclatura definida pelo PU. Note que os artigos não foram originalmente escritos para PU, embora contenham muitos conselhos e orientações úteis. Perceba um pequeno erro nessa série: eles descrevem a fase de elaboração do PU como uma fase na qual são criados protótipos descartáveis, dessa forma reduzindo a necessidade de atenção e cuidado na programação ou projeto. Isto não é exato; durante a elaboração são criados (embora de forma parcial) projetos e códigos de qualidade final. Ambler reconhece essa imprecisão e pode corrigi-la em uma edição subseqüente. 6

Para saber mais sobre outros métodos ágeis, recomendamos a série de livros Extreme Programming (XP) [BeckOO, BFOO, JAH0O], tal como Ext reme Programming Explained. Algumas práticas da XP são mencionadas nos capítulos posteriores. A maior parte das práticas da XP (como programação com “teste a priori” - test-first programming - e desenvolvimento iterativo) é compatível - ou idêntica - com as práticas do PU, sendo encorajada sua adoção em um projeto PU. Note que a XP não inventou (e nem alegou tê-lo feito) o desenvolvimento iterativo e adaptativo em janelas de tempo curtas, prática utilizada no PU e em outros métodos iterativos há anos. Diferenças de interesse - esta não é uma lista completa - entre o PU e a XP são: 1) o PU recomenda escrever os casos de uso incrementalmente e um documento de requisitos não funcionais (a XP não); e, 2) o PU recomenda mais tempo para a diagramação visual do projeto (como meio dia ou um dia inteiro) próximo do início de uma iteração, antes da programação principal. Os líderes da XP recomendam muito pouco, algo como 30 minutos.

Highsmith fornece uma justificativa sobre o valor do desenvolvimento adaptativo em Adaptive Software Development [Highsmithoo].

6Ambler, comunicação particular.

do

‘piaas

rePU

as

go

ti-

do

Introdução

de -

ão Este capitulo descreve o estudo de caso usado neste livro. Se voce ja compreende o

domínio do problema, este capítulo pode ser pulado. De fato, este problema foi esco lhid porque ele é bem conhecido, mas apresenta dificuldades interessantes de projeto e arquitetura, permitindo, desta forma, que nos concentremos em como fazer a

análise e o projeto.

3.1 O Sistema PDV ProxGer

e- Nosso caso é a próxima geração do Sistema de Pontos-de-Venda (PDV ProxGer).

s. Neste domínio de problema aparentemente simples, veremos que existem dificuldao des muito interessantes de requisitos e de projeto a serem vencidas. Além disso, é um

i- problema realista; a maioria das organizações, de fato, desenvolvem sistemas PDV

a- usando tecnologias de objetos.

na Um sistema PDV é uma aplicação computadori zad

usada (em parte) para registrar vendas e cuidar

de pagamentos (muito utilizado por lojas de varejo).

Inclui componentes de hardware, como um computa do

e um leitor de código de barras, e um software pa r

rodar o sistema. Tem interfaces com várias aplica çõe

de serviço, como uma aplicação de cálculo de im posto

e uma aplicação de controle de estoque. Estes

sistemas devem ser relativamente tolerantes a falhas;

1

Estudo de Caso:

o Sistema PDV ProxGer

Poucas coisas são mais difíceis de encontrar do que um bom exemplo.

3

- Mark Twain

52 UTILIZANDO UML E PADRÕES

ou seja, mesmo se os serviços remotos estiverem temporariamente não disponíveis (como o sistema de controle de estoque), eles devem ser capazes de capturar as vendas e tratar pelo menos os pagamentos em dinheiro (de modo que o negócio não seja muito afetado).

Um sistema PDV deve dar suporte de forma incremental a múltiplos e variados terminais e interfaces no lado do cliente. Estes incluem um terminal fino baseado em navegador da Web, um computador pessoal comum com uma interface de usuário gráfica, como Java Swing, entrada de informações por telas sensíveis ao toque, PDAs sem fio, etc.

Além disso, vamos criar um sistema PDV comercial que venderemos a diferentes clientes com necessidades diferentes em termos de processamento de regras de negócios. Cada cliente desejará um conjunto único de lógica de negócios para ser executado em pontos previsíveis no cenário de utilização do sistema, como quando uma nova venda é iniciada ou quando uma nova linha é acrescentada. Portanto, necessitaremos de um mecanismo que forneça esta capacidade de flexibilidade e personalização.

Usando uma estratégia de desenvolvimento iterativo, executaremos a análise

de requisitos, a análise orientada a objetos, o projeto e a implementação.

3.2 Arquitetura em Camadas e Ênfase do Estudo de Caso

Um típico sistema de informação orientado a objetos é projetado com uma arquitetura de várias camadas ou subsistemas (ver Figura 3.1). A lista a seguir não é completa, mas serve como exemplo:

• Interface do usuário - interface gráfica; janelas.

• Lógica da aplicação e objetos do domínio - objetos de software representando conceitos do domínio (por exemplo, uma classe de software denominada Venda)

que satisfazem os requisitos da aplicação.

• Serviços técnicos - objetos e subsistemas de uso geral que fornecem serviços técnicos de apoio, como interfaces com bancos de dados ou registro de erros. Esses serviços são usualmente independentes da aplicação e reutilizáveis por vários sistemas.

A A/POO é muito importante para a modelagem da lógica da aplicação e das

camadas de serviço.

O estudo de caso ProxGer destaca, principalmente, os objetos do domínio do problema, alocando responsabilidades aos mesmos para satisfazer os requisitos da aplicação. O projeto orientado a objetos é também aplicado para criar um subsistema de serviço técnico para fazer a interface com um banco de dados.

Nesta abordagem de projeto, a camada da TU (Interface do Usuário) tem uma respon- sabilidade pequena; dizemos que ela é fina ou leve (thin). As janelas não contêm código que executa lógica ou processamento da aplicação. Ao contrário, as solicitações de tarefas são repassadas para outras camadas.

52 IJTTUZANDO LJML E FADRÕES

ou seja, mesmo se os serviços remotos estiverem temporariamente não disponíveis (como o sistema de controle de estoque), eles devem ser capazes de capturar as vendas e tratar pelo menos os pagamentos em dinheiro (de modo que o negócio não seja muito afetado).

Um sistema PDV deve dar suporte de forma incremental a múltiplos e variados terminais e interfaces no lado do cliente. Estes incluem um terminal fino baseado em navegador da Web, um computador pessoal comum com uma interface de usuário gráfica, como Java Swing, entrada de informações por telas sensíveis ao toque, PDAs sem fio, etc.

Além disso, vamos criar um sistema PDV comercial que venderemos a diferentes clientes com necessidades diferentes em termos de processamento de regras de negócios. Cada cliente desejará um conjunto único de lógica de negócios para ser executado em pontos previsíveis no cenário de utilização do sistema, como quando uma nova venda é iniciada ou quando uma nova linha é acrescentada. Portanto, necessitaremos de um mecanismo que forneça esta capacidade de flexibilidade e personalização.

Usando uma estratégia de desenvolvimento iterativo, executaremos a análise

de requisitos, a análise orientada a objetos, o projeto e a implementação.

3.2 Arquitetura em Camadas e Ênfase do Estudo de Caso

Um típico sistema de informação orientado a objetos é projetado com uma arquitetura de várias camadas ou subsistemas (ver Figura 3.1). A lista a seguir não é completa, mas serve como exemplo:

• Interface do usuário - interface gráfica; janelas.

• Lógica da aplicação e objetos do domínio - objetos de software representando conceitos do domínio (por exemplo, uma classe de software denominada Venda)

que satisfazem os requisitos da aplicação.

• Serviços técnicos - objetos e subsistemas de uso geral que fornecem serviços técnicos de apoio, como interfaces com bancos de dados ou registro de erros. Esses serviços são usualmente independentes da aplicação e reutilizáveis por vários sistemas.

A A/POO é muito importante para a modelagem da lógica da aplicação e das

camadas de serviço.

O estudo de caso ProxGer destaca, principalmente, os objetos do domínio do problema, alocando responsabilidades aos mesmos para satisfazer os requisitos da aplicação, O projeto orientado a objetos é também aplicado para criar um subsistema de serviço técnico para fazer a interface com um banco de dados.

Nesta abordagem de projeto, a camada da TU (Interface do Usuário) tem uma responsabilidade pequena; dizemos que ela é fina ou leve (thin). As janelas não contêm código que executa lógica ou processamento da aplicação. Ao contrário, as solicitações de tarefas são repassadas para outras camadas.

EsTuDo DE CASO: O SISTEMA PDV PR0xGER 53

IU!JJf\JL f55f

Item 1D

Quantidade foco menor

Interface

explora como fazer

rEntrar item a conexão com

outras camadas

foco primário do

camada de logica “ estudo de caso

da aplicação 1 Venda Pagamento

e objetos - explora como

do domínio ._-- projetar objetos

foco

___________________ ______________________ secundário

camada de

serviços técnicos L Registro FachadaPersistente explora como

projetar objetos

Figura 3.1 Exemplo de camadas e objetos em um sistema orientado a objetos e o foco do

estudo de caso.

3.3 A Estratégia do Livro: Desenvolvimento e

Aprendizado Iterativos

Este livro segue uma estratégia de desenvolvimento iterativo. A A/POO é aplicada ao sistema PDV ProxGer em múltiplas iterações; a primeira trata de algumas funções centrais. As iterações posteriores expandem a funcionalidade do sistema (ver Figura 3.2). Em conjunto com o desenvolvimento iterativo, a apresentação dos tópicos de análise e projeto e a notação UML, os padrões são introduzidos iterativa e incrementalmente. Na primeira iteração, é apresentado um conjunto central de tópicos da análise, de projeto e da notação UML. A segunda iteração introduz novas idéias, notações UML e novos padrões. E, assim, de modo análogo, a terceira iteração.

analise e projeto Introduz habilidades

relacionados com adicionais de análise

a iteração 1. e de projeto. De modo análogo

Figura 3.2 A trajetória de aprendizado segue as iterações.