Teste de Software 15

16 .Net Magazine - Quick Update

Faa um up grade em sua carreira.Em um mercado cada vez mais focado em qualidade ter conhecimentos aprofundados sobre requisitos, metodologia, anlises, testes, entre outros, pode ser a diferena entre conquistar ou no uma boa posio profissional. Sabendo disso a DevMedia lana para os desenvolvedores brasileiros sua primeira revista digital totalmente especializada em Engenharia de Software. Todos os meses voc ir encontrar artigos sobre Metodologias Ageis; Metodologias tradicionais (document driven); ALM (application lifecycle management); SOA (aplicaes orientadas a servicos); Analise de sistemas; modelagem; Mtricas; orientao objetos; UML; testes e muito mais. Assine j!

Conhecimentofaz diferena!

Faa j sua assinatura digital! | www.devmedia.com.br/es

Edio Especial

ProjetoEntenda o conceito de Arquitetura de Software e

como trabalhar com os Estilos Arquiteturais

RequisitosConhea os principais conceitos envolvidos

na Engenharia de Requisitos

Verificao, Validao & TesteFerramentas Open Source e melhores

prticas na gesto de defeitos

Especial Processos

Melhore seus processos atravs da anlise de risco e conformidade

Veja como integrar conceitos de Modelos Tradicionais e geis

Veja como integrar o Processo Unificado ao desenvolvimento Web

mag

azin

e

Entenda os principais conceitos sobreTestes e Inspeo de Software

Engenharia de SoftwareSaiba seu significado e para que serve

Capa ESM - Final .pdf 19.02.08 18:15:13

Mais de 60 mil downloadsna primeira edio!

97

71

98

31

27

00

83

00

00

ISSN

1983127-7

Apoio

EDITORIAL

Corpo Editorial

ColaboradoresRodrigo Oliveira [email protected]

Marco Antnio Pereira ArajoEduardo Oliveira Spnola

DiagramaoGabriela de Freitas - [email protected]

CapaRomulo Araujo - [email protected]

Na Webwww.devmedia.com.br/esmag

Ano 2 - 15 Edio 2009 Impresso no Brasil

Um importante fator de sucesso de um software sua qualidade. Existem diversas maneiras de se avaliar a qualidade de um produto, uma dessas maneiras a realizao de atividades de testes de sof-tware por uma equipe especializada no assunto. Neste contexto, a Engenharia de Software Magazine destaca nesta edio trs mat-rias muito interessantes que abordam o tema. Testes de Software, um processo criativo: Este artigo aborda o tema processo de testes de software mostrando uma maneira de agrupar as atividades de testes em etapas, com objetivos bem definidos. Ele mostra que a organizao das atividades pode ter um impacto posi-tivo significativo na qualidade do produto gerado, e que muito mais do que burocracia preciso criatividade para um bom desempenho de tais atividades. Manuteno: Desafios para os Testes numa Fbrica de Software: Neste artigo sero apresentadas dicas e sugestes para superar os principais desafios e entraves associados s atividades de testes na manuteno de softwares em um ambiente de Fbrica de Software. Plano de Teste - Um Mapa Essencial para Teste de Software: Este artigo apresenta o plano de teste de software, destacando sua importncia no processo de desenvolvimento de software, mostran-do como elabor-lo e exemplificando os itens que devem compor o referido documento.

Alm destas matrias, esta edio traz mais cinco artigos: Priorizao Voltada para Resultados; Linhas de Produtos de Software; UML Diagrama de Seqncias; Incorporando Restries UML; Governana de Tecnologia de Informao.

Desejamos uma tima leitura!Equipe Editorial Engenharia de Software Magazine

Parceiros:

Rodrigo Oliveira Spnola([email protected])Doutorando em Engenharia de Sistemas e Computao (COPPE/UFRJ). Mestre em Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Cincias da Computao (UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo mi-nistrado cursos na rea de Qualidade de Produtos e Processos de Software, Requisi-tos e Desenvolvimento Orientado a Objetos. Consultor para implementao do MPS.BR. Atua como 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]) Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Linha de Pesquisa em Engenharia de Software, Especialista em Mtodos Estatsticos Computacionais e Bacharel em Matemtica com Habilitao em Informtica pela UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informao do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em Sistemas de Informao da Faculdade Meto-dista Granbery, Professor e Diretor do Curso Superior de Tecnologia em Anlise e Desenvol-vimento de Sistemas da Fundao Educacional D. Andr Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, Colaborador da Engenharia de Software Magazine.

Eduardo Oliveira Spnola([email protected]) Editor das revistas Engenharia de Software Magazine, SQL Magazine, WebMobile. bacharel em Cincias da Computao pela Universidade Salvador (UNIFACS) onde atualmente cursa o mestrado em Sistemas e Computao na linha de Engenharia de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicaes).

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:

Cristiany Queiroz Atendimento ao Leitorhttp://www.devmedia.com.br/mancad/(21) 2220-5375

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

Publicidade

Para informaes sobre veiculao de anncio na revista ou no site entre em

contato com:

Kaline [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 um artigo na revista ou no site SQL Magazine,

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]

NDICE08 - Priorizao Voltada para Resultados

Dairton Bassi

14 - Incorporando Restries UML Thiago Carvalho de Sousa

22 - UML Diagrama de SequnciasAna Cristina Melo

30 - Testes de Software, um processo criativoMelissa Barbosa Pontes

36- Manuteno: Desafios para os Testes numa Fbrica de SoftwareDaniel Scaldaferri Lages

42 - Plano de TesteAntonio Mendes da Silva Filho

48 - Linhas de Produtos de Software Pasqueline Scaico, Alexandre Scaico e Fillipe Loureno da Cunha Lima

55 - Governana de Tecnologia de InformaoMonalessa Perini Barcellos e Alex Sandro Barreto Rodrigues

Caro leitor, para esta edio, temos um conjunto de 5 vdeo aulas. Estas vdeo aulas esto disponveis para download no Portal da Engenharia de Software Magazine e certamen-te traro uma significativa contribuio para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:

Tipo: Engenharia de RequisitosTtulo: Solues Concretas para Problemas Prticos da Engenharia de Requisitos Parte 7Autor: Rodrigo Oliveira SpnolaMini-Resumo: Existem diferentes maneiras de estruturar um processo com atividades rela-cionadas engenharia de requisitos em empresas desenvolvedoras de software. Modelos de maturidade, como o MPS, podem servir como um arcabouo para a definio deste processo. Alm disso, fundamental para um processo de engenharia de requisitos que ele seja capaz de lidar com dificuldades e problemas relacionados a requisitos que possam surgir durante o desenvolvimento de software na prtica. Uma iniciativa rumo ao levantamento destas dificul-dades e problemas e de maneiras de estruturar um processo para lidar com estes problemas ser apresentada nesta srie de vdeo aulas. Nesta stima aula, sero apresentados problemas e sugestes de soluo associadas a atividades de verificao e validao de requisitos.

Tipo: Engenharia de Requisitos Ttulo: Solues Concretas para Problemas Prticos da Engenharia de Requisitos Parte 8Autor: Rodrigo Oliveira SpnolaMini-Resumo: Existem diferentes maneiras de estruturar um processo com atividades relacionadas engenharia de requisitos em empresas desenvolvedoras de software. Mode-los de maturidade, como o MPS, podem servir como um arcabouo para a definio deste processo. Alm disso, fundamental para um processo de engenharia de requisitos que ele seja capaz de lidar com dificuldades e problemas relacionados a requisitos que possam surgir durante o desenvolvimento de software na prtica. Uma iniciativa rumo ao levantamento destas dificuldades e problemas e de maneiras de estruturar um processo para lidar com estes problemas ser apresentada nesta srie de vdeo aulas. Nesta oitava aula, sero apresentados problemas e sugestes de soluo associadas a atividades de gerenciamento de requisitos.

Tipo: Engenharia de Requisitos Ttulo: Concretas para Problemas Prticos da Engenharia de Requisitos Parte 9Autor: Rodrigo Oliveira SpnolaMini-Resumo: Existem diferentes maneiras de estruturar um processo com atividades relacionadas engenharia de requisitos em empresas desenvolvedoras de software.

4 Engenharia de Software Magazine

Modelos de maturidade, como o MPS, podem servir como um arcabouo para a definio deste processo. Alm disso, fundamental para um processo de engenharia de requisitos que ele seja capaz de lidar com dificuldades e problemas relacionados a requisitos que possam surgir durante o desenvolvimento de software na prtica. Uma iniciativa rumo ao levantamento destas dificuldades e problemas e de maneiras de estruturar um processo para lidar com estes problemas ser apresentada nesta srie de vdeo aulas. Nesta nona e ltima aula desta srie, sero apresentados problemas e sugestes de soluo associadas a atividades de gerenciamento de requisitos, ferramentas e recursos humanos associados s atividades da engenharia de requisitos.

Tipo: Projeto Ttulo: Introduo Matriz de Rastreabilidade Parte 1Autor: Rodrigo Oliveira SpnolaMini-Resumo: pode ser considerado um conceito chave ao longo do desenvolvimento de projetos de software. Este conceito define que possvel mapear a relao entre os diferentes elementos elaborados durante o desenvolvimento de software. Esta relao identificada a partir das transformaes que existem em informaes ao longo do processo de desenvolvimento e podem ser representadas atravs de rastros em uma matriz de rastreabilidade. Nesta vdeo aula apresentaremos as definies iniciais associadas rastreabilidade.

Tipo: Projeto Ttulo: Introduo Matriz de Rastreabilidade Parte 2Autor: Rodrigo Oliveira SpnolaMini-Resumo: Rastreabilidade pode ser considerado um conceito chave ao longo do desenvolvimento de projetos de software. Este conceito define que possvel mapear a relao entre os diferentes elementos elaborados durante o desenvolvimento de software. Esta relao identificada a partir das transformaes que existem em informaes ao longo do processo de desenvolvimento e podem ser representadas atravs de rastros em uma matriz de rastreabilidade. Nesta segunda parte, apresentaremos a importncia do conceito de rastreabilidade e como ele pode ser aplicado atravs das matrizes de rastreabilidade.

6 SQL Magazine

Edio 05 - Engenharia de Software Magazine 7

8 Engenharia de Software Magazine - Priorizao Voltada para Resultados

Dairton Bassi [email protected] Mestre em Engenharia de Software com nfase em Mtodos geis pelo IME-USP. Bacharel em Cincia da Computao pelo IME-USP. Co-fundador da AgilCoop e cria-dor do Encontro gil (www.encontroagil.com.br). Especialista em implantao de metodologias geis. Ministra cursos e pa-lestras sobre mtodos geis. Atuou como programador, lder de desenvolvimento e consultor em diversas instituies do setor pblico e privado.

De que se trata o artigo?Neste artigo entenderemos os problemas causados pela falta de priorizao nas funcionalidades du-rante a implementao de projetos de software e apresentaremos tcnicas usadas em metodologias geis para determinar as prioridades de desenvol-vimento.

Para que serve?Com bons critrios de priorizao, a equipe de de-senvolvimento ter foco e poder trabalhar unida para atingir seu objetivo. Alm disso, o produto em desenvolvimento ter resultados palpveis mais rapidamente. Isso permitir que ele seja avaliado mais cedo e aprimorado.

Em que situao o tema til?A eleio de prioridades adequadas evita inmeros desperdcios de recursos e de tempo, tornando o pro-jeto mais propenso ao fracasso. A escolha adequada das funcionalidades que sero implementadas pode ser determinante para o cumprimento do prazo e dos custos do projeto e tambm pode antecipar a obten-o de verses preliminares do software.

Priorizao Voltada para Resultados

Priorizar significa determinar uma ordem, que pode ser, por exemplo, de importncia ou de precedn-cia. Neste processo, naturalmente alguns elementos so favorecidos em detrimen-to de outros.

Na produo de software, decises erradas na priorizao das funciona-lidades ou de mdulos de um projeto podem causar estouro de oramento, perda de prazos, retardamento na gerao de receita, adiamento do uso do software, falta de foco no desen-volvimento e, em ltima instncia, cancelamento do projeto.

Historicamente, a indstria de softwa-re no tem sido hbil em fazer prioriza-es e tem sofrido dos males que essa deficincia traz: grandes desperdcios de tempo e de recursos que comprometem o projeto e, em muitos casos, causam o seu fracasso.

Uma amostra representativa da in-dstria de software de pases desen-volvidos foi estudada por Jim Jonhson em 2002. Ele descobriu que 64% das


METODOLOGIAS GEIS

funcionalidades implementadas so raramente ou nunca utilizadas. Este nmero revela que somente cerca de 1/3 do que foi desenvolvido, de fato, precisava ser feito e, portanto, dois teros dos recursos e do tempo foram mal empregados. Ratificando os resultados de Jonhson, em 2007, o PMI Brasil apontou resultados semelhantes na indstria brasileira. 66% das empresas do setor de tecnologia tm problemas para cum-prir o custo dos projetos e em 82% para cumprir os prazos.

Estes nmeros sinalizam srios problemas relacionados priorizao. Se as prioridades fossem melhor elegidas, os 64% de funcionalidades raramente usadas provavelmente no pre-cisariam ser feitas. Com isso, haveria uma grande economia de recursos, os projetos seriam muito mais simples e, seria possvel concluir os 34% que tm valor muito mais rpido. Se isso fosse feito, os problemas com custos e prazos certamente no seriam gritantes.

H diversas maneiras de fazer a priorizao do desenvolvi-mento de um software. A escolha de uma delas geralmente guiada pela filosofia da empresa ou pelas caractersticas do projeto. Neste artigo apresentamos algumas tcnicas para determinar as prioridades de desenvolvimento com foco no valor de negcios trazido por cada funcionalidade. Essas tcnicas envolvem a equipe de desenvolvimento, mas contam principalmente com a participao de clientes e tambm de potenciais usurios.

Quem o responsvel? muito fcil pensar que os responsveis pela priorizao, ou

pela falta dela, so os gerentes do projeto, que significa que eles seriam exclusivamente culpados pelos resultados que a indstria tem apresentado. Esta seria uma anlise parcial e incorreta da situao. Uma boa priorizao s possvel quanto o processo de desenvolvimento reserva espao para que ela acontea. Dado isso, fundamental que os envolvidos na priorizao conheam o mercado no qual o software ser inserido e, principalmente, o ponto de vista dos usurios.

Modelos de desenvolvimento com escopo e prazo grandes e fixos so um dos principais responsveis por problemas de priorizao. Como nestes modelos todas as funcionalidades do escopo devem estar prontas no fim do prazo, os envolvidos no sentem tanta necessidade de priorizar, afinal, a ordem de implementao no relevante para atender o acordo com o cliente. Isso faz com que a ordem de desenvolvimento seja forte e exclusivamente influenciada pelos aspectos tcnicos do desenvolvimento. Por exemplo, as funcionalidades podem ser ordenadas de acordo com as tecnologias que elas requerem em sua implementao, ou conforme o grau de dificuldade de implementao. Em outros casos, a ordenao das funcionali-dades influenciada pela indisponibilidade de alguns recursos da equipe, como DBAs, designers, etc.

Alm dessas restries desfavorecerem o uso de priorizao alinhadas com os interesses comerciais, o formato de contrato que fixa prazo e escopo o preferido por ambas as partes envol-vidas na produo do software: clientes e desenvolvedores. Isso acontece porque tanto clientes como desenvolvedores querem

o contrato pelo mesmo motivo: aumentar a sua segurana. O comprador quer listar as funcionalidades que ele deseja para ter uma garantia de que ir receb-las. O desenvolvedor tambm quer listar as funcionalidades para estabelecer um limite sobre o tamanho do seu trabalho e de suas responsabi-lidades. O grande problema deste modelo que o comprador ir querer incluir o mximo de funcionalidades, pois ele no sabe precisamente quais ele ir querer ou de fato usar daqui a alguns meses ou anos. Na dvida, se uma funcionalidade ser ou no til, melhor inclu-la. E se algum precisar...

Com as funcionalidades e o prazo definidos, todas elas pre-cisam ficar prontas, por isso so tratadas igualmente ou pla-nejadas sob pontos de vista que no refletem as prioridades de negcio do projeto, criando uma seqncia de implementao motivada puramente por questes tcnicas. Priorizaes que consideram somente o ponto de vista tcnico podem implicar, depois de alguns meses, em uma grande quantidade de cdigo comercialmente intil. Isso acontece quando funcionalidades sem valor para os usurios so implementadas no incio do projeto, enquanto funcionalidades importantes ficam para o fim, correndo o risco de no serem implementadas caso o pro-jeto atrase ou seja cancelado justamente por falta de resultados.

Quando a ordem importaPriorizar, basicamente, significa definir uma ordem para que

as funcionalidades sejam implementadas. O estabelecimento de critrios para orden-las beneficia o desenvolvimento de diversas maneiras, independente do tipo de processo que se use. A eleio destes critrios importante para determinar uma direo para o desenvolvimento e facilitar a definio de metas intermedirias para a equipe.

Para compor os critrios de priorizao, podem ser usados vrios tipos de informao. Alguns exemplos so: a opinio dos usurios, o retorno financeiro ou a dificuldade de imple-mentao. Bons critrios de priorizao consideram mais de uma informao, como por exemplo, o retorno financeiro e a dificuldade de implementao. Assim, fatores cruciais para o sucesso comercial do software (retorno financeiro) so ponde-rados com variveis que indicam a viabilidade de produo (dificuldade de implementao).

Em projetos onde preciso conseguir receita para garantir a sua continuidade, ou para justificar mais investimentos, a ordem de implementao deve estar alinhada com os interes-ses comerciais. Neste caso, priorizar pelo retorno financeiro ou valor agregado so boas opes. Com este critrio de im-plementao, as funcionalidades mais importantes estaro prontas rapidamente e, mesmo sem que o produto inteiro esteja pronto, ser possvel testar e fazer demonstraes que exibem o potencial do software final.

A apresentao de funcionalidades que tornam o software capaz de gerar receita muda a percepo que o cliente tem a respeito do projeto. Seja ele um cliente externo, um investidor ou nveis superiores da prpria empresa que faz o desenvol-vimento, o projeto que era visto como uma fonte de gastos, ou como um investimento de alto risco, passa a ser tratado como


um ativo valioso. Como conseqncia, a equipe de desenvol-vimento tambm passa a ser mais valorizada.

Se a urgncia pelo produto for grande, uma priorizao voltada para as principais funcionalidades pode criar ra-pidamente uma verso simplificada, ou beta, do produto. Dessa forma, as prximas funcionalidades podem ser criadas enquanto uma verso j gera receita. Isso coloca o projeto em uma condio auto-sustentvel e a equipe de desenvolvimen-to em uma situao mais confortvel com relao cobrana por resultados.

Desenvolvimento iterativo, priorizao iterativaModelos de desenvolvimento iterativos tm se mostrado

adequados ao dinamismo com que as regras e as necessidades do mercado se comportam. Por meio de iteraes e desenvol-vimento incremental possvel segmentar a produo de um grande software e refinar as suas caractersticas desde o incio do projeto, evitando pagar o alto preo de grandes correes tardias.

Empresas que usam mtodos geis, como XP ou Scrum, ten-dem a fazer iteraes curtas com durao de algumas semanas cada uma. Com isso, possvel rever e ajustar o planejamento, alm de validar com freqncia o que j foi produzido. Peque-nas iteraes tambm ajudam na manuteno das prioridades, pois com revises peridicas, novas demandas podem ser consideradas e o desenvolvimento pode se manter sensvel s oscilaes do mercado.

Periodicidade da PriorizaoO tamanho das iteraes est relacionado com caractersticas

do projeto. Por exemplo, projetos sujeitos a muitas mudanas devem usar iteraes curtas para evitar que as necessidades mudem durante a iterao. Por outro lado, se houver dificul-dades para conseguir feedback ou uma validao sobre o que desenvolvido, iteraes maiores so mais adequadas, pois permitem que haja tempo hbil para a entrega.

Tambm importante que a periodicidade com que as prio-ridades so revistas mantenha uma relao com o tamanho das iteraes. O ideal que a periodicidade das prioridades seja um mltiplo do tamanho da iterao, podendo ocorrer, por exemplo, junto com o planejamento de cada iterao ou a cada duas iteraes. Se a periodicidade no estiver sin-cronizada com as iteraes, o modelo de desenvolvimento forar mudanas de prioridade enquanto a equipe est no meio de uma etapa do desenvolvimento. Isso pode criar um cenrio onde os programadores trabalham para produzir funcionalidades que deixaram de ser importantes, o que tornar a equipe pouco confiante e sem motivao para concluir a iterao.

O Scrum, por exemplo, prev a criao de um backlog com todas as funcionalidades desejadas, porm, a cada iterao, uma nova priorizao acontece para a escolha do que ser implementado no prximo sprint (iterao). Em XP, durante o planejamento da release costuma-se fazer uma diviso inicial das funcionalidades em iteraes. Isto facilita a obteno das

primeiras estimativas. Nas prximas priorizaes, possvel fazer permutas entre as funcionalidades medida que novas prioridades so identificadas. Essas mudanas acontecem no planejamento da iterao com o consentimento de clientes e desenvolvedores.

Para os cenrios onde no possvel ter todos os recur-sos (DBAs, designers, etc.) 100% do tempo, independente da metodologia, o ideal minimizar a distoro que as indisponibilidades causam na priorizao. Para fazer isso, determine a ordem ideal de implementao ignorando as indisponibilidades e depois tente ajustar o uso dos recursos para que a priorizao real seja a mais prxima possvel da priorizao ideal.

Tcnicas de PriorizaoAs tcnicas que apresentamos a seguir so fortemente basea-

das em interesses de negcios, portanto levam em considerao o ponto de vista dos clientes e usurios. Os programadores, apesar de estarem completamente envolvidos com a criao do software, no devem ter a responsabilidade de determinar as prioridades de negcio. Estas decises devem ser tomadas por aqueles que esto envolvidos com questes financeiras e estratgicas do projeto, como por exemplo, as tticas comerciais e as aes de marketing.

Opinio do ClienteOs clientes devem estar altamente envolvidos com o desen-

volvimento, pois os programadores, e mesmo o gerente, na maioria das vezes no so especialistas no domnio de negcios do software, portanto eles no tm condies de determinar sozinhos as prioridades do projeto.

Envolver os clientes e colocar as primeiras verses do sof-tware em contato com potenciais usurios uma forma de coletar opinies de pessoas que podero avali-lo pensando de que maneiras aquele programa ainda em construo pode se tornar rapidamente mais til e poderoso.

Para coletar as opinies de potenciais usurios, uma reu-nio pouco formal, no estilo de demonstrao o ideal. Aps a apresentao das funcionalidades, algumas perguntas ajudaro a entender os principais interesses dos usurios. Se o grupo de usurios for grande, cada um pode responder em uma folha de papel perguntas simples como: Quais so as prximas trs funcionalidades que voc gostaria que esse sistema possusse? acompanhada de uma discusso com o grupo sobre as respostas. Se os usurios j usam um software e o novo vem para substitu-lo ou para disputar mercado, a pergunta pode ser: Quais funcionalidades voc usa com frequncia que este programa ainda no tem?, e em um momento mais avanado do desenvolvimento a pergunta seria: Que funcionalidades voc gostaria que o sistema tivesse para tornar o seu trabalho mais fcil?. Se os potenciais usurios no possuem qualquer soluo em software, a pergunta pode ser: O que mais este software precisa fazer para ser til para voc? ou O que faria voc usar este software?.


METODOLOGIAS GEIS

Dependendo do processo de desenvolvimento usado, per-guntas parecidas com estas podem ter sido feitas em uma fase inicial do projeto, porm as suas respostas provavelmente foram usadas para entender as necessidades, mas no para determinar prioridades. Alm disso, as necessidades podem ter mudado, esta uma forma de verificar se elas continuam as mesmas.

Estas reunies de demonstrao podem acontecer periodica-mente durante o desenvolvimento do produto. Mensalmente ou sempre que as maiores prioridades apontadas na reunio anterior tiverem sido implementadas. Se as demonstraes acontecerem desde a primeira iterao, o software poder ser utilizado e avaliado desde o incio, reduzindo a possibilidade da equipe de desenvolvimento despender tempo em funcio-nalidades que no agregam valor ao software.

Em geral, aps algumas semanas j possvel fazer a primeira demonstrao para clientes ou potenciais usurios, mesmo que o software no tenha todas as funcionalidades ou mesmo uma interface grfica profissional. Naturalmente, importante alert-los de antemo de que esta ainda uma verso precoce que precisa da colaborao e opinio de todos para crescer e se tornar o produto que desejam.

Priorizao por Valor e RiscoOutra maneira de priorizar considera o valor de negcios

que a funcionalidade traz para o software, que vamos chamar simplesmente de valor, e a dificuldade de implementao, que inclui o risco de atraso e as incertezas a respeito da implemen-tao, chamamos essas dificuldades de risco. Esta tcnica simples e produz um diagrama que pode ser lido facilmente e oferece uma viso panormica do projeto sob o ponto de vista das duas variveis consideradas: valor e risco.

O resultado deste exerccio de priorizao ser visto em um plano cujos eixos so o valor e o risco. Ele pode ser desenhado em uma lousa, em um quadro branco ou em uma cartolina sem a necessidade de definir uma escala, basta apenas de-terminar a direo em que o valor e o risco crescem em seus respectivos eixos.

Para mensurar o valor e o risco de cada funcionalidade, a participao de clientes e desenvolvedores essencial. O cliente determina a quantidade de valor que cada funcionali-dade agrega ao produto final e a equipe de desenvolvimento dimensiona o risco de implementao. Desta forma, cada funcionalidade pode ser representada por um ponto no plano, conforme a Figura 1.

Neste exerccio a meta no obter estimativas para criar cronogramas. O objetivo dimensionar comparativamente a quantidade aproximada de valor e risco de cada funcio-nalidade, por isso no preciso associar nmeros para as medidas. O importante perceber quais funcionalidades so, de fato, valiosas e de alto risco atravs de comparaes diretas com as demais. Ao dispor os pontos (funcionalida-des) no grfico, as posies comeam a ser definidas pelas opinies dos participantes e depois so ajustadas por com-parao com os outros pontos.

Depois de dispor as funcionalidades no plano, este dividido em quadrantes. Desta forma, as funcionalidades ficaro agru-padas em quatro categorias, de acordo com suas quantidades de valor e risco. As categorias so: alto risco e alto valor, baixo risco e alto valor, baixo risco e baixo valor, e alto risco e baixo valor.

A seguir, uma estratgia de priorizao dos quadrantes escolhida conforme a metodologia, o projeto e a experin-cia da equipe. Para projetos que precisam comprovar sua viabilidade ou equipes experientes com mtodos geis, a prioridade mais alta pode ir para as funcionalidades do quadrante com valor e risco mais altos. Faz-las primeiro interessante porque quando estas estiverem implemen-tadas, haver uma grande quantidade de valor agregado ao software e ao mesmo tempo, uma grande quantidade de risco ter sido eliminada do projeto. Em seguida vem o quadrante de alto valor e baixo risco e depois o de baixo valor e baixo risco, conforme a Figura 2. Com esta estratgia, caso no seja possvel produzir as primeiras funcionalidades, que so de alta dificuldade, o projeto pode ser reavaliado sem ter tido custos elevados, pois os impedimentos foram identificados cedo. Tambm pode ser percebido que a im-plementao ser muito mais demorada do que o previsto. Isso permite que as estimativas sejam ajustadas ainda no incio do projeto.

Figura 1. Plano com os eixos de Valor e Risco com funcionalidades representadas por pontos.

Figura 2. Sequncia de implementao para equipes experientes ou projetos com muita incerteza.


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

seu Fe

edback

sob

re esta edio

Jim Johnson. ROI, its your job. In Keynote Speech at 3rd International Conference on eXtreme

Programming and Agile Processes in Software Engineering (XP2002), May 2002.

PMI Chapters Brasileiros. Estudo de benchmarking em gerenciamento de projetos brasil.

Technical report, www.pmi.org.br, 2007.

Kent Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999.

Ken Schwaber. Agile Software Development with Scrum. Microsoft Press, 2004.

Mike Cohn. Agile Estimating and Planning. Prentice Hall, 2006.

Dairton Bassi. Experincias com desenvolvimento gil. Masters thesis, Instituto de Matemtica

e Estatstica da Universidade de So Paulo - IME/USP, 2008.

Referncias

Equipes com pouca experincia em desenvolvimento gil ou projetos sem grandes desafios tcnicos podem usar outra sequncia de priorizao. Comeando pelo quadrante de alto valor e baixo risco, para produzir funcionalidades importantes e rapidamente chegar a uma verso do software em produo e, em seguida, implementar as funcionalidades dos quadrantes de alto valor e alto risco e baixo valor e baixo risco e, se necessrio, as do quadrante de baixo valor e alto risco. A Figura 3 exibe essa seqncia de implementao.

Figura 3. Sequncia de implementao para equipes pouco experientes ou projetos sem desafios tcnicos

Muitas vezes, independente de implementao escolhida, as funcionalidades do ltimo quadrante no chegam a ser implementadas porque o software j atende s necessidades dos usurios e o investimento para produzir funcionalidades de alto risco no recompensado.

ConclusesUma priorizao adequada das funcionalidades faz parte

da etapa de planejamento do desenvolvimento. Ela ajuda o projeto a aproveitar melhor seus recursos e, quando revista

periodicamente, mantm o foco nas funcionalidades de maior interesse, o que aumenta significativamente as chances de sucesso do projeto.

Os critrios de priorizao podem ser variados, contudo, para projetos que buscam retorno financeiro, uma boa ttica usar este fator como um dos critrios de priori-zao. Dessa forma, o desenvolvimento orientado pela mesma varivel que tambm guia a cobrana dos resul-tados da equipe.

A obteno das prioridades pode ser feita a partir de tcnicas de fcil execuo. As que vimos neste artigo visam criao rpida de uma verso funcional do software. Por isso consi-deram fortemente as opinies de usurios, desenvolvedores e especialistas no domnio de negcios da aplicao. Contudo, as mesmas tcnicas podem ser usadas considerando outros critrios de priorizao.


METODOLOGIAS GEIS

www.infnet.edu.br - [email protected] - Central de Atendimento: (21) 2122-8800

E D U C A O S U P E R I O R O R I E N T A D A A O M E R C A D O

PS-GRADUAO

Engenharia de Software: Desenvolvimento Java

GRADUAO

Anlise e Desenvolvimento de Sistemas

FORMAES

Desenvolvedor Java

Desenvolvedor Java: Sistemas Distribudos

Gestor de TI

Desenvolvedor Web .NET 2008

MCITP Server Administrator

SQL Server 2008

Acesse nosso site e conhea todos os nossos programas: www.infnet.edu.br/esti

A Escola Superior da Tecnologia da Informao oferece as melhores opes em cursos, formaes, graduaes e ps-graduaes para profissionais de desenvolvimento e programao.

So programas voltados para a formao de profissionais de elite, com aulas 100% prticas, corpo docente atuante no mercado, acesso mais atualizada biblioteca de TI do Rio, laboratrios equipados com tecnologia de ponta, salas de estudo e exames.

TURMASNO RIO DEJANEIRO

Modstia parte, suamelhor opo para

se destacar no mercado!

14 Engenharia de Software Magazine - Incorporando Restries UML

Thiago Carvalho de [email protected] em Engenharia de Computao e Sistemas Digitais (EP-USP). Mestre e Bacharel em Cincia da Computao (IME-USP). Traba-lha h mais de 8 anos com desenvolvimento de software e j atuou como gerente de projetos, analista de negcios e engenheiro de requisitos na Oracle, Johnson & Johnson, Goodyear, NET/Embratel e Grupo Claudino. Atualmente con-sultor da Alstom Transport e professor licencia-do das disciplinas de Engenharia de Software e Mtodos Formais do CEUT e da FAETE.

De que se trata o artigo?Neste artigo ser apresentada uma introduo OCL, a linguagem de restrio oficial da UML.

Para que serve?Impor restries a alguns objetos de fundamen-tal importncia para esclarecer, verificar e validar modelos UML. Este artigo trata sobre como pos-svel fazer isso atravs da OCL.

Em que situao o tema til?Em que situao o tema til: Para aqueles que no conseguem apenas com os diagramas UML definir todos os aspectos relevantes da especifi-cao do sistema.

Incorporando Restries UML Os conceitos principais por trs da linguagem OCL

A UML (Unified Modeling Lan-guage) uma linguagem para especificao, documentao, visualizao e desenvolvimento de sistemas orientados a objetos. Sintetiza os principais mtodos existentes, sendo considerada uma das linguagens mais expressivas para modelagem de siste-mas e por isso de grande aceitao na indstria. Por meio de seus diagramas possvel representar sistemas de sof-twares sob diversas perspectivas de visualizao. Facilita a comunicao de todas as pessoas envolvidas no proces-so de desenvolvimento de um sistema - gerentes, coordenadores, analistas, desenvolvedores - por apresentar um vocabulrio de fcil entendimento.

A primeira verso da UML foi apre-sentada em junho de 1996 e submetida OMG (Object Management Group), consrcio de empresas que define pa-dres de modelos e linguagens. A revi-so desse modelo mostrou uma grande

deficincia na clareza e consistncia das definies da UML. Em particular, uma dificuldade encontrada foi que a semn-tica da UML poderia ser interpretada de formas ambguas. O problema foi minimizado com a elaborao de uma nova verso da linguagem, a qual foi publicada em 1997. O mais importante incremento nesta verso foi a criao da OCL (Object Constraint Language), que acompanha oficialmente a evoluo da UML at os dias atuais.


PROJETO

A linguagem OCLA OCL (ou linguagem para especificao formal de restries,

em portugus) uma linguagem declarativa para descrever as regras que se aplicam aos modelos UML. uma linguagem de texto precisa que fornece afirmaes em um modelo orientado a objeto que no possam ser expressadas pela notao diagra-mtica. A OCL complementa os modelos UML fornecendo expresses que no tm nem as ambiguidades da lngua natural (eg. o sistema deve identificar uma pessoa com um telescpio), nem a dificuldade inerente de se usar matemtica complexa.

Com a OCL possvel testar a construo dos modelos, retirar mtricas ao nvel de projeto e ainda especificar vrios tipos de restries, que podero refletir regras de negcio, atravs de pr/ps condies e invariantes.

Como a OCL uma linguagem formal, semelhante a uma lin-guagem de programao, torna-se, tambm, possvel a criao de geradores de cdigo tendo como entrada os modelos e as es-pecificaes/restries nessa linguagem e como sada programas fontes em linguagens de programao ou triggers para bancos de dados. Inclusive, atualmente a OCL vem se tornando um componente fundamental no novo padro MDA-QVT (Query-View-Tranformation) para transformao de modelos da OMG.

A OCL pode ser utilizada para: Especificar invariantes em classes e tipos do modelos de classes. Especificar tipos invariantes para esteretipos. Descrever pr e ps-condies em operaes. Como uma linguagem de navegao entre associaes. Como uma linguagem de consulta. Para especificar o alvo das mensagens e aes. Para especificar regras de derivaes para atributos. Especificar restries sobre operaes.

A estrutura da OCL est intimamente ligada a outros modelos da UML, sendo bastante usada com o Diagrama de Classes atravs de uso de notas nos diagramas. composta por ex-presses escritas em forma de afirmaes. uma linguagem que possui tipos de dados pr-definidos, assim como algumas palavras reservadas. Nas prximas sees falaremos sobre a sintaxe de cada uma dessas caractersticas principais.

Expresses OCLToda expresso OCL declarativa no sentido de que expressa

o qu a restrio representa no sistema e no como essa res-trio implementada. A avaliao de uma expresso quase sempre resulta em um valor booleano e nunca muda o estado do sistema no modelo.

As expresses OCL so utilizadas para definir condies invariantes nas classes representadas em um modelo e tam-bm so utilizadas para especificar as pr e ps-condies em operaes aplicadas a classes deste modelo.

Expresses OCL tambm podem ser utilizadas para fazer consultas a um modelo de classes da UML. Essas consultas podem ser teis para validar modelos de classes na fase de projeto. Nesse caso, a avaliao dessa expresso no devolve um valor booleano, e sim valores de um tipo especfico da OCL.

Tipos de ExpressesAs expresses OCL podem ser de trs tipos:

Expresses que representam condies invariantes em classes de objetos; Expresses que representam pr-condies de operaes aplicveis a uma classe de objetos; Expresses que indicam as ps-condies de operaes aplicveis a uma classe de objetos;

Contexto de uma ExpressoAs expresses OCL requerem que as restries estejam liga-

das a um contexto de um modelo. O contexto de uma expresso pode ser uma classe de objetos ou pode ser uma operao aplicvel a um objeto.

Para representar um contexto em OCL utilizamos a seguinte palavra reservada:

context

InvariantesInvariantes so condies que os objetos modelados devem

respeitar durante toda sua existncia no sistema. Em OCL, para indicar que uma expresso uma invariante, utilizamos a palavra reservada inv: aps a declarao do contexto. Uma expresso tpica em OCL e que representa uma condio in-variante tem o seguinte formato:

context inv:

Pr-condiesPr-condies so declaraes que refletem o estado no

qual deve se encontrar o sistema para que as operaes sobre os objetos possam ser executadas. Em OCL, quando que-remos expressar uma condio na forma de pr-condio, utilizamos a palavra reservada pre: aps a declarao do contexto. O contexto deve possuir explicitamente a indica-o sobre qual operao a pr-condio ocorre. A expresso tpica em OCL usada para representar uma pr-condio tem a seguinte estrutura:

context pre:

Ps-condiesPs-condies so declaraes que apresentam o estado do

sistema aps a execuo de uma determinada operao de um objeto. Em OCL, para declararmos uma expresso na forma de ps-condio utilizamos a palavra reservada post: aps a declarao do contexto. O contexto deve possuir explicitamente a indicao sobre qual operao a ps-condio ocorre. Para as ps-condies temos a seguinte expresso tpica:

context post:


Palavras ReservadasAlgumas palavras que desempenham funes especiais no

contexto da expresso foram criadas para estruturar melhor certas restries em OCL.

SelfNuma expresso em OCL, a palavra reservada self usada

para referenciar explicitamente uma instncia do contexto.

@PreNuma expresso em OCL, a palavra reservada @pre acom-

panha um atributo ou associao, indicando o seu valor antes do inicio da operao.

ResultNuma expresso em OCL, a palavra reservada result indica

o resultado gerado por uma operao.

Let ... inAlgumas vezes uma pequena parte da expresso utilizada

mais de uma vez. As palavras reservadas let...in permitem a definio de uma varivel (que contm a pequena parte da expresso) a qual pode ser usada na restrio a ser expressada.

If Then. Else..... End IfPara uma restrio que envolve condies, foram criadas as

palavras reservadas if...then...else...end if.

Tipos de DadosUma das caractersticas da OCL ser uma linguagem tipada.

Toda informao manipulada, nas expresses construdas em OCL, pertence a um dos seguintes grupos de variveis: Tipos Bsicos: Real, Integer, String e Boolean; Colees: Set (elementos nicos e no ordenados), Bag (elementos duplicados e no ordenados), Sequence (uma bag ordenada), e OrderedSet (um set ordenado); Tipos dos modelos UML: todas as classes, atributos, inter-faces, associaes, consultas e enumeraes introduzidas por um diagrama de classes.

Operaes sobre Tipos Bsicos Real: +, -, *, /, >=, , =, , [operao]

As principais operaes so: size(): Integer encontra o tamanho da coleo; isEmpty(), notEmpty(): Boolean - verifica se a coleo vazia ou no; first(): Object encontra o primeiro elemento da coleo; last(): Object encontra o ultimo elemento da coleo; sum (): Integer/Real - soma os elementos da coleo; count(object): Integer numero de ocorrncias de um objeto; includes (object): Boolean verifica se um objeto est numa coleo; excludes (object): Boolean verifica se um objeto no de uma coleo; includesAll (collection): Boolean verifica a incluso de uma coleo em uma outra; excludesAll (collection): Boolean verifica a excluso de uma coleo em uma outra; including (object): Collection adiciona um elemento a coleo; excluding (object): Collection exclui um elemento da coleo; union (collection): Collection une duas colees; asSet(): Collection - transforma uma bag em um set, elimi-nando os duplicados; select (condition):Collection restringe a coleo os objetos sob uma certa condio; reject (condition): Collection - exclui da coleo os objetos sob uma certa condio; forall (condition): Boolean verifica se todos os objetos satisfazem uma certa condio; exists (condition): Boolean verifica se pelo menos um objeto satisfaz uma certa condio collect (condition): Collection - cria uma coleo derivada de outra, mas que tambm contm outros elementos.

Exemplo de Uso 1A OCL se encaixa perfeitamente na metodologia de desenho

por contrato (design by contract). Essa metodologia foi de-senvolvida em meados da dcada de 80 por Bertrand Meyer e tem crescido muito nos ltimos anos, tendo entre seus principais adeptos Craig Larman. O desenho por contrato (DbC) um mtodo de implementao que visa a construo de sistemas orientados a objetos mais confiveis, na medida em que prov mecanismos para deteco de violaes da sua especificao, em especial violaes de invariantes. A principal idia do DbC que entre as classes e seus clientes seja estabelecido explicitamente um contrato. Nele, o cliente deve garantir certas condies antes de invocar os mtodos da classe (pr-condies), que por sua vez deve garantir algumas propriedades aps ter sido executado (ps-condies). Vere-mos a seguir como a utilizao da OCL como ferramenta para a especificao de restries do sistema, usando dois exemplos para elucidar a teoria apresentada.

O primeiro exemplo um clssico proposto por Jos Warmer baseado na empresa fictcia Royal e Loyal (R&L). A R&L gerencia programas de fidelidade para empresas parceiras


PROJETO

que oferecem vrios tipos de bnus (eg. milhas areas). A classe principal a LoyaltyProgram. Um sistema que tem apenas um programa de fidelidade possuir um nico ob-jeto dessa classe. A empresa que oferece a seus clientes um programa de fidelidade chamada ProgramPartner. Mais de uma empresa pode participar de um mesmo programa. Nesse caso, os clientes que entram no programa fidelidade podem lucrar com servios prestados por qualquer das empresas participantes.

Todos os clientes entram no programa atravs do preenchi-mento de um formulrio e obtm um carto de fidelidade. Os objetos da classe Customer representam as pessoas que entraram no programa. O carto de fidelidade representado pela classe CustomerCard e pode ser do tipo ouro ou prata, dependendo dos gastos do cliente. A maioria dos programas permite que os clientes acumulem pontos de bnus. Cada parceiro decide quando e quantos pontos de bnus so atri-budos a uma determinada aquisio (Service). Os pontos podem ser usados para comprar servios especficos de um dos parceiros do programa. Para contabilizar os pontos de bnus que so salvos pelo cliente, cada membro asso-ciado a uma LoyaltyAccount. H dois tipos de transaes: uma para obter pontos (Earning) e outra para resgat-los (Burning). Para administrar os diferentes nveis de servios, a classe ServiceLevel foi introduzida ao modelo. Um nvel de servio definido pelo programa de fidelidade e usado por cada membro (Membership). Vejamos a seguir o diagrama

Figura 1. Diagrama de Classes.

.

R11: Todo cliente deve ter no mnimo 21 anos

R12: A data valid from do carto de fidelidade deve ser anterior a data valid to

R13: Um carto fidelidade s pode ser emitido para um membro

R14: A quantidade de nveis de servios exatamente dois

R15: O nome impresso no carto de fidelidade deve ser precedido pelo ttulo ao qual o cliente

deseja ser chamado

R16: O numero de cartes vlidos para cada cliente deve ser igual ao numero de programas que

ele participa

R17: Quando um programa no possui acrscimo e nem resgate de pontos, no existe necessidade

dos clientes terem uma conta

R18: O numero de clientes de um parceiro a soma dos participantes de um ou mais programas

daquele parceiro

R19: O primeiro nvel de servio o prata

R20: O mximo de pontos que pode ser resgatado em cada parceiro de 10000

R21: O ttulo do cliente Mr. se for homem, caso contrario Ms.

R22: O nvel de servio atual deve ser um servio oferecido pelo programa de fidelidade

R23: O conjunto de transaes em uma conta deve ter pelo menos uma transao com mais de

500 pontos

R24: A existncia de pontos em conta implica que pelo menos uma transao foi realizada.

R25. O numero de pontos resgatados em uma aquisio nunca deve exceder o numero de pontos

ganhos por esse servio.

.

Quadro 1. Especificao de Requisitos

de classes (Figura 1) desse sistema e mais detalhes sobre a especificao de requisitos (Quadro 1).


A partir desses requisitos e visualizando o diagrama de classes, podemos criar as seguintes expresses OCL:

context Customer (R11) inv: age( ) >= 21

- - age( ) um mtodo da classe Customer e pode ser usada em uma - - expresso OCL como consulta.

context CustomerCard (R12) inv: validFrom.isBefore(ValidTo)

- - isBefore ( ) um mtodo da classe Date e validFrom e validTo so - - atributos de CustomerCard do tipo Date.

context Membership (R13) inv: card.customer = customer

context LoyaltyProgram (R14) inv: serviceLevel->size() = 2

- - a pr-definida operao size da OCL devolve o tamanho da coleo de - - nveis de servios.

context CustomerCard (R15) inv: printedName = customer.title. concat(customer.name)

- - title do tipo String e pode ser concatenado (concat) com o nome do - - cliente, que tambm do tipo String, para formar o nome a ser - - impresso no carto.

context Customer (R16) inv: program->size() = cards->select (valid = true) ->size()

context LoyaltyProgram (R17) inv: partners.deliveredServices- >forAll(pointsEarned = 0 and pointsBurned = 0) implies membership.loyaltyAccount->isEmpty()

- - se um parceiro oferece um programa onde todos (forAll) os servios - - no oferecem acrscimo ( pointsEarned = 0) e nem resgate de pontos - - (pointsBurned = 0), ento a coleo de contas (loyaltyAccount) de um - - cliente deve ser vazia (isEmpty).

context ProgramPartner (R18) inv: numberofCustomers = loyaltyProgram. customer->asSet->size() - - a pr-definida operao asSet da OCL transforma uma bag em um - - set, eliminando os clientes repetidos.

context LoyaltyProgram (R19) inv serviceLevel.name ->first() = Silver - - o modelo define que a associao entre LoyaltyProgram e ServiceLeve - - ordenada, sendo silver o primeiro elemento.

context LoyaltyProgram (R20) inv: partners.deliveredServices.transaction-> select(Burning)-> collect (points)->sum( ) includes (actualLevel)

context LoyaltyAccount (R23) inv: transaction->collect(points) -> exists (p:Integer | p > 500)

context LoyaltyAccount (R24) inv: points> 0 implies transaction->exists (points> 0)

context ProgramPartner (R25) inv: self.services.transaction->select(Burning) -> collect(points) ->sum() select(Earning)->collect(points) ->sum()

Note que o requisito R18: O numero de clientes de um par-ceiro a soma dos participantes de um ou mais programas da-quele parceiro permite uma interpretao ambgua, pois pode ser tanto a quantidade total de participaes nos programas ou a quantidade de pessoas distintas. Com a OCL possvel esclarecer requisitos ambguos (no caso, o analista preferiu optar pela segunda opo) e coloc-los em uma notao ma-temtica precisa, sem margem para varias interpretaes, mas de fcil entendimento. Nesse exemplo usamos a OCL apenas para relatar os invariantes do sistema, mas poderamos us-la tambm para delimitar as pr-condies e as ps-condies. Faremos isso a seguir.

Exemplo de Uso 2O segundo exemplo baseado em um fictcio sistema banc-

rio. Os clientes (Customer) possuem uma conta (Account), que pode ser do tipo corrente (current) ou poupana (deposit). Toda conta do tipo corrente possui um limite de cheque especial (odLimit). Os clientes podem sacar, depositar (em cheque (che-ck) ou dinheiro (cash)) e solicitar emprstimos (Credit) usando bens (Security) como garantia. Vejamos a seguir o diagrama de classes (Figura 2) desse sistema e mais detalhes sobre a especificao de requisitos (Quadro 2).

A partir desses requisitos e visualizando o diagrama de classes, podemos criar as seguintes expresses OCL:

context Customer inv: age >= 18 (R1)

context Account inv: self.balance >= -self.odLimit (R2)

- - o saldo sempre deve ser maior que o cheque especial negativamente.

context Account inv: self.holder.getAge() < 25 implies self. odLimit = 0 (R3)

context Account inv: self.accountType = #deposit implies self.odLimit = 0 (R4)


PROJETO

- - se a conta do tipo poupana (deposit), ento no existe cheque - - especial.

context Account::deposit (amount: Integer, depositType: DepositType) pre: amount > 0 and accessor = holder (R26) post: (depositType = #cash implies balance = balance@pre + amount) or (R27) (depositType = #check implies uncleared = uncleared@pre + amount)

- - se o depsito for em dinheiro (cash), ento o saldo - - automaticamente incrementado. Se o depsito for em cheque (check), - - ento o saldo dos depsitos bloqueados incrementado.

context Account::clear (amount: Integer) pre: self.uncleared >= amount (Requisito Novo) post: (uncleared = unclered@pre amount) and (R28) (balance = balance@pre + amount)

- - quando um depsito liberado, o saldo dos depsitos bloqueados - - decrementado e o valor acrescentado ao saldo real (balance).

context Account::withdraw (amount: Integer) pre: amount > 0 and accessor = holder and balance-amout>= -odLimit (R32) post: balance = balance@pre amount (R33)

context Account::balanceEnquiry(): Integer pre: accessor = holder (R57) post: result = balance

.R1: Todo cliente deve ser maior de idadeR2: O limite de cheque especial nunca pode ser excedidoR3: Clientes menores de 25 anos no possuem cheque especialR4: Contas do tipo Poupana no possuem cheque especial.R26: Depsitos nulos e no realizados pelo titular so invlidosR27: Se o depsito for em dinheiro, o saldo deve ser incrementado. Se o depsito for em cheque, o valor ficar bloqueado em uma conta de saldos bloqueados at o cheque ser compensado.R28: Quando um cheque compensado, o seu valor incorporado ao saldo e a conta de saldos bloqueados atualizada..R32: No so permitidos saques nulos, que excedam o limite de cheque especial e no realizados pelo titular da conta.R33: O saldo deve ser atualizado aps um saque..R57: O saldo e o saldo total somente podem ser vistos pelo titular da conta.R58: O saldo total calculado pela soma do saldo com o limite do cheque especial .R62: Um cliente s pode pedir um emprstimo se possuir conta do tipo corrente e com cheque especial de pelo menos 10000R63: Um cliente s pode pedir um emprstimo se a soma de todos os seus emprstimos no exceder em 50% do seu salrioR64: Um cliente s pode pedir um emprstimo se a soma dos valores de todos os bens for pelo menos 20% maior que o valor dos emprstimosR65: Depois de pagar a mensalidade de todos os emprstimos, o saldo da conta deve ser positivoR66: O emprstimo mnimo de 10000 e o mximo de 1000000R67: Os bens dados como garantia devem ser obrigatoriamente do cliente.R74: Ser possvel consultar quais os clientes com saldo total maior que 100000..

Quadro 2. Especificao de Requisitos

Figura 2. Diagrama de Classes do cenrio 2


context Account::availableFunds(): Integer pre: accessor = holder (R57) post: result = balance + odLimit (R58) - - o saldo total a soma do saldo real com o limite do cheque especial. context Customer::getMortgage(sum: double, security: Security) pre: self.accountType = #current and odLimit >= 10000 and (sum + self.credits.monthlyRatio -> sum() sum() >= 1.2 * self.credits.amount -> sum() + sum) (R62) (R63) (R64)

- - o cliente possuir conta do tipo corrente (current), seu cheque - - especial ser maior ou igual a 1000 (odLimit >= 10000), a soma dos - - pagamentos mensais (monthlyRatio) ser menor que a metade de seu - - salario (income) e o valor do bens penhorados (incluindo o atual, - - security.value) ser maior que 20% do valor do emprstimos - - (incluindo o atual, sum) pr-condio para realizar um novo - - emprstimo. context Customer (R65) inv: heldAccount.balance - credits. monthlyRate->sum() >= 0

context Credit (R66) inv: amount >= 10000 and amount forAll(owner | owner = customer) (R67)

context Customer inv: self.heldAccount->select(balanceEnquiry() > 100000) (R74)

Mais uma vez podemos ver que a OCL transforma os requisi-tos (descritos em linguagem natural ambgua, como o requisito R32) em notao matemtica precisa e de fcil entendimento. Alm disso, durante essa transformao, o analista pode lembrar de pontos importantes esquecidos no documento de especificao, como verificar se a conta de saldos bloqueados

possui um valor maior ou igual ao que vai ser desbloqueado. A vantagem da OCL se completa quando se usa ferramentas automatizadas (eg. Together) para gerar cdigos fontes (eg. uma consulta SQL a partir do requisito R74) e testar se todas as possveis entradas/sadas das operaes atendem as pr e ps-condies.

ConclusoA evoluo da engenharia de software pode ser comparada

da engenharia civil. Com o passar do tempo, esta precisou se basear em clculos estruturais formais a fim de garantir a qualidade dos imveis construdos. O que se percebe que essa evoluo natural para um formalismo mais apurado est tambm ocorrendo na engenharia de software para alguns pro-blemas especficos, uma vez que as exigncias de confiabilidade e segurana de um software tm aumentado nos ltimos anos.

Nesse contexto, apresentamos no artigo as noes bsicas da OCL, a linguagem oficial de restries da UML, que vem se destacando a cada dia, sendo a grande aposta da OMG como pea fundamental da arquitetura MDA-QVT.

OMG OCL Specification Site

http://www.omg.org/docs/formal/06-05-01.pdf

Artigo Introduction to OCL, de Jos Warmer e Anneke Kleppe

http://www.klasse.nl/ocl/ocl-introduction.html

Applying Design by Contract, de Bertrand Meyer

http://www.cs.ucl.ac.uk/students/A.Masalskis/files/contract.pdf

Artigo Introduction to OCL in Together, de Dan Massey

http://conferences.codegear.com/article/32200

Links

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

seu Fe

edback

sob

re esta edio

Edio 65 - .Net Magazine 17

quick update

22 Engenharia de Software Magazine - UML Diagrama de Sequncias

De que se trata o artigo?Este artigo tem por objetivo apresentar as regras para se modelar um diagrama de sequncia, par-tindo da integrao com os casos de uso e modelo de classes.

Para que serve?Fornecer aos desenvolvedores ou estudantes da rea de sistemas uma linha de entendimento com o intuito de orient-los a modelar seus dia-gramas de sequncia.

Em que situao o tema til?Para quem ainda no modelou diagramas de inte-rao, ou para quem tem experincia e quer revisar a sintaxe permitida nesse tipo de diagrama.

UML Diagrama de SequnciasDescobrindo como modelar um diagrama de sequncias

Ana Cristina Melo [email protected] especialista em Anlise de Sistemas e pro-fessora de graduao e ps-graduao da Universidade Estcio de S. Atua em anlise e programao h 21 anos, sendo os ltimos 11 anos no servio pblico. Autora do livro Desenvolvendo aplicaes com UML - do conceitual implementao, na segunda edio, e Exercitando modelagem em UML. Palestrante em alguns eventos, entre eles, Congresso Fenasoft, OD e Sepai.

A UML, na sua verso atual, nos oferece treze diagramas que tratam de aspectos diferentes de todas as fases de desenvolvimento de um sistema. Todos tm suas utilidades, mas, na prtica, sabemos que possvel desenvolver a maioria dos sistemas orientados a objetos utilizando apenas trs deles. Desses, j apresentei aqui os Casos de Uso e o Diagrama de Classes. E hoje, trabalhando em como modelar um Diagrama de Sequncias, podemos dizer que vocs tero o conhecimento bsico para desenvolver cerca de 70% dos sistemas orientados a objeto.

Veremos o que significa esse diagra-ma e como o mesmo se integra com os outros modelos.

O Diagrama de Sequncias um Diagrama de Interao

O Diagrama de Sequncias o principal dos quatro diagramas de interao. Os outros so: Diagrama de Comunicao, Dia-grama de Viso Geral e Diagrama Temporal.

Um diagrama de interao tem por responsabilidade mostrar a interao entre os objetos de um sistema por meio

de uma viso dinmica. Essa interao entre objetos representada por meio de mensagens. Ao se identificar as mensagens, estamos identificando os servios oferecidos pelas classes. E, por sua vez, identificar os servios significa que estamos descobrindo quais os m-todos necessrios a cada classe. Por isso, normalmente s chegamos a uma verso final do modelo de classes depois que passamos pelo diagrama de sequncias,


PROJETO

pois s com ele conseguimos enxergar claramente todos os mtodos que sero necessrios para atender aos casos de uso.

Apesar de todos os diagramas terem um objetivo final co-mum, cada um atende a uma caracterstica particular.

O Diagrama de Sequncias enfatiza a troca de mensagens dentro de uma linha de tempo sequencial.

O Diagrama de Comunicao enfatiza o relacionamento estrutural entre os objetos, sem se preocupar com o tempo determinado para cada interao.

O Diagrama de Viso Geral uma variao do diagrama de atividades que mostra de uma forma geral o fluxo de controle den-tro de um sistema ou processo de negcios. Cada n ou atividade dentro do diagrama pode representar outro diagrama de interao.

O Diagrama Temporal mostra a mudana de estado de um objeto numa passagem de tempo, em resposta a eventos exter-nos. Este ltimo mais utilizado quando o objetivo principal do diagrama a determinao do tempo exato, o que indicado para sistemas de tempo real.

Integrando os modelosO Diagrama de Sequncias no surge do nada e sim de uma

modelagem feita a partir dos casos de uso, com o auxlio das classes j identificadas num modelo de classes. No caso de uso, estabelecemos a ordem das funcionalidades, sem nos preocuparmos com a implementao. Ao modelarmos o diagrama de sequncias, representaremos por mensagens cada item descrito nos cenrios principal e alternativos. Es-sas mensagens podem ser expressas do ator para o sistema, ou da interface para os objetos.

Para exemplificar essa modelagem, tomaremos por base um pequeno estudo de caso que se refere a um sistema de vota-o interna de uma empresa. Para isso, apresentaremos nas Figuras 1 e 2 os diagramas de casos de uso e a verso inicial do diagrama de classes, respectivamente. Nas Listagens 1, 2, 3, 4 e 5 apresentaremos os cenrios dos principais casos de uso, para que vocs possam compreender como chegamos ao modelo de classes e como o pequeno sistema funciona.

Figura 1. Diagrama de casos de uso para o sistema gestor de votao interna de uma empresa

Figura 2. Diagrama de classes (verso inicial) para o sistema gestor de votao interna de uma empresa

Listagem 1. UC Manter Eleio

Descrio: Este caso de uso tem por objetivo manter o cadastro de eleies, permitindo a incluso, alterao, excluso ou consulta de eleies. Atores: Coordenadoria de EleiesCenrio principal:1. O sistema prepara uma lista de eleies cadastradas, exibindo para cada uma: objetivo, data da eleio, status da apurao. 1.1. O usurio pode pesquisar uma eleio, informando os seguintes critrios: - objetivo ou - perodo inicial e final em que ocorreu a eleio2. O sistema habilita as seguintes opes para o usurio: 2.1. Incluso de eleio 2.2. Alterao de eleio 2.2.1. Para alterao, o usurio deve pr-selecionar a eleio 2.3. Excluso de eleio 2.3.1. Para excluso, o usurio deve pr-selecionar a eleio3. Para a opo de Incluso ou Alterao: 3.1. O usurio informa/edita: 3.1.1. objetivo da eleio 3.1.2. data da eleio4. Para a opo de Excluso: 4.1. O sistema exibe os dados do item 3.1 desabilitados para edio. 4.2. O usurio confirma a excluso da eleio.5. O usurio confirma a operao. 5.1. O sistema atualiza o cadastro de eleies. Cenrios alternativos: Pesquisa de eleio 1.a. A pesquisa de eleio deve desconsiderar caixa alta e baixa, acentuao e realizar a localizao dos trechos em qualquer ordem que os mesmos apaream no cadastro. 1.b. A pesquisa de perodo deve ser feita considerando os perodos inicial e final, inclusive; podendo ser informado apenas um dos perodos. Permisso de Alterao da eleio 2.a. Se j houver data que indique o incio da votao, a eleio no poder ser alterada. Exibir mensagem de erro e retornar ao passo 1. Permisso de Excluso da eleio 2.b. Se j houver data que indique o incio da votao, a eleio no poder ser excluda. Exibir mensagem de erro e retornar ao passo 1. Validao da data de eleio 3.a. Se o usurio informar uma data de eleio que no seja futura, exibir mensagem de erro e retornar ao passo 3. 3.a. Se o usurio informar uma data de eleio futura que j esteja cadastrada para outra eleio, exibir mensagem de erro informando a qual eleio a data j est cadastrada e retornar ao passo 3.


Modelando o primeiro Diagrama de SequnciasAo se modelar um diagrama de sequncias, em geral elabo-

ramos ao menos um diagrama para cada caso de uso. Come-aremos com o UC Habilitar Eleitor, por ser o mais simples para nossa primeira explicao.

Primeiro desenhamos o mesmo ator do caso de uso (Mes-rio), no canto superior esquerdo. No topo desenhamos, em seguida, um objeto para representar a interface do sistema e um objeto para cada classe envolvida nesse caso de uso. Nesse caso, as classes Eleicao e Eleitor. A partir de cada objeto, incluindo o ator, desenharemos uma linha tracejada que a linha de vida desse objeto.

A linha de vida indica o tempo de vida desse objeto. Sendo colocada desde o incio do diagrama como se esse objeto fosse criado desde o incio da rotina. Terminando no final do diagrama, indica que o objeto destrudo quando a rotina encerrada. A maioria dos diagramas de sequncias desenha-da dessa maneira. Contudo, se for necessrio representar que um objeto criado ou destrudo durante a execuo da rotina possvel faz-lo. Veremos num tpico mais frente. Veja a representao grfica desse primeiro diagrama na Figura 3.

Listagem 2. UC Manter Candidatos

Descrio: Este caso de uso tem por objetivo manter o cadastro de candidatos, permitindo a incluso, alterao, excluso ou consulta de candidatos. Atores: Coordenadoria de EleiesPr-condio: existir cadastro prvio de eleies.Cenrio principal:1. O sistema prepara uma lista de eleies cadastradas, que ainda no tenham ocorrido a votao (incio de votao em branco), exibindo para cada uma: objetivo, data da eleio, lista de candidatos cadastrados. Para cada candidato cadastrado, exibir: nmero e nome. 2. O usurio seleciona uma eleio.3. O sistema habilita as seguintes opes para o usurio: 3.1. Incluso de candidato 3.2. Alterao de candidato 3.2.1.Para alterao, o usurio deve pr-selecionar tambm o candidato. 3.3. Excluso de candidato 3.3.1. Para excluso, o usurio deve pr-selecionar tambm o candidato.4. Para a opo de Incluso ou Alterao: 4.1. O usurio informa/edita: 4.1.1. nmero do candidato 4.1.2. nome do candidato 4.1.3. foto do candidato5. Para a opo de Excluso: 5.1. O sistema exibe os dados do item 4.1 desabilitados para edio. 5.2. O usurio confirma a excluso da eleio.6. O usurio confirma a operao. 6.1 O sistema atualiza o cadastro de candidatos. Cenrios alternativos: Validao do nmero do candidato 4.a. Se o usurio informar um nmero de candidato j cadastrado na eleio escolhida, exibir mensagem de erro informando a que candidato est associado e retornar ao passo 4.

Listagem 5. UC Votar

Descrio: Este caso de uso tem por objetivo permitir que o eleitor registre o seu voto. Atores: EleitorPr-condio: a urna estar liberada para votao. Receber a identificao da eleio e do eleitor habilitado para votao.Cenrio principal:1. O sistema busca e exibe todos os candidatos associados eleio identificada. 1.1. Para cada candidato, o sistema exibe: nmero do candidato, nome do candidato e foto do candidato.2. O sistema habilita as opes Nulo e Branco.3. O usurio seleciona um dos candidatos ou uma das opes Nulo ou Branco.4. O usurio confirma a votao.5. O sistema atualiza o cadastro de votao. 5.1. O sistema registra que o eleitor identificado j efetuou seu voto, sem associ-lo ao voto. 5.2. O sistema computa 1 voto para o candidato selecionado ou para as opes Nulo ou Branco. 5.3. O sistema libera a urna. Cenrios alternativos: Permisso de correo da votao 4.a. O usurio pode solicitar a correo do seu voto, no momento de confirmar a votao. Nesse caso, o sistema deve retornar ao passo 3.

Listagem 3. UC Iniciar Votao

Descrio: Este caso de uso tem por objetivo dar incio votao de uma eleio. Atores: MesrioPr-condio: existir uma eleio cuja data igual data vigente e que ainda no tenha tido a votao iniciada.Cenrio principal:1. O sistema busca a eleio cuja data igual data vigente.2. O usurio confirma o incio da votao. 2.1. O sistema atualiza o cadastro de eleies, registrando a data e hora atual no campo incio da votao. Cenrios alternativos:No se aplica

Listagem 4. UC Habilitar Eleitor

Descrio: Este caso de uso tem por objetivo validar o eleitor e liberar a urna para votao. Atores: MesrioPr-condio: existir uma eleio cuja data igual data vigente e cujo incio da votao j tenha sido preenchido.Cenrio principal:1. O usurio informa a matrcula do eleitor. 1.1. O sistema busca o eleitor, exibindo o seu nome.2. O usurio libera a urna para votao. Cenrios alternativos: Validao da matrcula do eleitor 1.a. Se o usurio informar um nmero de matrcula que no exista no cadastro, exibir mensagem de erro e retornar ao passo 1. 1.b. Se o eleitor j tiver votado na eleio corrente, exibir mensagem de erro e retornar ao passo 1. Permisso para liberar a urna 2.a. Se o eleitor anterior ainda no tiver finalizado a votao, exibir mensagem de erro e retornar ao passo 1. Figura 3. Primeira parte do desenho do

Diagrama de Sequncias do UC Habilitar Eleitor


PROJETO

Os objetos se diferenciam das classes por se apresentarem su-blinhados. E podem ser desenhados com trs notaes diferentes:

nome do objeto : nome da classe

ou

: nome da classe

ou

nome do objeto

A primeira notao traz primeiro um nome aleatrio de objeto que ser til se precisarmos usar esse objeto como parmetro de um mtodo.

A segunda notao indica um objeto annimo, ou seja, desconhecemos o nome do objeto por ele ser irrelevante, mas conhecemos a classe da qual ele instanciado.

A terceira notao a menos indicada, pois desconhecemos o nome da classe. Nesse caso o nome do objeto deve ser claro o sufi-ciente para que o leitor identifique de qual classe ele foi instanciado.

A partir da estrutura inicial, j podemos desenhar as mensa-gens, que partem sempre de uma origem para o objeto destino que contm o servio que se est querendo chamar.

Assim comearamos pelo item 1 do caso de uso. Contudo, como temos uma pr-condio, essa pr-condio pode representar apenas um parmetro que a rotina receba ao ser iniciada, ou uma verificao que precisa ser verdadeira, para que a rotina tenha incio. Como, nesse caso, representa uma verificao, a primeira mensagem de nosso diagrama de sequncias ser essa checagem.

A pr-condio determina que exista uma eleio cuja data igual data vigente e cujo incio da votao j tenha sido preenchido. Isso significa que precisamos de um mtodo na classe Eleicao que possa retornar se existe ou no uma eleio com a data atual. E depois, se existir, basta verificar se o atribu-to inicioVotacao est preenchido. Essa ltima verificao reside no processamento que se inicia com a mensagem que parte da interface. Se essa verificao for OK, a rotina ter incio.

O retngulo que surge a partir de uma mensagem disparada chamado de caixa de ativao. Ele dura o tempo de processamento daquela mensagem, tanto no objeto origem quanto no objeto destino.

O mtodo criado na classe Eleicao o buscaEleicao, passando como parmetro a dataAtual, que ser usada para comparao com as datas cadastradas das eleies.

Com a primeira verificao concluda, o ator est liberado para iniciar a interao com o sistema. Olhando o caso de uso, vemos no item 1 que o usurio informa a matrcula do eleitor. Essa re-presentao vista no diagrama de sequncias com a mensagem partindo do ator (com o contedo matriculaEleitor) para o objeto interface. A partir dessa mensagem, no caso de uso, tem-se a ao do sistema buscando esse eleitor e exibindo seus dados, caso encontre. A busca do eleitor requer um novo mtodo, nesse caso, o mtodo buscaEleitor na classe Eleitor. Como argumento, esse mtodo receber a informao passada pelo ator, a matriculaEleitor.

Porm, repare que o cenrio principal que faz a busca do eleitor (item 1) tem dois cenrios alternativos associados. O primeiro trata a resposta falsa na busca do eleitor, o que j se resolve na mensagem de retorno. O segundo cenrio alternativo verifica se esse eleitor j votou. Essa informao ser obtida questionando-se classe Eleio a existncia de um relacionamento da eleio com eleitor, que s criada quando da votao pelo eleitor. Assim, temos no mesmo processamento iniciado com a mensagem do ator, uma nova mensagem sendo disparada (sem que tenha havido interrupo do processamento) em direo classe Eleicao, chamando pelo mtodo verificaVotacao. Como argumento passado o prprio objeto Eleitor, chamado objEleitor, que, nesse momento, estar preenchido com o eleitor identificado na mensagem anterior.

Com todas as validaes efetuadas, o controle repassado novamente ao usurio, para decidir o momento de liberar a urna para votao item 2 do caso de uso. Porm, da mesma forma que ocorreu com o item anterior, esse item do cenrio principal tem atrelado a ele um item do cenrio alternativo. Ento, logo depois da interface receber a mensagem do ator, ela, que representa o sistema, deve verificar se possvel liberar a urna. Para isso, preciso questionar classe Eleicao se a urna est liberada. Isso feito pela chamada do mtodo urnaLiberada. Aqui, fazemos uso do retorno status para colocar uma condio na mensagem que liberar a urna para o prximo eleitor.

Repare que, por conveno, s colocamos mensagem de re-torno para o ator, no final do diagrama, indicando que a rotina foi concluda com sucesso.

Analisando-se esse diagrama, percebemos que identificamos quatro mtodos da classe Eleicao (buscaEleicao(), verificaVotacao(), urnaLiberada() e liberarUrna()) e um mtodo da classe Eleitor (buscaEleitor()) (ver Figura 4).

Figura 4. Diagrama de Sequncias finalizado do UC Habilitar Eleitor


Modelando Diagrama de Sequncias usando a nomenclatura da UML 2.0

Se podemos considerar um local no qual houve boas al-teraes na verso 2.0 da UML, esse local o Diagrama de Sequncias. A fim de obtermos maior legibilidade na separa-o das funcionalidades, de forma a permitir agrupamentos, condies relacionadas a um grupo de mensagens e no s a uma mensagem, trechos opcionais, etc., a UML disponibilizou os operadores e as ocorrncias de interao.

Vejamos na prtica como isso funciona modelando o Diagra-ma de Sequncias do UC Manter Candidatos.

Comeamos desenhando o ator Coordenadoria de Eleies. Em seguida, o objeto da interface e os objetos para as classes Eleicao e Candidato.

Analisando o caso de uso, vemos que a primeira providn-cia a tomar garantir a pr-condio. Ento, traaremos uma mensagem da interface (que representa o sistema) para a classe Eleicao, a fim de obter com o mtodo existeEleicaoCadastrada() a garantia de que a pr-condio ser cumprida.

Com a resposta positiva, o sistema continua com o controle, pois dever trazer a lista de eleies cadastradas, que ainda no tenham ocorrido a votao. Nesse caso, criaremos o mtodo buscaEleicoesNaoRealizadas() da classe Eleicao. Repare que o retorno dessa lista no traz apenas dados da eleio, mas dados do candidato tambm. Isso significa dizer que o mtodo buscaEleicoesNaoRealizadas() deve ser responsvel por obter, para cada eleio encontrada, os candidatos que j se encontram cadastrados. Essa dependncia na busca tpica do relacionamento de agregao por composio que existe entre as classes Eleicao e Candidato.

Ento, dentro do processamento do mtodo buscaEleicoes-NaoRealizadas() feita uma chamada ao objeto Candidato, chamando o mtodo buscaCandidato() que far uma busca simples dos atributos desse objeto. S que esse mtodo no ser chamado uma nica vez, e, sim, tantas vezes quantas forem a quantidade de candidatos cadastrados. Por isso, aparece sobre a mensagem o smbolo * para indicar iterao (repetio) e a condio, colocada entre colchetes, para indicar a condio de parada.

Veja que s depois que essa busca feita, o controle entre-gue, pela primeira vez ao ator. Ento ele faz a seleo de uma das eleies exibidas. Veja que todo esse processo de exibio fica dentro da caixa de ativao, ou seja, no relevante mostrar no Diagrama de Seqncias, pois o detalhamento desse tipo de procedimento j est no caso de uso.

A partir da seleo da eleio, o controle volta ao sistema que habilita as opes. Isso tambm no representado explicita-mente no diagrama de sequncias, ficando subentendido na caixa de processamento. A quebra da caixa de ativao indica que o controle volta para o usurio, para que o use no tempo desejado. Na nova interveno do ator, h a passagem de uma mensagem com a seleo da sua opo.

Repare que, a partir desse ponto, temos blocos diferentes de processamento. Temos um bloco reservado incluso e alterao, e outro excluso. Os blocos so controlados pelo

operador alt. Em cada bloco interno, coloca-se uma condio que indica que esse bloco s ser executado se a condio for verdadeira. Assim, o primeiro bloco s ser executado se a opo selecionada pelo usurio tiver sido a incluso ou a alterao. No segundo bloco, somente se a opo selecionada tiver sido a excluso.

Vemos que todas as mensagens que ficam dentro de um bloco so pertinentes s e somente s a esse bloco. Ento, s haver passagem da mensagem com o nmero, nome e foto do candidato, se o processamento estiver na incluso ou na altera-o. Uma vez informados esses dados, o diagrama representa o cenrio alternativo que verifica se esse nmero duplicado ou no. Assim surge a mensagem com chamada do mtodo buscaCandidato da classe Candidato. Se nenhum candidato for encontrado com aquele nmero, o sistema estar habilitado para continuar o processo de edio, chamando ento o mtodo gravaCandidato da classe Eleicao, pois somente essa classe pode se responsabilizar pela gravao do candidato, visto que a classe Eleicao a classe todo no relacionamento de agregao por composio.

No segundo bloco, h a mensagem de confirmao do ator. A partir do recebimento dessa mensagem, o sistema pode passar a mensagem excluiCandidato para a classe Eleicao para que ela se responsabilize pela chamada do mtodo excluiCandidato() da classe Candidato. Veja como ficou esse diagrama na Figura 5.

Outros recursos do Diagrama de SequnciasVejamos os outros recursos que o Diagrama de Sequncias

nos oferece para se atingir o melhor que for possvel na mo-delagem que representar um caso de uso.

Vimos que, por padro, criamos os objetos no incio do dia-grama e sua destruio feita ao trmino do mesmo, quando a rotina se encerra. Mas se precisarmos criar um objeto no meio do diagrama, devemos colocar uma mensagem de cria-o chegando ao centro do objeto, e depois podemos incluir as outras mensagens que executaro os demais mtodos. Veja a estrutura na Figura 6.

Da mesma forma, para excluir um objeto durante a execuo do diagrama, devemos colocar uma mensagem de destruio chegando ao final da linha de vida, onde colocado um X, para indicar esse fim precoce. Veja a estrutura na Figura 7.

Outra necessidade que pode surgir durante a modelagem a chamada de um mtodo dentro da prpria classe. Suponha que uma mensagem que chega no objeto Disciplina chame o mtodo busca. Porm, ao encontrar a disciplina, temos que fazer a busca de todos os objetos que estejam ligados a essa instncia. E se um desses objetos for a prpria disciplina, que esteja como um atributo de pr-requisito, teremos que fazer uma nova busca, ao mesmo objeto. Essa chamada recursiva denominada auto-chamada e representada por uma caixa de ativao sobreposta caixa anterior. Veja exemplo na Figura 8.

Para finalizarmos, vamos conhecer os outros operadores existentes e seus objetivos. bom lembrar que esses operado-res so colocados na aba de identificao do frame com o qual estamos trabalhando.


PROJETO

Operador ref: permite referenciar como ocorrncia de inte-rao uma outra interao que representa uma poro comum. O uso do operador ref permite que trechos de um diagrama de sequ-ncia sejam isolados em pequenos frames e chamados apenas pelo nome, evitando a duplicidade de modelagem. No s a modelagem evitada, como a manuteno simplificada em um nico lugar. Veja exemplo nas Figuras 9 e 10 com o uso desse operador ref.

Para entender esse exemplo, imagine um sistema de controle acadmico, no qual na maioria das funes necessrio que se faa uma busca do aluno, por meio de sua matrcula. No nosso exemplo, esse trecho de busca (Figura 9) representado apenas por uma mensagem da interface para a classe aluno, com a chamada do mtodo busca, e depois a mensagem de retorno. Mas esse trecho poderia ser mais complexo, com chamadas a mais de uma classe, a mais de um mtodo. Imagine esse trecho sendo repetido em vrios diagramas de seqncia! Alm do

esforo em se reproduzir um mesmo trecho, em caso de manu-teno, teramos que procurar todos os diagramas para alterao. No momento em que extramos esse trecho de interao que se repete em vrios lugares, e o colocamos num nico lugar, ganha-mos reaproveitamento de modelo e agilidade de manuteno.Aps o trecho ser separado, basta que faamos a sua chamada no diagrama de seqncias que precisar utiliz-lo, por meio da ocorrncia de interao, com o operador ref. Em vez de se desenhar o trecho, desenha-se apenas um frame, colocando ao centro o nome da ocorrncia de interao (Figura 10). Tambm possvel adicionarmos parmetros de entrada e sada a essas ocorrncias de interao. O default o parmetro de entrada, em que nada preciso acrescentar. Para o parme-tro de sada, acrescenta-se a palavra-chave out. Veja exemplo:

sd BuscarAlunoMaiorMedia (objDisciplina, out media): objAluno

Figura 5. Diagrama de Sequncias finalizado do UC Manter Candidatos

Figura 6. Sintaxe para criao do objeto durante a sequncia de mensagens

Figura 7. Sintaxe para destruio do objeto durante a sequncia de mensagens

Figura 8. Exemplo de auto-chamada


No exemplo acima, a ocorrncia de interao recebe dois parmetros: objDisciplina e media. O parmetro objDisci-plina apenas de entrada. O parmetro media deve retornar preenchido, pois um parmetro de sada. O retorno da funo ser o objAluno que indicar quem o aluno que tem a maior mdia. Assim, conseguimos que o retorno do Diagrama de Sequncias ter dois valores de retorno: o objeto que representa o aluno com maior mdia e a prpria mdia desse aluno.

Operador opt: permite definir um trecho da interao como opcional. Similar ao que acontece com o operador alt, colocado no topo, ao centro, uma condio que indicar se o bloco ser executado ou no.

Suponha que temos um diagrama de sequncias que recebe o valor vendido de um produto, para atualizar o estoque. Logo depois de chamar o mtodo que faz a atualizao do estoque, o sistema deve checar se o estoque do produto atin-giu o valor mnimo. Se atingiu, deve emitir um pedido de compra, enviar um alerta para o gerente da rea e um outro para o setor de compras. Imagine que so vrias mensagens que dependem da resposta do teste:

[estoque.valorAtual


PROJETO

30 Engenharia de Software Magazine - Testes de Software, um processo criativo

De que se trata o artigo?Este artigo aborda o tema processo de testes de software mostrando uma maneira de agrupar as atividades de testes em etapas, com objetivos bem definidos. Ele mostra que a organizao das atividades pode ter um impacto positivo signi-ficativo na qualidade do produto gerado, e que muito mais do que burocracia preciso criativida-de para um bom desempenho de tais atividades.

Para que serve?Uma maneira de se avaliar a qualidade de um pro-duto atravs da realizao de atividades de testes. Porm, se essas atividades forem realizadas de ma-neira ad-hoc, ou seja, sem um planejamento nem estruturao, pode no ficar to evidente a dimen-so da contribuio que os testes podem trazer para a qualidade de um produto. Por isso, fundamental a definio e utilizao de um processo para guiar a equipe de testes na conduo de suas atividades.

Em que situao o tema til?Uma vez entendida a importncia da realizao de testes em um projeto, prudente que estas comecem de maneira mais estruturada possvel. A viso geral de um processo de testes fornecida por este artigo d uma idia de como implantar as atividades de testes em uma organizao com um mnimo de organizao.

Testes de Software, um processo criativo

Melissa Barbosa Pontes [email protected] em Engenharia de Software do Ce-sar.EDU. Certificada em testes de software pelo ISTBQ (International Software Testing Qualification Board), atualmente trabalha como engenheira de testes no CESAR (Centro de Estudos e Sistemas Avanados do Recife), onde desempenha atividades de definio de processos, liderana e consultoria. in-tegrante do GrIT (Grupo Independente de Testes do Cesar) atravs do qual realiza pes-quisas e treinamentos em testes na organi-zao. Possui artigos e trabalhos publicados em eventos internacionais. membro inte-grante da comisso de organizao de EBTS - Encontro Brasileiro de Testes de Software, que j se encontra na quarta edio.

Um importante fator de sucesso de um software sua qualidade. Existem diversas maneiras de se avaliar a qualidade de um produto, uma dessas maneiras a realizao de atividades de testes de software por uma equipe especializada no assunto. O principal objetivo dessas atividades descobrir se o produto est de acordo com as exigncias do cliente. A introduo dessas atividades em uma organizao deve ser feita de maneira estruturada, de forma que lhe permita uma boa definio de quais atividades devem ocorrer em um projeto, em que sequncia e por quem estas devem ser realizadas.

O Pro

Teste de Software 15

Documents

Transcript of Teste de Software 15