Engenharia De Software
vezes tão pouco compreendido em sua totalidade
Padrões De Objetos De Sistemas De Informa-
ção
Em engenharia de software, um padrão de proje-
to ou padrão de desenho (do inglês design pat-
tern) é uma solução geral reutilizável para um
problema que ocorre com frequência dentro de
um determinado contexto no projeto de software.
Um padrão de projeto não é um projeto finalizado
que pode ser diretamente transformado em códi-
go fonte ou de máquina, ele é uma descrição ou
modelo (template) de como resolver um problema
que pode ser usado em muitas situações diferen-
tes.
Padrões são melhores práticas formalizadas que
o programador pode usar para resolver proble-
mas comuns quando projetar uma aplicação ou
sistema. Padrões de projeto orientados a obje-
to normalmente mostram relacionamentos e inte-
rações entre classes ou objetos, sem especificar
as classes ou objetos da aplicação final que estão
envolvidas. Padrões que implicam orientação a
objetos ou estado mutável mais geral, não são
tão aplicáveis em linguagens de programação
funcional.
Atualmente não se concebe um processo de de-
senvolvimento de software sério sem a utilização
da orientação a objetos, pois esta permite agregar
qualidades importantes aos sistemas desenvolvi-
dos sob seus paradigmas, como a extensibilidade
e a reusabilidade.
Mas somente por estar utilizando-a, não é garan-
tia de se obter essas qualidades. Para criar as
melhores soluções, é preciso seguir um processo
detalhado para obter uma análise dos requisitos,
funcionais ou não funcionais, e desenvolver um
projeto que os satisfaça e que possibilite subme-
tê-los a teste, para constatar eventuais falhas,
além do mais se deseja que o projeto tenha uma
arquitetura flexível para acomodar futuros pro-
blemas e requisitos sem a necessidade da reali-
zação do re-projeto.
Analisando o cotidiano do desenvolvimento de
software é possível identificar que a procura por
uma solução a um problema específico possui
características idênticas, senão igual a encontra-
da em um projeto anteriormente desenvolvido,
mas que devido à deficiência do processo, a so-
lução e o problema não fora documentado e às
impossibilitando o reaproveitamento das idéias e
soluções. Desta forma, problemas idênticos que
se repetem em outros contextos não são reco-
nhecidos como tal, consumindo tempo e recursos
em busca de soluções que em tese,já haviam
sido encontradas.
Uma coisa que os projetistas avançados sabem
que não devem fazer é resolver cada problema a
partir de princípios elementares ou do zero. Ao
invés disso, eles reutilizam soluções que funcio-
naram no passado, e os utilizam repetidamente
em seus projetos. É como resolver um problema
matemático até então inédito, ou pelo, menos
desconhecido a alguém.
Primeiro utiliza-se todos os conhecimentos e prin-
cípios matemáticos que se tem conhecimento e
que venha a ser útil na solução, depois de algu-
mas tentativas e uso das teorias matemáticas,
chega-se à solução e a partir daí tem-se um “al-
goritmo” (estrutura) montado que pode ser utiliza-
do para resolver tantos problemas existirem e que
sejam idênticos ao resolvido, e mesmo que não
seja, é possível reaproveitar as idéias e conclu-
sões do problema resolvido.
É por isso que os padrões de projetos, design
patterns, tem chamado a atenção e despertado o
interesse dos projetistas de software, por propor-
cionar elementos que conduzem ao reaproveita-
mento de soluções para projetos, e não apenas a
reutilização de código.
Os padrões de projetos tornam mais fácil reutilizar
soluções e arquiteturas bem-sucedidas para
construir softwares orientados a objetos de forma
flexível e fácil de manter. O uso de padrões de
projeto pode reduzir a complexidade do processo
de projetar software. Além disso, o software orien-
tado a objetos bem projetado possibilita aos pro-
jetistas reutilizar e empregar componentes pree-
xistentes em sistemas futuros.
Em software, os padrões de projeto não são clas-
ses nem objeto. Em vez disso, os projetistas
usam esses padrões para construir conjuntos de
classes e objetos. Para utilizá-los de maneira
eficaz, os projetistas precisam se familiarizar com
os padrões mais populares e eficazes utilizados
pela engenharia de software e conhecer o seu
contexto e escopo.
1
A idéia de projetar soluções a partir de algo já
conhecido e documentado, não é nova e tão pou-
co teve origem na industria de software, apesar
dela já demonstrar um interesse pelo tema. A
idéia surgiu em 1977 quando Christopher Alexan-
der publicou um catálogo com mais de 250 pa-
drões para a arquitetura civil, que discutiam ques-
tões comuns da arquitetura, descrevendo em
detalhe o problema e as justificativas de sua solu-
ção.
Christopher Alexander descobriu que diminuindo
o foco, ou seja, procurando estruturas que resol-
vam problemas similares, ele pode discernir simi-
laridades entre projetos de alta qualidade. Ele
chamou essas similaridades de “padrões”.
Algum tempo depois ele formaliza seu método de
descrição dos padrões, defendendo que seu uso
não limitaria os arquitetos às soluções prescritas,
mas garantiria a presença de elementos funda-
mentais, e a possibilidade de aperfeiçoa-la atra-
vés das experiências adquiridas. Esse método
chamou atenção da comunidade de software,
fazendo que o tema ganhasse destaque nas con-
ferências sobre orientação a objetos.
Em 1995 Erich Gama, Richard Helm, Ralph John-
son, John Vlissides, conhecidos como os quatro
amigos [Gang of Four - GoF], publicaram o livro
sobre o título: “Design patterns – elements of
reusable object-oriented software, Addison Wes-
ley Longman”, que ganhou uma versão na língua
portuguesa sobre o título de “Padrões de Projeto
– Soluções reutilizáveis de software orientado a
objetos. Bookman”. O livro é um catálogo que
descreve 23 padrões de projeto cada um forne-
cendo uma solução para um problema de softwa-
re, seu contexto, aplicação e suas eventuais con-
seqüências, dividindo-os em 3 categorias: pa-
drões de criação, estruturais, e de comportamen-
to.
Definindo Padrões de Projeto
Definir o que é um padrão de projeto de maneira
clara e objetiva, tem sido o objetivo da comunida-
de de software, desde a década de 80.O primeiro
a apresentar uma definição do que seria um pa-
drão, foi o arquiteto de professor Christopher Ale-
xandre, no seu livro “A Times Way of Building”
(Oxford University Press, 1979), que é: “Cada
padrão é uma regra de três partes, que expressa
uma relação entre um certo contexto, um proble-
ma e uma solução”. Sendo assim para entender a
necessidade, existência, de um padrão é neces-
sário estudar suas partes: o problema, a solução
e o contexto sobre o qual ele é aplicável.
Dessa forma, resumidamente pode-se entender
como padrão de projeto, como a solução recor-
rente para um problema em um contexto, mesmo
que em projetos e áreas distintas. Observe que
os termos chaves dessa definição são: contexto,
problema e solução, o que torna obrigatório à
compreensão inequívoca de cada um. Um con-
texto diz respeito ao ambiente, e as circunstân-
cias dentro do qual algo existe. O problema é a
questão indefinida, algo que precisa ser investi-
gado e solucionado. Normalmente, está atrelado
ao contexto em que ocorre. Finalmente, a solução
refere à resposta do problema que ajuda a soluci-
ona-lo.
Entretanto, se tivermos uma solução para um
problema em um certo contexto, ela não necessa-
riamente pode constituir um padrão, pois é ne-
cessário que ela tenha como característica a re-
gularidade, isto é, ela se constituirá como um
padrão se puder ser utilizada repetidamente.
Segundo Christopher Alexander, “cada padrão
descreve um problema no nosso ambiente e o
núcleo da sua solução, de tal forma que você
possa usar esta solução mais de um milhão de
vezes, sem nunca faze-lo da mesma maneira”.
O grupo dos quatro amigos classificou os padrões
de projeto por dois critérios. O primeiro critério é
a finalidade - reflete o que um padrão faz. Os
padrões podem ter finalidades de criação, com-
portamento e estrutural. Os padrões de criação
descrevem as técnicas para instanciar objetos (ou
grupos de objetos), e possibilitam organizar clas-
ses e objetos em estrutura maiores, os de com-
portamento se caracterizam pela maneira pelas
quais classes ou objetos interagem e distribuem
responsabilidades e os estruturais lidam com a
composição de classes ou objetos. O segundo
critério é o escopo - especifica se o padrão é apli-
cado à classe ou objeto.
Características de um Padrão de Projeto
Embora um padrão seja a descrição de um pro-
blema, de uma solução genérica e sua justificati-
va, isso não significa que qualquer solução co-
nhecida para um problema possa constituir um
2
padrão, pois existem características obrigatórias
que devem ser atendidas pelos padrões:
1. Devem possuir um nome, que descreva o
problema, as soluções e conseqüências. Um no-
me permiti definir o vocabulário a ser utilizado
pelos projetistas e desenvolvedores em um nível
mais alto de abstração.
2. Todo padrão deve relatar de maneira clara
a qual (is) problema(s) ele deve ser aplicado, ou
seja, quais são os problemas que quando inserido
em um determinado contexto o padrão consegui-
rá resolve-lo. Alguns podendo exigir pré-
condições.
3. Solução descreve os elementos que com-
põem o projeto, seus relacionamentos, responsa-
bilidades e colaborações. Um padrão deve ser
uma solução concreta, ele deve ser exprimido em
forma de gabarito (algoritmo) que, no entanto
pode ser aplicado de maneiras diferentes.
4. Todo padrão deve relatar quais são as
suas conseqüências para que possa ser analisa-
da a solução alternativa de projetos e para a
compreensão dos benefícios da aplicação do
projeto.
Não pode ser considerado um padrão de projeto
trecho de códigos específicos, mesmo que para o
seu criador ele reflita um padrão, que soluciona
um determinado problema, porque os padrões
devem estar a um nível maior de abstração e não
limitado a recursos de programação. Um padrão
de projeto nomeia, abstrai e identifica os aspectos
chaves de uma estrutura de projeto comum para
torna-la útil para a criação de um projeto orienta-
do a objetos reutilizável.
A Importância dos Padrões de Projeto
O mais importante sobre os padrões é que eles
são soluções aprovadas. Cada catálogo inclui
apenas padrões que foram considerados úteis por
diversos desenvolvedores em vários projetos. Os
padrões catalogados também são bem definidos;
os autores descrevem cada padrão com muito
cuidado e em seu próprio contexto, portanto será
fácil aplicar o padrão em suas próprias circuns-
tâncias. Eles também formam um vocabulário
comum entre os desenvolvedores.
Quando os Padrões não o Ajudarão
Os padrões são um mapa, não uma estratégica.
Os catálogos geralmente apresentarão algum
código-fonte como uma estratégica de exemplo,
portanto eles não devem ser considerados como
definitivos.
Os padrões não ajudarão a determinar qual apli-
cação você deve estar escrevendo apenas como
implementar melhor a aplicação assim que o con-
junto de recursos e outras exigências forem de-
terminados. Os padrões ajudam com o que e
como, mas não com por que ou quando.
O conceito de utilizar os padrões de forma indis-
criminada é conhecido como anti padrões (anti
patterns). De acordo com Andrew Koenig, se um
padrão representa a “melhor prática”, então um
anti padrão representa uma “lição aprendida”.
Existem duas noções de anti padrões:
1. Aqueles que descrevem uma solução ruim
para um problema que resultou em uma situação
ruim;
2. Aqueles que descrevem como se livrar de
uma situação ruim e como proceder dessa situa-
ção para uma situação boa.
Em suma um anti padrão constitui ao uso indevi-
do dos padrões de projeto, ou o seu uso exage-
rado, o que pode ser constatado pela utilização
de padrões impróprios para um determinado con-
texto, ou uso inadequado. A utilização dos pa-
drões proporciona um aumento na flexibilidade do
sistema, entretanto pode deixá-lo mais complexo
ou degradar a desempenho. Algumas perdas são
toleráveis, mas subestimar os efeitos colaterais
da adoção dos patterns é um erro comum, princi-
palmente daqueles que tomam o uso como um
diferencial e não pela real necessidade.
Como Padrões de Projeto Solucionam Pro-
blemas de Projeto
O alvo principal do uso dos padrões de projeto no
desenvolvimento de software é o da orientação a
objetos. Como os objetos são os elementos cha-
ves em projetos OO, a parte mais difícil do projeto
é a decomposição de um sistema em objetos. A
tarefa é difícil porque muitos fatores entram em
jogo: encapsulamento, granularidade, dependên-
cia, flexibilidade, desempenho, evolução, reutili-
zação e assim por diante. Todos influenciam a
3
decomposição, freqüentemente de formas confli-
tantes.
Muito dos objetos participantes provêm do méto-
do de análise. Porém, projetos orientados a obje-
tos acabam sendo compostos por objetos que
não possui uma contrapartida no mundo real.
As abstrações que surgem durante um projeto
são as chaves para torna-lo flexível. Os padrões
de projeto ajudam a identificar abstrações menos
óbvias bem como os objetos que podem capturá-
las. Por exemplo, objetos que representam pro-
cesso ou algoritmo não ocorrem na natureza, no
entanto, eles são uma parte crucial de projetos
flexíveis. Esses objetos são raramente encontra-
dos durante a análise ou mesmo durante os está-
gios iniciais de um projeto; eles são descobertos
mais tarde, durante o processo de tornar um pro-
jeto mais flexível e reutilizável.
Como Selecionar um Padrão de Projeto
Escolher dentre os padrões existentes aquele que
melhor soluciona um problema do projeto, sem
cometer o erro de escolher de forma errônea e
torná-lo inviável, é uma das tarefas mais difíceis.
Em suma, a escolha de um padrão de projeto a
ser utilizado, pode ser baseada nos seguintes
critérios:
1. Considerar como os padrões de projeto
solucionam problemas de projeto.
2. Examinar qual a intenção do padrão, ou
seja, o que faz de fato o padrão de projeto, quais
seus princípios e que tópico ou problema particu-
lar de projeto ele trata (soluciona).
3. Estudar como os padrões se relacionam.
4. Estudar as semelhanças existentes entre
os padrões.
5. Examinar uma causa de reformulação de
projeto.
6. Considerar o que deveria ser variável no
seu projeto, ou seja, ao invés de considerar o que
pode forçar uma mudança em um projeto, consi-
derar o que você quer ser capaz de mudar sem
reprojetá-lo.
Como Usar um Padrão de Projeto
Depois de ter sido feita a escolha do(s) padrão
(ões) a ser (em) utilizado(s) no projeto é necessá-
ria conhecer como utilizá-lo(s). Uma abordagem
recomendada pela gangue dos quatros amigos
para aplicar um padrão a um projeto é:
1. Ler o padrão por completo uma vez, para
obter sua visão geral. Conhecer o padrão princi-
palmente a sua aplicabilidade e conseqüências
são importantes para que ele realmente solucione
o seu problema;
2. Estudar seções Estrutura, Participantes e
Colaborações. Assegurando-se de que compre-
endeu as classes e objetos no padrão e como se
relacionam entre si;
3. Escolher os nomes para os participantes do
padrão que tenham sentido no contexto da apli-
cação;
4. Definir as classes. Declarar as interfaces,
estabelecer os seus relacionamentos de herança
e definir as variáveis de instância que represen-
tam dados e referências a objetos. Identifique as
classes existentes na aplicação que serão afeta-
das pelo padrão e modifique-as;
5. Defina os nomes específicos da aplicação
para as operações no padrão. Os nomes em ge-
ral dependem da aplicação. Use as responsabili-
dades e colaborações associadas com cada ope-
ração como guia;
6. Implemente as operações para suportar as
responsabilidades e colaborações presentes do
padrão. A seção de Implementação oferece su-
gestões para guiá-lo na implementação.
Essas são apenas diretrizes que podem ser utili-
zadas até que seja obtido experiência e conheci-
mento necessário para desenvolver uma maneira
de trabalho particular com os padrões de projeto.
Os padrões de projeto não devem ser aplicados
indiscriminadamente. Freqüentemente eles obtêm
flexibilidade e variabilidade pela introdução de
níveis adicionais de endereçamento indireto, e
isso pode complicar um projeto e/ou custar algo
em termos de desempenho. Um padrão de proje-
to deverá apenas ser aplicado quando a flexibili-
dade que ele oferece for realmente necessária.
Principais Padrões de Projeto
4
Uma rápida leitura dos códigos da VCL (Visual
Component Library) do Delphiä constata-se que
ela fora construído fazendo uso intensivo dos
padrões de projetos. O que é muito bom, pois
constata o nível de excelência da ferramenta. Isto
devido ao Delphiä implementar completamente as
boas práticas da orientação a objetos – OOP, que
auxiliam na implementação de projetos reutilizá-
veis.
Padrões de Criação
Os padrões de criação são aqueles que abstraem
e ou adiam o processo criação dos objetos. Eles
ajudam a tornar um sistema independente de
como seus objetos são criados, compostos e
representados. Um padrão de criação de classe
usa a herança para variar a classe que é instan-
ciada, enquanto que um padrão de criação de
objeto delegará a instanciação para outro objeto.
Os padrões de criação tornam-se importantes à
medida que os sistemas evoluem no sentido de
dependerem mais da composição de objetos do
que a herança de classes.
O desenvolvimento baseado na composição de
objetos possibilita que os objetos sejam compos-
tos sem a necessidade de expor o seu interior
como acontece na herança de classe, o que pos-
sibilita a definição do comportamento dinamica-
mente e a ênfase desloca-se da codificação de
maneira rígida de um conjunto fixo de comporta-
mentos, para a definição de um conjunto menor
de comportamentos que podem ser compostos
em qualquer número para definir comportamentos
mais complexos.
Há dois temas recorrentes nesses padrões. Pri-
meiro todos encapsulam conhecimento sobre
quais classes concretas são usadas pelo sistema.
Segundo ocultam o modo como essas classes
são criadas e montadas. Tudo que o sistema
sabe no geral sobre os objetos é que suas clas-
ses são definidas por classes abstratas. Conse-
qüentemente, os padrões de criação dão muita
flexibilidade no que é criado, quem cria, como e
quando é criado.
Eles permitem configurar um sistema com objetos
“produto” que variam amplamente em estrutura e
funcionalidade. A configuração pode ser estática
(isto é, especificada em tempo de compilação) ou
dinâmica (em tempo de execução).
Análise e Projeto Orientado a Objetos Com
UML
A UML (Unified Modeling Language), que signifi-
ca Linguagem Unificada de Modelagem é uma
linguagem padrão para modelagem orientada a
objetos. Ela surgiu da fusão de três grandes mé-
todos, do BOOCH, OMT (Rumbaugh) e OOSE
(Jacobson). Esta linguagem de modelagem não
proprietária de terceira geração, não é um método
de desenvolvimento. Têm como papel auxiliar a
visualizar o desenho e a comunicação entre obje-
tos. Ela permite que desenvolvedores visualizem
os produtos de seu trabalho em diagramas pa-
dronizados, e é muito usada para criar modelos
de sistemas de software.
Além de fornecer a tecnologia necessária para
apoiar a prática de engenharia de software orien-
tada a objetos, a UML poderá ser a linguagem de
modelagem padrão para modelar sistemas con-
correntes e distribuídos. Utiliza-se de um conjunto
de técnicas de notação gráfica para criar modelos
visuais de software de sistemas intensivos, com-
binando as melhores técnicas de modelagem de
dados, negócios, objetos e componentes. É uma
linguagem de modelagem única, comum e am-
plamente utilizável.
Embora com a UML seja possível representar o
software através de modelos orientados a obje-
tos, ela não demonstra que tipo de trabalho deve
ser feito, ou seja, não possui um processo que
define como o trabalho tem que ser desenvolvido.
O objetivo então é descrever "o que fazer", "como
fazer", "quando fazer" e "porque deve ser feito". É
necessária a elaboração completa de um dicioná-
rio de dados, para descrever todas as entidades
envolvidas, refinando, com isso, os requisitos
funcionais do software.
A Linguagem Unificada de Modelagem possui
diagramas (representações gráficas do modelo
parcial de um sistema) que são usados em com-
binação, com a finalidade de obter todas as vi-
sões e aspectos do sistema.
Os Diagramas da UML estão divididos em Estru-
turais e Comportamentais.
Diagramas Estruturais
 De Classe: Este diagrama é fundamental e
o mais utilizado na UML e serve de apoio aos
5
outros diagramas. O Diagrama de Classe mostra
o conjunto de classes com seus atributos e méto-
dos e os relacionamentos entre classes.
 De Objeto: O diagrama de objeto esta re-
lacionado com o diagrama de classes e, é prati-
camente um complemento dele. Fornece uma
visão dos valores armazenados pelos objetos de
um Diagrama de Classe em um determinado
momento da execução do processo do software.
 De Componentes: Está associado à lin-
guagem de programação e tem por finalidade
indicar os componentes do software e seus rela-
cionamentos.
 De implantação: Determina as necessida-
des de hardware e características físicas do Sis-
tema.
 De Pacotes: Representa os subsistemas
englobados de forma a determinar partes que o
compõem.
 De Estrutura: Descreve a estrutura interna
de um classificador.
Diagramas Comportamentais
 De Caso de Uso (Use Case): Geral e in-
formal para fases de levantamento e análise de
Requisitos do Sistema.
 De Máquina de Estados: Procura acom-
panhar as mudanças sofridas por um objeto den-
tro de um processo.
 De Atividades: Descreve os passos a se-
rem percorridos para a conclusão de uma ativida-
de.
 De Interação: Dividem-se em:
1. De Sequência: Descreve a ordem temporal
em que as mensagens são trocadas entre os
objetos.
2. Geral interação: Variação dos diagramas
de atividades que fornece visão geral dentro do
sistema ou processo do negócio.
3. De comunicação: Associado ao diagrama
de Seqüência, complementando-o e concentran-
do-se em como os objetos estão vinculados.
4. De tempo: Descreve a mudança de estado
ou condição de uma instância de uma classe ou
seu papel durante o tempo.
Metodologias Ágeis De Desenvolvimento De
Sistemas
As metodologias ágeis têm o objetivo de acelerar
o desenvolvimento do software visando à melho-
ria contínua do processo, gerando benefícios
como o aumento da comunicação e interação da
equipe, organização diária para o alcance da
meta definida, evitar falhas na elaboração, res-
postas rápidas às mudanças e aumento significa-
tivo da produtividade.
A expressão “Metodologias Ágeis” tornou-se co-
nhecida em 2001, quando especialistas em pro-
cessos de desenvolvimento de software represen-
tando entre outros, os métodos Scrum e Extreme
Programming (XP), foram estabelecidos princí-
pios e características comuns destes métodos.
Assim foi criada a “Aliança Ágil” e efetuou-se o
estabelecimento do “Manifesto Ágil”.
Scrum
Scrum é uma metodologia ágil para gestão e pla-
nejamento de projetos de software.
No Scrum, os projetos são divididos em ciclos
(tipicamente mensais) chamados de Sprints. O
Sprint representa um Time Box dentro do qual um
conjunto de atividades deve ser executado. Meto-
dologias ágeis de desenvolvimento de software
são iterativas, ou seja, o trabalho é dividido em
iterações, que são chamadas de Sprints no caso
do Scrum.
As funcionalidades a serem implementadas em
um projeto são mantidas em uma lista que é co-
nhecida como Product Backlog. No início de cada
Sprint, faz-se um Sprint Planning Meeting, ou
6
seja, uma reunião de planejamento na qual o
Product Owner prioriza os itens do Product Bac-
klog e a equipe seleciona as atividades que ela
será capaz de implementar durante o Sprint que
se inicia. As tarefas alocadas em um Sprint são
transferidas do Product Backlog para o Sprint
Backlog.
A cada dia de uma Sprint, a equipe faz uma breve
reunião (normalmente de manhã), chamada Daily
Scrum. O objetivo é disseminar conhecimento
sobre o que foi feito no dia anterior, identificar
impedimentos e priorizar o trabalho do dia que se
inicia.
Ao final de um Sprint, a equipe apresenta as fun-
cionalidades implementadas em uma Sprint Revi-
ew Meeting. Finalmente, faz-se uma Sprint Re-
trospective e a equipe parte para o planejamento
do próximo Sprint. Assim reinicia-se o ciclo. Veja
a ilustração abaixo:
Extreme Programming (XP)
A Extreme Programming (XP) é uma Metodologia
Ágil para equipes pequenas e médias que desen-
volvem software baseado em requisitos vagos e
que se modificam rapidamente. Entre as princi-
pais diferenças da XP em relação às Metodologi-
as Clássicas estão o feedback constante, a abor-
dagem incremental e o encorajamento da comu-
nicação entre as pessoas.
A maioria das regras da XP causa surpresa no
primeiro contato e muitas não fazem sentido se
aplicadas isoladamente. É a força de seu conjun-
to que sustenta o sucesso da XP, trazendo uma
verdadeira revolução no desenvolvimento de sof-
tware.
O principal objetivo da XP é dar agilidade ao de-
senvolvimento do projeto e busca garantir a satis-
fação do cliente. As práticas, regras, e os valores
da XP garantem um agradável ambiente de de-
senvolvimento de software para os seus seguido-
res, que são conduzidos por quatro princípios
básicos:
A – Princípio da Comunicação - busca manter o
melhor relacionamento possível entre clientes e
desenvolvedores, preferindo conversas pessoais
a outros meios de comunicação.
B – Princípio da Simplicidade - entende-se co-
mo simplicidade, a busca do objetivo de imple-
mentar o software com o menor número possível
de classes e métodos. Outra idéia importante
deste princípio é procurar implementar apenas
requisitos atuais, evitando assim adicionar funcio-
nalidades que podem ser importantes apenas no
futuro. A aposta da XP é que é melhor fazer algo
simples hoje do que implementar algo complicado
hoje que talvez não venha a ser usado.
C – Princípio do Feedback - A prática do feed-
back constante significa que o desenvolvedor terá
informações constantes do código e do cliente. A
informação do código é dada pelos testes cons-
tantes, que indicam os erros tanto individuais
quanto do software integrado.
D – Princípio da Coragem - Sabe-se que não
são todas as pessoas que possuem facilidade de
comunicação e têm bom relacionamento inter-
pessoal, este princípio também dá suporte à sim-
plicidade, pois assim que a oportunidade de sim-
plificar o software é percebida, a equipe pode
experimentar e buscar novas soluções, além dis-
so, é preciso coragem para obter e cobrar cons-
tantemente um feedback do cliente.
Principais práticas da Extreme Programming
(XP):
A – Planejamento - Define o que é ou não ne-
cessário ser feito no projeto. A XP baseia-se em
requisitos atuais para desenvolvimento de softwa-
re, não em requisitos futuros.
B - Entregas Freqüentes - Baseiam-se no de-
senvolvimento de um software simples, e confor-
me os requisitos aparecem, há a atualização da
versão do software. Cada versão entregue deve
ter o menor tamanho possível, contendo os requi-
sitos de maior valor para o negócio. É recomen-
dado que as versões devem ser entregues a cada
mês, ou no máximo a cada dois meses, aumen-
7
tando a possibilidade de feedback rápido do clien-
te.
C - Metáfora - São as descrições de um software
sem a utilização de termos técnicos com o objeti-
vo de guiar o desenvolvimento do software com a
maior transparência possível para o cliente.
D - Projeto simples - O software desenvolvido de
acordo com a metodologia XP deve ser o mais
simples possível e satisfazer os requisitos atuais,
sem a preocupação de requisitos futuros. Eventu-
ais requisitos futuros devem ser adicionados as-
sim que eles realmente existirem.
E – Testes - A Extreme Programming (XP) priori-
za a validação do projeto durante todo o processo
de desenvolvimento. Os desenvolvedores imple-
mentam o software criando primeiramente os
testes.
F - Programação em pares - A implementação
do código é feita em dupla, ou seja, dois desen-
volvedores trabalham em um único computador.
Procurando identificar erros sintáticos e semânti-
cos, pensando estrategicamente em como melho-
rar o código que está sendo implementado. Esses
papéis podem e devem ser alterados sempre que
possível.
G – Refatoração - Focaliza a lapidação do proje-
to do software e está presente em todas as eta-
pas do desenvolvimento. A refatoração deve ser
feita sempre que possível, buscando principal-
mente simplificar o código atual sem perder ne-
nhuma funcionalidade.
H - Propriedade coletiva - O código do projeto
pertence a todos os membros da equipe. Isto
significa que qualquer pessoa que percebe que
pode adicionar valor a um código, mesmo que ele
próprio não o tenha desenvolvido, pode fazê-lo,
desde que faça os testes necessários e não pre-
judique as funcionalidades atuais. Isto é possível
porque na XP todos são responsáveis pelo sof-
tware. Uma grande vantagem desta prática é que,
caso um membro da equipe deixe o projeto antes
do fim, a equipe consegue continuar o projeto
sem grandes dificuldades, pois todos conhecem
todas as partes do software, mesmo que não seja
de forma detalhada.
I - Integração contínua - É a prática de interagir
e construir o sistema de software várias vezes por
dia, mantendo os programadores em sintonia,
além de possibilitar processos rápidos. Integrar
apenas um conjunto de modificações de cada vez
é uma prática que funciona bem porque fica óbvio
quem deve fazer as correções quando os testes
falham. Esta prática é facilitada com o uso de
apenas uma máquina de integração, que deve ter
livre acesso a todos os membros da equipe.
J - 40 horas de trabalho semanal - a XP assu-
me que não se deve fazer horas extras constan-
temente. Caso seja necessário trabalhar mais de
40 horas pela segunda semana consecutiva, exis-
te um problema sério no projeto que deve ser
resolvido não com aumento de horas trabalhadas,
mas com melhor planejamento.
K - Cliente presente - É fundamental a participa-
ção do cliente durante todo o desenvolvimento do
projeto. O cliente deve estar sempre disponível
para sanar todas as dúvidas de requisitos, evitan-
do atrasos e até mesmo construções erradas.
Uma idéia interessante é manter o cliente como
parte integrante da equipe de desenvolvimento
(Tester).
L - Código padrão - Baseia-se na padronização
da arquitetura do código, para que este possa ser
compartilhado entre todos os programadores e
até mesmo entre outros softwares.
Desenvolvimento Ágil De Software
No conceito tradicional, metodologia de desenvol-
vimento de software é um conjunto de atividades
e resultados associados, que auxiliam na produ-
ção de software. Todas as metodologias de de-
senvolvimento tentam, entre outras coisas, redu-
zir o alto risco associado ao desenvolvimento de
software.
O desenvolvimento ágil é um fruto da constatação
feita, de forma independente, por diversos profis-
sionais renomados na área de engenharia de
software, de que, apesar de terem aprendido
segundo a cartilha tradicional, só conseguiam
minimizar os riscos associados ao desenvolvi-
mento de software, pensando e agindo de forma
muito diferente do que tradicionalmente está nos
livros.
Estes profissionais, a maioria veteranos consulto-
res para projetos de softwares, decidiram reunir-
8
se no início de 2001 durante um workshop reali-
zado em Snowbird, Utah, EUA.
Embora cada envolvido tivesse suas próprias
práticas e teorias preferidas, todos concordavam
que, em suas experiências prévias, os projetos de
sucesso tinham em comum um pequeno conjunto
de princípios.
Com base nisso eles criaram o Manifesto para o
Desenvolvimento Ágil de Software, freqüentemen-
te chamado apenas de Manifesto Ágil. O termo
Desenvolvimento Ágil identifica metodologias de
desenvolvimento que adotam os princípios do
manifesto ágil. Estes princípios são os seguintes:
· Indivíduos e interação entre eles mais que pro-
cessos e ferramentas
· Software em funcionamento mais que documen-
tação abrangente
· Colaboração com o cliente mais que negociação
de contratos
· Responder a mudanças mais que seguir um
plano
O manifesto reconhece o valor dos itens à direita,
mas diz que devemos valorizar bem mais os itens
à esquerda.
No desenvolvimento ágil, os projetos adotam o
modelo iterativo e em espiral (figura 1.5). Neste
processo, todas as fases descritas no modelo em
cascata são executadas diversas vezes ao longo
do projeto, produzindo ciclos curtos que se repe-
tem ao longo de todo o desenvolvimento, sendo
que, ao final de cada ciclo, sempre se tem um
software funcional, testado e aprovado. Os ciclos
são chamados de iterações e crescem em núme-
ro de funcionalidades a cada repetição, sendo
que, no último ciclo, todas as funcionalidades
desejadas estarão implementadas, testadas e
aprovadas [TELES, 2004].
Figura 1.5 - Desenvolvimento iterativo em espiral
DSDM
Metodologia de Desenvolvimento de Sistemas
Dinâmicos (Dynamic Systems Development Me-
thod - DSDM) é uma metodologia de desenvolvi-
mento de software originalmente baseada em
Desenvolvimento Rápido de Aplicação (RAD).
DSDM é uma metodologia de desenvolvimento
iterativo e incremental que enfatiza o envolvimen-
to constante do usuário. Seu objetivo é entregar
softwares no tempo e com custo estimados atra-
vés do controle e ajuste de requisitos ao longo do
desenvolvimento. DSDM é um dos modelos de
Metodologia Ágil de desenvolvimento de software.
O princípio fundamental por trás desta metodolo-
gia está no fato de, ao invés de fixar as funciona-
lidades do produto, e somente depois ajustar o
tempo e os recursos, é melhor fixar o tempo e os
recursos, para depois ajustar o número de funcio-
nalidades adequadamente. Como uma extensão
do RAD, o DSDM é aplicado em projetos de Sis-
temas caracterizados pelos cronogramas e custos
limitados. A ponta falhas de informação mais co-
muns destes projetos, incluindo custos exceden-
tes, perda de prazos, falta de envolvimento de
usuários e acompanhamento da alta gerência.
Através do uso do RAD, contudo, sem os devidos
cuidados com o DSDM pode aumentar ainda
mais o risco em outros quesitos.
Princípios da DSDM
A DSDM possui alguns princípios chaves, que
delimitam as bases do desenvolvimento.
• O ponto fundamental desta metodologia prende-
se com a entrega de um sistema que se aproxime
das necessidades atuais de negócio;
• O desenvolvimento iterativo e incremental é
necessário para convergir com precisão às solu-
ções do negócio;
• O time deve ter o poder para tomar decisões;
• O foco é na entrega freqüente de produtos;
• A entrega do projeto deve ser feita na data esti-
pulada, dentro do orçamento previsto e com boa
qualidade;
• O teste é integrado por todo o ciclo de vida;
9
• Uma abordagem colaborativa e cooperativa
entre as partes envolvidas é essencial;
Principais Técnicas Da DSDM
Timeboxing: Técnica utilizada para realizar o de-
senvolvimento no tempo previsto, dentro do or-
çamento e com a qualidade desejada ideia. Divi-
dir o projeto em porções, cada uma com um or-
çamento fixo e uma data de entrega estipulada
MoSCoW: Técnica que prioriza os requisitos,
representa um método de definição de priorida-
des nas tarefas efetuadas.
M - deve ter isso.
S - devem ter este se possível.
C - poderia ter esta se não realizar qualquer outra
coisa.
W - não terá esse tempo, mas gostaria no futuro.
• Prototipagem: Técnica se refere à criação de
protótipos do sistema em desenvolvimento em um
estágio inicial do projeto. Ele permite a descober-
ta precoce de deficiências do sistema e permite
que os futuros usuários de "test-drive" do sistema;
•Workshop: Técnica que visa trazer os diferentes
atores do projeto para discutir requisitos, funcio-
nalidades e compreensão mútua. Em uma oficina,
os participantes se reúnem e discutir o projeto;
•Testes: Um dos objetivos da DSDM é a criação
de um SI com boa qualidade. Para obter esta
solução, a DSDM obriga a efetuar testes em to-
das as iterações. Uma vez que a DSDM é uma
metodologia independente de ferramentas e téc-
nicas, a equipe do projeto é livre de escolher o
seu próprio método de realização de testes.
FDD
O Desenvolvimento Guiado por Funcionalidades
(FDD) é uma metodologia ágil para gerenciamen-
to e desenvolvimento de software nascida em
1997 em Cingapura, a partir do Método Coad
desenvolvido por Peter Coad e das técnicas de
gerenciamento de projetos de Jeff de Luca.
Seu lema é "Resultados frequentes, tangíveis e
funcionais".
A primeira descrição oficial dos processos foi
publicada no livro "Java Modeling in Color with
UML", por Peter Coad, Eric Lefebvre e Jeff De
Luca, em 1999.
O livro de referência é "A Practical Guide to Fea-
ture-Driven Development", por Stephen Palmer e
John Mac Felsing, publicado em 2002 pela Pren-
tice-Hall, compondo uma série editada pelo pró-
prio Peter Coad.
FDD é, classicamente, descrita por cinco proces-
sos:
 Desenvolver um Modelo Abrangente:
pode envolver desenvolvimento de requisitos,
análise orientada por objetos, modelagem lógica
de dados e outras técnicas para entendimento do
domínio de negócio em questão. O resultado é
um modelo de objetos (e/ou de dados) de alto
nível, que guiará a equipe durante os ciclos de
construção.
 Construir uma Lista de Funcionalidades:
decomposição funcional do modelo do domínio,
em três camadas típicas: áreas de negócio, ativi-
dades de negócio e passos automatizados da
atividade (funcionalidades). O resultado é uma
hierarquia de funcionalidades que representa o
produto a ser construído (também chamado
de product backlog, ou lista de espera do produ-
to).
 Planejar por Funcionalidade: abrange a
estimativa de complexidade e dependência das
funcionalidades, também levando em considera-
ção a prioridade e valor para o negócio/cliente. O
resultado é um plano de desenvolvimento, com os
pacotes de trabalho na seqüência apropriada
para a construção.
 Detalhar por Funcionalidade: já dentro de
uma iteração de construção, a equipe detalha os
requisitos e outros artefatos para a codificação de
cada funcionalidade, incluindo os testes. O proje-
to para as funcionalidades é inspecionado. O
resultado é o modelo de domínio mais detalhado
e os esqueletos de código prontos para serem
preenchidos.
 Construir por Funcionalidade: cada es-
queleto de código é preenchido, testado e inspe-
cionado. O resultado é um incremento do produto
integrado ao repositório principal de código, com
10
qualidade e potencial para ser usado pelo clien-
te/usuário.
Processo Unificado
Muitas vezes os engenheiros de software preci-
sam desenvolver sistemas grandes e complexos.
O escopo e a complexidade desses sistemas são
modelados de forma para que todos os envolvi-
dos no projeto entendam quais requisitos devem
ser integrados, para que os problemas possam
ser melhores subdivididos entre as pessoas que
têm de solucioná-los e para que a qualidade pos-
sa ser avaliada enquanto estamos projetando e
desenvolvendo o sistema.
Muitas notações e métodos de modelos têm sur-
gidos ao longo das últimas décadas. Esses méto-
dos e notações auxiliam tanto a análise quanto o
projeto e muitas vezes geram implementações
baseando-se nesses modelos. Apesar de eles
terem evoluído, ainda temos o problema de man-
tê-los. A cada mudança devemos atualizar os
modelos e muitas vezes cuidando com o grau de
formalismo que é imposto.
Os métodos ágeis oferecem uma alternativa para
a modelagem de engenharia de software. Scott
Ambler descreve o que ele chama de modelagem
ágil da seguinte forma: "Modelagem ágil (AM)
consiste em uma metodologia baseada na práti-
ca, voltada para a modelagem e documentação
de sistemas com base em software. Simplifican-
do, modelagem ágil consiste em um conjunto de
valores, princípios e práticas voltadas para a mo-
delagem do software que podem ser aplicados
em um projeto de desenvolvimento de software
de forma leve e efetiva. Os modelos ágeis são
mais efetivos que os tradicionais pelo fato de
serem meramente bons, pois não têm a obriga-
ção de ser perfeitos".
Todos os valores do manifesto ágil são consisten-
tes com o que é pregado na modelagem ágil.
Entre as principais características da modelagem
ágil tem-se:
 Modelar com um objetivo: O desenvolvedor
sempre deverá ter um objetivo antes de criar um
modelo como, por exemplo, comunicar informa-
ções ao cliente ou ajudar a compreender melhor
algum aspecto que não esteja tão claro. Podemos
notar que aqui a modelagem ágil foca em pen-
sarmos antes de criarmos modelos simplesmente
por criar ou para guardar modelos. O modelo
criado deverá realmente servir para algum fim
específico.
 Usar modelos múltiplos: Existem diversos
modelos e notações que podemos utilizar para
descrever o software, no entanto, apenas um
subconjunto é realmente essencial para a maioria
dos projetos. A modelagem ágil sugere que sejam
utilizados os modelos que realmente comuniquem
adequadamente para os usuários específicos.
Além disso, sugere-se que devemos usar diferen-
tes modelos para apresentar um aspecto diferen-
te do sistema.
 Viajar leve: Devemos apenas conservar
aqueles modelos que terão valor em longo prazo,
os demais devem ser descartados. Isso ocorre
porque efetuar manutenção em modelos é árduo,
assim como qualquer outro artefato de software.
Modelos são apenas mais um artefato para dar-
mos manutenção.
 Conteúdo é mais importante do que repre-
sentação: A modelagem deve sempre transmitir
informação, seja para um cliente tentando enten-
der alguma parte do sistema, seja o próprio en-
genheiro de software tentando tirar informações
do cliente ou uma equipe de desenvolvimento de
software tentar entender ou repassar algo. Dessa
forma, um modelo sintaticamente perfeito que não
transmite muito conteúdo não possui tanto valor
quanto um modelo com notações falhas que for-
nece conteúdo valioso para seu público-alvo.
 Ter conhecimento e domínio dos modelos e
ferramentas que serão utilizadas: Devemos com-
preender os pontos fores e fracos de cada mode-
lo e ferramenta usada para criá-lo. Isso dá mais
visibilidade e possibilidade de resolver problemas
da melhor forma.
 Adaptar localmente: Como sempre prega-
mos na agilidade, devemos adaptar a modelagem
às necessidades da nossa equipe. Um exemplo
disso é uma equipe que odiava mexer com as
ferramentas de modelagem. Dessa forma, adap-
tamos a modelagem para ser realizada num qua-
dro, numa sala de reunião. A modelagem flui mui-
to mais e a equipe pode se sentir mais animada.
Processo Unificado Ágil (AUP)
11
O Processo Unificado Ágil ou Agile Unified Pro-
cess (AUP) adota uma filosofia serial (sequência
linear de atividades) para o que é amplo e iterati-
vo para o que é particular. Este processo possui
atividades nas fases clássicas adotadas pelo
Processo Unificado: Início, Elaboração, Constru-
ção e Transição. Dentro de cada uma das ativi-
dades a equipe itera ou se repete para alcançar a
agilidade e entregar incrementos de software para
os usuários finais. É importante que essa entrega
seja mais rápida quanto possível.
A AUP possui seis atividades, na qual a equipe
irá sempre iterar. As atividades são:
 Modelagem: Modelos UML representando
o negócio são criados. Os modelos devem ser
suficientemente bons e adequados para perma-
necer ágil.
 Implementação: Modelos são traduzidos
para o código-fonte.
 Teste: A equipe projeta e executa uma
série de teste a fim de descobrir possíveis erros e
para assegurar que o código-fonte se ajuste aos
requisitos.
 Aplicação: É a entrega de um incremento
de software e a aquisição de feedback dos usuá-
rios finais com base neste incremento.
 Gerenciamento de Configuração e Geren-
ciamento de projeto: No contexto da AUP, geren-
ciamento de configuração refere-se ao gerencia-
mento de alterações, riscos e de controle de
qualquer artefato persistente que são produzidos
pela equipe. O gerenciamento de projeto controla
o progresso de uma equipe e coordena suas ati-
vidades.
cam-se os produtos gerados nas atividades e
indicam-se os papeis das pessoas envolvidas. As
empresas normalmente definem seus próprios
modelos de processos, juntando o que tem de
melhor nos diferentes modelos de processos exis-
tentes. Outras empresas preferem adotar um
modelo de processo que seja mais adequado ao
seu contexto.
Orientação a Objetos
A Programação Orientada a Objetos conhecida
como POO, é onde o desenvolvedor tem de co-
meçar a pensar fora da caixa, a imaginar uma
forma aonde será preciso recorrer ao mundo real
para o desenvolvimento das aplicações, pois hoje
toda a programação em Java é orientada a obje-
tos.
Para obter esse entendimento, é necessário co-
nhecer alguns dos pilares da Orientação a Obje-
tos que são: Abstração, Encapsulamento, Heran-
ça e Polimorfismo. Neste artigo o pilar do Polimor-
fismo não será visto.
1º Pilar - Abstração
É utilizada para a definição de entidades do mun-
do real. Sendo onde são criadas as classes. Es-
sas entidades são consideradas tudo que é real,
tendo como consideração as suas características
e ações, veja na Figura 1 como funciona.

 Gerenciamento de Ambiente: Coordena

toda a infraestrutura de processos incluindo pa-
drões, ferramenta e outras tecnologias de suporte
disponíveis para a equipe.

Como vimos nesse artigo, um processo de sof-

tware tem como característica um conjunto de
atividade que conduzem o desenvolvimento do
produto de software. Um processo tem como
característica a definição de quem realiza uma Figura 1: Abstrações do mundo real
atividade e quando fazê-la. Um Modelo de pro-
cesso é uma descrição simplificada de um pro- Encapsulamento
cesso onde se definem as atividades, especifi-

12
Os objetos como dito acima contém atributos e
métodos. O encapsulamento trata de dar alguma
segurança aos objetos. Explico:

Um objeto Cliente por exemplo tem atributos co-

mo qualquer outro e estes não podem ser aces-
sados por qualquer outro objeto diretamente.
Existem dois tipos de atributos, os privados e os
públicos. Em UML e OO (orientação a objetos) é
definido que para atributos privados usa-se o
sinal de “-” antes do nome e para atributos públi-
cos usa-se o sinal de “+” antes do nome.

Exemplo:

Herança

Herança:

Na Programação Orientada a Objetos o significa-

do de herança tem o mesmo significado para o
mundo real. Assim como um filho pode herdar
alguma característica do pai, na Orientação a
Objetos é permitido que uma classe herde atribu-
tos e métodos da outra, tendo apenas uma restri-
ção para a herança. Os modificadores de acessos
das classes, métodos e atributos só podem estar
com visibilidade public e protected para que se-
jam herdados.

Uma das grandes vantagens de usar o recurso da

Para que o encapsulamento exista é preciso dei-
xar os atributos privados e os métodos públicos,
assim está sendo garantido que os valores atribu-
ídos aos atributos serão sempre respeitados pe-
las regras existentes.
Exemplo:
herança é na reutilização do código. Esse reapro-
veitamento pode ser acionado quando se identifi-
ca que o atributo ou método de uma classe será
igual para as outras. Para efetuar uma herança
de uma classe é utilizada a palavra reservada
chamada extends.

O atributo cpf deve sempre ter 11 números, se o

atributo não for privado, ele perde essa regra (11
números) pois alguém poderia acessar e colocar
12 ou 9 números tornando-o inválido.

Como os atributos privados não podem ser aces-

sados diretamente por outros objetos, existem os
métodos públicos que são os responsáveis em
acessar os atributos e trazer ou levar algum dado
para o objeto respeitando as regras.
Ideia de encapsulamento:
(Hierarquia das classes)
Para saber se estamos aplicando a herança cor-
retamente, realiza-se o teste “É UM”. Esse teste
simples ajuda a detectar se a subclasse pode
herdar a superclasse.

13
Por exemplo, na acima, está mostrando que a
classe “Gerente” herda da classe “Funcionário”,
se for aplicado o teste “É UM” nota-se que o teste
é aprovado, pois o “Gerente” também “É UM”
Funcionário.
Polimorfismo é o princípio pelo qual duas ou mais
classes derivadas de uma mesma superclasse
podem invocar métodos que têm a mesma identi-
ficação, assinatura, mas comportamentos distin-
tos, especializados para cada classe derivada,
usando para tanto uma referência a um objeto do
tipo da superclasse. O overload não é um tipo de
polimorfismo, pois com overload a assinatura do
método obrigatoriamente tem que ter argumentos
diferentes, requisito que fere o conceito de Poli-
morfismo citado acima.
De forma genérica, polimorfismo significa várias
formas. No caso da Orientação a Objetos, poli-
morfismo denota uma situação na qual um objeto
pode se comportar de maneiras diferentes ao
receber uma mensagem, dependendo do seu tipo
de criação.
Por exemplo, a operação move quando aplicada
a uma janela de um sistema de interfaces tem um
comportamento distinto do que quando aplicada a
uma peça de um jogo de xadrez. Um método é
uma implementação específica de uma operação
para certa classe.
Polimorfismo
Polimorfismo também implica que uma operação
de uma mesma classe pode ser implementada
por mais de um método. O usuário não precisa
saber quantas implementações existem para uma
operação, ou explicitar qual método deve ser
utilizado: a linguagem de programação deve ser
capaz de selecionar o método correto a partir do
nome da operação, classe do objeto e argumen-
tos para a operação.
Desta forma, novas classes podem ser adiciona-
das sem necessidade de modificação de código
já existente, pois cada classe apenas define os
seus métodos e atributos. Em Java, o polimorfis-
mo se manifesta apenas em chamadas de méto-
dos.
A decisão sobre qual o método que deve ser se-
lecionado, de acordo com o tipo da classe deriva-
da, é tomada em tempo de execução, através do
mecanismo de ligação tardia. A ligação tardia
ocorre quando o método a ser invocado é definido
durante a execução do programa. Através do
mecanismo de sobrecarga, dois métodos de uma
classe podem ter o mesmo nome, desde que
suas assinaturas sejam diferentes, entretanto isso
não é polimorfismo.
Como dito anteriormente, tal situação não gera
conflito, pois o compilador é capaz de detectar
qual método deve ser escolhido a partir da análi-
se dos tipos dos argumentos do método. Nesse
caso, diz-se que ocorre a ligação prematura para
o método correto. Em Java, todas as determina-
ções de métodos a executar ocorrem através de
ligação tardia exceto em dois casos:
1. Métodos declarados como final não podem
ser redefinidos e, portanto, não são passíveis de
invocação polimórfica da parte de seus descen-
dentes; e
2. Métodos declarados como private são im-
plicitamente finais.
No caso de polimorfismo, é necessário que os
métodos tenham exatamente a mesma identifica-
ção, sendo utilizado o mecanismo de redefinição
de métodos, que é o mesmo que sobrescrita de
métodos em classes derivadas. A redefinição
ocorre quando um método cuja assinatura já te-
nha sido especificada recebe uma nova definição,
ou seja, um novo corpo, em uma classe derivada.
É importante observar que, quando polimorfismo
está sendo utilizado, o comportamento que será
adotado por um método só será definido durante
a execução. Embora em geral esse seja um me-
canismo que facilite o desenvolvimento e a com-
preensão do código orientado a objetos, há algu-
mas situações onde o resultado da execução
pode ser não-intuitivo.
Reutilização de Componentes
No contexto social, a imitação ou reutilização de
idéias são vistas como falta de originalidade, po-
rém em desenvolvimento de software isso pode
resultar em um aumento significativo na produtivi-
dade e uma redução considerável no tempo de
execução das tarefas.
As primeiras ideias sobre reutilização de software
são do ano de 1968, quando Doug McIlroy mos-
trou a sua motivação por software que funcionas-
14
se como "Circuitos Integrados" (CI) e que estes
pudessem ser fabricados em massa. Além disso,
ele examinou os tipos de variabilidade necessá-
rias aos CIs e os possíveis tipos de CIs que pode-
riam ser padronizados desta forma. A visão de
McIlroy era baseada na indústria de componentes
eletrônicos que podiam ser selecionados em catá-
logos de diferentes fabricantes, apresentando
propriedades configuráveis e diferentes níveis de
confiabilidade.
Apesar de os primeiros conceitos sobre reutiliza-
ção de software terem sido idealizados no final da
década de 1960, eles não receberam muita aten-
ção da indústria e das universidades até os anos
80, quando a complexidade dos sistemas come-
çou a aumentar e as empresas foram forçadas a
procurar por métodos mais eficientes de constru-
ção de sistemas para refletir as necessidades do
mercado.
Em 1980 foi estabelecido o primeiro projeto de
pesquisa universitário no tema de reutilização, na
Universidade da Califórnia, coordenado por Peter
Freeman. Atualmente, existem duas principais
conferências sobre reutilização, a ICSR – Interna-
tional Conference on Software Reuse e o SSR –
Symposium on Software Reusability.
É notório que a reutilização, quando feita de for-
ma intencional, planejada e controlada, os benefí-
cios alcançados são relevantes. Redução de cus-
tos e esforço, melhoria de qualidade, potencial
para abranger o leque de produtos, atingir novos
mercados, ganhar espaço da concorrência são
alguns dos principais chamarizes da reutilização.
Tudo isso só é possível, pois a técnica simplifica
a tarefa de aquisição de conhecimento. Diversos
estudos mostram que muito do software que es-
tamos começando a construir já foi feito e que
apenas algo em torno de 15% dele é realmente a
contribuição do nosso negócio. Todavia, embora
todos acreditem nos benefícios dessa técnica, a
reutilização ainda não é uma prática freqüente.
Reutilização
A reutilização de software se baseia no uso de
conceitos, produtos ou soluções previamente
elaboradas ou adquiridas para criação de um
novo software, visando melhorar significativamen-
te a qualidade e a produtividade. Reusar um pro-
duto significa poder reusar partes de um sistema
desenvolvido anteriormente como: especifica-
ções, módulos de um projeto, arquitetura e código
fonte. É a reaplicação de informações e artefatos
de um sistema já definido, em outros sistemas
semelhantes. O termo reuso pode ser considera-
do uma denominação genérica para uma série de
técnicas utilizadas, que vão desde a etapa de
modelagem de um projeto até a implementação.
A principal motivação para a reutilização está
relacionada ao aumento dos níveis de qualidade
e produtividade no desenvolvimento de software.
O aumento de qualidade é uma conseqüência da
reutilização de componentes que foram previa-
mente documentados, testados e aprovados. O
aumento da produtividade é resultado de uma
redução no tempo de desenvolvimento, evitando
a reconstrução de partes do sistema que já exis-
tem.
A reutilização pode ser introduzida em diferentes
fases e níveis do desenvolvimento de software:
requisitos, design, código. É mais comum a reuti-
lização de porções de código, design e testes, do
que a reutilização de requisitos. A reutilização em
fases com maior nível de abstração aumenta os
benefícios da mesma e facilita a reutilização em
fases mais avançadas do ciclo de vida do produ-
to.
Embora já se tenha chegado a essa conclusão, a
reutilização de requisitos tem merecido pouca
atenção dos investigadores. É necessário mobili-
zar o estabelecimento de um processo gradativo
e coordenado de reutilização, não só no código,
mas em todo o processo de desenvolvimento de
software.
Atualmente existem várias técnicas de reuso co-
mo frameworks, arquiteturas orientadas a servi-
ços (SOA), engenharia de software baseada em
componentes, entre outras.
Vejo três formas comuns de se reutilizar compo-
nentes:
 Utilizar componentes de terceiros;
 Desenvolver componentes próprios reutili-
záveis;
 Copiar e colar (sim, isso mesmo).
Utilizar Componentes de Terceiros
15
Essa forma de reutilização é, à princípio, a que
demanda menos esforço por parte da equipe de
desenvolvimento, afinal, não é necessário desen-
volver nada.
Porém, o custo do desenvolvimento é apenas
uma parte do custo total de utilização de um
componente. Ao adotar um componente de tercei-
ro deve-se ter cuidado com algumas outras ques-
tões:
 Qual a curva de aprendizado dele?
 Quão extensível ele é? Pode ser customi-
zado para atender as diversas necessidades?
 No caso de um problema nesse componen-
te, como será feita a correção?
 Este componente está em desenvolvimen-
to? Está maduro? Há previsão de continuidade no
desenvolvimento dele?
Como pode-se ver, adotar um componente de
terceiros geralmente não é uma opção tão sim-
ples quanto se imagina à princípio. Além da
aprendizagem necessária, deve-se atentar ao
desenvolvimento dele, se a equipe de desenvol-
vimento poderá contar com melhorias futuras e/ou
suporte em caso de problemas.
Desenvolver Componentes Próprios Reutilizá-
veis
Quando não há um componente de terceiros dis-
ponível, ou há alguma outra limitação como o
preço ou inadequação do componente, a solução
pode ser desenvolver seus próprios componentes
reutilizáveis.
Um detalhe muito importante é: não desenvolver
um componente sem um caso de uso em mente.
Já vi diversas vezes componentes ultra genéri-
cos, que resolvem todos os problemas do mundo,
serem criados e quando precisam ser utilizados,
simplesmente não servem para nada.
Normalmente a criação de um componente reuti-
lizável deve ocorrer de forma natural. Se um de-
terminado componente foi útil para uma situação,
e poderá ser aproveitado para outras, então sim,
podemos reutilizá-lo. Antes de pensar em reutili-
zar é necessário utilizar.
A questão mais complexa dessa reutilização é o
versionamento do componente. Deve-se ter muita
atenção no controle das versões e alterações que
fazem outros projetos deixarem de funcionar.
Esse componente, afinal, estará sendo utilizado
em mais de um projeto e consequentemente,
cada alteração deve ser muito bem pensada.
Copiar e Colar
Copiar e colar é uma ótima forma de reutilização.
Há situações onde determinado código é usado
em várias situações, mas em todas com peque-
nas modificações, não sendo possível ou valendo
a pena tentar criar um componente. Deve-se to-
mar muito cuidado para o copiar e colar não virar
regra. Essa forma de reutilização deve ser utiliza-
da somente como exceção, e somente entre mais
de um projeto, quando o custo de versionamento
e gerenciamento do componente são maiores que
o benefício da reutilização. Dentro de um mesmo
projeto, o custo de versionamento é pequeno, por
isso, normalmente o copiar e colar nunca será
utilizado.
Gerencia De Projetos
Gestão de projetos é um conjunto de práticas que
serve de guia a um grupo para trabalhar de ma-
neira produtiva. Ela compreende métodos e fer-
ramentas que organizam as tarefas, identificam
sua seqüência de execução e dependências exis-
tentes, apóia a alocação de recursos e tempo,
além de permitir o rastreamento da execução das
atividades e medição do progresso relativo ao
que foi definido no plano de projeto.
Qualquer que seja o projeto com o qual você es-
teja envolvido, o plano de projeto é um documen-
to essencial o qual o gerente de projeto ´vive e
respira´ ao longo de todo o projeto. É obrigatório
o seu desenvolvimento e manutenção. O plano de
projeto define os marcos de projeto (isto é, os
´milestones´) e as principais atividades necessá-
rias à execução do projeto. Este documento defi-
ne a data de cada marco de projeto, as atividades
associadas, os artefatos gerados e respectivos
responsáveis.
Perceba que é, até certo ponto, natural àqueles
que desenvolvem novos produtos e sistemas de
software iniciarem as atividades de desenvolvi-
mento antes mesmo que eles entendam o que
tem de ser feito, ou seja, antes mesmo de sabe-
16
rem qual é o problema a ser tratado. Esse tipo de
atitude, comumente, resulta no insucesso de pro-
jetos.
Estudos apontam que cerca de 40% de insucesso
de projetos são devidos ao mau planejamento ou,
até mesmo, a inexistência de plano de projeto,
enquanto que quase 20% se deve a uma gestão
inadequada do projeto. Interessante destacar que
aproximadamente 50% dos problemas e insuces-
so de projeto se devem a uma ´pobre´ comunica-
ção entre os principais envolvidos no projeto (ou
seja, os stakeholders). Num projeto, as questões
essenciais que um gerente deve se fazer são:
1. Que problema precisamos solucionar?
2. Quais recursos necessito para resolver?
3. Quanto tempo disponho para o projeto e im-
plementação da solução?
A lição que fica é: sem o entendimento completo
do problema a ser tratado e um bem elaborado
plano de projeto em mãos, você (gerente) e sua
equipe não saberão onde querem e precisam
chegar. A conseqüência é você (juntamente com
sua equipe) deparar-se com a inserção de defei-
tos logo cedo no desenvolvimento, os quais virão,
apenas bem mais tarde, a serem descobertos,
resultando em atraso no projeto e/ou comprome-
tendo a qualidade do produto final.
Essas situações apontadas ocorrem, com fre-
qüência, quando não há qualquer ‘preocupação’
com a gestão de projeto do software. Essas, den-
tre outras, são razões pelas quais muitos projetos
se transformam em casos de insucesso.
Por que a Gestão de Projetos é Essencial?
A gestão de projetos é uma atividade ortogonal às
demais atividades de projeto e atua como guia
para a boa execução do projeto. Todas as pesso-
as envolvidas com um projeto têm a necessidade
de acesso às suas informações. Quando lidamos
com projeto de médio a grande porte e de nature-
za complexa, uma atividade chave é a coordena-
ção. Um gerente de projeto precisa coordenar:
§ Múltiplas pessoas de formação diversa;
§ Múltiplas tarefas onde ocorre relação de depen-
dência;
§ Uso de múltiplos recursos (como equipamentos,
ferramentas, laboratórios);
§ Decisão e aprovação em múltiplos pontos num
projeto;
§ Alocação adequada de recursos humanos e
financeiros a tarefas.
Portanto, é preciso dar visibilidade e compartilhar
informações de projeto, pois as decisões preci-
sam ser tomadas com base de informações bem
entendidas e explicitadas.
A qualidade resultante de um produto ou sistema
é determinada a partir do início de seu desenvol-
vimento. Uma criteriosa análise, feita logo cedo
no projeto, visa encontrar erros, identificar incon-
sistências e averiguar quão correto e completo é
o entendimento do problema e adequada é a
solução trabalhada.
Isto torna a gestão de projeto uma atividade es-
sencial à execução de projetos e sucesso de pro-
dutos. A gestão de projetos de software pode ser
vista sob duas perspectivas: técnica e pessoal
onde a ênfase se dá sobre atividades de plane-
jamento e execução, conforme ilustrado na Figura
1.
Figura 1. Perspectivas da gestão de projetos.
Perceba que a visão ilustrada na Figura 1 é uma
visão simplificada das reais necessidades de
projetos. Dominar as habilidades necessárias a
uma boa gestão de projetos requer tempo, expe-
riência e reciclagem. Embora algumas pessoas
sejam levadas a acreditar que a capacidade para
fazer a gestão de projetos seja um mito, isso não
passa de uma falácia. Não se trata de caracterís-
tica inata que o indivíduo traz consigo, mas de um
conjunto de habilidades que podem ser reconhe-
17
cidas, classificadas e desenvolvidas pelas pesso-
as.
O reconhecimento desses fatos tem motivado os
profissionais a buscarem atualizar-se, bem como
às empresas a considerarem a gestão de projetos
no plano estratégico da instituição.
Hoje em dia, profissionais e empresas buscam a
capacitação em gestão de projetos que seguem
as orientações da principal referência mundial no
assunto: o PMI (Project Management Institute) o
qual tem tido um crescimento quase exponencial
no número de afiliações, que hoje conta com mais
de 240 mil profissionais membros.
Métricas e Estimativas de Software
Imagine que você faça parte de uma equipe de
Rally, e que você e sua equipe tenham que atra-
vessar um deserto enorme e cheio de obstáculos
e que 50% dos fatores críticos de sucesso de-
pendam do seu navegador para estimar o tempo
do percurso e a distância.
Agora imagine-se diante de um projeto de Siste-
mas de Informação onde 50% dos fatores críticos
de sucesso estão nos prazos e custos. Certamen-
te você terá que fazer uma eficiente métrica e
estimativa de software.
As métricas e estimativas de software vem se
tornando um dos principais tópicos na Engenharia
da Informação com a crescente exigência de seus
consumidores pela qualidade, rapidez, comodida-
de e baixo custo de implantação e manutenção, é
impossível não enxergar tais técnicas como ala-
vanca para um produto de melhor qualidade, com
custos adequados.
Mas existem ainda muitas barreiras que impedem
os profissionais da área de utilizarem tais técnicas
ou de o fazerem de maneira errônea, embora a
literatura disponível atualmente sobre engenharia
da informação seja relativamente ampla e varia-
da, o que nos leva a questionar: Por que as mé-
tricas e estimativas de software propostas para o
desenvolvimento de sistemas não são fiéis à rea-
lidade e à dimensão do problema? Tais técnicas
acompanharam a rápida evolução do setor?
Tais questões nos levam a crer que algumas mé-
tricas e estimativas de software ficaram obsoletas
e outras ganharam vigor nas épocas atuais,
quando a busca da qualidade de software vem
crescendo com grande rapidez.
Acredito que o ato de medir e estimar é a parte
mais importante de um projeto de sistema bem-
sucedido e alguns fatos como: a falta de maturi-
dade, o desinteresse das empresas de desenvol-
vimento de sistemas e a baixa popularidade deste
assunto entre os profissionais da área de informá-
tica são algumas das principais causas para o
insucesso e o alto custo dos sistemas de informa-
ção.
O termo métrico de software refere-se à mensu-
ração dos indicadores quantitativos do tamanho e
complexidade de um sistema. Estes indicadores
são, por sua vez, utilizados para correlatar contra
os desempenhos observados no passado afim de
derivar previsões de desempenho futuro.
A métrica de software tem como princípios espe-
cificar as funções de coleta de dados de avalia-
ção e desempenho, atribuir essas responsabilida-
des a toda a equipe envolvida no projeto, reunir
dados de desempenho pertencentes à comple-
mentação do software, analisar os históricos dos
projetos anteriores para determinar o efeito des-
ses fatores e utilizar esses efeitos para pesar as
previsões futuras. Estes princípios nos permitem
prever o resto do processo, avaliar o progresso e
reduzir a complexidade, como numa prova de
rally, onde a cada corrida ficamos mais esclareci-
dos da condições e limites da equipe.
As Métricas Orientadas ao Tamanho
Métricas de software orientadas ao tamanho são
medidas diretas do software e do processo por
meio do qual ele é desenvolvido. Se uma organi-
zação de software mantiver registros simples,
uma tabela de dados orientada ao tamanho pode-
rá ser criada. A tabela relaciona cada projeto de
desenvolvimento de software que foi incluído no
decorrer dos últimos anos aos correspondentes
dados orientados ao tamanho deste projeto. A
partir dos dados brutos contidos na tabela, um
conjunto de métricas de qualidade e de produtivi-
dade orientadas ao tamanho pode ser desenvol-
vido para cada projeto. Médias podem ser compu-
tadas levando-se em consideração todos os pro-
jetos.
As métricas orientadas ao tamanho provocam
controvérsias e não são universalmente aceitas
18
como a melhor maneira de se medir o processo
de desenvolvimento de software.
A maior parte da controvérsia gira em torno do
uso das linhas de código (LOC) como uma medi-
da-chave. Os proponentes da afeição de linhas
de código afirmam que as mesmas são o "artefa-
to" de todos os projetos de desenvolvimento de
software que podem ser facilmente contados, que
muitos modelos existentes usam LOC ou KLOC
(milhares de linhas de código) como entrada-
chave e que já existe um grande volume de litera-
tura e de dados baseados nas linhas de código.
Por outro lado, os opositores afirmam que as
medidas LOC são dependentes da linguagem de
programação utilizada na codificação do projeto,
que elas penalizam programas bem projetados,
porém mais curtos, que elas não podem acomo-
dar facilmente linguagens não-procedurais e que
seu uso em estimativas requer um nível de deta-
lhes que pode ser difícil de conseguir (isto é, o
planejador deve estimar as linhas de código a ser
produzidas muito antes que a análise e o projeto
tenham sido construídos).
Essa forma de medida foi uma herança do mode-
lo de manufatura em que os CIO'S podiam deter-
minar os recursos necessários para uma "corri-
da", contando o número de produtos manufatura-
dos necessários. Essa métrica não leva em con-
sideração o fato de que o desenvolvimento envol-
ve um custo relativo ao ambiente ou linguagem
de programação utilizada. Por exemplo, em orien-
tação a objeto (OO), a flexibilidade da ferramenta
no uso de mecanismos de herança dilui o resulta-
do final da contagem de linhas.
A contagem de linhas de código pode ser uma
medida do que foi feito, e não uma medida a ser
utilizada para previsão.
Métricas Orientadas à Função
Consiste em um método para medição de softwa-
re do ponto de vista do usuário, que determina de
forma consistente o tamanho e complexidade de
um software, sob a perspectiva do usuário. Ele
dimensiona um software, quantificando a funcio-
nalidade proporcionada ao usuário a partir do seu
desenho lógico. Ou seja, são medidas indiretas
do software e do processo por meio do qual ele é
desenvolvido. Em vez de contar linhas de código,
a métrica orientada à função concentra-se na
funcionalidade ou utilidade do programa. Uma
abordagem foi sugerida baseada nesta proposta
chamada de pontos-por-função (function point).
Os pontos-por-função (FP’s) são derivados usan-
do-se uma relação empírica baseada em medidas
de informações e complexidade do software.
Um dos princípios da análise de pontos-por-
função focaliza-se na perspectiva de como os
usuários "enxergam" os resultados que um siste-
ma produz. A análise considera as várias formas
com que os usuários interagem com o sistema,
com os seguintes objetivos:
1. Fornecer medidas consistentes;
2. Medir funcionalidades que o usuário solicita ou
recebe;
3. Independência da tecnologia;
4. Método simples.
As métricas orientadas à função apresentam vá-
rios benefícios, dentre eles podemos citar o se-
guinte:
1. Uma ferramenta para dimensionar aplicações;
2. Um veículo para quantificar custo, esforço e
tempo;
3. Um veículo para calcular índices de produtivi-
dade e qualidade;
4. Um fator de normalização para comparar sof-
tware.
Tal métrica parece ser útil e funcional para o de-
senvolvimento tradicional, mas apresenta algu-
mas falhas com o modelo de desenvolvimento em
orientação a objeto (OO), pois alguns atributos do
design em OO invalidam o cálculo de alguns pon-
tos-por-função. As características fundamentais
de OO têm efeito de reduzir a validade da conta-
gem de funções para a avaliação de esforço e
recursos necessários para a execução de um
projeto.
A métrica de pontos por função foi originalmente
projetada para sistemas de informação comerci-
ais. Para acomodar estas aplicações, a dimensão
dos dados foi enfatizada para a exclusão de di-
mensões funcionais e de controle. Por esta razão,
a medida de pontos por função era adequada
para muitos sistemas de engenharia. Um número
19
de extensões para a medida básica de pontos por
função tem sido propostas para remediar esta
situação.
Uma extensão de pontos por função chamada
"feature points" (ou, pontos característicos) é uma
evolução da medida de pontos por função que
pode ser aplicada a sistemas e aplicações de
engenharia de software. A medida "feature points"
acomoda aplicações em que a complexidade
algorítmica é alta. Sistemas real-time de controle
de processos e outros apresentam alta complexi-
dade algorítmica, e são receptivos a métrica de
"feature points".
Para computar o "feature point", valores do domí-
nio são contados e ponderados. A métrica "featu-
re point" conta uma nova característica de softwa-
re, os algoritmos. Um algoritmo é definido como
"um problema computacional que é incluído com
um programa de computador específico". Inverte
uma matriz, decodificar um bit de string ou manu-
sear uma interrupção são exemplos de algorit-
mos.
Outra extensão de pontos por função para siste-
mas real-time e produtos de engenharia tem sido
desenvolvido por Boeing. A aproximação de
Boeing integra a dimensão dos dados de software
com dimensões funcionais e de controle para
obter uma medida orientada à função, chamada
pontos por função 3D, que é receptiva a aplica-
ções que enfatizem capacidades de função e
controle. Características de todas as três dimen-
sões dão "contadas, quantificadas e transforma-
das" em uma medida que fornece uma indicação
da funcionalidade fornecida pelo software.
Contagem de dados retidos (a estrutura de dados
interna do programa, isto é, arquivos) e dados
externos (entradas, saídas e referências exter-
nas) são usados com medidas de complexidade
para derivar uma contagem da dimensão de da-
dos.
A dimensão funcional é medida considerando "o
número de informações internas requeridas para
transformar entradas em dados de saída". Para
os propósitos da computação de pontos por fun-
ção 3D, uma transformação é vista como uma
série de passos de processamento que são limi-
tados por regras semânticas estabelecidas. Como
uma regra geral, a transformação é concluída
com um algoritmo que resulta em uma mudança
fundamental para dados de entrada como são
processados para se transformarem em dados de
saída. Passos de processamento que adquirem
dados de um arquivo e simplesmente os coloca
na memória do programa não poderia ser consi-
derado uma transformação. O dado não sofreu
nenhuma mudança.
O nível de complexidade associado a cada trans-
formação é uma função do número de passos de
processamento e o número de regras semânticas
é que controla os passos de processamento.
A dimensão de controle é medida pela contagem
do número de transições entre os estados. Um
estado representa algum modo internamente
observável de comportamento e uma transição
ocorre como resultado de algum evento que força
o software ou sistema a mudar seu comportamen-
to, isto é, mudar seu estado.
Quando pontos por função 3D são computados,
transições não são associadas a valores de com-
plexidade.
Nota-se que pontos por função, "feature points" e
pontos por função 3D representam a mesma coi-
sa – "funcionalidade" ou "utilidade" fornecida pelo
software. De fato, cada uma destas medidas re-
sulta no mesmo valor se somente a dimensão de
dados de uma aplicação é considerada.
Para sistemas real-time mais complexos, a con-
tagem "feature points" é de 20 a 35% mais alta
que a contagem determinada usando somente
pontos por função.
Pontos por função (e suas extensões), como a
medida LOC, é controversa. Os proponentes
acham que FP é independente da linguagem de
programação, tornando-se ideal para aplicações
usando linguagens convencionais e não procedu-
rais, e que ela é baseada em dados que são co-
nhecidos muito cedo na evolução do projeto, fa-
zendo a FP mais atrativa como uma estimativa
mais próxima.
Oponentes acham que o método requer alguma
prestidigitação em que a computação é baseada
em dados subjetivos, que a contagem das infor-
mações de domínio (e outras dimensões) podem
ser difíceis de coletar após terminado o projeto, e
que FP não tem significado físico direto. É só um
número.
20
Métricas Voltadas para Orientação a Objeto
Muitas métricas já foram desenvolvidas para ge-
rações passadas de tecnologia e, em muitos ca-
sos, são usadas até para desenvolvimento OO,
porém não são muito coerentes, pois a diferença
entre sistemas tradicionais e sistemas OO são
muito grandes.
Existem várias propostas para métricas OO que
levam em consideração as características básicas
e interações do sistema como: número de clas-
ses, número de cases, número de métodos, mé-
dias de métodos, médias de métodos por classe,
linhas de código por método, profundidade máxi-
ma da hierarquia de classes, a relação existente
entre métodos públicos e privados, entre outros.
Tais métricas baseiam-se na análise detalhada do
design do sistema. Como na técnica de pontos-
por-função, faz sentido adicionar um peso às
métricas das classes para produzir uma medida
de complexidade do sistema. A maioria das me-
didas examina atributos em termos dos conceitos
de OO, como herança, polimorfismo e encapsu-
lamento. Para tanto, seria necessário coletar um
número significativo de contagens, ou seja, seria
necessário tomar valores de vários projetos e
dimensioná-los selecionando as classes, os mé-
todos e os atributos desejáveis para medir o ta-
manho e a complexidade de um novo software, o
que nos tomaria um longo tempo.
Documentação De Software
A documentação de software mesmo sendo o
carma de qualquer desenvolvedor, é extrema-
mente necessária e auxilia na redução de horas
preciosas na correção de problemas. Neste pri-
meiro momento, vamos ver o que é a documenta-
ção de um sistema, suas partes principais e tam-
bém as ferramentas que auxiliam desenvolvedo-
res a fazer desta uma tarefa menos maçante.
Para muitos desenvolvedores a criação de docu-
mentação técnica é a parte mais aterrorizante
para se enfrentar em todo o processo de criação
de um software, seja pela necessidade de escre-
ver várias e várias páginas de texto, gráficos e
desenhos ou ainda pela necessidade de largar
aquilo que se aprendeu (programar) para fazer
aquilo que não sabe bem (redigir).
Entretanto a documentação é parte integrante de
qualquer sistema ou programa criado. Arrisco a
dizer inclusive que a documentação é tão impor-
tante (ou mais) que as questões de segurança
pois sem a devida documentação, bug’s e pontos
vulneráveis no sistema demoram a ser encontra-
dos e corrigidos, permitindo assim que os ataques
continuem levando à falência múltipla do sistema
e, consequentemente, de seu usuário.
Normalmente em grandes corporações existem
pessoas e/ou equipes voltadas única e exclusi-
vamente para a criação de documentação, sendo
que o desenvolvedor fica restrito à codificação e
comentários de seu código. Já no mundo “real”,
esta atividade é realizada pelo próprio desenvol-
vedor e demanda um bom conjunto de horas para
planejar e criar cada uma de suas partes a fim de
atender minimamente as necessidades do produ-
to desenvolvido. Então, como não é possível evi-
tar a criação da documentação técnica, vamos
tentar amenizar um pouco sua horrível aparência
usando ferramentas que auxiliam na tarefa de
domar o monstro. Mas antes disso, uma pequena
apresentação do que é a documentação em si.
Documentação, o que é?
A documentação de um software é composta por
várias partes diferentes que abrangem todo o
sistema e pode ser dividida em dois grandes gru-
pos: documentação técnica e documentação de
uso. A primeira é voltada ao desenvolvedor ou
pessoa de TI e compreende principalmente dicio-
nários e modelos de dados, fluxogramas de pro-
cessos e regras de negócios, dicionários de fun-
ções e comentários de código.
Já a documentação de uso é voltada tanto para o
usuário final quanto para o administrador do sis-
tema e comumente é formada por apostilas ou
manuais que apresentam como o software deve
ser usado, o que esperar dele e como receber as
informações que se deseja.
A primeira parte (técnica) é, para o desenvolve-
dor, a mais simples pois literalmente descreve
seu trabalho e também é utilizada pelo mesmo
como ferramenta para o desenvolvimento de um
bom código. Já a segunda costuma ser um martí-
rio pois a redação de manuais, inserção
de screenshots, desenhos e outros elementos
gráficos não é aquilo que podemos considerar
21
como skill deste profissional (são raros os que
possuem).
Ambas podem ser criadas em vários formatos de
visualização tais como páginas HTML, documen-
tos PDF, apresentações, vídeos ou ainda arqui-
vos texto. A forma de apresentação não importa.
O importante é saber que para cada tarefa existe
uma ferramenta certa, inclusive para a documen-
tação de sistemas em qualquer nível de comple-
xidade ou necessidade e que precisa ser feita, de
uma forma ou de outra.
As Ferramentas para Documentação
Aproveitando a divisão da documentação em
duas grandes áreas, vamos conhecer suas partes
e algumas ferramentas que ajudam e/ou facilitam
aqueles que tem pela frente a tarefa de gerar
documentação de sistemas.
Modelos de dados
Modelos de dados são aquelas folhas com várias
caixinhas das tabelas de um banco de dados
interligadas e que muitas vezes somente são
utilizadas para decoração de escritórios. Mas
longe de ser um quadro ou pôster, o modelo de
dados reflete de uma forma gráfica (e lógica) a
base de dados de um sistema, seus relaciona-
mentos, entidades, chaves e tudo aquilo que é
referente aos dados em si.
Este modelo, junto com o dicionário de dados, é
peça fundamental para o desenvolvimento de um
sistema, sendo inclusive pensado e criado AN-
TES do início do desenvolvimento. Um bom mo-
delo de dados bem pensado e bem estruturado
não impacta somente em um bom código, mas
também na performace da aplicação com um todo
e na redução de horas de desenvolvimento equi-
vocado.
Para criá-lo são utilizadas ferramentas de mode-
lagem de dados, as quais geram de forma gráfica
as tabelas, índices, relacionamentos e tudo aquilo
que tem a ver com a base de dados em si, po-
dendo ser criados por meio de engenharia rever-
sa ou ainda baseando-se nas necessidades do
aplicativo que está sendo desenvolvido.
As ferramentas mais conhecidas para modelagem
de dados dentro do mundo livre são o DBDesig-
ner, MySQL Workbenche também o PGDesigner,
as quais possuem funcionalidades diferentes e
dispõem de versões tanto para Linux quanto para
Windows.
Conhecimento em RUB
O Processo Unificado da Rational conheci-
do como RUP (Rational Unified Process), é um
processo de engenharia de software criado para
apoiar o desenvolvimento orientado a objetos,
fornecendo uma forma sistemática para se obter
vantagens no uso da UML. Foi criado pela Ratio-
nal Software Corporation e adquirido em fevereiro
de 2003 pela IBM.
O principal objetivo do RUP é atender as neces-
sidades dos usuários garantindo uma produção
de software de alta qualidade que cumpra um
cronograma e um orçamento previsíveis. Assim, o
RUP mostra como o sistema será construído na
fase de implementação, gerando o modelo do
projeto e, opcionalmente, o modelo de análise
que é utilizado para garantir a robustez. O RUP
define perfeitamente quem é responsável pelo
que, como as coisas deverão ser feitas e quando
devem ser realizadas, descrevendo todas as me-
tas de desenvolvimento especificamente para que
sejam alcançadas.
O RUP organiza o desenvolvimento de software
em quatro fases, onde são tratadas questões
sobre planejamento, levantamento de requisitos,
análise, implementação, teste e implantação do
software. Cada fase tem um papel fundamental
para que o objetivo seja cumprido, distribuídos
entre vários profissionais como o Analista de sis-
tema, Projetista, Projetista de testes, entre outros.
Fases do RUP
Fase de Concepção / Iniciação: Esta fase do RUP
abrange as tarefas de comunicação com o cliente
e planejamento. É feito um plano de projeto avali-
ando os possíveis riscos, as estimativas de custo
e prazos, estabelecendo as prioridades, levanta-
mento dos requisitos do sistema e preliminarmen-
22
te analisá-lo. Assim, haverá uma anuência das
partes interessadas na definição do escopo do
projeto, onde são examinados os objetivos para
se decidir sobre a continuidade do desenvolvi-
mento.
Fase de Elaboração: Abrange a Modelagem do
modelo genérico do processo. O objetivo desta
fase é analisar de forma mais detalhada a análise
do domínio do problema, revisando os riscos que
o projeto pode sofrer e a arquitetura do projeto
começa a ter sua forma básica. Indagações como
"O plano do projeto é confiável?", "Os custos são
admissíveis?" São esclarecidas nesta etapa.
Fase de Construção: Desenvolve ou Adquire os
componentes de Software. O principal objetivo
desta fase é a construção do sistema de software,
com foco no desenvolvimento de componentes e
outros recursos do sistema. É na fase de Cons-
trução que a maior parte de codificação ocorre.
Fase de Transição: Abrange a entrega do softwa-
re ao usuário e a fase de testes. O objetivo desta
fase é disponibilizar o sistema, tornando-o dispo-
nível e compreendido pelo usuário final. As ativi-
dades desta fase incluem o treinamento dos usu-
ários finais e também a realização de testes da
versão beta do sistema visando garantir que o
mesmo possua o nível adequado de qualidade.
CMMI
O dia-a-dia dentro da área de desenvolvimento de
software é caracterizado por uma grande pressão
no que se refere a prazos de entrega, custos e
qualidade daquilo que se está produzindo. Inde-
pendente do tamanho das equipes voltadas a
tarefas deste tipo, muitas organizações possuem
dificuldades em gerenciar tais atividades, sendo
comum a ocorrência de atrasos, estouros orça-
mentários e sistemas que ficam aquém do espe-
rado.
Levando em consideração esses fatos, alguns
modelos foram desenvolvidos de forma a auxiliar
a condução de atividades que envolvam projetos
de software. O objetivo deste artigo é fornecer
uma visão geral sobre dois destes modelos
(CMMI e MPS-BR), baseando-se para isto em um
conceito conhecido como “maturidade”.
O termo “maturidade” deve ser compreendido
como a capacidade de se repetir uma série de
resultados de uma maneira previsível. Importante
ressaltar ainda que os modelos CMMI e MPS-BR
contemplam diferentes níveis de maturidade,
disponibilizando-se assim uma forma de mensu-
rar o grau de progresso atingido por uma organi-
zação na implementação de projetos de software.
CMMI
O CMMI (Capability Maturity Model Integration) foi
criado pelo SEI (Software Engineering Institute), o
qual é um órgão integrante da universidade norte-
americana Carnegie Mellon. Trata-se de um mo-
delo que está atualmente na versão 1.3 (Janei-
ro/2013), com um enfoque voltado para a capaci-
dade de maturidade de processos de software.
Um processo representa, dentro da área de sof-
tware, um conjunto de atividades cujo objetivo é
atingir uma meta previamente estipulada. Já por
capacidade e maturidade de um processo, deve-
se ter a noção do grau de qualidade com o qual
um processo atinge um resultado esperado.
O CMMI está dividido em 5 níveis de maturidade
(Figura 1) que atestam, por sua vez, o grau de
evolução em que uma organização se encontra
num determinado momento. Além disso, tem por
objetivo principal funcionar como um guia para a
melhoria dos processos da organização, conside-
rando para isto atividades como o gerenciamento
do desenvolvimento de software, prazos e custos
previamente estabelecidos.
O objetivo maior, considerando o CMMI e seus
diferentes conceitos, está justamente na produ-
ção de software com maior qualidade e menos
propenso a erros.
23

Figura 1: Os diferentes níveis de maturidade do
CMMI
Dentre os principais benefícios da implantação do
CMMI, vale a pena destacar:
 Uma maior confiabilidade no que refere ao
cumprimento de prazos e custos que foram acor-
dados, inicialmente, perante o cliente que solici-
tou o desenvolvimento de um sistema. Essa pre-
visibilidade é decorrente do rigor que o CMMI
exige quanto à medição dos processos, fato este
que conduz à obtenção de uma base histórica
realista e confiável para estes fins;
 O gerenciamento das atividades relativas à
produção de software aumenta consideravelmen-
te;
 Uma maior qualidade nos softwares cria-
dos, já que processos bem definidos e controla-
dos conduzem à produção de produtos mais con-
fiáveis;
 A menor dependência da empresa de de-
senvolvimento para com seus especialistas. Com
um foco voltado para processos e melhoria contí-
nua, além do uso intensivo de informações histó-
ricas, a organização deixa de depender única e
exclusivamente de profissionais com um elevado
grau de conhecimento técnico;
 A busca por melhorias contínuas nos pro-
cessos cotidianos.
Para se conseguir o que este modelo propõe, a
organização interessada na implantação do CMMI
deverá evoluir progressivamente, considerando
para isto uma sucessão de diferentes de níveis.
Cada nível indica, por sua vez, o grau de maturi-
dade dos processos num determinado instante:
 Nível 1 - Inicial: os processos normalmente
estão envoltos num caos decorrente da não obe-
diência ou ainda, inexistência de padrões;
 Nível 2 - Gerenciado: os projetos têm seus
requisitos gerenciados neste ponto. Além disso,
há o planejamento, a medição e o controle dos
diferentes processos;
 Nível 3 - Definido: os processos já estão
claramente definidos e são compreendidos dentro
da organização. Os procedimentos se encontram
padronizados, além de ser preciso prever sua
aplicação em diferentes projetos;
 Nível 4 - Gerenciado Quantitativamente:
ocorre o aumento da previsibilidade do desempe-
nho de diferentes processos, uma vez que os
mesmos já são controlados quantitativamente;
 Nível 5 - Otimizado: existe uma melhoria
contínua dos processos.
A implantação do CMMI é recomendável para
grandes fábricas de software. Implementar os
diversos estágios é uma tarefa árdua, não só
numa fase inicial, mas também quando se leva
em conta a migração de um nível para outro. Isto
exigirá, invariavelmente, a realização de vultosos
investimentos financeiros, assim como uma mu-
dança de postura da organização (principalmente
quando a mesma não contava uma experiência
anterior bem-sucedida no gerenciamento de pro-
cessos).
Mais sobre SCRUM
O SCRUM é um framework para gerenciamento
de produtos complexos, isso quer dizer que o
SCRUM não é aplicado somente à área de TI,
também pode ser utilizado em diversas áreas do
conhecimento. O SCRUM NÃO É um processo ou
técnica, ele é um framework, que pode agrupar
vários processos e técnicas.
O SCRUM é iterativo e incremental. Isso significa
que ele trabalha com iterações (períodos pré-
determinados de desenvolvimento), e de maneira
incremental (a medida que as iterações vão pas-
sando, mais valor é agregado ao produto).
Os Pilares
Existem três pilares que mantém o uso do
SCRUM, são importantíssimos para seu bom
24
funcionamento. Segui-los não garante que você
conseguirá implementar o SCRUM em sua orga-
nização, mas aumentam suas chances conside-
ravelmente.
 Transparência: os aspectos mais significa-
tivos do projeto devem estar visíveis para todos
os envolvidos, aumentando assim a visibilidade
do andamento do projeto. Deixando claro o que
está sendo feito, o que ainda será feito, e o que
está pronto;
 Inspeção: os envolvidos devem inspecionar
os artefatos gerados, para verificar se o projeto
está seguindo de acordo com o planejado, detec-
tando variações de desempenho. Deve-se tomar
cuidado com a frequência das inspeções para
que não chegue ao ponto de atrapalhar o anda-
mento do desenvolvimento;
 Adaptação: baseado nos resultados obtidos
da inspeção, a adaptação realiza as alterações
necessárias para que o projeto continue seu bom
andamento, ou para consertar falhas;
Os Papéis
O Time SCRUM é composto pela Equipe de De-
senvolvimento, o SCRUM Master e o Product
Owner. O Time deve ser auto-gerenciável e mul-
tidisciplinar, isto é, os componentes do time de-
vem ser proativos, e comprometidos com o proje-
to. E dentro do time, deve haver pessoas que
possam projetar, desenvolver e testar. O SCRUM
é projetado para melhorar a flexibilidade, criativi-
dade e produtividade.
 A Equipe de Desenvolvimento: é com-
posta pelos desenvolvedores, os que criam in-
crementos para o produto. Assim como o Time
SCRUM, as Equipes de Desenvolvimento tam-
bém são auto gerenciáveis. Outro detalhe impor-
tante, é que o SCRUM não define títulos, todos os
membros da equipe de desenvolvimento são de-
senvolvedores, independentemente de sua fun-
ção (se vai testar, programar ou projetar). Existe
uma discussão muito grande quanto ao tamanho
da equipe de desenvolvimento, algumas pessoas
dizem que o número ideal é 7 (com uma margem
de 2 pra mais ou menos, ou seja, 5 a 9), outros
dizem ser 8, 9. Enfim, este valor varia bastante de
equipe para equipe. O SCRUM Guide define que
o tamanho exato é um número de membros pe-
queno o suficiente para que a equipe se mante-
nha ágil, e grande o bastante para que consiga
entregar o trabalho.
 O Product Owner: é o responsável por
maximizar o ROI (retorno sobre investimento) do
produto. Ele é responsável por gerenciar o bac-
klog do produto. Priorizando as tarefas, alimen-
tando o backlog. E garantindo que a Equipe de
Desenvolvimento entenda os itens do backlog. O
PO pode delegar essa tarefa para a equipe de
desenvolvimento, no entanto, ele continua sendo
o responsável. O PO é uma pessoa (apenas
uma), que deverá se comprometer com o produto,
qualquer alteração só será realizada mediante
solicitação do PO, logo se existir uma comissão
interessada no projeto, devem passar as solicita-
ções para o PO, e esse sim deverá solicitá-las a
equipe de desenvolvimento.
 O SCRUM Master: o SM é o responsável
pela aplicação e andamento do SCRUM na orga-
nização, sua função é remover impedimentos, e
proteger a equipe de intervenções externas. O
SM NÃO É um Gerente de Projetos. Ele não de-
lega tarefas, sua função é facilitar o andamento
do processo. Ele é um líder-servo, deve tomar
suas decisões baseado no bem da equipe. Como
já disse, ele é o facilitador do processo, e sua
rigidez depende da experiência e maturidade da
equipe, com equipes novas, e que ainda não con-
seguem se auto-gerenciar, o SM deve ser mais
rígido, e mostrar como o SCRUM deve ser execu-
tado, com equipes mais experientes, sua rigidez
diminui.
ANOTAÇÕES
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
25