Engenharia de Software - Edição 32.pdf

7/28/2019 Engenharia de Software - Edio 32.pdf

1/42


2/42


3/42

Corpo Editorial

ColaboradoresRodrigo Oliveira SpnolaMarco Antnio Pereira ArajoEduardo Oliveira Spnola

Capa e DiagramaoRomulo Araujo - [email protected]

Coordenao GeralDaniella Costa - [email protected]

Revisor e SupervisorThiago Vincenzo - [email protected]

Jornalista ResponsvelKaline Dolabella - JP24185

Na Webwww.devmedia.com.br/esmag

Ano 3 - 32 Edio - 2011 Impresso no Brasil

Durante muitos anos, as metodologias tradicionais foram utilizadas

amplamente pela maioria dos projetos e das empresas de desen-

volvimento de software, e o modelo cascata era tido como o mais

completo e efetivo. Essa situao se modificou assim que surgiram os pri-

meiros projetos geis, logo aps o manifesto gil em 2001, e o mundo dodesenvolvimento de software se dividiu entre os mais conservadores e os

simpatizantes do Scrum, XP e outras metodologias geis.

No entanto, apesar dos casos de sucesso serem muitos, logo comearam

a aparecer os primeiros estudos de caso que apresentavam problemas

utilizando tais metodologias e, principalmente, o Scrum. O Scrum, mesmo

com inmeras vantagens em vrias perspectivas, deve-se deixar claro, no

a soluo perfeita para todos os problemas da rea de Engenharia de

Software, logo, no a bala de prata dos projetos de desenvolvimento.

Neste contexto, esta edio da Engenharia de Software Magazine desta

o artigo Scrum: No funcionou p ara voc?. O artigo apresenta algumas

lies aprendidas durante os ltimos anos na rea da qualidade de sof-

tware e tambm na liderana em equipes de desenvolvimento trabalhan-

do com Scrum. A principal inteno de listar tais lies ajudar outrasequipes que possam vir a ter os mesmos (ou semelhantes) problemas no

decorrer do desenvolvimento de aplicativos e sistemas.

Alm desta matria, esta edio traz mais sete artigos:

TenhoumChefedifcil:eagora?

ModelagememumaVisogil

EntendendomelhorSOAeESB

EspecificaodeCasosdeUso

EngenhariadeSoftware:SobreaNecessidadedeEducaoContinuada

RefatoraoparaPadres-Parte5

ModelagemTemporal,deImplantao,deArtefatosedeComponentes

atravsdaUML.

Desejamos uma tima leitura!

Equipe Editorial Engenharia de Software Magazine

Rodrigo Oliveira [email protected]

Doutorando em Engenharia de Sistemas e Computao (COPPE/UFRJ). Mestre emEngenharia de Software (COPPE/UFRJ, 2004). Bacharel em Cincias da Computao(UNIFACS,2001).Colaborador da Kali Software (www.kalisoftware.com),tendo minis-trado cursos na rea de Qualidade de Produtos e Processos de Software,Requisitos eDesenvolvimento Orientado a Objetos.Consultor para implementao do MPS.BR.Atuacomo Gerente de Projeto e Analista de Requisitos em projetos de consultoria na COPPE/UFRJ. Colaborador da Engenharia de Software Magazine.

Marco Antnio Pereira Arajo

[email protected] e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Li-nha de Pesquisa em Engenharia de Software, Especialista em Mtodos EstatsticosComputacionais e Bacharel em Matemtica com Habilitao em Informtica pelaUFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informaodo Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado emSistemas de Informao da Faculdade Metodista Granber y, Professor e Diretor do Cur-so Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da FundaoEducacional D.Andr Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora,Colaborador da Engenharia de Software Magazine.

Eduardo Oliveira [email protected]

Colaborador das revistas Engenharia de Software Magazine,Java Magazine e SQL Ma-gazine. bacharel em Cincias da Computao pela Universidade Salvador (UNIFACS)

onde atualmente cursa o mestrado em Sistemas e Computao na linha de Engenhariade Software,sendo membro do GESA (Grupo de Engenharia de Software e Aplicaes).

Apoio

Atendimento ao Leitor

A DevMedia conta com um departamento exclusivo para o atendimento ao leitor.

Se voc tiver algum problema no recebimento do seu exemplar ou precisar de

algum esclarecimento sobre assinaturas, exemplares anteriores, endereo de

bancas de jornal, entre outros, entre em contato com:

Isabelle Macedo e Uellen Goulart AtendimentoaoLeitorwww.devmedia.com.br/mancad(21) 2220-5338

Kaline DolabellaGerente de Marketing e [email protected](21) 2220-5338

Publicidade

Para informaes sobre veiculao de anncio na revista ou no site entre emcontato com:

Cristiany [email protected]

Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo

voc gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a

vontade para entrar em contato com os editores e dar a sua sugesto!

Se voc estiver interessado em publicar umartigonarevistaounositeSQLMagazine,

entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc

gostaria de publicar:

Rodrigo Oliveira Spnola - Colaborador

[email protected]

EDITORIAL


4/42

NDICE

Por trs do bvio

06 Tenho um Chefe difcil: e agora?Glnio Cabral

Agilidade

08 - Modelagem em uma Viso gilLenildo Morais

13 - Scrum: No funcionou para voc?Gabriela de Oliveira Patuci

Desenvolvimento

18 - Modelagem Temporal, de Implantao, de Artefatos e de Componentes

atravs da UMLGeraldo Magela Dutra Gonalves

26 - Refatorao para Padres Parte 5Jacimar Fernandes Tavares e Marco Antnio Pereira Arajo

Engenharia33 - Engenharia de Software: Sobre a Necessidade de Educao Continuada

Antonio Mendes da Silva Filho

39 - Especificao de Casos de UsoRodrigo Oliveira Spnola

40 - Entendendo melhor SOA e ESBLenildo Morais

Tipo: ProcessoTtulo: Especificao de casos de uso na prtica Partes 6 a 10

Autor: Rodrigo Oliveira SpnolaMini-Resumo: Definir requisitos no uma atividade trivial. Uma dasformas de realizar esta atividade atravs da especificao de casos deuso. Neste sentido, nesta srie de vdeo aulas apresentaremos um conjuntode especificaes de casos de uso. Os cenrios sero especificados passoa passo considerando tpicos como fluxo principal, fluxo alternativo eregras de negcios.

Caro Leitor,Para esta edio, temos um conjunto de 5 vdeo aulas.Estas vdeo aulas esto disponveis para download no Portalda Engenharia de Software Magazine e certamente trarouma significativa contribuio para seu aprendizado. A listade aulas publicadas pode ser vista abaixo:


5/42

Edio 05 -Engenharia de Software Magazine 5


6/426 Engenharia de Software- Tenho um chefe difcil: e agora?

Glnio [email protected]

Administrador de Empresas, ps-graduado em Gesto de Pessoas e msi-co. Idealizador do site de educao infantil www.novainfancia.com.br.

Tenho um Chefe difcil:e agora?

Pos trs do bvio

No mercado atual, todos os lderes sabem como mo-tivar suas equipes estabelecendo um timo climaorganizacional, certo? Errado!

Parece estranho, mas ainda h lderes que possuem umgrande talento para promover a desmotivao geral de suasequipes. Pesquisas apontam que chefes considerados difceisnunca admitem seus erros, no costumam dar feedbacks, soditadores e esto sempre insatisfeitos com o desempenho dosseus subordinados. Ser que voc, caro leitor, tem sido premia-do com um chefe assim? Na dvida, a vo algumas dicas paraque voc saiba lidar melhor com um chefe complicado.

1. Certifique-se de que voc no a nica pessoa a terdificuldades de lidar com seu chefe. Lderes que so com-provadamente um problema costumam ser encarados dessaforma por todos, e no apenas por uma pessoa. Se voc anica pessoa a ter problemas com seu chefe, o problema podeestar em voc.

2. Nunca bata de frente. Estudos comprovam que as relaespessoais tm um peso muito grande no mercado brasileiro.Por isso, nada de bater de frente, pois voc poder ser malinterpretado. preciso ter o cuidado de conhecer melhor ochefe para saber a melhor hora de falar, de opinar e de pediralgo. Em nossa cultura, essas coisas costumam dar muitoresultado. Voc est na sua razo? Ainda assim bater de frente

nunca ser uma boa. V com calma e pelas beiradas.

3. Faa sempre o dever de casa e no d brechas para pu-xes de orelha. A produtividade e a competncia sempresero recompensadas e desejadas, mesmo que seu chefeseja um Hitler. Seu chefe insensvel e nunca reconheceseus mritos? Ento d o melhor de si e continue fazendoseu trabalho com responsabilidade e seriedade, porque noh chefe que resista ao charme de um bom profissional.Essa postura de excelncia costuma inclusive abrir portaspara outras possibilidades profissionais.

4. No se envolva em fofocas nem fique falando mal deseu chefe para os colegas de trabalho. Essas coisas costu-mam chegar aos ouvidos dele, o que pode tornar a situaoainda mais difcil. A maledicncia corporativa nunca uma

boa postura profissional. Alm do mais, numa possveltransferncia de departamento ou de funo a fama deencrenqueiro s ir dificultar as coisas.

5. Sempre que possvel, solicite do seu chefe o feedbackde suas aes. Se tem algo que os chefes complicados nose sentem vontade para fazer dar um feedback. Issoacontece porque eles so pssimos no quesito comunica-o, e como dar um feedback basicamente comunicar-se, a coisa acaba emperrando. Por isso, em alguns casos preciso arrancar o feedback do chefe. Atravs desseretorno o colaborador ter informaes importantes para

aprimorar suas aes e ser mais produtivo. O que, diga-se


7/42Edio 32 - Engenharia de Software Magazine 7

POR T R S D O B VI O

D seu feedback sobre esta edio!

A Engenharia de Software Magazine tem que ser feita ao seu gosto.

Para isso, precisamos saber o que voc, leitor, acha da revista!

D seu voto sobre este artigo, atravs do link:

www.devmedia.com.br/esmag/feedback

D

seuFeedback

sobree

sta

edio

de passagem, far com que seu chefe reclame menos do seudesempenho.

6. No adote uma imagem de vtima e de coitadinho. Os bonsprofissionais no agem assim. Se voc se sente perseguidoou no reconhecido por seu chefe, no ande cabisbaixo pelos

cantos. Seja auto-motivado e tenha sempre a conscinciado seu valor e potencial. Lembre-se: os bons profissionaissempre so reconhecidos e desejados. Se no pelo seu chefe,pelo concorrente ao lado.

7. Desenvolva o hbito de engolir alguns sapinhos. Aolongo das nossas vidas, sempre estaremos engolindo algunsanf bios saltitantes. Isso acontece porque nem sempre vamospoder chutar o balde quando bem entendermos. Afinal,temos contas para pagar e famlia para sustentar. Sem falarque mudar de funo ou de emprego no garantia de quese estar livre para sempre de um chefe difcil. Manter ocontrole e esperar a hora certa de tomar certas decises so

posturas que sempre acompanham o profissional maduro eque sabe o que quer.

Por fim, se nada disso adiantar, talvez seja a hora de ter umaconversa franca com o departamento de recursos humanos esinalizar que est disposto a mudar de ares. Mas lembre-sede duas coisas: primeiro, chefes difceis esto com os diascontados. No h mais espao para eles num mercado de

trabalho globalizado e dinmico. E segundo, voc pode atdeixar uma empresa por causa de um chefe dif cil, mas se forum bom profissional o mercado de trabalho nunca o deixar.Siga em frente.


8/428 Engenharia de Software Magazine- Modelagem em uma Viso gil

Lenildo [email protected]

analista de sistemas e analista de testes.Atualmente est cursando mestrado no centrode informtica da UFPE em engenharia desoftware com nfase em testes e qualidadede software.

De que se trata o artigo?

Apresentar, atravs de uma viso geral, os valores,

princpios e prticas da modelagem gil (Agile Mo-

deling), abordando aspectos como: trabalho em

conjunto, participao efetiva do cliente, comuni-

cao, rascunhos como forma de modelagem e a

utilizao da modelagem na obteno da qualida-

de e de maior produtividade.

Para que serve?

Proporcionar s equipes de desenvolvimento de

software maior conhecimento sobre a modela-

gem gil, uma vez que grande parte dos projetos

de desenvolvimento ainda precisa evoluir neste

aspecto.

Em que situao o tema til?

Nos projetos de desenvolvimento de software,

sobretudo quando se deseja buscar mercados

externos ou expandir seus clientes internos au-

mentando a satisfao dos mesmos.

Modelagem em uma Viso gilO que? Quanto? E para que modelar?

Amodelagem, do ponto de vistagil, um mtodo eficienteque tem como objetivo tornar

mais produtivos os esforos da tarefade modelar, to comum nos projetos desoftware.

Os valores, princpios e prticas da Mo-delagem gil podem auxiliar as equipesna definio de componentes tcnicosde alto e baixo nvel que faro parte dodesenvolvimento de software. Artefatossofisticados elaborados por ferramentasde alto custo nem sempre so os melho-res para ajudar no desenvolvimento dosoftware. Modelar o software em grupoe com a participao dos usurios, utili-zando rascunhos, vista como uma boaprtica para se conseguir isto.

Uma das dificuldades mais comuns nasequipes de desenvolvimento como con-seguir efetivamente capturar as necessi-dades dos usurios. Uma das maneirasde se alcanar isso passa pelo desenvol-vimento iterativo, onde so entregues

software funcionando constantemente

com o objetivo de observar se as ne-cessidades foram atendidas. Ao longodeste artigo veremos os conceitos e al-guns aspectos importantes no tocante modelagem gil, assim como alguns

benefcios trazidos por esta prtica.

Agilidade

Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.

Contedo Multimdia!

Neste artigo voc encontra o vdeo: Uma visogeral da UML.

www.devmedia.com.br/esmag



AGILIDADE

Viso geral da Modelagem gilO processo atual de desenvolvimento de software ainda

est em um nvel de qualidade muito abaixo do que seriaconsiderado ideal, isto porque os sistemas so entregues aosclientes fora do prazo estipulado no projeto e com um custo

maior do que o previsto. Alm disso, esses sistemas frequen-temente no alcanam a qualidade desejada pelo cliente e, emmuitos casos, no satisfazem as reais necessidades do mesmo,levando a altos ndices de manuteno ou passando a ideiade isso ter de ficar para uma prxima verso.

A modelagem gil vista como um processo de desenvolvi-mento de software baseado em prticas que visa aumentar aeficincia das equipes dentro dos projetos. Ao contrrio dosprocessos tradicionais, que requer basicamente os mesmosartefatos para todos os tipos de projetos, a modelagem gil

busca a construo e manuteno eficiente de artefatos,criando-os apenas quando agregarem valor real ao projeto,

e focando principalmente os esforos no desenvolvimentodo software.Entretanto, a modelagem gil no uma metodologia de

desenvolvimento gil como eXtreme Programming (XP) ouScrum, mas sim uma boa prtica. Ela visa construir e mantermodelos de sistemas de maneira eficaz e eficiente, podendoser utilizada dentro de metodologias geis e tradicionais.J com relao comunicao da equipe, a modelagem gil

pode ser aplicada fazendo com que as pessoas envolvidasnos projetos colaborem para que a soluo atenda ao negcio.Neste contexto, no interessante se prender a papis. Umaequipe de desenvolvimento de software mais eficientese todos so capazes de fazer todas as atividades. Esta boaprtica proporciona um trabalho muito mais colaborativo eintegrado, uma vez que comum nas equipes haver pessoascom qualidades diferenciadas. possvel que haja uma pessoacom excelente desenvoltura para conversar com os usurios,outra pessoa consegue codificar com uma rapidez e qualidadeacima da mdia, e outra pessoa pode ter um conhecimentoabrangente para dar solues a problemas complexos.

comum algumas pessoas, que no so da rea de desen-volvimento de software, acharem que a engenharia de siste-mas prxima da engenharia civil ou engenharia mecnica.Enquanto nas engenharias tradicionais existe uma divisoentre design e construo, na engenharia de software noexiste esta separao.

Quando um edifcio construdo, o gerenciamento de pro-jeto tradicional faz sentido, pois para esse tipo de produto(o prdio), necessrio ter uma planta detalhada para poderiniciar a construo. Nesse projeto quem responsvel pelaatividade de design um arquiteto ou engenheiro que possuiqualificaes intelectuais distintas de quem ir efetuar oprojeto (a construo). O trabalho de construo ser desem-penhado pelo pedreiro, que no necessita ter o conhecimentototal da engenharia para fazer o seu trabalho. Essa divisoacontece por conta das caractersticas totalmente diferentesentre os dois trabalhadores: um altamente intelectual, o

outro mais braal. Um engenheiro pode ter um custo alto j

o pedreiro tem um custo menor, assim como um engenheiropode gerar demandas para o trabalho de at 100 pedreiros.

Dado a natureza do projeto civil, lgico que haja essa divisode trabalho entre design e construo. Neste cenrio, no fazsentido as pessoas do projeto serem engenheiro-pedreiro,

como pode ser na Engenharia de Software.Durante a construo de um software so consideradas ba-sicamente quatro atividades principais:1. Compreender o que o usurio quer;2. Definir como os elementos de software resolvero as neces-sidades do usurio;3. Escrever esses elementos de software e integr-los;4. Testar os elementos e homolog-los com o usurio.

Antes de tudo, deve-se observar que essas atividades ocorremmuitas vezes dentro de um projeto. Entretanto, considerandoas quatro atividades, a diferena que h com relao enge-

nharia civil que no existem importantes diferenas no nvelintelectual necessrio para desempenhar essas atividades. Aatividade de levantamento dos requisitos do software no intelectualmente inferior atividade de codificar estes requi-sitos. So atividades diferentes, mas no to diferentes comoo trabalho do engenheiro e do pedreiro. O erro que muitasempresas cometem achar que analistas de sistemas so comoengenheiros civis e programadores so como pedreiros, e istono ocorre na prtica.

Aspectos humanos e tcnicos no desenvolvimento desoftware

A modelagem gil baseada em uma coleo de prticas,guiadas por princpios e valores que podem ser aplicadospor profissionais de software no dia a dia. No sendo umprocesso prescritivo, no define procedimentos detalhadosde como criar um dado tipo de modelo. Ao invs disso, provsugestes de como ser mais efet ivo. Em resumo, a modelagemgil busca o ponto de melhor custo/benefcio entre os artefatosque devem ser criados para o sistema e o custo de manutenoe atualizao desses artefatos. Pode-se citar duas motivaesprincipais para a criao desta metodologia:1. O objetivo primrio de um projeto de software o prpriosoftware, e no um grande conjunto de documentos sobre ele;2. Um artefato criado primordialmente para permitir a co-municao e a troca de informaes entre a equipe e permitira discusso e refinamento do modelo do sistema. Assim, se umartefato no est passando informaes relevantes ao projeto,ele no cumpre seu objetivo bsico.

Basicamente, o que se quer com a modelagem do sistema satisfazer as necessidades dos usurios, garantindo a qualidadeinterna (ver Nota 1) do software e respeitando as restries decusto e prazo do projeto.

Quando se tem que lidar com muita complexidade tcnica,que geralmente ocorre em sistemas que lidam com milhares degigabytes, de usurios, de transaes e de processamento distri-

budo, um pequeno desvio de disciplina pode levar o sistema ao



caos. Nesse caso, a modelagem voltada para o aspecto tcnico,em que obrigatrio conhecer a estrutura interna dos compo-nentes, as dependncias, algoritmos complexos, etc.

Todo projeto possui restries de custo e prazo. No se temtodo tempo e dinheiro do mundo para fazer o software. A mis-

so de um bom modelador administrar as expectativas docliente, avaliando com ele quais problemas so prioritrios.Uma das coisas que as metodologias geis trouxeram tona

a importante participao dos usurios ou clientes para auxiliarna modelagem do sistema: seja elaborando um mapa mental,rascunhando uma tela, ou testando um release que acabou deser liberado. Os usurios, clientes ou stakeholders possuem umpapel importantssimo para gerar as demandas corretas e avaliara qualidade dos trabalhos executados. Isso requer uma comuni-cao rica entre o cliente e todos os envolvidos no projeto.

Focando nos usurios ou em aspectos mais tcnicos, sem-pre importante estabelecer o escopo da modelagem gil para

esclarecer o que pode e o que no pode ser atendido por esteprocesso. A modelagem gil um complemento aos processosexistentes, no uma metodologia completa. Ela no umaespcie de receita mgica que resolver todos os problemas,tampouco uma tcnica que garantir melhores resultados. Aideia por trs da modelagem gil a de utilizar seus esforosde maneira mais racional e permanecer focado no projeto,aumentando sua eficincia no desenvolvimento do projeto.

A modelagem gil no visa eliminao da documentao.Simplesmente diz que a documentao deve ser feita de modomais racional, maximizando o investimento do cliente noprocesso de desenvolvimento.

A documentao sem dvida uma forma importante decomunicao nos projetos de software. Entretanto, o pior meiode comunicao e documentao so artefatos sendo troca-dos via e-mail. Infelizmente muitos projetos ainda utilizamsomente esse meio pobre de comunicao. Esta a maneiramenos eficiente e mais fria de trocar ideias. J um meio ricode se comunicar a maneira compartilhada de demonstrargraficamente as propostas, como rascunho ou um quadro

branco. A prtica bem simples: junta-se as pessoas numasala, permitindo que elas colaborem entre si, trocando ideias esentimentos com o auxlio de um meio grfico compartilhado.A eficincia dessa tcnica comprovada em workshops derequisitos com o cliente ou em discusses arquiteturais dentroda equipe. O resultado dessas reunies so rascunhos quepodem ser feios na forma, mas so perfeitos para o propsitode modelagem do sistema.

Rascunhos como forma de modelagemSempre que falamos em rascunho, as pessoas ficam com

impresso de coisas mal feitas ou informalidade em excesso.

Capacidade do software de satisfazer as necessidades implcitas, ou seja, requisitos relacionados

estrutura do software, como por exemplo, a integridade dos dados ou codificao mais

adequada.

Nota 1: Qualidade Interna

Capacidade do software de satisfazer as necessidades explcitas, como por exemplo, o

atendimento s funcionalidades acordadas com o cliente ou o desempenho esperado pelo

software, sempre observando a percepo do usurio.

Nota 2: Qualidade Externa

No entanto, no nosso contexto rascunho um esboo, deli-neamento, trabalho prvio de redao feito antes de passara limpo.

Por alguma razo, profissionais de informtica possuemum vcio por artefatos digitais. comum ter preferncia

por arquivos que esto em algum lugar do HD. Contudo,a indstria sobreviveu vrias dcadas sem o computa-dor, e vrias reas de atuao vivem em paz sem o usodas mquinas. Na rea de desenvolvimento de softwarepodemos tambm utilizar meios que no so digitais.Quando falamos em modelagem de um software, umadas grandes dvidas das equipes de projeto quo longedevemos nos aprofundar em detalhes. Como ponto departida (apoio) podemos nortear nosso raciocnio atravsde questionamentos como:1. Qual o nome do projeto?2. Qual a dvida que tenho?

3. Quem poder modelar isso junto comigo para obter asrespostas?4. Qual o modelo certo?

Quando nos fazemos estas perguntas significa que esta-mos com o cliente e querendo saber o que o projeto, ouseja, na fase de levantamento de requisitos descobrindoos objetivos, o escopo, as funcionalidades, os riscos. Logi-camente quem ajudar a obter essas respostas o cliente.Estando, portanto, o analista de requisitos e o cliente reu-nidos, o ponto principal da reunio ter uma compreensoem alto nvel do sistema, e no todos os detalhes. No conveniente nessa reunio discutir as mincias. Detalhessero adicionados iterativamente e de maneira incrementaldurante todo o projeto.

Modelos tambm so formas de decises ou percepes.Nesse caso, a forma da percepo das funcionalidades edeciso do escopo inicial do projeto. Um dos valores damodelagem gil modelar com um propsito e, muitasvezes, modelar com um propsito significa buscar os cri-trios de sucesso do projeto. A modelagem busca atenderao usurio apresentando qualidade e reduzindo custoou prazo do projeto. altamente questionvel quando semodela s para cumprir etapas do processo ou porqueo processo de desenvolvimento exige tal modelo.

Uma das questes relevantes, vistas anteriormente, Qual o modelo certo?. importante ressaltar que h uma quan-tidade infinita de maneiras de se modelar. Um esboo feito deforma conjunta com as partes interessadas um meio muitoeficiente de capturar requisitos e descobrir como atingir oobjetivo de fazer um software com qualidade externa (verNota2), que atenda s expectativas dos usurios.



AGILIDADE

A importncia de se escrever documentos derequisitos

A vantagem em se fazer com que os clientes e usuriosparticipem da modelagem do sistema utilizando artefatos eferramentas simples, como rascunhos em papel ou no quadro

branco, promover a colaborao e ganhar agilidade na cap-tura de requisitos. Porm, algumas pessoas ou empresas noreconhecem artefatos em papel como vlidos no processode desenvolvimento. Isso leva a uma burocratizao desne-cessria na captura de requisitos.

Muitas pessoas levantam requisitos em artefatos informaispara depois transform-los em casos de uso, especificaessuplementares, prottipos, documentos de regras de negcioe outros quando voltam para casa. Isto , preenchem essestemplates depois das reunies, formalizando o levantamento.Como houve uma transformao de artefatos, tpica umareviso com o cliente para obter uma aprovao. O problema

que essa aprovao na maioria das vezes no ocorre. Ao ver osartefatos transformados o cliente lembra-se de mais requisitosque so mais uma vez capturados em artefatos informais e ociclo se repete muitas vezes. Com isso, levam-se semanas parase aprovar os requisitos e um tempo precioso perdido.

O objetivo de se trabalhar com rascunhos rapidamentetransform-los em software funcionando, de modo que seja en-tregue ao cliente o software a ser homologado e no documen-tos a serem aprovados. No se deve perder tempo aprovandodocumentos de requisitos depois que foram levantados, poiseles nunca sero aprovados, e mesmo que sejam aprovados ocliente poder mudar de ideia quando ver realmente o que elequer de fato. Num contexto geral, software funcionando ainda o melhor artefato para levantamento de requisitos. Dessaforma, os usurios olham o software e solicitam alteraesno software e no em documentos. Software a nica coisaconcreta que realmente validamos com os usurios.

Documentos de requisitos tm como objetivo registrar o queos usurios esperam da aplicao independente da soluotcnica. Isso faz com que esses documentos sejam simples erpidos de serem elaborados. Mas o mais importante queesses artefatos sejam elaborados na reunio de levantamentoe no em casa. Deve-se sair da reunio com requisitos levan-tados e documentados, depois disso, fazer o software paracumprir o planejamento da iterao.

Modelagem na obteno da qualidadeAt ento vimos que a modelagem gil pode melhorar e

documentar decises focadas na qualidade da aplicao,facilitando a comunicao e disseminando ideias dentro dotime. A modelagem gil possui um princpio chamado TravelLight. Este princpio diz que manter modelos difcil, e podese tornar ainda mais se estes forem complexos e detalhados.Especialistas na rea afirmam que trs ou quatro modelosque forneam uma viso geral da anlise, da arquitetura e dodesign so suficientes para melhorar a comunicao da equipe. errado pensar que quanto maior o nmero de documentaes

melhor ser o projeto. A documentao precisa ser enxuta.

Entretanto, a prtica do excesso de documentao aindaocorre em muitos projetos. A implantao da modelagemgil dentro da cultura de desenvolvimento de software umaexperincia tanto interessante quanto traumtica, devido grande mudana de pensamento trazida pelo mtodo. Para

direcionar os esforos em torno da modelagem gil, existemalguns princpios que devem ser observados para que o pro-cesso adotado seja realmente gil. Dentre esses princpios, osmais importantes so:

Princpios Fundamentais

Software seu principal objetivo: Produzir softwares quefuncionem;Racionalizao de artefatos: Racionalizao da documenta-o, escolhendo aqueles a serem mantidos durante o processode desenvolvimento; Modele com um propsito: Para atender a realidade e paramelhorar a comunicao;

Maximize o investimento do Stakeholder: Valorizar a pes-soa chave que representa a empresa.

Princpios Complementares

Contedo mais importante que representao: Despren-der-se um pouco de prottipos, apresentando o softwarerodando como uma importante forma de validao junto aocliente; Cada um tem algo a aprender com o outro: Na modelagemgil comum a participao ativa do cliente. Esta interaomais estreita permite que ambas as partes (produtor e clien-te) se entendam melhor, trazendo importantes ganhos aoprojeto; Adapte o modelo organizao: Cada projeto possui parti-cularidades que precisam ser observadas. Muitas vezes estasparticularidades esto relacionadas com o estilo da empresaprodutora do software e neste caso o modelo deve estar ali-nhado a ela; Comunicao transparente e honesta: Com a participaoefetiva do cliente importante prezar pela transparncia dasinformaes, que devem estar de comum acordo para ambasas partes; Atentar para os instintos da equipe: Ouvir as sugestes ereclamaes da equipe, pois talvez o problema que ela encon-trou possa dificultar no restante da implementao.

A modelagem gil tambm possui dois tipos de prticas: asprticas centrais e as prticas suplementares. Elas sugerempontos que devem ser observados pelas equipes de desenvol-vimento de software que ainda no utilizam a modelagem gil,mas que pretendem introduzi-la em seus projetos.

Prticas Centrais

Trabalho em Equipe: Participao dos vrios perfis da equipedo projeto durante o desenvolvimento de software, incluindoo Stakeholder, proporcionando o conhecimento coletivo e evi-tando que somente uma pessoa domine todo o processo. Uma

forma de disseminar o conhecimento pode ser a divulgao



dos modelos produzidos colocando-os em painis, parede ououtro meio; Simplicidade: Criao de contedo mais leve, descrevendomodelos simples e utilizando ferramentas menos complexas.

Prticas Suplementares Produtividade: Utilizar padres e normas de modelagem,aplicando padres com sabedoria e reutilizando recursosexistentes; Documentao: Descartar modelos temporrios, formali-zando os modelos de contrato; Propsito: Modelar para entender e para se comunicar; Boas Ideias: Conhecer bem as ferramentas, refactoring eTest-First Design.

Comprovao atravs do cdigoUma das discordncias que muitas equipes tm contra meto-

dologias geis o foco no cdigo. Entretanto, no cdigo quea alta coeso e baixo acoplamento oferecem benefcios. Umdos princpios da Modelagem gil : Prove com Cdigo.Isto , os modelos so somente uma abstrao daquilo que seest construindo de fato. Mas ser que o modelo est correto?Ser que ele implementvel? Para saber estas respostas necessrio provar o modelo com cdigo.

importante ressaltar que a atividade de modelagem visaobter uma qualidade do cdigo e no do modelo. Uma boamodelagem tem como objetivo obter um bom cdigo, e no um

bom modelo. A qualidade sempre deve focar no cdigo e nosimportantes conceitos de alta coeso e baixo acoplamento.

ConclusoEste artigo apresentou que artefatos simples podem ser uti-

lizados para aplicar boas prticas de modelagem. Modelagem uma atividade em grupo (na maioria das vezes) e tudo quese faz deve ser focado em melhorar a qualidade do software ea produtividade da equipe. Modelar simplesmente para tero modelo deve ser evitado.

Entretanto, o mais importante de tudo focar nas atividadesdo desenvolvimento e no nos artefatos criados. Durante olevantamento de requisitos, as atividades de conversar com ousurio, obter informaes e enriquecer o conhecimento somais importantes que os casos de uso, prottipos ou modelos

que surgirem dessa atividade. O importante a criatividade nasoluo do problema, na separao dos conceitos e nas mensa-gens trocadas entre os envolvidos no projeto do software.

Podemos ver tambm ao longo do artigo que muitas pessoasconfundem a atividade de levantamento de requisitos compreenchimento dos templates de artefatos de requisitos. E,pior ainda, muitas vezes esse preenchimento de artefatos feito simplesmente para cumprir tarefas de um processo dedesenvolvimento pesado, que muitas vezes interferem deforma negativa na criatividade das pessoas.

O que o cliente quer o software e no os documentos queabstraem o que se espera do software. Muitos dos artefatos

sugeridos e utilizados na modelagem gil so rascunhos decasos de uso, rascunhos de prottipos de tela, rascunhos dediagrama de atividades. Tudo em papel, desenhados junto como cliente e com isso automaticamente aprovados por ele. Essesrascunhos so ento transformados em software funcionando,seguindo as boas prticas da Engenharia de Software.






D

seuFeedback

sobree

sta

edio

AMBLER, SCOTT. Home Page Agile Modeling

www.agilemodeling.com

COCKBURN, ALISTAIR. Home Page www.alistair.cockburn.us.

Referncias



Gabriela de Oliveira [email protected]

formada pela UNICAMP em Tecnologiaem Informtica e est cursando mestradona rea de Engenharia de Software. Possuicertificao pela Scrum Alliance, tem expe-rincia de trs anos no trabalho com me-todologias geis e de cinco anos em Testese Qualidade de Software. Hoje atua comoScrum Master em projetos internacionais

pela Ci&T e j palestrou em eventos comoAgile Brazil 2010.


Neste artigo apresentada uma lista onde citou-

se o resultado de um estudo que lista quais as

principais causas para os problemas mais fre-

quentes em projetos Scrum. Este estudo foi rea-

lizado dentro dos ltimos dois anos em projetos

com times geis, inicialmente dentro do papel de

analista de testes e lder de testes, e nos ltimos

meses, tambm no papel de Scr um Master.

Para que serve?

O artigo tem a inteno de ser uma referncia

tanto como lies aprendidas de um estudo de

caso, que so consideradas valiosas no ambien-

te gil, assim como para abrir precedentes para

futuras discusses sobre os pontos levantados

como causas razes e suas solues propostas.

Acredita-se que muitas pessoas no meio gil ou

at mesmo fora dele possam contribuir para a

melhoria deste cenrio vislumbrado no estudo

citado.


O tema til para os prossionais de Engenharia

de Software em geral que planejam iniciar pro-

jetos uti lizando me todologias g eis ou at mes-

mo para aqueles que j as utilizam mas esto

enfrentando problemas com seus resultados.

Scrum: No funcionou para voc?Erros comuns na tentativa de implantar Scrum em times geis

Durante muitos anos, as metodo-logias tradicionais foram utili-zadas amplamente pela maioriados projetos e das empresas de desenvol-vimento de software, e o modelo cascataera tido como o mais completo e efetivo.Essa situao se modificou assim quesurgiram os primeiros projetos geis,logo aps o manifesto gil em 2001, e omundo do desenvolvimento de softwarese dividiu entre os mais conservadores eos simpatizantes do Scrum, XP e outrasmetodologias geis.

No entanto, apesar dos casos de su-cesso serem muitos, logo comearam aaparecer os primeiros estudos de casoque apresentavam problemas utilizando

tais metodologias e, principalmente, o

Agilidade

Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.


14/4214 Engenharia de Software Magazine- Scrum: No funcionou para voc?

Scrum. O Scrum, mesmo com inmeras vantagens em vriasperspectivas, deve-se deixar claro, no a soluo perfeita paratodos os problemas da rea de Engenharia de Software, logo,no a bala de prata dos projetos de desenvolvimento.

Neste artigo, pretende-se apresentar algumas lies aprendi-

das durante os ltimos anos na rea da qualidade de softwaree tambm na liderana em equipes de desenvolvimento traba-lhando com Scrum. A principal inteno de listar tais lies ajudar outras equipes que possam vir a ter os mesmos (ousemelhantes) problemas no decorrer do desenvolvimento deaplicativos e sistemas.

Conceitos da MetodologiaAntes de apresentar os problemas decorrentes do mau uso

da metodologia citada, faz-se necessrio entender os conceitosbsicos envolvidos no trabalho com projetos geis e a origemdas ideias que definem o SCRUM.

No ano de 2001, logo aps um encontro onde profissionaise acadmicos da rea de desenvolvimento de software de-monstraram seu descontentamento com a maneira com que osprojetos estavam sendo desenvolvidos dentro das empresas,surgiu o Manifesto gil. Este manifesto foi o ponto de inciopara os principais conceitos das metodologias que viriam aseguir. Ele foi traduzido para muitas lnguas, inclusive para oportugus, e citado em vrios artigos da rea de Engenhariade Software [1].

O Manifesto deu origem a metodologias como XP, Scrumentre outros e junto com estes conceitos tambm nasceram ospapis envolvidos neste processo. Estes papis so: Time: Quem realmente desenvolve e produz com qualidade.Os membros do time devem ser comprometidos com o trabalhoe responsveis por atingir a meta de uma sprint (perodo dedesenvolvimento). Devem ser cada vez mais auto-gerenciveise multidisciplinares. Um time normalmente no ultrapassa onmero de nove pessoas e atua em um ambiente adequadoafim de facilitar a comunicao efetiva (um dos pontos maisimportantes em times geis); Product Owner (PO): quem faz a ponte entre o clientee o fornecedor. Deve ter uma boa noo do produto e dasnecessidades do cliente. Responsvel por manter o product

backlog sempre atualizado e priorizar o trabalho das sprintsque viro. Tambm so atividades do PO definir a viso doprojeto, metas e objetivos das sprints e repassar para o ScrumMaster o objetivo do produto;

Scrum Master (SM): um lder, mas acima de tudo, umfacilitador. O principal objetivo deste papel remover im-pedimentos, melhorar o dia-a-dia do time, auxiliar o PO naconstruo e priorizao do Product Backlog, enfim, garantira aplicao do Scrum. Um bom Scrum Master deve ensinar

o cliente a maximizar o ROI (Retorno sobre Investimento) efacilitar o desenrolar das reunies, to fundamentais nesteprocesso.

Outro ponto fundamental, alm dos papis, so as reuniesrealizadas no decorrer de uma sprint (Figura 1). Os conceitosque envolvem estas reunies e a sprint so apresentados aseguir. Sprint Planning: Define o incio de uma sprint com a re-alizao de tarefas como: identificao dos itens do ProductBacklog (requisitos) para a construo do Sprint Backlog queser atacado durante a sprint, estimativa em pontos dos itens

que sero desenvolvidos, definio da meta da sprint (commit-ment) e quebra dos itens (estrias) em pequenas tarefas; Daily Meetings (Stand up Meetings): Reunio, como onome j diz, diria e feita geralmente em p. O costume defaz-la em p foi uma maneira escolhida para garantir que sos 15 minutos determinados seriam utilizados e que o timeno perderia o foco da reunio. O principal objetivo destepequeno encontro responder as perguntas base definidaspela metodologia: O que eu fiz desde a ltima reunio?,O que vou fazer at a prxima reunio? e Tenho algo queesteja me impedindo?;Retrospective Meeting: Mais uma reunio que tem por basea resposta a trs perguntas. O time todo responde s pergun-tas: O que foi bom nesta sprint?; O que no foi bom nestasprint?; e O que devemos melhorar para a prxima sprint?.Para esta ltima pergunta, deve-se escolher entre as respostas(atravs de votao no time) quais os pontos que sero desen-volvidos e melhorados para a prxima sprint; Review Meeting: Tem por objetivo apresentar o que foiconstrudo durante a sprint pelo time. O time apresenta aoPO o que foi desenvolvido at o presente ponto e o prprioPO decide se o que foi apresentado atingiu ou no a meta dasprint. Podem se fazer necessrios ajustes no backlog ou atmesmo repriorizao de estrias a partir deste ponto.

Vale ressaltar aps a conceituao das reunies, que a atu-ao do Scrum Master, durante toda a sprint essencial parao bom andamento do projeto. A participao do PO em todasas reunies citadas acima tambm essencial, tanto que esteponto ser salientado em breve neste mesmo artigo.

A raiz dos problemas (ou seriam as razes?)Depois de alguns anos trabalhando com a metodologia

Scrum, pode-se perceber alguns fatores que se repetem comoos principais viles e so, muitas vezes, responsveis peloinsucesso de projetos e entregas. Feito um estudo inicial e umlevantamento destes fatores j citados, encontrou-se inclusive,

suas respectivas causas razes.Figura 1. Ciclo de Vida de uma Sprint



AGILIDADE

Antes de detalharmos os problemas e suas causas, devemoster a conscincia de que, como em toda e qualquer metodologia,no desenvolver projetos seguindo suas principais caracters-ticas, vai sim acarretar problemas. Vale ter em mente que, ne-nhuma metodologia pode obter bons resultados se as equipes

no seguem seus valores e premissas corretamente.

Product Owner no envolvidoVisto qual o papel do Product Owner e sua importncia

para a metodologia proposta, pode-se analisar o quo grave a falta da presena deste papel durante o decorrer da sprint.Exemplos claros como blocks (impedimentos) no decorrer dodesenvolvimento podem atrasar e prejudicar muito um projeto.Ter o PO durante todas as reunies dirias e principalmenteno momento da Planning, onde todas as dvidas (ou pelomenos sua grande maioria) sobre as regras de negcio soresolvidas, essencial.

Este problema de no envolvimento do PO com o time ou como projeto em discusso normalmente causado pela falta deprofissionais alocados para o papel: um mesmo PO divididoentre vrios projetos e s vezes, este chega at confundir requi-sitos, times etc. Este fato, por exemplo, pode ser visto quandoh uma demora para solucionar blocks.

Um dos jeitos mais fceis para identificar quando um blockest afetando o bom andamento do sprint o prprio burndo-wn chart. Pode-se perceber pela Figura 2, o desvio de trabalhocausado por um block entre os dias 23 e 25/11 dentro de umprojeto real. O time vinha trabalhando em uma velocidadeesperada e muito prxima da linha do ideal (segundo a le-genda), mas teve um pequeno desvio neste perodo citado nacapacidade de realizar tarefas. Isto se deve ao fato de que estemesmo time no possua em mos o contedo necessrio paraconfeco das pginas acordadas nas estrias. Esta falta decontedo, aqui sendo considerada o block, foi a principal causapara tal desvio no meio da sprint e pde ser vista claramenteno grfico durante as reunies dirias.

E a segunda pergunta importante a fazer seria: como tratareste problema? A melhor maneira de tentar minimizar osefeitos deste problema dentro de um projeto seria o ScrumMaster trabalhar mais prximo ao Product Owner, no senti-do de conseguir as informaes necessrias e desbloquearo time. O papel do Scrum Master tambm ajudar o PO aseguir os ritos do Scrum e manter o time sempre livre paratrabalhar sem blocks.

Falta de Requisito (Estrias mal escritas)Outro problema srio que envolve diretamente o trabalho

do PO so os requisitos (estrias) mal escritos. O requisito,ao contrrio do que a maioria das pessoas pensa, sim partefundamental no Scrum. As estrias servem como base para otrabalho tanto durante o desenvolvimento, quanto para testesde software e validao em homologao. Eles so feitos demaneira mais resumida, mas no podem deixar de conter asinformaes necessrias para o bom entendimento da funcio-

nalidade desejada e devem ser bons o suficiente para servirem

Figura 2.Burndowndeprojetocomblockentreosdias23e25/11

como base aos casos de testes (isto tambm ser discutidomais adiante).

Falando de fatores que levam a insucesso, podemos consi-derar alguns fatores que levam estrias a serem mal escritas.O primeiro fator uma descrio muito longa. A ideia dedescrever uma estria que os principais pontos possam sertratados como uma checklist para futuras discusses du-rante a planning meeting. Descrever com muita informaoe muitos detalhes pode levar o time a perda da colaboraoe a confiana de que tudo j est escrito (como acontecia emantigas metodologias). O principal papel da estria levar otime a estar sempre buscando a comunicao e a colaborao.Se estes pontos no surgirem, perde-se o foco do Scrum.

O segundo fator confundir critrios de aceitao com casosde teste. Critrios de aceitao so teis para responder pergun-tas do tipo Quando sabemos que a estria est pronta? e nopara perguntas do tipo Como testar e como saber se foi feitoda maneira correta?. Estas sim so questes para se pensar nomomento da criao dos casos de testes em si. Critrios devemser o suficiente para se saber o que deve ser feito do momento daplanning meeting em diante, mas no podem ser to detalhadoscomo um documento de Caso de Uso. O uso de ferramentas decriao de estrias tambm pode ajudar nestes casos, principal-mente nos primeiros projetos dos times com menor experincia

ou com Product Owners novos dentro dos times.

Figura 3.ExemplodeUserStory


16/4216 Engenharia de Software Magazine- Scrum: No funcionou para voc?

Seguir o exemplo da Figura 3, ainda a melhor sada paraevitar problemas de estrias mal escritas. O padro da figurapode ser traduzido como: Eu, como , quero , para que . Este exemplo,por estudos na rea e experincia pessoal, o modelo mais

utilizado em times geis no mercado at hoje. Abaixo umexemplo de estria que segue o modelo da Figura 3.Eu, como Product Owner, quero que a home page tenha

uma busca, para que todo usurio possa acessar o contedoque deseja rapidamente.

Vrias estrias em desenvolvimentoUma ideia muito utilizada nos processos geis o one piece

flow. A ttica de atacar todos juntos o mesmo problema, um aum, um dos motivos da metodologia ser representada por umafoto de um time de rugby (todo o time atacando junto e ao mes-mo tempo exatamente a jogada Scrum). Na Figura 4 podemos

ver como este time se posiciona para resolver a jogada.Se no estamos atacando as estrias uma por vez, estepode ser um dos pontos de ateno para o no cumprimentodas metas finais. Tentar realizar todas as estrias de uma vez um dos maiores problemas e pode ser visto em muitos timesna atualidade.

Pode-se perceber pela Figura 5, um exemplo claro de board dotime em que muitas estrias esto sendo executadas ao mesmotempo. Deve-se perguntar: existe mesmo a necessidade de terpessoas alocadas em tantas estrias ao mesmo tempo? Real-mente no existe nenhuma tarefa que estas pessoas poderiam

estar atacando na primeira estria? Se o time multifuncional,por que no dividir tarefas de teste com desenvolvedores,tarefas de webdesign com testers, etc.? Responder todas estasperguntas pode ser um bom ponto de partida para a soluodo problema de no entregar estrias totalmente prontas (done)ao final da sprint e ter vrias estrias iniciadas.

Estimativas OtimistasOutro problema frequente que pode ser analisado durante

os projetos geis so as estimativas erradas. Quase sempre,as estimativas so otimistas e os resultados so catastrficos.Ser que somos mesmo capazes de fazer o trabalho proposto

em to pouco tempo? Esta uma das perguntas que o timenunca se faz quando est em meio presso do Scrum Master eprincipalmente, do Product Owner. claro que o cliente (nestecaso a figura do Product Owner) sempre ter o interesse emver o produto final pronto em menos tempo, mas o que temosque ter em mente que esta pressa por chegar reta final nofaz com que o trabalho fique efetivamente pronto mais rpido,e o pior, acarreta problemas ainda mais srios como defeitosem produo e regresso no desenvolvimento do software. Oque deve ser relembrado durante a planning meeting o fatode quem estima o esforo o time. Scrum Master e ProductOwner devem participar apenas para facilitar a reunio esolucionar possveis dvidas, respectivamente.

Projeto Scrum vendido com prazo e/ou Escopofechados

Trabalhar com um product backlog que aos poucos vai setransformando em Sprint Backlog e entregar produto comvalor ao cliente: este o formato que buscamos. Fica claro quesempre que se vende projetos em Scrum, estes deveriam servendidos por nmero de sprints, ou valor por sprint, e nuncaescopo fechado. Scrum no tem escopo fechado, incremen-tal, e como tal, tem o direito de ser mutvel. Prazos e escoposfechados so uma realidade do passado quando trata-se deprojetos geis e isso tem que ser respeitado para um bomresultado dos projetos.

Logo, fica a pergunta, como vender projetos Scrum? Existemvrias maneiras que vem sendo utilizadas, mas uma das maissimples pode ser vista pela frmula/exemplo a seguir:

Consideremos um time fixo, com velocidade e tamanho desprints tambm definidos. O Product Backlog deste projetoseria algo em torno de 1000 pontos. Se a equipe possui umavelocidade de 50 pontos e as Sprints duram 2 semanas, comoseria feito o clculo de venda deste projeto? Dividimos o n-mero de pontos do backlog (1000) pelo tamanho das sprints(50) e vamos obter o nmero das semanas (40 semanas). Aeste nmero de semanas, somamos uma sprint a cada 5, para

que possveis defeitos possam ser corrigidos e mudanas de

Figura 4.Timederugby(representaodoSCRUM)

Figura 5.Boardcomvriasestriassendofeitasaomesmotempo



AGILIDADE

escopo possam ser mais bem tratadas. Neste caso, ficaramoscom 24 sprints. O clculo final seria o nmero final de sprints(24) vezes o nmero de horas de todo o time.

Testes geis ou mtodo cascata?

claro que o desenvolvimento gil chegou nos ltimos anoscom peso muito forte e que est tomando cada vez mais espaonas salas em empresas no mundo todo. O que devemos nosperguntar : Estamos TESTANDO de maneira gil?

Bem, se desenvolvemos de maneira incremental, por quemuitos ainda deixam os testes como a ltima atividade dacadeia? Sem dvida, como resultado das pesquisas realizadasnos ltimos anos, esta a principal causa de problemas nosprojetos onde o escopo alterado e a falta de qualidade na en-trega foram ressaltados pelo cliente. Como justificar muitosdefeitos ao final do projeto? Simples dizer se notarmos queos testes so deixados para o final da sprint da mesma forma

como j era feita no mtodo cascata.Mudamos de metodologia, devemos mudar de paradigma.Casos em que o time todo ajuda a testar e depois o especialistaem testes fica bloqueado at o final da sprint ou at mesmoque o testador fica com todos os testes e, por falta de tempo,defeitos acabam no surgindo, so frequentes. importanteressaltar: temos que mudar o paradigma e comear a fazer tes-tes tambm de maneira incremental. Deixamos este contedopara um prximo artigo, mas esta questo pode ser utilizadacomo o ponto inicial para que todos ns pensemos em comoresolver o problema.

De uma forma geral, pode-se explicar uma possvel soluopara testes funcionando como uma espcie de gargalo notrabalho do time, com a criao dos Testes geis ou TestesIncrementais. O profissional da rea de testes pode e devecomear a atuar desde o primeiro dia da sprint. Segue abaixouma lista com as atividades do dia a dia deste profissional,fazendo com que todo o time esteja mais engajado na disciplinade testes e que todo o trabalho seja cumprido de forma maiseficaz e incremental:

Dia a dia de testes dentro do Scrum: Dia 0: Antes mesmo da planning meeting, o analista detestes, aproveitando-se de sua viso geral do produto, poderrevisar os requisitos (estrias), fazendo com que estas fiquemmais claras e completas. Este trabalho pode ajudar tanto oPO como o time todo, j que a planning ser muito mais pro-veitosa tendo um requisito mais completo e revisado por ummembro do time;Dia 1: Incio do desenvolvimento. Enquanto nada est desen-volvido, criam-se os casos de testes baseados nos critrios deaceitao das estrias. Este trabalho ser bem reduzido pelofato da reviso j ter sido feita anteriormente; Dia 2 a Dia n: Durante todo o desenvolvimento, os testessero realizados em duas etapas: durante toda a sprint noambiente dos desenvolvedores (assim muitos dos defeitossero antecipados e a comunicao entre desenvolvedores e

testadores far com que a qualidade do produto fique aindamais elevada) e logo aps a finalizao do desenvolvimento, noambiente separado para testes (o teste funcional que as equipes

j fazem), onde todos os defeitos so realmente reportados, svezes at atravs de uma ferramenta;

Dia Final: Os testes se concentram em Testes de Regresso,para que se possa confirmar a qualidade verificada anterior-mente no produto e em Retestes, para assegurar que todos osdefeitos reportados foram corrigidos.

Este o incio de uma das vrias propostas que esto sendofeitas para minimizar os problemas que vem sendo encontra-dos na disciplina de testes em equipes geis.

ConclusoEste artigo apresentou um estudo sobre quais os principais

problemas encontrados em projetos utilizando a metodologia

Scrum.Foi apresentada uma lista de problemas frequentes, junta-mente com a conceituao bsica do que a metodologia ecomo deveria ser tratada, para que todas as equipes tenham achance de pensar mais sobre o assunto e tentar melhorar emfuturos projetos.

Algumas ideias j foram apresentadas como possveis solu-es para a maioria das questes citadas, mas claro que serianecessrio outro artigo para tratarmos das melhores soluespara cada um dos itens da lista. Assim como o estudo realizadopara verificar os pontos que afetavam a qualidade de entregaem projetos Scrum, seriam necessrios outros estudos voltadospara todas as possveis solues. Precedentes para trabalhosfuturos j comeam a surgir e podero ser verificados emartigos futuros.

[1] BECK, K.; FOWLER, M. et al (2001). Manifesto for Agile Software Development.

http://www.agilemanifesto.org/.

[2] CRISPIN, L; GREGORY, J. (2009). Agile Testing: A Practical Guide for Testers and Agile Teams.

Addison-Wesley Professional. ISBN 0321534468.

[3] COHN, M. (2004). User Stories Applied for Agile Software Development. Addison-Wesley

Professional. ASIN B000SEFH1A.

[4]PEREIRA, R. (2008). 10 Benefits of One Piece Flow.

http://lssacademy.com/2008/03/27/10-benefits-of-one-piece-flow

Referncias






D

seuFeedback

sobree

sta

edio


18/4218 Engenharia de Software Magazine- Modelagem Temporal, de Implantao, de Artefatos e de Componentes atravs da UML

Geraldo Magela Dutra [email protected]

graduado em Engenharia Civil e possui es-pecializao em Anlise e Desenvolvimento deSistemas, ambas pela Universidade Federal deJuiz de Fora. tcnico em TI da UniversidadeFederal de Juiz de Fora onde trabalha comdesenvolvimento de sistemas de informao einformtica desde 1988. professor do CursoSuperior de Tecnologia em Anlise e Desenvol-vimento de Sistemas da Fundao Dom AndrArcoverde em Valena/RJ.


Esse artigo apresenta os Diagramas de Temporiza-

o, que integram o grupo de diagramas da UML

destinados a modelar comportamento. Apresenta

tambm os Diagramas de Artefatos, Diagramas de

Componentes e Diagramas de Implantao, desti-

nados documentao nas atividades de projeto de

desenvolvimento de sistemas.

Para que serve?

A mesma viso dos artigos anteriores se aplica aqui.

Apresentar a notao de forma clara e objetiva, pro-

curando destacar principalmente os elementos mais

teis nas situaes reais de modelagem. Procura-se

uma maneira prtica de aplicao dos recursos, sem

grandes nus para os cronogramas de projeto. Docu-

mentao desenvolvida de modo draft, no incio do

projeto, pode ser detalhada ao longo dele, paralela-

mente s atividades de implementao e testes.


Sistemas com estados tempo-dependentes de

forma contnua podem valer-se dos Diagramas de

Temporizao para especicao das transies

permitas e das restries de tempo associadas a es-

sas transies. J sistemas com topologia no trivial

e/ou extensa, necessitam modelagem atravs dos

Diagramas de Implantao. Sistemas desenvolvidos

com orientao a componentes so cada vez mais

comuns e enfatizam a desejada capacidade de reu-

so, onde Diagramas de Componentes sero teis em

sistemas de porte mdio a grande.

Modelagem Temporal, de Implantao, deArtefatos e de Componentes atravs da UMLAbordagem Prtica Parte 4

Aliteratura tcnica, hoje vastae diferenciada, costuma serunnime em classificar os dia-gramas da UML (Unified ModelingLanguage) em dois grandes grupos: Dia-gramas Estruturais e Diagramas Com-portamentais. No h nada de erradocom essa classificao, mas existe umaoutra, com mais sub-nveis, que traduzde forma mais completa a natureza de

cada diagrama, assim como tipifica mais

acuradamente as abstraes capturadaspor cada um deles. Ento, classifica ostreze diagramas da UML em quatrocategorias: Modelagem Estrutural: Diagramas deCasos de Uso, Diagramas de Classes, Dia-gramas de Objetos, Diagramas de Pacotese Diagramas de Estrutura Composta.Modelagem de Interaes: Diagramas deSequncia, Diagramas de Comunicao e

Diagramas de Viso Geral da Interao.

Desenvolvimento

Nesta seo voc encontra artigos voltados para diferentesabordagens de apoio ao desenvolvimento de projetos de software

Contedo Multimdia!

Neste artigo voc encontra o vdeo: Conhecen-do o diagrama de componentes.

www.devmedia.com.br/esmag



PROJETO

Modelagem Comportamental: Diagramas de Transiode Estados, Diagramas de Atividades e Diagramas deTemporizao. Modelagem da Implantao: Diagramas de Artefatos, poucodiscutidos na literatura tcnica mas teis em sistemas de to-

pologia no trivial, Diagramas de Componentes e Diagramasde Implantao.

Nos dois ltimos artigos dessa srie foram abordados osDiagramas de Transio de Estados e os Diagramas de Ati-vidades. O Diagrama de Temporizao completa o grupode Modelagem Comportamental. Para encerrar essa srie deartigos, so apresentados tambm os trs diagramas de mo-delagem da implantao, fase final da execuo de um projetode desenvolvimento de sistemas de informao.

Restries Temporais Discretas e Restries Temporais

ContnuasSistemas com estados ou processos tempo-dependentes po-dem ser classificados em duas categorias bem distintas. Numprimeiro grupo, situam-se os sistemas onde os intervalos detempo (time units) associados s transies entre estados sopercebidos de forma discreta. Isto significa que os intervalosde tempo tm duraes uniformes e pr-fixadas, no admitindovariaes. Como exemplo, no fluxo de controle de uma mquinade lavar moderna, o tempo em que ela estar operando no esta-do lavando sempre igual, ou seja, tem um valor fixo finito epr-fixado, no admitindo variaes entre diferentes sesses deexecuo. Em termos objetivos, a mquina estar operando emestado lavando por 5 minutos, por exemplo. Tais restries detempo, presentes nos cada vez mais comuns sistemas embarca-dos, podem ser modeladas pela rica sintaxe dos Diagramas deTransio de Estados e pelos Diagramas de Atividades, comofoi demonstrado nos dois artigos anteriores.

Um segundo grupo, rene sistemas onde as transies entreestados de um objeto ou de um grupo de objetos se darodentro de um intervalo de tempo no fixo, embora finito. Emtermos prticos, o sistema espera por um evento externo ouinterno que inicie uma transio dentro de um intervalo detempo que possui um mximo. O evento dever ocorrer entre0 e 5 segundos, por exemplo. Se o intervalo de tempo se es-gotar sem que o evento esperado ocorra, o sistema provocarum evento interno que inicia uma transio alternativa. Paramodelar essa segunda categoria de sistemas, a UML disponi-

biliza o Diagrama de Temporizao.

Diagramas de TemporizaoDiagramas de Estados representam os estados possveis

de apenas um objeto e as transies permitidas entre eles.Diagramas de Atividades so um caso especial de Diagramasde Estados onde os estados so aes/atividades e podemrepresentar a participao de diversos objetos. Diagramas deTemporizao so, tambm, uma variao de diagramas deestados e de transies entre eles, mas onde tais transies

esto associadas a restries de tempo. Em ltima anlise,

representam estados e transies de um objeto ao longo deum perodo de tempo.

Construindo um Diagrama de TemporizaoO perodo de tempo representado nos Diagramas de Tempori-

zao chamado de linha de vida (lifeline) e pode ser divido emperodos menores chamados unidades de tempo (time units).Os estados e transies so representados dentro de um qua-dro com rtulo td (timing diagram). Um mesmo quadro poderepresentar uma nica linha de vida (de um objeto) ou vriaslinhas de vida (de uma colaborao) incluindo interferncia deuma linha de vida de um objeto sobre a linha de vida de outro.Essa interferncia se d atravs da emisso de mensagens detempo. Isto ser tratado frente, neste artigo.

Diagramas de Temporizao podem ser apresentados emduas notaes diferentes. Uma delas, mais simples, denomi-nada linha de vida de valor, e uma mais completa, denominada

linha de vida de estado. Para exemplificar a construo de umDiagrama de Temporizao, a Figura 1 apresenta um quadrode temporizao (timing frame) para um equipamento decaixa eletrnico utilizando a notao linha de vida de estados.Nela aparecem 3 linhas de vida (lifelines), cada uma delasrepresentando a linha de vida de objetos controladores doscomponentes do equipamento.

Cada linha de vida deve exibir os estados pelos quais oobjeto em questo transita, para que o grfico de tempo sejaapresentado como uma evoluo entre eles. Um leitor de car-tes magnticos e um mecanismo de contagem e entrega decdulas, so equipamentos fsicos controlados por objetos dosoftware de auto-atendimento bancrio. Tais objetos vo emitirsinais que sero recebidos e processados pelos equipamentos,ativando ou desativando suas funes. Para executar umasesso de uso, o software de controle do caixa eletrnico vaiinstanciar objetos de classes controladoras e ativar um fluxo decontrole condizente com a escolha do usurio a partir de ummenu de opes. Para realizar um saque, por exemplo, o con-trolador transita, em linhas gerais, entre os seguintes estados:disponvel lendoCarto esperandoSenha processando contandoCdulas disponvel. Alm disso, o leitor de cartes eo mecanismo de contagem de cdulas estaro sempre em umade duas condies possveis: disponvel/operando.

Para representar a evoluo da linha de vida ao longo dotempo, deve ser introduzida uma escala de tempo que divide

Figura 1. Timing Frame para um caixa eletrnico



um determinado perodo em unidades de tempo (time units).A Figura 2 apresenta essa escala, bem como os estados pelosquais transitam os trs elementos do equipamento.

O grfico de tempo ento montado horizontalmentesobre as linhas de vida, com as transies posicionadas nas

unidades de tempo. A linha de vida principal, do softwarecontrolador do equipamento (realizando um caso de uso),vai estar, a princpio, sincronizada com as linhas de vida dasunidades auxiliares apenas pela superposio coincidentedos momentos em que acontecem, mas essa representaopode ser melhorada com a introduo de mensagens detempo, como ser demonstrado.A Figura 3 apresenta os grficos representativos da evo-

luo pelos estados dos trs componentes do caixa. As ope-raes do leitor de cartes e do mecanismo de contagem decdulas esto sincronizadas com suas referncias feitas nalinha de vida do software controlador do caixa eletrnico.

Para enriquecer a representao de sincronia e depen-dncia entre as trs linhas de vida, pode-se lanar modo recurso de incluir mensagens de tempo, como referidoanteriormente. Uma mensagem de tempo deixa uma linhade vida e chega a outra no mesmo diagrama, enfatizandoa dependncia entre elas. Para fixar em que momentos issoacontece, cada unidade de tempo deve ser quantificadae nomeada. Os lapsos de tempo em que as unidades detempo representam no so necessariamente iguais, isto, cada estado permanece ativo por tempos diferentes. AFigura 4 apresenta mensagens de tempo emitidas da linhade vida do controlador principal para os controladores dosequipamentos auxiliares. Apenas os marcos importantes

Figura 2. Estados/Condies para cada linha de vida Figura 3. Grficos de temporizao das trs linhas de vida sincronizadas

do tempo foram nomeados, ou seja, apenas aqueles em quese do as transies de estados.

Finalizando o Diagrama de TemporizaoUm ltimo elemento nessa forma de representao de Dia-

gramas de Temporizao so as restries de tempo. Conformereferido anteriormente, essa representao dos Diagramas deTemporizao denominada linha de vida de estados. Ela apre-senta, claramente, estados e transies entre eles, assim comoas restries temporais aplicadas s transies. A Figura 5apresenta um diagrama de temporizao completo, com asrestries de temporizao aplicadas.

Comparando RepresentaesUma segunda maneira de representar Diagramas de Tempo-

rizao denominada linha de vida de valor. Mais adequadaquando se est lidando com uma grande quantidade de esta-

dos e transies, ela mais compacta e concisa, embora exibamenos informaes do que o formato anterior. A Figura 6mostra o formato de linha de vida de valor para o caixa ele-trnico apresentado. Nela, cada estado representado porum hexgono e as transies por cruzamentos das linhas desuas arestas. A escala de tempo pode ser apresentada comono formato anterior ou pode ser omitida, enquanto restriesde tempo e durao aparecem entre chaves.

Diagramas da Fase de ImplantaoNum processo de desenvolvimento de sistemas incremental

e iterativo (do qual o Rational Unified Process RUP umainstncia), quatro grandes fases de desenvolvimento so atra-vessadas por pelo menos 6 atividades diferentes: elicitao



PROJETO

de requisitos, anlise de requisitos, projeto, implementao,testes e implantao. Nesse tipo de processo de desenvolvi-mento aliam-se as melhores qualidades de duas aproximaesdiferentes para o desenvolvimento de sistemas de software ro-

bustos. A primeira delas a adoo das ferramentas e tcnicasde modelagem, que fornecem documentao de alto nvel e desuporte efetivo implementao. A segunda busca a melhorqualidade dos processos geis, rapidez no desenvolvimentosem sacrifcio da qualidade.

O processo incremental alia o desenvolvimento de modelosestveis e robustos da anlise orientada a objetos rapidezde desenvolvimento conseguida com a execuo de diversasiteraes durante a fase de construo, produzindo a cadaciclo concludo, um incremento que passa a integrar a partedo sistema que j est em operao. Assim, por exemplo, duassemanas aps o incio da fase de construo (uma duraoaproximada de uma iterao), j possvel implantar umaparte do sistema e torn-la operacional.

Para apoiar e documentar essa atividade dos ciclos de desen-volvimento, a UML disponibiliza trs tipos diferentes de dia-gramas: Diagramas de Artefatos, Diagramas de Componentes eos Diagramas de Implantao propriamente ditos. Embora nosejam citados e explorados na literatura tcnica e nem faamparte das listas oficiais de diagramas da UML, Diagramas deArtefatos so claramente referidos por Booch, Rumbaugh e Ja-cobson em sua obra UML Guia do Usurio, e podem ser muitoteis para documentao e localizao de artefatos em sistemas

de mdio a grandes portes, como ser demonstrado.

Figura 4. Mensagens de tempo emitidas entre linhas de vida Figura 5. Restries de tempo associadas s transies

Figura 6. Formato de linha de vida de valor para o caixa eletrnico

Artefatos e Diagramas de ArtefatosEnquanto modela as diversas vises de um sistema, o desen-

volvedor constri modelos lgicos, compostos de elementosigualmente lgicos. Assim a natureza de classes, interfaces,suas associaes, casos de uso e outros diversos componentesda linguagem de modelagem. Em determinado momento doprocesso, estes elementos lgicos tero de ser manifestadospor componentes fsicos, reais, que os implementem e permitamsuas operaes. Tais elementos fsicos so chamados artefatos.

Artefatos so elementos fsicos, suportados por uma platafor-ma de implementao. Um artefato pode ser entendido comoum pacote fsico contendo elementos lgicos tais como classes,interfaces e colaboraes. A Figura 7 mostra a notao UML2 para um artefato.

A ideia de artefato est fortemente ligada definio dearquivos reais, embora seja mais abrangente do que isso. Mas

de uma forma prtica, pode-se considerar que artefatos so



simplesmente arquivos individuais que suportam os elemen-tos lgicos e seus relacionamentos. Assim, existem artefatosresultantes do trabalho de desenvolvimento, ou seja, o produtodo desenvolvimento. So eles, arquivos fonte e arquivos de da-dos a partir dos quais sero gerados artefatos de implantao.

Estes, por sua vez, incluem os arquivos executveis, arquivosde configurao, arquivos de inicializao e bibliotecas, entreoutros. Esse segundo conjunto configura um sistema execut-vel completo, que suporta totalmente as especificaes lgicascontidas no primeiro conjunto. Um terceiro e ltimo conjuntode artefatos inclui aqueles que s tm existncia em tempode execuo de um sistema. Podem denominar-se transientesou efmeros.

Tais tipos de artefatos podem ser reconhecidos pela colocaode esteretipos tais como: , um arquivo comcdigo executvel, , uma biblioteca convencionalou dinmica, , um arquivo contento cdigo fonte, ou

, um arquivo em formato texto ou outro formatoque contenha uma tabela, um script, entre outros. Na represen-tao de artefatos, o desenvolvedor tem liberdade para criare usar esteretipos especficos para identificar artefatos inco-muns ou muito particulares de um determinado sistema.

A combinao desses tipos de artefatos permite modelartrs aspectos importantes de implantao de sistemas: a mo-delagem de executveis e bibliotecas, a modelagem de tabelas,arquivos e documentos, e a modelagem de cdigo fonte.

Diagramas de Artefatos admitem dois tipos de relaciona-

mento entre artefatos: uma dependncia, quando um artefatoutiliza servios oferecidos por outros, ou uma manifestao,quando um artefato uma manifestao fsica de um elementolgico qualquer.

Diagramas de Artefatos de Cdigo FonteO cdigo fonte que implementa as funcionalidades de um

sistema geralmente desenvolvido em uma srie de artefatosque so ento relacionados. Tais relacionamentos podemoriginar-se primariamente das especificaes lgicas dos re-lacionamentos entre trechos de cdigo, mas tambm podemrefletir dependncias de compilao, ou seja, diretivas obriga-

trias para obteno do cdigo executvel. Em outras palavras,a simples ausncia de uma biblioteca de classes pode tornarimpossvel a compilao de um mdulo, de um componenteou de todo um sub-sistema.

A modelagem criteriosa dos artefatos produto do desenvol-vimento oferece uma viso privilegiada dessas dependncias.A Figura 8 um exemplo desse tipo de modelagem aplicadoao caixa eletrnico.

A Figura 8 representa as dependncias entre artefatos. Paragerar o artefato software.class, que um arquivo executvel(interpretvel no caso do Java). O diagrama mostra tambmclaramente que, para executar, software.class faz uso de uma

biblioteca dinmica, biblioteca.dll, assim como depende deuma conexo a um sistema gerenciador de banco de dados,do qual usa dados de uma tabela denominada nomes.tbl.Para sistemas complexos de software, esta representao podeassumir importncia crtica.

Diagramas de Artefatos de Cdigo ExecutvelEsse diagrama pode ser particularmente til em sistemas

com diversos mdulos executveis que utilizam bibliotecasdinmicas. Os elementos que tm relao direta so represen-tados, assim como seus relacionamentos, que neste caso sotodos de dependncia, ou seja, um artefato utilizando serviosoferecidos por outros. A Figura 9 apresenta um exemplo demodelagem onde tambm esto modeladas as dependnciasexistentes em relao a um arquivo de inicializao assim comode um arquivo de ajuda on-line.

Diagramas de Artefatos de Arquivos AuxiliaresNem todos os artefatos que integram o conjunto de artefatos

do sistema so arquivos fonte, executveis ou bibliotecas. Umatabela integrante de um banco de dados relacional, por exemplo, tambm um artefato. A rigor, um sistema gerenciador de bancode dados um componente formado de dezenas de artefatos.Numa outra situao, um arquivo HTML pode ser usado comofonte para implementao de ajuda on-line para um sistema de

acesso via WEB. claro que modelar todo um banco de dados

Figura 7.Umartefato

Figura 8. Diagrama de Artefatos



PROJETO

utilizando Diagramas de Artefatos uma tarefa desnecessria,j que existe toda uma notao apropriada para essa finalidade,mas para destacar a interao entre um elemento executvel euma das tabelas de um SGBD, os Diagramas de Artefatos sode valia e ajuda inestimvel. AFigura 10 apresenta um exemplo

desse tipo de modelagem.Existem diversas consideraes importantes sobre o empregode Diagramas de Artefatos, especificamente falando, assimcomo sobre os inter-relacionamentos entre estes e os Diagramasde Componentes e de Implantao tratados frente.

Em primeiro lugar, os trs tipos de Diagramas de Artefatosno so estanques, isto , eles podem ser mesclados de formalivre, mostrando relacionamentos entre artefatos fonte, exe-cutveis e auxiliares e representando dependncias, manifes-taes e implantaes de forma livre. Isso gera uma riquezade representao que torna tais diagramas muito teis emgerao de documentao de apoio manuteno. Diagramas

de Artefatos construdos assim podem exibir tags com valoresatribudos que expressam uma srie til de atributos associa-dos aos artefatos, tais como verses, modificaes, atualizaese outros elementos.

Uma segunda considerao importantssima sobre a pos-sibilidade, e s vezes necessidade, de interseo entre os trsdiagramas de implantao. Artefatos podem estar contidosdentro de componentes de software (tratados adiante), e estespodem estar contidos dentro de pacotes, dentro de outros com-ponentes ou mesmo dentro de outros artefatos. Componentes desoftware, assim como artefatos isolados, podem estar alocadosa ns de processamento (elementos dos diagramas de implanta-o apresentados frente). Elementos lgicos da linguagem demodelagem podem ser manifestados pelos artefatos j citados,enquanto artefatos podem ser implantados em ns especficosde processamento. Quando se desenvolvem diagramas que as-sociam artefatos, componentes, pacotes e ns de processamento(tratados adiante), os relacionamentos entre artefatos e os demaiselementos, alm da dependncia, podem ser de outros dois tipos:implantao (deployment) ou manifestao (manifestation).Uma implantao indica um n fsico onde um artefato serlocalizado. Um relacionamento de manifestao representa umainstanciao fsica de um artefato qualquer.

Componentes e Diagramas de ComponentesNo cerne da ideia de componentes est a reutilizao. Em linhas

gerais, o desenvolvimento de software baseado em componentesinspira-se na mesma atividade desenvolvida com sucesso pelaengenharia de hardware e eletrnica em geral, que j projeta comsucesso, baseada em componentes, com mais de meio sculo devantagem em relao ao desenvolvimento de software. A idiano nova e nem engatinha. J existem padres de indstriareais e em desenvolvimento. Como elemento fundamental paraconstruo de tais sistemas situa-se o componente.

Um componente de software um elemento que integra umdeterminado sistema sem ser exclusivo deste. Em outras pa-lavras, um mesmo componente pode estar presente em mais

de um sistema de naturezas diferentes e pode ser tambm



substitudo a qualquer momento sem prejuzo para o sistema.A atuao de um componente dentro de um determinado siste-ma se d atravs de interfaces fornecidas pelo componente ourequeridas pelo mesmo, atravs das quais so fornecidos servi-os daquele componente ou requeridos servios fornecidos poroutros componentes. Interfaces se conectam ao componenteatravs de portas, definidas em sua estrutura encapsulada. Umcomponente , assim, totalmente encapsulado, s disponibili-zando suas funcionalidades atravs de portas especficas quecomportam interfaces.

Componentes no so elementos atmicos; eles possuemuma estrutura interna. Sua composio pode ser de classesinternas ou de outros componentes, assim como de pacotes.Os elementos da estrutura interna de um componente devem,naturalmente, exibir associaes. A forma mais corriqueira derepresentar estas associaes atravs de dependncias, mas ocaminho mais utilizado para isso a utilizao das interfaces.A Figura 11 apresenta a representao de um componente nanotao da UML 2. Est representada, alm do componente,uma interface requerida, atravs da qual esse componentepoder se conectar ao sistema. O contexto o mesmo usadoanteriormente. O componente mostrado utilizando um es-teretipo que pode ser omitido, j que o smbolo exclusivo

para componentes.



Desenvolvendo um Diagrama de ComponentesPara desenvolver um diagrama de componentes, a primeira

atividade determinar que componentes compem o siste-ma. Para o contexto do caixa eletrnico, trs componentespodem ser listados: o conjunto de classes que implementam

as funcionalidades do equipamento, o conjunto de classesque controlam o leitor de cartes e o conjunto de classes quecontrolam o mecanismo de contagem e liberao de cdulas,embora componentes nem sempre sejam apenas conjuntosde classes. Os equipamentos sero acessados por interfacesrequeridas, que sero realizadas pelos controladores (mtodosde classes controladoras) das funcionalidades (casos de uso)do equipamento.

O componente principal, o software controlador do equipa-mento, exibe uma estrutura interna que pode ser representadano diagrama. Essa estrutura interna inclui classes de fronteirae controladoras para cada funcionalidade, alm de acesso a

mecanismo de persistncia de objetos. Em ltima anlise,esse importante componente contm o sistema de controlepropriamente dito.

As interfaces requeridas pelos equipamentos perifricos sotodas fornecidas pelo componente principal, atravs de por-tas dedicadas que preservam o encapsulamento de todos oscomponentes. A Figura 12 apresenta um Diagrama de Compo-nentes que modela a arquitetura baseada em componentes dosistema. O diagrama foi desenvolvido dentro de um frame comrtulo cmp (componente). A estrutura interna do componente

Figura 11.Umcomponentecominterfacerequerida

principal no foi completamente mostrada, pois isso tornariao diagrama visualmente confuso.

Diagramas de ImplantaoSistemas simples, destinados execuo em estaes standa-

lone, tm todos os seus artefatos residentes nessa nica estao.Mas estes sistemas praticamente no existem mais. Sistemasmodernos de processamento de informaes so baseadosem acesso via web e residem em ambientes de processamentodistribudo, com seus artefatos residindo em diferentes pontosde uma rede de processamento. Estes pontos so denomi-nados ns de processamento e sua localizao geogrfica jno necessita fronteiras. Uma rede pode estar, e na realidadefrequentemente est, localizada em diversas locaes, s vezesem pases diferentes.

Em casos menos extremos, sistemas de mdio a grandeportes podem conter-se em um nico site, mas ainda assim

espalhando-se por diversos servidores diferentes. Para docu-mentar a rede de ns de processamento, assim como determi-nar a localizao real (fsica) dos diversos artefatos que compeo sistema, a UML disponibiliza o Diagrama de Implantaoque, entre outras finalidades, representa as localizaes fsi-cas (ns) e seu contedo (artefatos), exibindo ainda uma sriede atributos atravs de tags. Um n de processamento umalocalizao fsica que possui alguma quantidade de memriae freqentemente capacidade de processamento. A notao daUML para representar um n aparece na Figura 13.

Embora um n possa ser representado com apenas o nome,ele admite o uso de adornos, como tags com valores atribudose compartimentos especiais contendo listas de nomes de arte-fatos residentes naquele n. Na representao da topologia deum ambiente de processamento surgiro ns com capacidadede processamento e ns que simplesmente so dispositivosde armazenamento. Para distinguir entre esses tipos de nspode-se utilizar os esteretipos para dispositivos,e para processadores.

As conexes entre ns so normalmente representaes deligaes fsicas entre os componentes de uma rede, j que os nsrepresentam exatamente estes componentes. Para obter um dia-grama legvel e til no convm representar todos os artefatose sim aqueles considerados fundamentais para compreensodo funcionamento do sistema. Assim, em vez de representartodas as tabelas de um banco de dados, pode-se represent-locomo um pacote ou como um conjunto de componentes. Paradocumentar de maneira clara e til, o desenvolvedor podelanar mo de todos os elementos dos diagramas de artefatos,de componentes, de pacotes e de implantao, combinando-os vontade, para gerar documentao rica e til.

A Figura 14 representa a topologia para o sistema do caixaeletrnico, as conexes (inclusive as remotas) entre os diversosns, e as residncias dos principais artefatos do sistema. Site-Banco representa uma localizao fsica que executa programasde acesso s bases de dados. O n CaixaEletrnico conecta-seremotamente ao SiteBanco e estabelece uma colaborao que

desempenhar a funcionalidade requisitada.Figura 12. Diagrama de Componentes para o caixa eletrnico


25/42


26/4226 Engenharia de Software Magazine- Refatorao para Padres Parte 5

Marco Antnio Pereira [email protected]

Doutor e Mestre em Engenharia de Sis-temas e Computao pela COPPE/UFRJ,Especialista em Mtodos Estatsticos Com-putacionais e Bacharel em Informtica pelaUFJF, professor do curso de Bacharelado emCincia da Computao da FAGOC, professordos Cursos de Bacharelado em Sistemas deInformao do Centro de Ensino Superiorde Juiz de Fora, da Faculdade MetodistaGranbery e da Universidade Severino Som-bra, professor do Curso de Tecnologia emAnlise e Desenvolvimento de Sistemas daFundao Educacional D. Andr Arcoverde.Analista de Sistemas da Prefeitura de Juiz

de Fora, Editor da Engenharia de SoftwareMagazine.

Jacimar Fernandes [email protected]

Aluno do Curso de Bacharelado em Cin-cia da Computao da FAGOC - FaculdadeGovernador Ozanam Coelho, MicrosoftStudent Partners.


Aborda o tema refatorao para padres com o objeti-

vo de mostrar como o desenvolvedor pode us-lo para

melhorar o cdigo-fonte de suas aplicaes.

Para que serve?

Para prover conhecimento ao desenvolvedor sobre

refatorao para padres e demonstrar atravs de

um exemplo prtico a aplicao das tcnicas de refa-

torao para padres Substituir Lgica condicional por

Strategy.


O tema se torna fundamental para desenvolvedo-

res que j esto familiarizados com padres de pro-

jeto e j os implemen tam em seu s soft wares e que

querem saber mais sobre refatorao para padres,

conhecendo os benefcios que sua utilizao traz.

Refatorao para Padres Parte 5Implementando o padro Strategy com Substituir lgica condicional porStrategy

Uma prtica comum a vrios de-senvolvedores, principalmenteos que no possuem conheci-

mento sobre padres de projeto, a decriar extensos mtodos com complexalgica de seleo, com o objetivo de for-necer todos os caminhos para determi-nados comportamentos em um s lugar.Tal prtica funcional e pode ser realiza-da em tempo hbil, mas outras questesdevem ser levadas em considerao.

Mtodos com extensa lgica de seleopossuem complexidade ciclomtica ele-vada, o que pode vir a ser um problemaquando se pensa em manutenes futuras.A refatorao para o padroStrategy forne-ce um mecanismo mais sofisticado que ummtodo com extensa lgica condicional, se

bem aplicada. Contudo, refatorar para opadro Strategy no uma tarefa simples,visto que h vrios conceitos e prticasenvolvidas neste processo.

A partir deste momento sero apresen-tados conceitos e prticas que esto dire-tamente ligados ao processo de refatorarpara o padro Strategy com a utilizao

da tcnica de refatorao para padres

Substituir Lgica condicional por Stra-tegy, uma viso geral do que o padrode projeto Strategy, bem como as tcni-cas de refatorao Mover Mtodo (verNota do DevMan1), Introduzir ObjetoParmetro, Substituir Condicional porPolimorfismo e Substituir Enumeraopor Subclasse. Ao final ser abordada

a tcnica de refatorao para padres

Desenvolvimento

Nesta seo voc encontra artigos voltados para diferentesabordagens de apoio ao desenvolvimento de projetos de software



DESENVOLVIMENTO

Substituir Lgica condicional por Strategy, onde um exemploprtico de sua utilizao ser apresentado.

O padro de projeto Strategy

Nome do padro de projeto: Strategy. Pertencente ao con-

junto dos padres de projeto classificados como PadresComportamentais.Oproblema: Em alguns momentos possvel encontrar apli-

Engenharia de Software - Edição 32.pdf

Documents

Transcript of Engenharia de Software - Edição 32.pdf