14 Maio | Porto Alegre RS, Brasil

Modelagem gil
Clayton Barbosa
Faculdade QI Jlio de Castilhos
claycezar@gmail.com

Gabriel Alves

Fbio dos Santos

Faculdade QI Jlio de Castilhos

gabriellvs60@gmail.com

Resumo
Este artigo apresenta o processo de modelagem de software
conhecido como Agile Modeling (AM), mostrando suas
caractersticas e seus princpios. Os prs e os contras desta
metodologia so abordados, auxiliando a identificao do
tipo de projeto no qual este processo poder ser mais
eficiente que os processos prescritivos tradicionais..

Introduo

Faculdade QI Jlio de Castilhos

fabiockt@ibest.com.br

como as citadas h pouco, como tambm em metodologias

prescritivas como o Unified Process.

Agile Modeling
Segundo Scott W. Ambler, Agile Modeling (AM) uma
metodologia baseada na prtica para modelagem eficaz de
software. AM uma coleo de prticas, guiadas por

O processo atual de desenvolvimento de software em

princpios e valores que podem ser aplicados por

vrios lugares est em um nvel de qualidade muito abaixo

do que seria considerado ideal, pois normalmente os
sistemas so entregues aos clientes fora do prazo
estipulado no projeto preliminar e com um custo maior do
que o previsto; alm disso, esses sistemas frequentemente
no alcanam a qualidade desejada pelo cliente e, em
muitos casos, no satisfazem as reais necessidades dos
mesmos, necessitando ser desenvolvidos de novo, e de
novo, e de novo, num processo conhecido por muitos
profissionais como isso ter de ficar para uma prxima
verso.

profissionais de software no dia a dia. No sendo um

processo prescritivo, no define procedimentos detalhados
de como criar um dado tipo de modelo, em vez disso,
prov conselhos de como ser efetivo como modelador. Em
resumo, AM busca o ponto de melhor custo/benefcio entre
os artefatos que devem ser criados para o sistema e o custo
de manuteno e atualizao desses artefatos.
Pode-se citar duas motivaes principais para a criao

Uma das propostas para minimizar esse problema o Agile

Modeling (AM), um processo de desenvolvimento de
software baseado em prticas que visa aumentar a
eficincia da equipe dentro de um projeto de
desenvolvimento de software. Ao contrrio dos processos
tradicionais como o sugerido pelo Unified Process, por
exemplo, que requer basicamente os mesmos artefatos para
todos os tipos de projetos, AM busca a construo e
manuteno eficiente de artefatos, criando-os apenas
quando agregarem valor real ao projeto, e focando
principalmente os esforos no desenvolvimento do
software que, em ltima anlise, o objetivo principal do
processo.
Deve-se notar, entretanto, que AM no uma metodologia
de desenvolvimento gil como eXtreme Programming
(XP), SCRUM, DSDM, etc., mas uma metodologia de
modelagem gil, isto , AM visa construir e manter
modelos de sistemas de maneira eficaz e eficiente e,
portanto, pode ser utilizada dentro de metodologias geis

desta metodologia:
1.

O objetivo primrio de um projeto de software o

prprio software, e no um grande conjunto de
documentao sobre ele;

2.

Um artefato criado primordialmente para

permitir a comunicao e a troca de informaes
entre a equipe (um modelo de classes criado
para passar para a equipe a hierarquia imaginada
pelo projetista, assim como um diagrama de casos
de uso criado para a equipe ter uma viso do
mecanismo

da

funcionalidade

envolvida)

permitir a discusso e refinamento do modelo do

sistema. Assim, se um artefato no est passando

informao relevante ao projeto, ele no cumpre

suficiente para especificar o sistema, que o cliente

seu objetivo bsico.

vive mudando de ideia sobre o que o sistema deve

fazer, que o cliente vive adicionando requisitos,

Baseado nessas constataes um grupo de

etc., porm essa a realidade do processo de

pesquisadores (entre eles Grady Booch, Martin

desenvolvimento; em vez de tratar o cliente como

Fowler e Alistair Cockburn) com suporte de

aquele pessoal que s atrapalha, deve-se realizar

algumas

Rational,

um trabalho de descoberta das necessidades do

TogetherSoft e Object Mentor), criaram a Agile

cliente e educao do mesmo para o processo

Software

foi

durante a durao do projeto. um caminho

definido um manifesto para o incentivo s

bastante rduo, porm tem se mostrado muito

melhores maneiras de produo de software,

gratificante para aqueles que o trilham.

empresas

(entre

Development

elas

Alliance,

onde

definindo valores que devem ser praticados para a

obteno de um processo mais interativo e menos

Aceitao das mudanas em vez de obedincia

burocrtico do que os atuais. Tais valores so:

cega a um plano: Mudanas fazem parte da vida,

especialmente na rea de desenvolvimento de

Indivduos e interao em vez de processos e

software;

simplesmente

contraproducente

ferramentas: Infelizmente em muitas empresas

reclamar desse fato... Em vez disso, acostume-se

de desenvolvimento de software os analistas e

s mudanas; no estamos dizendo que no se

gerentes de projeto acabam se limitando em

deve ter um plano de projeto, pelo contrrio: o

documentaes e ferramentas de integrao de

plano deve ser flexvel o bastante para aceitar as

seus modelos e, com isso, acabam deixando de

mudanas do ambiente aonde esse software

lado algo que muito importante em uma equipe,

dever ser utilizado. De fato, um sistema que

que a cooperao de todos e os feedback dos

atendia aos requisitos do usurio na fase de

colaboradores envolvidos com o projeto.

anlise, porm no atende mais esses requisitos

quando posto em produo no configura

Software

funcional

em

vez

de

extensa

exatamente um sistema til, no mesmo?

documentao: Em vrias ocasies mais til

um prottipo simples que mostre o funcionamento

Definio de Modelos geis

de uma arquitetura do que um grande e complexo

diagrama de classes; tambm mais simples para

Um modelo utilizando AM simplesmente um modelo

o cliente analisar o funcionamento do sistema

eficiente, o qual apresenta as seguintes caractersticas:

atravs de um prottipo, mesmo que no seja real,

do que atravs de um conjunto de diagramas de

Atende o seu propsito: Um modelo tem por propsito

casos de usos e projetos de interface. No se trata

comunicar alguma coisa para a equipe. Se o modelo no

de abandonar o processo de documentao, mas

traz informao adicional sobre o projeto, ento ele no

apenas de utilizar a ferramenta certa para

est cumprindo o seu papel e no vale a pena pagar o custo

transmitir a informao desejada no momento.

necessrio para mant-lo;

Colaborao

de

inteligvel: Um modelo deve ser inteligvel, e no

renegociao de contrato: Quem deve definir o

com o

cliente

em vez

bonito. Isto significa que um modelo desenhado mo em

que o sistema deve ou no fazer o cliente. Pode-

uma folha de papel ou uma foto digital de um modelo

se dizer que o cliente no tem conhecimento

desenhado em um quadro branco pode comunicar a

informao pretendida to bem como o mesmo modelo

cliente no processo de desenvolvimento. AM no visa a

desenhado em uma ferramenta CASE da moda, com a

eliminao de ferramentas CASE: Pelo contrrio: AM diz

vantagem de ser muito mais fcil de ser construdo;

que a melhor ferramenta para criar um modelo a mais

simples. Se um modelo for mais fcil de ser desenhado em

suficientemente detalhado: Todo modelo deve ser

uma ferramenta CASE do que em um papel, ento a

atualizado de acordo com a evoluo do sistema. Se o

ferramenta CASE deve ser utilizada para a criao desse

modelo for exageradamente detalhado, o custo de manter

modelo.

esse modelo atualizado maior devido sua maior

AM na prtica

complexidade. O modelo deve ser suficientemente

detalhado para conseguir transmitir a informao desejada
e manter o custo de manuteno em um nvel mnimo.

Mais detalhe que esse ponto pode inserir informao

desenvolvimento de software uma experincia tanto

demais no modelo, o que gera uma complexidade

interessante quanto traumtica, devido grande mudana

desnecessria. Esse detalhamento adicional normalmente

de pensamento acarretada pelo mtodo e tambm devido

pode

inrcia natural das pessoas frente a mudanas.

ser

colocado

em

um

outro

modelo

ou,

implantao

de

AM

dentro

da

cultura

de

preferencialmente, definido pelo prprio cdigo do

sistema.

Para direcionar os esforos em torno de AM, existem

alguns princpios que devem ser observados para que o

Definio de Modelagem gil

processo adotado seja realmente gil. Dentre esses

princpios, os mais importantes so:

Deve-se diferenciar o que so os modelos geis, descritos

na seo anterior, do processo de modelagem gil.

5.1 Princpios fundamentais ou centrais:

Tambm importante estabelecer o escopo do AM para

esclarecer o que pode e o que no pode ser atendido por

este processo: AM um complemento aos processos

Software seu principal objetivo: software que

funcione.

existentes; no uma metodologia completa: AM foca em

modelagem e, em segundo plano, documentao. AM pode
ser utilizado para aumentar a eficincia da modelagem e

secundrio:

documentao, tanto em processos prescritivos como o

para a melhoria dos esforos de desenvolvimento de

pensar

sempre

nas

prximas

funcionalidades.

Unified Process quanto processos geis como o SCRUM;

AM no uma bala de prata: AM uma tcnica eficiente

Habilitar seu prximo esforo um objetivo

Viaje com pouca bagagem: menos documentos

software de muitos profissionais da rea. AM no uma

durante o projeto - escolher documentos a serem

espcie de leo mgico que resolver todos os problemas,

mantidos durante o processo de desenvolvimento.

tampouco uma tcnica que garantir melhores resultados.

A idia por trs de AM a de que se voc utilizar seus

Assuma Simplicidade.

Aceite a Mudana.

Aplique Mudanas Incrementais.

esforos de modelagem de maneira mais racional e

permanecer focado no projeto, ento provavelmente sua
eficincia no desenvolvimento do projeto ir aumentar;
AM no visa a eliminao da documentao: AM
simplesmente diz que a documentao deve ser feita de
modo mais racional, maximizando o investimento do

Modele com um propsito: para atender a

realidade, para melhorar a comunicao.

Construa Mltiplos Modelos.

Trabalhe com Qualidade.

Simplicidade:
- Crie contedo simples;
- Descreva modelos simples;
- Use a ferramenta mais simples.
Validao:
Considere a testabilidade;
Prove com cdigo.
6.2 Prticas suplementares

Obtenha rpido Feedback.

Maximize o investimento do Stakeholder

(pessoa chave que representa a empresa).

5.2 Princpios suplementares:

Contedo mais importante que

representao.
Cada um tem algo a aprender com o outro.
Conhea seus modelos.
Conhea suas ferramentas.
Adapte o modelo organizao.
Comunicao aberta e honesta.
Atente para os instintos da equipe: oua as
sugestes/reclamaes de sua equipe, pois talvez
o problema que a equipe encontrou poder
dificultar o restante da implementao.

Produtividade:
- Utilize padres e normas de modelagem;
- Aplique padres (design patterns) com
sabedoria;
- Reutilize recursos existentes.
Documentao:
- Descarte Modelos temporrios;
- Formalize os modelos de contrato Contract
Models;
- Atualize apenas quando di (para que o modelo
no fique
inconsistente).
Propsito:
- Modele para entender;
- Modele para comunicar.
Boas Idias:
- Conhea bem suas ferramentas;
- Refactoring;
- Test-First Design.

Prticas da AM
Modelagem na Obteno da Qualidade
O AM tambm possui dois tipos de prticas, as prticas
centrais e as prticas suplementares.
6.1 Prticas fundamentais ou centrais

Modelagem Iterativa e Incremental:

- Aplique o artefato correto;
- Crie vrios modelos em paralelo;
- Itere entre diferentes artefatos;
- Modele em pequenos incrementos.
Trabalho em Equipe:
- Modelar com outras pessoas;
- Participao ativa do Stakeholder;
- Conhecimento coletivo (nunca deixe somente
uma pessoa dominar todo o processo, pois se a
mesma morrer, acabou o projeto);
- Exiba modelos publicamente (colocar em
painis, parede, etc.).

A modelagem gil possui um princpio chamado Travel

Light. Este princpio diz que manter modelos difcil, e
pode se tornar ainda mais se estes forem complexos e
detalhados. Trs ou quatro modelos so suficientes para
melhorar a comunicao da equipe desde que forneam
uma viso geral da anlise, da arquitetura e do design.
errado pensar que quanto maior o nmero de
documentaes, melhor ser o projeto. A documentao
precisa ser enxuta.
Para direcionar os esforos em torno da modelagem gil,
existem alguns princpios que devem ser observados para
que o processo adotado seja realmente gil.
- Software seu principal objetivo: produzir softwares que
funcionem;
- Racionalizao de artefatos: racionalizao da
documentao, escolhendo aqueles que sero mantidos
durante o processo de desenvolvimento;
- Modele com um propsito: para atender a realidade e
para melhorar a comunicao;

- Contedo mais importante que a apresentao: o

software uma poderosa forma de validao junto ao
cliente;
- Cada um tem algo a aprender com o outro: na modelagem
gil comum a participao ativa do cliente. Esta interao
permite que ambas as partes se entendam melhor trazendo
importantes ganhos para o projeto;
- Adapte o modelo organizao: cada projeto possui suas
particularidades que precisam ser observadas;
- Comunicao transparente e honesta: transparncia das
informaes que devem estar em comum acordo para
ambas as partes;
- Atentar para os instintos da equipe: ouvir sugestes e
reclamaes da equipe pois talvez o problema que ela
encontrou pode dificultar o restante da implementao.

utilizar os esforos de maneira mais racional e

permanecer focado no projeto, aumentando sua eficincia
no desenvolvimento do mesmo.

Rascunhos como Forma de Modelagem

Quando falamos em modelagem de software, uma das
grandes dvidas das equipes de projeto quo longe
devemos nos aprofundar em detalhes. Como ponto de
partida podemos nortear nosso raciocnio atravs de
questionamentos como:
1- Qual o nome do projeto?
2- Qual a dvida que eu tenho?

Aspectos Humanos e Tcnicos no

Desenvolvimento de Software
A modelagem gil baseada em uma coleo de prticas
guiadas por princpios e valores que podem ser aplicados
por profissionais de software no dia a dia. Prov sugestes
de como ser mai efetivo. Busca o ponto de melhor
custo/benefcio entre os artefatos que devem ser criados
para que o sistema e o custo de manuteno e atualizao
destes artefatos.
Podemos citar duas motivaes principais para a criao
desta metodologia:
1- O objetivo primrio de um projeto de software o
prprio software, e no um grande nmero de documentos
sobre ele;
2- Um artefato criado primordialmente para permitir a
comunicao e a troca de informaes entre a equipe e
permitir a discusso e refinamento do modelo do sistema.
Assim, se um artefato no est passando informaes
relevantes ao projeto, ele no cumpre seu objetivo bsico.
Na verdade o que se quer com a modelagem do sistema
satisfazer as necessidades dos usurios, garantindo a
qualidade interna do software (integridades dos dados ou
codificao mais adequada) e respeitando as restries de
custo e prazo do projeto.
A misso de um bom modelador administrar as
expectativas do cliente, avaliando com Le quais problemas
so prioritrios. Uma das coisas que a metodologia gil
trouxe a tona a importante participao dos usurios ou
clientes para auxiliar na modelagem do sistema, seja
elaborando um mapa mental, rascunhando uma tela ou
testando um release que acabou de ser liberado.
sempre importante estabelecer o escopo da modelagem
gil para esclarecer o que pode e o que no pode ser
atendido por este processo. A modelagem gil um
complemento de processos existentes. A idia por trs dela

3- Quem poder modelar isso junto comigo para obter as

respostas?
4- Qual o modelo certo?
Lembrando que ao conversar com nosso cliente, nosso
principal objetivo ter uma compreenso em alto nvel do
sistema, e no de todos os detalhes.
Um dos valores da modelagem gil modelar com um
propsito, o que significa buscar os critrios de sucesso do
projeto. A modelagem busca atender ao usurio
apresentando qualidade e reduzindo custo ou prazo do
projeto. H uma quantidade infinita de maneiras de
modelar. Um esboo feito de forma conjunta com as partes
interessadas um meio muito eficiente de capturar
requisitos e descobrir como atingir o objetivo de fazer um
software com qualidade externa (atendimento s
funcionalidades acordadas com o cliente ou desempenho
esperado pelo software) que atendas s expectativas dos
usurios.

A Importncia do Documento de Requisitos

Software funcionando ainda o melhor artefato para
levantamento de requisitos. Dessa forma os usurios olham
o software e solicitam alteraes no mesmo e no em
documentos. Software a nica coisa concreta que
realmente validamos com os usurios.
Documentos de requisitos tm como objetivo registrar o
que os usurios esperam da aplicao independente da

soluo tcnica. Isso faz com que esses documentos sejam

simples e rpidos de serem elaborados. Mesmo mais
importante que estes artefatos sejam elaborados em

reunio de levantamento e no em casa.

AM para o desenvolvedor mdio, mas no um

substituto de pessoas competentes;

Concluso
O AM uma metodologia que tem o objetivo de facilitar e

AM no um ataque documentao, pelo

ao mesmo tempo fazer com que o analista ganhe tempo no

contrrio, AM aconselha a criao de documentos

desenvolvimento. Para que no existam confuses sobre o

que tm valor;

que AM, tenha em mente os statements descritos

abaixo. Eles iro ajud-lo na hora de identificar se o AM
a melhor soluo para o seu projeto ou no.

AM uma atitude, no um processo prescritivo;

AM um suplemento aos mtodos existentes, ele

AM no um ataque s ferramentas CASE;

AM no para todos.

no uma metodologia completa;

Fontes
Agile Modeling Home Page
www.agilemodeling.com

AM uma forma efetiva de se trabalhar em

conjunto

para

atingir

as

necessidades

dos

patrocinadores no projeto;

Agile Alliance Home Page

www.agilealliance.org
Agile Data Home Page
www.agiledata.org
Modeling Style Home Page
www.modelingstyle.info

AM efetivo e sobre ser efetivo;

Agile Modeling Mailing List
www.agilemodeling.com/feedback.htm

AM uma coisa que funciona na prtica, no

teoria acadmica.

Agile Modeling Pamphlet (original deste doc)

www.agilemodeling.com/pamphlet.htm
Agile Modeling Workshop
www.ronin-intl.com/services/agileModeling.html
Agile Modeling (O Livro)
www.ambysoft.com/agileModeling.html

AM no uma soluo salvadora;

Referncias

1.

AGILE ALLIANCE. Disponvel em:

<http://www.agilealiance.org/home>. Acesso em: 05
Maio. 2014.

2.

AGILE ALLIANCE. Disponvel em:

<http://www.controlchaos.com>. Acesso em: 05 Maio.
2014.

3.

AMBLER, S. W. Agile modeling (AM) site. Disponvel

em:
<http://www.agilemodeling.com>. Acesso em: 05
Maio. 2014.

4.

AMBLER, S. W.; JEFFRIES, R. Agile modeling:

effective practices for extreme programming and the
unified process. [S.l.]: John Wiley & Sons, 2002.

5.

AMBLER, S. W. The practices of agile modeling

(AM). Disponvel
em: <http://www.agilemodeling.com/
practices.htm>.

6.

BECK. K. et al. Manifesto for agile software

development.
Disponvel em:
<http://www.agilemanifesto.org> . Acesso em: 05
Maio. 2014.

7.

HIGHSMITH, J. Disponvel em:

<http://www.adaptivesd.com>. Acesso em: 05 Maio.
2014.

8.

RONIN INTERNATIONAL. Disponvel em:

<http://www.ambysoft.com/
agilemodeling.html>. Acesso em : 05 Maio. 2014.

9.

XPROGRAMMING.COM an extreme programming

resource. Disponvel em:
<http://www.xprogramming.com>. Acesso em: 05
Maio. 2014.