&(1752'(&,1&,$6$*55,$6
'(3$57$0(172'(&20387$d2
',6&,3/,1$'((1*(1+$5,$'(62)7:$5(

Agile Modeling


'RFHQWH
Prof.Rodolfo Miranda de Barros

$OXQRV
 Andr Ricardo Gonalves
Daniel Csar Romano Luvizotto
Heber A. A. Nascimento
Luiz Gustavo Andrade dos Santos

/RQGULQD


6XPiULR


,QWURGXomR

$JLOH0RGHOLQJ$0
2.1 Manifesto Agile ........................................................................................................4
2.2 Valores do Agile Modeling.......................................................................................5
2.3 Princpios do Agile Modeling ...................................................................................6
2.4 Prticas do Agile Modeling......................................................................................7
'HILQLomRGHPRGHORViJHLV

'HILQLomRGHPRGHODJHPiJLO

8VRGH80/QmRpVXILFLHQWH

)HUUDPHQWDV&$6( 

&RQFOXVmR

5HIHUrQFLDV 


,QWURGXomR

Com o passar do tempo empresas desenvolvedoras de software viram a necessidade

de adotar um modelo de gerenciamento no desenvolvimento de software, visto que sem um
gerenciamento adequado, o desenvolvimento era uma baguna. No existia uma
documentao adequada, no havia um padro de desenvolvimento, no existia uma maneira
de se estimar mais precisamente o tempo de desenvolvimento, e quanto menos, um valor
adequado do software. Hoje em dia existem vrios tipos de modelos, como por exemplo, [1]:
Agile, Cleanroom, Iterativo, RAD, RUP, Espiral, Waterfall, XP dentre outros.
Com a adoo de um modelo para o desenvolvimento de projetos de softwares e sua
correta aplicao, a empresa s tem a ganhar. Vamos analisar alguns casos, supre todas as
deficincias citadas anteriormente, define melhor o papel de cada pessoa no desenvolvimento
de um projeto, assim obtm um maior controle sobre cada pessoa e conseqentemente sobre o
trabalho desenvolvido pela mesma, posteriormente facilita a manuteno, especifica melhor
as funcionalidades do software, etc.
O modelo proposto neste trabalho o Agile Modeling (AM) [5] que 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, [5] 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 como as citadas h
pouco, como tambm em metodologias prescritivas como o Unified Process.


$JLOH0RGHOLQJ$0
AM segundo Scott W. Ambler[5] uma metodologia baseada na prtica pra
modelagem eficaz de software. AM no segue um processo prescritivo, ou seja, no define
procedimentos detalhados tal como a criao de um dado tipo de modelo, ao invs disso AM
uma coleo de valores, princpios e praticas que podem ser aplicados por profissionais de
software no dia-a-dia. Em outras palavras [3] AM utiliza mtodos geis que se adaptam
rapidamente as mudanas para o desenvolvimento de um software. Embora mtodos geis
difiram de projeto para projeto, estes mtodos possuem caractersticas comuns, incluindo
desenvolvimento iterativo, comunicao e uma reduo de artefatos intermedirios.
Uma caracterstica do AM que ele aplicado juntamente com outras metodologias
geis para se chegar a um melhor resultado no desenvolvimento de um projeto de software,
observe a seguinte figura:

Os mtodos geis podem ser vistos de varias perspectivas. Perspectiva do produto, os

mtodos geis so mais apropriados em situaes de mudanas rpidas e de emergentes
exigncias, e no so apropriados em situaes que o sistema em questo possui um alto nvel
de risco em relao confiabilidade e segurana. Assim, podemos observar que h casos que
convm a utilizao do AM j em outros casos no, embora no haja um consenso geral com
relao a este ponto. Perspectiva Organizacional pode ser avaliada examinando trs pontos
chaves de uma organizao [3]: cultura, povos, e comunicao. Com relao a estas reas um
nmero de fatores chaves de sucesso foram identificados, e so eles:
3

A cultura da organizao deve suportar negociao;

As pessoas devem ser confiveis;

As organizaes devem conviver com as decises tomadas pelos colaboradores;

As organizaes precisam ter ambientes que facilite a comunicao entre as pessoas.

Com certeza o fator mais importante de escolha ou no de mtodos geis o

tamanho do projeto, com o crescente tamanho do projeto, a comunicao face a face torna-se
mais difcil, conseqentemente os mtodos geis so mais indicados para projetos que
envolvam um numero que varia de 20 at 40 pessoas em um dado projeto [1].
Em resumo, AM surgiu para melhorar as maneiras de desenvolvimento de software,
definindo valores, princpios e praticas que devem ser praticado para a obteno de um
processo mais interativo e menos burocrtico do que os atuais.

0DQLIHVWR$JLOH
Esse manifesto surgiu de um grupo de consultores, engenheiros e autores que no ano

de 2001 apresentaram o 7KH$JLOH0DQLIHVWR, com o intuito de apresentar e discutir melhores

formas para o desenvolvimento de software, aplicando alguns conceitos de agilidade s
metodologias existentes. E este manifesto contm algumas citaes interessantes, como por
exemplo, [3]:

Valorizar as pessoas envolvidas no processo e as relaes entre elas, ao invs

de se focar em processos e em ferramentas;

Focar-se mais na produo do software do que em documentao;

Estar preparado para mudanas em oposio ao seguimento rigoroso de um

plano;

O objetivo principal satisfazer o cliente com a entrega rpida de um

software funcional;

Os mtodos geis devem transformar a mudana numa vantagem competitiva

do cliente;
4

Os elementos do grupo de desenvolvimento e os clientes devem reunir-se

frequentemente, com o objetivo de discutir o andamento e obter mais
informaes acerca do software;

Oferecer um ambiente e apoio apropriado aos envolvidos no projeto;

Ser simples, etc.

9DORUHVGR$JLOH0RGHOLQJ
Ambler [1] apresenta, os valores do Agile Modeling, tais valores so apresentados
abaixo::

Comunicao: promete uma comunicao clara entre a equipe e os

VWDNHKROGHUVe tambm entre desenvolvedores e a equipe;

Simplicidade: muito importante que os desenvolvedores entendam que

modelos so crticos para simplificar software e processos de software,
muito fcil explorar uma idia, assim, devemos melhor-la para um melhor
entendimento, e isso pode ser feito atravs de desenho de um diagrama, ao
invs de dois ou mais diagramas. Portanto no desenvolvimento do projeto
devemos nos apegar a simplicidade.

Feedback: recorrendo exposio de idias e conceitos atravs de diagramas,

fica facilitada a troca de opinies entre os pares e mais rpida a introduo
de possveis melhorias.

Coragem: a coragem de extrema importncia, pois, em um projeto sempre

temos que fazer importantes decises e estar pronto para mudanas caso as
escolhas tomadas no foram corretas.

Humildade: os melhores desenvolvedores tem a humildade de reconhecer que

no sabem de tudo, e que clientes e VWDNHKROGHUV tm seus valores e esses

valores adicionam qualidade ao projeto.

3ULQFtSLRVGR$JLOH0RGHOLQJ
Os princpios do AM so os seguintes:

Assumir a simplicidade: busca uma soluo simples na qual se trabalha

apenas com requisitos atuais no se preocupando com os futuros requisitos,
assim trabalha-se de forma organizada, e com isso mais rapidamente;

Abertura a mudanas: com o passar do projeto RVVWDNHKROGHUV podem mudar

de idia em relao a um dado requisito, portanto deve-se estar preparado
para mudanas;

Abertura a mudanas: estar preparado a mudanas, pois com o andamento do

projeto, as avaliaes de alguns requisitos podem mudar na opinio de
VWDNHKROGHUV

Software o objetivo primrio: como o objetivo principal o software, ele

deve estar de acordo com os interesses dos VWDNHKROGHUV.
Viabilizar esforos futuros: preparar a prxima etapa muito importante, para
que ela possa ser iniciada sem muita dificuldade e com eficincia. Para isso
necessria uma boa documentao, tomando em conta pessoas envolvidas,
natureza e outros fatores;

Alteraes incrementais: a fim de otimizar recursos deve-se dirigir o projeto

de maneira incremental.

Maximizar o investimento dos VWDNHKROGHUV: afim que os VWDNHKROGHUV

invistam mais se deve satisfazer as interesses deles.

Modelar com propsito: antes de criar qualquer coisa necessrio identificar

a razo para saber o que ser e feito por quem, assim s ser realizado
necessrio poupando tempo e dinheiro.

Mltiplos modelos: no desenvolvimento vrios modelos so requeridos, ento

deve-se classificar os mais importantes, e descartar os outros;

Trabalho com qualidade: o projeto deve ter qualidade a fim de satisfazer o

cliente;
6

Feedback rpido: o tempo entre uma ao e resposta muito importante, pois

quanto mais rpida a reao, mais cedo pode ser corrigido um erro.

Travel Light: necessrio um equilbrio entre a quantidade de modelos

produzidos e a agilidade que introduzida no projeto, pois a atualizao dos
diferentes modelos pode ser muito difcil.

3UiWLFDVGR$JLOH0RGHOLQJ
No fcil a implementao de AM na cultura de desenvolver software, pois o
mtodo gera uma grande mudana no pensamento e tambm pelo medo natural das pessoas
por mudanas.
Os princpios mais importantes para direcionar os esforos em relao ao
Para direcionar os esforos em torno de AM, existem alguns princpios que devem
ser observados para que o processo adotado seja realmente gil. Dentre esses princpios, os
mais importantes so:

Participao ativa dos VWDNHKROGHUV: em poucas palavras a participao

daqueles que realmente tem a capacidade de contribuir para o projeto com
relao aos requisitos. O AM expande uma pratica do XPs On-Site Customer
que consiste em ter os VWDNHKROGHUV envolvidos ativamente no projeto,
tomando decises acerca da atribuio de recursos e definio do projeto;

Aplicao correta dos artefatos: cada artefato tem as suas prprias

caractersticas. Na maioria dos casos, um diagrama uma melhor opo em
relao a um exemplo de cdigo. A nica inconvenincia que a equipe
necessita de conhecer em detalhe diferentes artefatos para poder avaliar
quando utilizar um em detrimento de outro;

Posse coletiva: todas as pessoas envolvidas no projeto podem e devem

trabalhar em qualquer artefato quando necessrio. Os modelos produzidos so
de todos e para todos;

Criao de modelos em paralelo: trabalhar com modelos em paralelo tem se

mostrado mais produtivo para o projeto, visto que no existe apenas um que
preencha todas as necessidades de um projeto;
7

Maximizar a simplicidade: deve-se simplificar ao mximo o contedo dos

modelos, acompanhando as necessidades e expectativas dos VWDNHKROGHUV;

Descries simples e acessveis: um modelo simples que disponibilize as

funcionalidades chave, ou ento um modelo tpico que descreva as principais
responsabilidades das classes e suas relaes, muito mais eficaz e eficiente;

Publicao dos modelos: deve ser disponibilizado um local designado por

modeling wall, onde so colocados todos os modelos, acessvel equipe de
desenvolvimento, bem como aos VWDNHKROGHUV;

Iterao para outro artefato: sempre que surja um bloqueio, conveniente

ponderar a alterao do artefato. Essa situao ser mesmo um indicador para
mudar de artefato alvo, pois uma alterao do ponto de vista aumenta a
probabilidade de descobrir a dificuldade encontrada;

Modelao incremental: a modelagem incremental caracteriza-se pela diviso

de um modelo em pequenas partes, designadas por incrementos, que so
progressivamente disponibilizados. Esta prtica aumenta a agilidade atravs
da possibilidade de entregar software mais rapidamente aos utilizadores;

Modelagem entre todos: o processo de modelagem facilita a comunicao de

idias e conceitos, assim como ajuda a compreender a situao e a encontrar
um sentido comum para o projeto. Trata-se, portanto, de uma atividade que
dever ser realizada em grupo, com a participao eficaz de todos;

Comprovao atravs do cdigo Um modelo uma abstrao que reflete o

aspecto do que est a ser desenvolvido. Mas nem sempre assim e torna-se
necessrio comprov-lo atravs de cdigo, recordando que numa abordagem
iterativa, a modelagem apenas uma das muitas tarefas a realizar;

Fonte de informao nica: toda a informao associada a um projeto deve

ser armazenada num s local, privilegiando a reutilizao de artefatos.

Utilizar as ferramentas mais simples, a maioria dos modelos pode ser

desenhada recorrendo a um rascunho, posteriormente digitalizado e integrado
no projeto. Na fase de desenho, esta abordagem acaba por ser muito valiosa,
pois provoca reflexo e evita o consumo de recursos em diagramas mais
elaborados;
8

Aplicao de normas de modelagem: dever ser selecionada uma norma de

modelagem, como por exemplo, o UML, cuja notao e semntica ter de ser
aplicada de forma consistente em todos os modelos produzidos;

Aplicao cuidadosa de padres: os modeladores devero possuir um

conhecimento alargado de todos os modelos existentes, de forma a terem
sensibilidade sobre qual o padro de desenho apropriado a cada situao.

Atualizar/Descartar modelos temporrios: uma parte considervel dos

modelos produzidos so considerados temporrios, pois j cumpriram o seu
propsito e agora no acrescentam o mesmo valor ao projeto. Uma vez
desatualizados, torna-se necessrio optar por sincronizar ou descart-los, aps
uma avaliao dos custos envolvidos.

Formalizar documentos de contrato: os modelos de contrato so utilizados

sempre que um grupo externo controla um recurso de informao necessrio.
O seu desenvolvimento e manuteno envolvem recursos considerveis, de
modo que o nmero de modelos de contrato existentes dever ser
minimizado, sem descurar a sua preciso e detalhe;

Minimizar as atualizaes: deve-se atualizar um modelo apenas quando se

revelar necessrio. Com esta prtica, os modeladores apercebem-se que agora
atualizam um menor nmero de modelos e que estes no necessitam de ser
perfeitos para revelarem valor ou servirem os seus propsitos.


'HILQLomRGHPRGHORViJHLV
Podemos definir modelos geis usando AM como sendo um modelo eficiente que
resolva os problemas nas etapas de um projeto, e esses modelos possuem um aspecto prprio
[2].
Um modelo gil tem de ser inteligvel e no belo e cheio de dados irrelevantes, que
s sobrecarrega a representao do software, ou seja, no necessrio sempre o uso de uma
ferramenta CASE pra se construir um modelo, com um simples lpis e uma folha pode se
construir um modelo suficientemente bom.
Um modelo tem de ser suficientemente detalhado, a toda mudana o modelo deve ser
atualizado e como dito anteriormente, no necessrio um modelo muito detalhado, pois
alguns desses dados so inteis e isso s torna o sistema mais complexo e com isso torna-se
mais caro a sua atualizao. Ento o modelo deve ser simples o bastante para representar de
forma clara e concisa o seu objeto, para deixar o custo da atualizao bem baixo.
E o mais importante, um modelo tem de atender o seu propsito, como assim? O
modelo tem um importante papel, que o de manter a equipe informada sobre um conjunto de
dados. E se esses dados no forem mostrados de forma clara, ento ele no estar cumprindo
o seu papel e isso resultara em um custo maior para mant-lo.

10

'HILQLomRGHPRGHODJHPiJLO

Deve-se diferenciar o que so os modelos geis, descritos na seo anterior, do

processo de modelagem gil. 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 existentes; no uma metodologia completa: AM foca em
modelagem e, em segundo plano, documentao [2].
AM pode ser utilizado para aumentar a eficincia da modelagem e documentao,
tanto em processos prescritivos como o Unified Process quanto processos geis como o
SCRUM.
AM uma tcnica eficiente para a melhoria dos esforos de desenvolvimento de
software de muitos profissionais da rea. AM no uma espcie de leo mgico que resolver
todos os problemas, tampouco uma tcnica que garantir melhores resultados.
A idia por trs de AM a de que se voc utilizar seus esforos de modelagem de
maneira mais racional e permanecer focado no projeto, ento provavelmente sua eficincia no
desenvolvimento do projeto ir aumentar; $0 QmR YLVD j HOLPLQDomR GD GRFXPHQWDomR
AM simplesmente diz que a documentao deve ser feita de modo mais racional,
maximizando o investimento do cliente no processo de desenvolvimento. $0 QmR YLVD j

HOLPLQDomR GH IHUUDPHQWDV &$6( Pelo contrrio: AM diz que a melhor ferramenta para

criar um modelo a mais simples. Se um modelo for mais fcil de ser desenhado em uma
ferramenta CASE do que em um papel, ento a ferramenta CASE deve ser utilizada para a
criao desse modelo.

11


8VRGH80/QmRpVXILFLHQWH

O princpio de mltiplos modelos do AM nos diz que ns precisamos ter muitas

tcnicas de modelagem em nosso trabalho se ns desejamos ser eficientes como
desenvolvedores. O artigo Artefatos para AM apresenta uma viso geral de varias modelagem
de artefatos, incluindo a UML, e como podemos observar a uma larga seleo de modelos
disponvel.
Cada modelo tem seus prs e contras, consequentemente um nico modelos no
suficiente para as necessidades de desenvolvimento de um projeto. Embora a UML seja de
fato robusta, ela no suficiente para as necessidades de modelagem, ou seja, UML no
suficiente. A UML dever ser usada como uma base de coleo de tcnicas de modelagem a
qual complementa outras tcnicas.

12


)HUUDPHQWDV&$6(
Segundo Ambler[3] no AM o uso de ferramentas CASE tratado com muito
cuidado, em todo projeto deve-se usar ferramentas CASE, mas deve ser utilizadas de forma
inteligente. Como assim? Em certos projetos podemos adotar ferramentas simples como um
quadro ou uma folha em branco para se desenhar os diagramas, j em outros casos, devemos
utilizar ferramentas mais complexas, tais como, Compuware'
s OptimalJ, Borlands Together,
Rational System Architect ou Computer Associates ERWin.
As ferramentas CASE devem ser usadas de forma inteligente para maximizar ao
mximo o desenvolvimento do projeto, assim, se um dado projeto necessita de uma
ferramenta mais complexa use a ferramenta mais complexa, j se o projeto no necessita de
uma ferramenta complexa use a mais simples. No h a necessidade de temer a mudanas.
Mudana feita de forma correta s trs benefcios ao desenvolvimento de projetos.
Custo de uso de ferramentas CASE:

Treinamento da equipe;

Custos de Avaliao;

Geralmente as ferramentas mais complexas dificultam a entrada de novos

desenvolvedores;

A integrao inadequada com outras ferramentas reduz a produtividade e/ou

requer trabalho da integrao.

Benefcios no uso de ferramentas CASE:

Reengenharia;

Suporte para mudanas de nveis de abstrao;

Testa a consistncia e validao de modelos;

Sincronizao dos modelos com cdigo;

Gerao de documentao.

13


&RQFOXVmR

O AM uma metodologia que tem o objetivo de facilitar e ao mesmo tempo fazer

com que o analista ganhe tempo no desenvolvimento. Para que no existam confuses sobre o
que AM, h algumas definies que nos auxiliar a identificar se o AM a melhor soluo
pra um dado projeto. E essas definies so as seguintes [2]:

AM uma atitude, no um processo prescritivo;

AM um suplemento aos mtodos existentes, ele NO uma metodologia

COMPLETA;

AM uma forma efetiva de se trabalhar em conjunto para atingir as

necessidades dos patrocinadores no projeto;

AM uma coisa que funciona na prtica, no teoria acadmica;

AM no uma soluo salvadora;

AM para o desenvolvedor mdio, mas no um substituto de pessoas

competentes;

AM no um ataque documentao, pelo contrrio, AM aconselha a

criao de documentos que tm valor;

AM no um ataque s ferramentas CASE;

Com isso podemos observar que o Agile Modeling no foca muito a documentao e
ferramentas, isso no quer dizer que no so utilizadas, so utilizadas, mas de forma
inteligente e gil. E tambm podemos observar que o AM no se aplica em todo tipo de
projeto.

14

5HIHUrQFLDV

[1]

AMBLER, S. W. $JLOHPRGHOLQJ$0VLWH. Disponvel em:

<http://www.agilemodeling.com>. Acesso em: 01 maio 2007.

[2]

Santos, Alexandre Denes dos, Martins, Jefferson Carlos, Leal, Manoel

Flavio. $JLOH0RGHOLQJ2YHUYLHZ. Disponvel em
<http://www.pr.gov.br/batebyte/edicoes/2003/bb131/agile.shtml>.
Acessado em: 28 abril 2007.

[3]

Ambler, Scott W. $JLOH0RGHOLQJ. Disponvel em:

<http://www.ambysoft.com/books/agileModeling.html> Acessado em:
05 maio 2007.

[4] Cardim, Ivan Cordeiro.$YDOLDQGRR0LFURVRIW6ROXWLRQV)UDPHZRUN


IRU$JLOH6RIWZDUH'HYHORSPHQWHPUHODomRDRH[WUHPH3URJUDPPLQ
Universidade Federal de Pernambuco. Recife. Pernambuco.2006.
[5]

Mendona, Alexandre, Viera, Jos Nuno, Moura, Milton. $JLOH 0RGHOLQJ.

Universidade de Lisboa. Lisboa. Portugal.

15