Revista Engenharia de Software 32

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

PÓS-GRADUAÇÃO

Engenharia de Software: Desenvolvimento Java

Engenharia de Software: Desenvolvimento .NET

GRADUAÇÃO

Engenharia de ComputaçãoAnálise e Desenv. de Sistemas

FORMAÇÕES

Desenvolvedor Java

Desenv. Java: Sist. Distribuídos

Gestor de TI

Desenvolvedor Web .NET 2008

MCITP Server Administrator

SQL Server 2008

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

A Escola Superior da Tecnologia da Informação oferece as melhores opções em cursos, formações, graduações e pós-graduações para profissionais de desenvolvimento e programação.

São programas voltados para a formação de profissionais de elite, com aulas 100% práticas, corpo docente atuante no mercado, acesso à mais atualizada biblioteca de TI do Rio, laboratórios equipados com tecnologia de ponta, salas de estudo e exames.

r/esti

TURMASNO RIO DEJANEIRO

Modéstia à parte, suamelhor opção para

se destacar no mercado!

Corpo Editorial

ColaboradoresRodrigo Oliveira SpínolaMarco Antônio Pereira Araújo Eduardo Oliveira Spínola

Capa e diagramaçãoRomulo Araujo - [email protected]

Coordenação geralDaniella Costa - [email protected]

revisor e SupervisorThiago Vincenzo - [email protected]

Jornalista responsávelKaline Dolabella - JP24185

na Webwww.devmedia.com.br/esmag

Ano 3 - 32ª Edição - 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 situação se modificou assim que surgiram os pri-

meiros projetos ágeis, logo após o manifesto ágil em 2001, e o mundo do

desenvolvimento 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 começaram

a aparecer os primeiros estudos de caso que apresentavam problemas

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

com inúmeras vantagens em várias perspectivas, deve-se deixar claro, não

é a solução perfeita para todos os problemas da área de Engenharia de

Software, logo, não é a “bala de prata” dos projetos de desenvolvimento.

Neste contexto, esta edição da Engenharia de Software Magazine desta

o artigo “Scrum: Não funcionou para você?”. O artigo apresenta algumas

lições aprendidas durante os últimos anos na área da qualidade de sof-

tware e também na liderança em equipes de desenvolvimento trabalhan-

do com Scrum. A principal intenção de listar tais lições é ajudar outras

equipes que possam vir a ter os mesmos (ou semelhantes) problemas no

decorrer do desenvolvimento de aplicativos e sistemas.

Além desta matéria, esta edição traz mais sete artigos:

• Tenho um Chefe difícil: e agora?

• Modelagem em uma Visão Ágil

• Entendendo melhor SOA e ESB

• Especificação de Casos de Uso

• Engenharia de Software: Sobre a Necessidade de Educação Continuada

• Refatoração para Padrões - Parte 5

• Modelagem Temporal, de Implantação, de Artefatos e de Componentes

através da UML.

desejamos uma ótima leitura!

Equipe Editorial Engenharia de Software Magazine

Rodrigo Oliveira Spínola [email protected] em Engenharia de Sistemas e Computação (COPPE/UFRJ). Mestre em Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computação (UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo minis-trado cursos na área de Qualidade de Produtos e Processos de Software, Requisitos e Desenvolvimento Orientado a Objetos. Consultor para implementação 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 Antônio Pereira Araú[email protected] e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Li-nha de Pesquisa em Engenharia de Software, Especialista em Métodos Estatísticos Computacionais e Bacharel em Matemática com Habilitação em Informática pela UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informação do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em Sistemas de Informação da Faculdade Metodista Granbery, Professor e Diretor do Cur-so Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Fundação Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, Colaborador da Engenharia de Software Magazine.

Eduardo Oliveira Spí[email protected]É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Ma-gazine. É bacharel em Ciências da Computação pela Universidade Salvador (UNIFACS) onde atualmente cursa o mestrado em Sistemas e Computação na linha de Engenharia de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicações).

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, endereço de

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

isabelle Macedo e uellen goulart – Atendimento ao Leitorwww.devmedia.com.br/mancad(21) 2220-5338

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

publicidade

Para informações sobre veiculação de anúncio na revista ou no site entre em

contato 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 sugestão!

Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine,

entre em contato com os editores, informando o título e mini-resumo do tema que você

gostaria de publicar:

Rodrigo Oliveira Spínola - Colaborador

[email protected]

EDITORIAL

ÍNDICE

Por trás do óbvio

06 – Tenho um Chefe difícil: e agora?Glênio Cabral

Agilidade

08 - Modelagem em uma Visão Ágil Lenildo Morais

13 - Scrum: Não funcionou para você?Gabriela de Oliveira Patuci

Desenvolvimento

18 - Modelagem Temporal, de Implantação, de Artefatos e de Componentes

através da UMLGeraldo Magela Dutra Gonçalves

26 - Refatoração para Padrões – Parte 5 Jacimar Fernandes Tavares e Marco Antônio Pereira Araújo

Engenharia

33 - Engenharia de Software: Sobre a Necessidade de Educação Continuada Antonio Mendes da Silva Filho

39 - Especificação de Casos de UsoRodrigo Oliveira Spínola

40 - Entendendo melhor SOA e ESB Lenildo Morais

Tipo: Processo Título: Especificação de casos de uso na prática – Partes 6 a 10Autor: Rodrigo Oliveira SpínolaMini-Resumo: Definir requisitos não é uma atividade trivial. Uma das formas de realizar esta atividade é através da especificação de casos de uso. Neste sentido, nesta série de vídeo aulas apresentaremos um conjunto de especificações de casos de uso. Os cenários serão especificados passo a passo considerando tópicos como fluxo principal, fluxo alternativo e regras de negócios.

Caro Leitor, Para esta edição, temos um conjunto de 5 vídeo aulas. Estas vídeo aulas estão disponíveis para download no Portal da Engenharia de Software Magazine e certamente trarão uma significativa contribuição para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:

Edição 05 - Engenharia de Software Magazine 5

6 Engenharia de Software - Tenho um chefe difícil: e agora?

Glênio [email protected]

É Administrador de Empresas, pós-graduado em Gestão de Pessoas e músi-co. Idealizador do site de educação infantil www.novainfancia.com.br.

Tenho um Chefe difícil: e agora?

Pos trás do Óbvio

No mercado atual, todos os líderes sabem como mo-tivar suas equipes estabelecendo um ótimo clima organizacional, certo? Errado!

Parece estranho, mas ainda há líderes que possuem um grande talento para promover a desmotivação geral de suas equipes. Pesquisas apontam que chefes considerados difíceis nunca admitem seus erros, não costumam dar feedbacks, são ditadores e estão sempre insatisfeitos com o desempenho dos seus subordinados. Será que você, caro leitor, tem sido premia-do com um chefe assim? Na dúvida, aí vão algumas dicas para que você saiba lidar melhor com um chefe complicado.

1. Certifique-se de que você não é a única pessoa a ter dificuldades de lidar com seu chefe. Líderes que são com-provadamente um problema costumam ser encarados dessa forma por todos, e não apenas por uma pessoa. Se você é a única pessoa a ter problemas com seu chefe, o problema pode estar em você.

2. Nunca bata de frente. Estudos comprovam que as relações pessoais têm um peso muito grande no mercado brasileiro. Por isso, nada de bater de frente, pois você poderá ser mal interpretado. É preciso ter o cuidado de conhecer melhor o chefe para saber a melhor hora de falar, de opinar e de pedir algo. Em nossa cultura, essas coisas costumam dar muito resultado. Você está na sua razão? Ainda assim bater de frente nunca será uma boa. Vá com calma e pelas beiradas.

3. Faça sempre o dever de casa e não dê brechas para pu-xões de orelha. A produtividade e a competência sempre serão recompensadas e desejadas, mesmo que seu chefe seja um Hitler. Seu chefe é insensível e nunca reconhece seus méritos? Então dê o melhor de si e continue fazendo seu trabalho com responsabilidade e seriedade, porque não há chefe que resista ao charme de um bom profissional. Essa postura de excelência costuma inclusive abrir portas para outras possibilidades profissionais.

4. Não se envolva em fofocas nem fique falando mal de seu chefe para os colegas de trabalho. Essas coisas costu-mam chegar aos ouvidos dele, o que pode tornar a situação ainda mais difícil. A maledicência corporativa nunca é uma boa postura profissional. Além do mais, numa possível transferência de departamento ou de função a fama de encrenqueiro só irá dificultar as coisas.

5. Sempre que possível, solicite do seu chefe o feedback de suas ações. Se tem algo que os chefes complicados não se sentem à vontade para fazer é dar um feedback. Isso acontece porque eles são péssimos 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. Através desse retorno o colaborador terá informações importantes para aprimorar suas ações e ser mais produtivo. O que, diga-se


por tráS do óbvio

Dê seu feedback sobre esta edição!

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, através do link:

www.devmedia.com.br/esmag/feedback

Dê

seu Feedback

sob

re esta edição

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

6. Não adote uma imagem de vítima e de coitadinho. Os bons profissionais não agem assim. Se você se sente perseguido ou não reconhecido por seu chefe, não ande cabisbaixo pelos cantos. Seja auto-motivado e tenha sempre a consciência do seu valor e potencial. Lembre-se: os bons profissionais sempre são reconhecidos e desejados. Se não pelo seu chefe, pelo concorrente ao lado.

7. Desenvolva o hábito de engolir alguns sapinhos. Ao longo das nossas vidas, sempre estaremos engolindo alguns anfíbios saltitantes. Isso acontece porque nem sempre vamos poder chutar o balde quando bem entendermos. Afinal, temos contas para pagar e família para sustentar. Sem falar que mudar de função ou de emprego não é garantia de que se estará livre para sempre de um chefe difícil. Manter o controle e esperar a hora certa de tomar certas decisões são posturas que sempre acompanham o profissional maduro e que sabe o que quer.

Por fim, se nada disso adiantar, talvez seja a hora de ter uma conversa franca com o departamento de recursos humanos e sinalizar que está disposto a mudar de ares. Mas lembre-se de duas coisas: primeiro, chefes difíceis estão com os dias contados. Não há mais espaço para eles num mercado de trabalho globalizado e dinâmico. E segundo, você pode até deixar uma empresa por causa de um chefe difícil, mas se for um bom profissional o mercado de trabalho nunca o deixará. Siga em frente.

8 Engenharia de Software Magazine - Modelagem em uma Visão Ágil

Lenildo Morais [email protected]

É analista de sistemas e analista de testes. Atualmente está cursando mestrado no centro de informática da UFPE em engenharia de software com ênfase em testes e qualidade de software.

De que se trata o artigo?Apresentar, através de uma visão geral, os valores, princípios e práticas da modelagem ágil (Agile Mo-deling), abordando aspectos como: trabalho em conjunto, participação efetiva do cliente, comuni-cação, rascunhos como forma de modelagem e a utilização da modelagem na obtenção 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 situação o tema é útil?Nos projetos de desenvolvimento de software, sobretudo quando se deseja buscar mercados externos ou expandir seus clientes internos au-mentando a satisfação dos mesmos.

Modelagem em uma Visão ÁgilO que? Quanto? E para que modelar?

A modelagem, do ponto de vista ágil, é um método eficiente que tem como objetivo tornar

mais produtivos os esforços da tarefa de modelar, tão comum nos projetos de software.

Os valores, princípios e práticas da Mo-delagem Ágil podem auxiliar as equipes na definição de componentes técnicos de alto e baixo nível que farão parte do desenvolvimento de software. Artefatos sofisticados elaborados por ferramentas de alto custo nem sempre são os melho-res para ajudar no desenvolvimento do software. Modelar o software em grupo e com a participação dos usuários, utili-zando rascunhos, é vista como uma boa prática para se conseguir isto.

Uma das dificuldades mais comuns nas equipes de desenvolvimento é como con-seguir efetivamente capturar as necessi-dades dos usuários. Uma das maneiras de se alcançar isso passa pelo desenvol-vimento iterativo, onde são entregues software funcionando constantemente

com o objetivo de observar se as ne-cessidades foram atendidas. Ao longo deste artigo veremos os conceitos e al-guns aspectos importantes no tocante à modelagem ágil, assim como alguns benefícios trazidos por esta prática.

Agilidade

Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

Conteúdo Multimídia!

Neste artigo você encontra o vídeo: “Uma visão geral da UML”.

www.devmedia.com.br/esmag


AgilidAdE

Visão geral da Modelagem ÁgilO processo atual de desenvolvimento de software ainda

está em um nível de qualidade muito abaixo do que seria considerado ideal, isto porque os sistemas são entregues aos clientes fora do prazo estipulado no projeto e com um custo maior do que o previsto. Além disso, esses sistemas frequen-temente não alcançam a qualidade desejada pelo cliente e, em muitos casos, não satisfazem as reais necessidades do mesmo, levando a altos índices de manutenção ou passando a ideia de “isso terá de ficar para uma próxima versão”.

A modelagem ágil é vista como um processo de desenvolvi-mento de software baseado em práticas que visa aumentar a eficiência das equipes dentro dos projetos. Ao contrário dos processos tradicionais, que requer basicamente os mesmos artefatos para todos os tipos de projetos, a modelagem ágil busca a construção e manutenção eficiente de artefatos, criando-os apenas quando agregarem valor real ao projeto, e focando principalmente os esforços no desenvolvimento do software.

Entretanto, a modelagem ágil não é uma metodologia de desenvolvimento ágil como eXtreme Programming (XP) ou Scrum, mas sim uma boa prática. Ela visa construir e manter modelos de sistemas de maneira eficaz e eficiente, podendo ser utilizada dentro de metodologias ágeis e tradicionais.

Já com relação à comunicação da equipe, a modelagem ágil pode ser aplicada fazendo com que as pessoas envolvidas nos projetos colaborem para que a solução atenda ao negócio. Neste contexto, não é interessante se prender a papéis. Uma equipe de desenvolvimento de software é mais eficiente se todos são capazes de fazer todas as atividades. Esta boa prática proporciona um trabalho muito mais colaborativo e integrado, uma vez que é comum nas equipes haver pessoas com qualidades diferenciadas. É possível que haja uma pessoa com excelente desenvoltura para conversar com os usuários, outra pessoa consegue codificar com uma rapidez e qualidade acima da média, e outra pessoa pode ter um conhecimento abrangente para dar soluções a problemas complexos.

É comum algumas pessoas, que não são da área de desen-volvimento de software, acharem que a engenharia de siste-mas é próxima da engenharia civil ou engenharia mecânica. Enquanto nas engenharias tradicionais existe uma divisão entre design e construção, na engenharia de software não existe esta separação.

Quando um edifício é construído, o gerenciamento de pro-jeto tradicional faz sentido, pois para esse tipo de produto (o prédio), é necessário ter uma planta detalhada para poder iniciar a construção. Nesse projeto quem é responsável pela atividade de design é um arquiteto ou engenheiro que possui qualificações intelectuais distintas de quem irá efetuar o projeto (a construção). O trabalho de construção será desem-penhado pelo pedreiro, que não necessita ter o conhecimento total da engenharia para fazer o seu trabalho. Essa divisão acontece por conta das características totalmente diferentes entre os dois trabalhadores: um é altamente intelectual, o outro é mais braçal. Um engenheiro pode ter um custo alto já

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

Dado a natureza do projeto civil, é lógico que haja essa divisão de trabalho entre design e construção. Neste cenário, não faz sentido as pessoas do projeto serem “engenheiro-pedreiro”, como pode ser na Engenharia de Software.

Durante a construção de um software são consideradas ba-sicamente quatro atividades principais:1. Compreender o que o usuário quer;2. Definir como os elementos de software resolverão as neces-sidades do usuário;3. Escrever esses elementos de software e integrá-los;4. Testar os elementos e homologá-los com o usuário.

Antes de tudo, deve-se observar que essas atividades ocorrem muitas vezes dentro de um projeto. Entretanto, considerando as quatro atividades, a diferença que há com relação à enge-nharia civil é que não existem importantes diferenças no nível intelectual necessário para desempenhar essas atividades. A atividade de levantamento dos requisitos do software não é intelectualmente inferior à atividade de codificar estes requi-sitos. São atividades diferentes, mas não tão diferentes como o trabalho do engenheiro e do pedreiro. O erro que muitas empresas cometem é achar que analistas de sistemas são como engenheiros civis e programadores são como pedreiros, e isto não ocorre na prática.

Aspectos humanos e técnicos no desenvolvimento de software

A modelagem ágil é baseada em uma coleção de práticas, guiadas por princípios e valores que podem ser aplicados por profissionais de software no dia a dia. Não sendo um processo prescritivo, não define procedimentos detalhados de como criar um dado tipo de modelo. Ao invés disso, provê sugestões de como ser mais efetivo. Em resumo, a modelagem ágil busca o ponto de melhor custo/benefício entre os artefatos que devem ser criados para o sistema e o custo de manutenção e atualização desses artefatos. Pode-se citar duas motivações principais para a criação desta metodologia:1. O objetivo primário de um projeto de software é o próprio software, e não um grande conjunto de documentos sobre ele;2. Um artefato é criado primordialmente para permitir a co-municação e a troca de informações entre a equipe e permitir a discussão e refinamento do modelo do sistema. Assim, se um artefato não está passando informações relevantes ao projeto, ele não cumpre seu objetivo básico.

Basicamente, o que se quer com a modelagem do sistema é satisfazer as necessidades dos usuários, garantindo a qualidade interna (ver Nota 1) do software e respeitando as restrições de custo e prazo do projeto.

Quando se tem que lidar com muita complexidade técnica, que geralmente ocorre em sistemas que lidam com milhares de gigabytes, de usuários, de transações e de processamento distri-buído, um pequeno desvio de disciplina pode levar o sistema ao


caos. Nesse caso, a modelagem é voltada para o aspecto técnico, em que é obrigatório conhecer a estrutura interna dos compo-nentes, as dependências, algoritmos complexos, etc.

Todo projeto possui restrições de custo e prazo. Não se tem todo tempo e dinheiro do mundo para fazer o software. A mis-são de um bom “modelador” é administrar as expectativas do cliente, avaliando com ele quais problemas são prioritários.

Uma das coisas que as metodologias ágeis trouxeram à tona é a importante participação dos usuários ou clientes para auxiliar na modelagem do sistema: seja elaborando um mapa mental, rascunhando uma tela, ou testando um release que acabou de ser liberado. Os usuários, clientes ou stakeholders possuem um papel importantíssimo para gerar as demandas corretas e avaliar a qualidade dos trabalhos executados. Isso requer uma comuni-cação rica entre o cliente e todos os envolvidos no projeto.

Focando nos usuários ou em aspectos mais técnicos, é sem-pre importante estabelecer o escopo da modelagem ágil para esclarecer o que pode e o que não pode ser atendido por este processo. A modelagem ágil é um complemento aos processos existentes, não é uma metodologia completa. Ela não é uma espécie de receita mágica que resolverá todos os problemas, tampouco uma técnica que garantirá melhores resultados. A ideia por trás da modelagem ágil é a de utilizar seus esforços de maneira mais racional e permanecer focado no projeto, aumentando sua eficiência no desenvolvimento do projeto.

A modelagem ágil não visa à eliminação da documentação. Simplesmente diz que a documentação deve ser feita de modo mais racional, maximizando o investimento do cliente no processo de desenvolvimento.

A documentação sem dúvida é uma forma importante de comunicação nos projetos de software. Entretanto, o pior meio de comunicação e documentação são artefatos sendo troca-dos via e-mail. Infelizmente muitos projetos ainda utilizam somente esse meio pobre de comunicação. Esta é a maneira menos eficiente e mais fria de trocar ideias. Já um meio rico de se comunicar é a maneira compartilhada de demonstrar graficamente as propostas, como rascunho ou um quadro branco. A prática é bem simples: junta-se as pessoas numa sala, permitindo que elas colaborem entre si, trocando ideias e sentimentos com o auxílio de um meio gráfico compartilhado. A eficiência dessa técnica é comprovada em workshops de requisitos com o cliente ou em discussões arquiteturais dentro da equipe. O resultado dessas reuniões são rascunhos que podem ser feios na forma, mas são perfeitos para o propósito de modelagem do sistema.

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

impressão de coisas mal feitas ou informalidade em excesso.

Capacidade do software de satisfazer as necessidades implícitas, ou seja, requisitos relacionados

à estrutura do software, como por exemplo, a integridade dos dados ou codificação mais

adequada.

Nota 1: Qualidade Interna

Capacidade do software de satisfazer as necessidades explícitas, como por exemplo, o

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

software, sempre observando a percepção do usuário.

Nota 2: Qualidade Externa

No entanto, no nosso contexto rascunho é um esboço, deli-neamento, trabalho prévio de redação feito antes de passar a limpo.

Por alguma razão, profissionais de informática possuem um vício por artefatos digitais. É comum ter preferência por arquivos que estão em algum lugar do HD. Contudo, a indústria sobreviveu várias décadas sem o computa-dor, e várias áreas de atuação vivem em paz sem o uso das máquinas. Na área de desenvolvimento de software podemos também utilizar meios que não são digitais. Quando falamos em modelagem de um software, uma das grandes dúvidas das equipes de projeto é quão longe devemos nos aprofundar em detalhes. Como ponto de partida (apoio) podemos nortear nosso raciocínio através de questionamentos como:1. Qual é o nome do projeto?2. Qual é a dúvida que tenho?3. Quem poderá modelar isso junto comigo para obter as respostas?4. Qual é o modelo certo?

Quando nos fazemos estas perguntas significa que esta-mos com o cliente e querendo saber o que é o projeto, ou seja, na fase de levantamento de requisitos descobrindo os 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 reunião é ter uma compreensão em alto nível do sistema, e não todos os detalhes. Não é conveniente nessa reunião discutir as minúcias. Detalhes serão adicionados iterativamente e de maneira incremental durante todo o projeto.

Modelos também são formas de decisões ou percepções. Nesse caso, a forma da percepção das funcionalidades e decisão do escopo inicial do projeto. Um dos valores da modelagem ágil é “modelar com um propósito” e, muitas vezes, modelar com um propósito significa buscar os cri-térios de sucesso do projeto. A modelagem busca atender ao usuário apresentando qualidade e reduzindo custo ou prazo do projeto. É altamente questionável quando se modela só para cumprir “etapas” do processo ou porque o processo de desenvolvimento exige tal modelo.

Uma das questões relevantes, vistas anteriormente, é “Qual é o modelo certo?”. É importante ressaltar que há uma quan-tidade infinita de maneiras de se modelar. Um esboço feito de forma conjunta com as partes interessadas é um meio muito eficiente de capturar requisitos e descobrir como atingir o objetivo de fazer um software com qualidade externa (ver Nota 2), que atenda às expectativas dos usuários.


AgilidAdE

A importância de se escrever documentos de requisitos

A vantagem em se fazer com que os clientes e usuários participem da modelagem do sistema utilizando artefatos e ferramentas simples, como rascunhos em papel ou no quadro branco, é promover a colaboração e ganhar agilidade na cap-tura de requisitos. Porém, algumas pessoas ou empresas não reconhecem artefatos em papel como “válidos” no processo de desenvolvimento. Isso leva a uma burocratização desne-cessária na captura de requisitos.

Muitas pessoas levantam requisitos em artefatos informais para depois transformá-los em casos de uso, especificações suplementares, protótipos, documentos de regras de negócio e outros quando “voltam para casa”. Isto é, preenchem esses templates depois das reuniões, formalizando o levantamento. Como houve uma transformação de artefatos, é típica uma revisão com o cliente para obter uma aprovação. O problema é que essa aprovação na maioria das vezes não ocorre. Ao ver os artefatos transformados o cliente lembra-se de mais requisitos que são mais uma vez capturados em artefatos informais e o ciclo se repete muitas vezes. Com isso, levam-se semanas para se aprovar os requisitos e um tempo precioso é perdido.

O objetivo de se trabalhar com rascunhos é rapidamente transformá-los em software funcionando, de modo que seja en-tregue ao cliente o software a ser homologado e não documen-tos a serem aprovados. Não se deve perder tempo aprovando documentos de requisitos depois que foram levantados, pois eles nunca serão aprovados, e mesmo que sejam aprovados o cliente poderá mudar de ideia quando ver realmente o que ele quer de fato. Num contexto geral, software funcionando ainda é o melhor artefato para levantamento de requisitos. Dessa forma, os usuários olham o software e solicitam alterações no software e não em documentos. Software é a única coisa concreta que realmente validamos com os usuários.

Documentos de requisitos têm como objetivo registrar o que os usuários esperam da aplicação independente da solução técnica. Isso faz com que esses documentos sejam simples e rápidos de serem elaborados. Mas o mais importante é que esses artefatos sejam elaborados na reunião de levantamento e não “em casa”. Deve-se sair da reunião com requisitos levan-tados e documentados, depois disso, é fazer o software para cumprir o planejamento da iteração.

Modelagem na obtenção da qualidade Até então vimos que a modelagem ágil pode melhorar e

documentar decisões focadas na qualidade da aplicação, facilitando a comunicação e disseminando ideias dentro do time. A modelagem ágil possui um princípio chamado Travel Light. Este princípio diz que manter modelos é difícil, e pode se tornar ainda mais se estes forem complexos e detalhados. Especialistas na área afirmam que três ou quatro modelos que forneçam uma visão geral da análise, da arquitetura e do design são suficientes para melhorar a comunicação da equipe. É errado pensar que quanto maior o número de documentações melhor será o projeto. A documentação precisa ser enxuta.

Entretanto, a prática do excesso de documentação ainda ocorre em muitos projetos. A implantação da modelagem ágil dentro da cultura de desenvolvimento de software é uma experiência tanto interessante quanto traumática, devido à grande mudança de pensamento trazida pelo método. Para direcionar os esforços em torno da modelagem ágil, existem alguns princípios que devem ser observados para que o pro-cesso adotado seja realmente ágil. Dentre esses princípios, os mais importantes são:

Princípios Fundamentais• Software é seu principal objetivo: Produzir softwares que funcionem;• Racionalização de artefatos: Racionalização da documenta-ção, escolhendo aqueles a serem mantidos durante o processo de desenvolvimento;• Modele com um propósito: Para atender a realidade e para melhorar a comunicação;• Maximize o investimento do Stakeholder: Valorizar a pes-soa chave que representa a empresa.

Princípios Complementares • Conteúdo é mais importante que representação: Despren-der-se um pouco de protótipos, apresentando o software rodando como uma importante forma de validação junto ao cliente;• Cada um tem algo a aprender com o outro: Na modelagem ágil é comum a participação ativa do cliente. Esta interação mais estreita permite que ambas as partes (produtor e clien-te) se entendam melhor, trazendo importantes ganhos ao projeto;• Adapte o modelo à organização: Cada projeto possui parti-cularidades que precisam ser observadas. Muitas vezes estas particularidades estão relacionadas com o estilo da empresa produtora do software e neste caso o modelo deve estar ali-nhado a ela;• Comunicação transparente e honesta: Com a participação efetiva do cliente é importante prezar pela transparência das informações, que devem estar de comum acordo para ambas as partes;• Atentar para os instintos da equipe: Ouvir as sugestões e reclamações da equipe, pois talvez o problema que ela encon-trou possa dificultar no restante da implementação.

A modelagem ágil também possui dois tipos de práticas: as práticas centrais e as práticas suplementares. Elas sugerem pontos que devem ser observados pelas equipes de desenvol-vimento de software que ainda não utilizam a modelagem ágil, mas que pretendem introduzi-la em seus projetos.

Práticas Centrais• Trabalho em Equipe: Participação dos vários perfis da equipe do projeto durante o desenvolvimento de software, incluindo o 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 divulgação


dos modelos produzidos colocando-os em painéis, parede ou outro meio;• Simplicidade: Criação de conteúdo mais leve, descrevendo modelos simples e utilizando ferramentas menos complexas.

Práticas Suplementares • Produtividade: Utilizar padrões e normas de modelagem, aplicando padrões com sabedoria e reutilizando recursos existentes;• Documentação: Descartar modelos temporários, formali-zando os modelos de contrato;• Propósito: Modelar para entender e para se comunicar;• Boas Ideias: Conhecer bem as ferramentas, refactoring e Test-First Design.

Comprovação através do códigoUma das discordâncias que muitas equipes têm contra meto-

dologias ágeis é o foco no código. Entretanto, é no código que a alta coesão e baixo acoplamento oferecem benefícios. Um dos princípios da Modelagem Ágil é: “Prove com Código”. Isto é, os modelos são somente uma abstração daquilo que se está construindo de fato. Mas será que o modelo está correto? Será que ele é implementável? Para saber estas respostas é necessário “provar o modelo com código”.

É importante ressaltar que a atividade de modelagem visa obter uma qualidade do código e não do modelo. Uma boa modelagem tem como objetivo obter um bom código, e não um bom modelo. A qualidade sempre deve focar no código e nos importantes conceitos de alta coesão e baixo acoplamento.

ConclusãoEste artigo apresentou que artefatos simples podem ser uti-

lizados para aplicar boas práticas de modelagem. Modelagem é uma atividade em grupo (na maioria das vezes) e tudo que se faz deve ser focado em melhorar a qualidade do software e a produtividade da equipe. Modelar simplesmente para “ter o modelo” deve ser evitado.

Entretanto, o mais importante de tudo é focar nas atividades do desenvolvimento e não nos artefatos criados. Durante o levantamento de requisitos, as atividades de conversar com o usuário, obter informações e enriquecer o conhecimento são mais importantes que os casos de uso, protótipos ou modelos que surgirem dessa atividade. O importante é a criatividade na solução do problema, na separação dos conceitos e nas mensa-gens trocadas entre os envolvidos no projeto do software.

Podemos ver também ao longo do artigo que muitas pessoas confundem a atividade de levantamento de requisitos com preenchimento dos templates de artefatos de requisitos. E, pior ainda, muitas vezes esse preenchimento de artefatos é feito simplesmente para cumprir tarefas de um processo de desenvolvimento pesado, que muitas vezes interferem de forma negativa na criatividade das pessoas.

O que o cliente quer é o software e não os documentos que abstraem o que se espera do software. Muitos dos artefatos sugeridos e utilizados na modelagem ágil são rascunhos de casos de uso, rascunhos de protótipos de tela, rascunhos de diagrama de atividades. Tudo em papel, desenhados junto com o cliente e com isso automaticamente aprovados por ele. Esses rascunhos são então transformados em software funcionando, seguindo as boas práticas da Engenharia de Software.



www.devmedia.com.br/esmag/feedbackD

ê se

u Feedback

sob

re esta edição

AMBLER, SCOTT. Home Page Agile Modeling

www.agilemodeling.com

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

Referências


Gabriela de Oliveira [email protected]

É formada pela UNICAMP em Tecnologia em Informática e está cursando mestrado na área de Engenharia de Software. Possui certificação pela Scrum Alliance, tem expe-riência de três anos no trabalho com me-todologias ágeis e de cinco anos em Testes e Qualidade de Software. Hoje atua como Scrum Master em projetos internacionais pela Ci&T e já palestrou em eventos como Agile Brazil 2010.

De que se trata o artigo?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 líder de testes, e nos últimos meses, também no papel de Scrum Master.

Para que serve?O artigo tem a intenção de ser uma referência tanto como lições aprendidas de um estudo de caso, que são consideradas valiosas no ambien-te ágil, assim como para abrir precedentes para futuras discussões sobre os pontos levantados como causas raízes e suas soluções propostas. Acredita-se que muitas pessoas no meio ágil ou até mesmo fora dele possam contribuir para a melhoria deste cenário vislumbrado no estudo citado.

Em que situação o tema é útil?O tema é útil para os pro� ssionais de Engenharia de Software em geral que planejam iniciar pro-jetos utilizando metodologias ágeis ou até mes-mo para aqueles que já as utilizam mas estão enfrentando problemas com seus resultados.

Scrum: Não 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 maioria

dos projetos e das empresas de desenvol-vimento de software, e o modelo cascata era tido como o mais completo e efetivo. Essa situação se modificou assim que surgiram os primeiros projetos ágeis, logo após o manifesto ágil em 2001, e o mundo do desenvolvimento de software se dividiu entre os mais conservadores e os simpatizantes do Scrum, XP e outras metodologias ágeis.

No entanto, apesar dos casos de su-cesso serem muitos, logo começaram a aparecer os primeiros estudos de caso que apresentavam problemas utilizando tais metodologias e, principalmente, o

Agilidade

Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

14 Engenharia de Software Magazine - Scrum: Não funcionou para você?

Scrum. O Scrum, mesmo com inúmeras vantagens em várias perspectivas, deve-se deixar claro, não é a solução perfeita para todos os problemas da área de Engenharia de Software, logo, não é a “bala de prata” dos projetos de desenvolvimento.

Neste artigo, pretende-se apresentar algumas lições aprendi-das durante os últimos anos na área da qualidade de software e também na liderança em equipes de desenvolvimento traba-lhando com Scrum. A principal intenção de listar tais lições é ajudar outras equipes que possam vir a ter os mesmos (ou semelhantes) problemas no decorrer do desenvolvimento de aplicativos e sistemas.

Conceitos da Metodologia Antes de apresentar os problemas decorrentes do mau uso

da metodologia citada, faz-se necessário entender os conceitos básicos envolvidos no trabalho com projetos ágeis e a origem das ideias que definem o SCRUM.

No ano de 2001, logo após um encontro onde profissionais e acadêmicos da área de desenvolvimento de software de-monstraram seu descontentamento com a maneira com que os projetos estavam sendo desenvolvidos dentro das empresas, surgiu o Manifesto Ágil. Este manifesto foi o ponto de início para os principais conceitos das metodologias que viriam a seguir. Ele foi traduzido para muitas línguas, inclusive para o português, e é citado em vários artigos da área de Engenharia de Software [1].

O Manifesto deu origem a metodologias como XP, Scrum entre outros e junto com estes conceitos também nasceram os papéis envolvidos neste processo. Estes papéis são:• Time: Quem realmente desenvolve e produz com qualidade. Os membros do time devem ser comprometidos com o trabalho e responsáveis por atingir a meta de uma sprint (período de desenvolvimento). Devem ser cada vez mais auto-gerenciáveis e multidisciplinares. Um time normalmente não ultrapassa o número de nove pessoas e atua em um ambiente adequado afim de facilitar a comunicação efetiva (um dos pontos mais importantes em times ágeis);• Product Owner (PO): É quem faz a ponte entre o cliente e o fornecedor. Deve ter uma boa noção do produto e das necessidades do cliente. Responsável por manter o product backlog sempre atualizado e priorizar o trabalho das sprints que virão. Também são atividades do PO definir a visão do projeto, metas e objetivos das sprints e repassar para o Scrum Master o objetivo do produto;

• Scrum Master (SM): É um líder, mas acima de tudo, é um facilitador. O principal objetivo deste papel é remover im-pedimentos, melhorar o dia-a-dia do time, auxiliar o PO na construção e priorização do Product Backlog, enfim, garantir a aplicação do Scrum. Um bom Scrum Master deve ensinar o cliente a maximizar o ROI (Retorno sobre Investimento) e facilitar o desenrolar das reuniões, tão fundamentais neste processo.

Outro ponto fundamental, além dos papéis, são as reuniões realizadas no decorrer de uma sprint (Figura 1). Os conceitos que envolvem estas reuniões e a sprint são apresentados a seguir.• Sprint Planning: Define o início de uma sprint com a re-alização de tarefas como: identificação dos itens do Product Backlog (requisitos) para a construção do Sprint Backlog que será atacado durante a sprint, estimativa em pontos dos itens que serão desenvolvidos, definição da meta da sprint (commit-ment) e quebra dos itens (estórias) em pequenas tarefas;• Daily Meetings (Stand up Meetings): Reunião, como o nome já diz, diária e feita geralmente em pé. O costume de fazê-la em pé foi uma maneira escolhida para garantir que só os 15 minutos determinados seriam utilizados e que o time não perderia o foco da reunião. O principal objetivo deste pequeno encontro é responder as perguntas base definidas pela metodologia: “O que eu fiz desde a última reunião?”, “O que vou fazer até a próxima reunião?” e “Tenho algo que esteja me impedindo?”;• Retrospective Meeting: Mais uma reunião que tem por base a resposta a três perguntas. O time todo responde às pergun-tas: “O que foi bom nesta sprint?”; “O que não foi bom nesta sprint?”; e “O que devemos melhorar para a próxima sprint?”. Para esta última pergunta, deve-se escolher entre as respostas (através de votação no time) quais os pontos que serão desen-volvidos e melhorados para a próxima sprint;• Review Meeting: Tem por objetivo apresentar o que foi construído durante a sprint pelo time. O time apresenta ao PO o que foi desenvolvido até o presente ponto e o próprio PO decide se o que foi apresentado atingiu ou não a meta da sprint. Podem se fazer necessários ajustes no backlog ou até mesmo repriorização de estórias a partir deste ponto.

Vale ressaltar após a conceituação das reuniões, que a atu-ação do Scrum Master, durante toda a sprint é essencial para o bom andamento do projeto. A participação do PO em todas as reuniões citadas acima também é essencial, tanto que este ponto será salientado em breve neste mesmo artigo.

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

Scrum, pode-se perceber alguns fatores que se repetem como os principais vilões e são, muitas vezes, responsáveis pelo insucesso de projetos e entregas. Feito um estudo inicial e um levantamento destes fatores já citados, encontrou-se inclusive, suas respectivas causas raízes.Figura 1. Ciclo de Vida de uma Sprint


AgilidAdE

Antes de detalharmos os problemas e suas causas, devemos ter a consciência de que, como em toda e qualquer metodologia, não desenvolver projetos seguindo suas principais caracterís-ticas, vai sim acarretar problemas. Vale ter em mente que, ne-nhuma metodologia pode obter bons resultados se as equipes não seguem seus valores e premissas corretamente.

Product Owner não envolvidoVisto qual o papel do Product Owner e sua importância

para a metodologia proposta, pode-se analisar o quão grave é a falta da presença deste papel durante o decorrer da sprint. Exemplos claros como blocks (impedimentos) no decorrer do desenvolvimento podem atrasar e prejudicar muito um projeto. Ter o PO durante todas as reuniões diárias e principalmente no momento da Planning, onde todas as dúvidas (ou pelo menos sua grande maioria) sobre as regras de negócio são resolvidas, é essencial.

Este problema de não envolvimento do PO com o time ou com o projeto em discussão é normalmente causado pela falta de profissionais alocados para o papel: um mesmo PO é dividido entre vários projetos e às vezes, este chega até confundir requi-sitos, times etc. Este fato, por exemplo, pode ser visto quando há uma demora para solucionar blocks.

Um dos jeitos mais fáceis para identificar quando um block está afetando o bom andamento do sprint é o próprio burndo-wn chart. Pode-se perceber pela Figura 2, o desvio de trabalho causado por um block entre os dias 23 e 25/11 dentro de um projeto real. O time vinha trabalhando em uma velocidade esperada e muito próxima da linha do ideal (segundo a le-genda), mas teve um pequeno desvio neste período citado na capacidade de realizar tarefas. Isto se deve ao fato de que este mesmo time não possuía em mãos o conteúdo necessário para confecção das páginas acordadas nas estórias. Esta falta de conteúdo, aqui sendo considerada o block, foi a principal causa para tal desvio no meio da sprint e pôde ser vista claramente no gráfico durante as reuniões diárias.

E a segunda pergunta importante a fazer seria: como tratar este problema? A melhor maneira de tentar minimizar os efeitos deste problema dentro de um projeto seria o Scrum Master trabalhar mais próximo ao Product Owner, no senti-do de conseguir as informações necessárias e “desbloquear” o time. O papel do Scrum Master também é ajudar o PO a seguir os ritos do Scrum e manter o time sempre livre para trabalhar sem blocks.

Falta de Requisito (Estórias mal escritas)Outro problema sério que envolve diretamente o trabalho

do PO são os requisitos (estórias) mal escritos. O requisito, ao contrário do que a maioria das pessoas pensa, é sim parte fundamental no Scrum. As estórias servem como base para o trabalho tanto durante o desenvolvimento, quanto para testes de software e validação em homologação. Eles são feitos de maneira mais resumida, mas não podem deixar de conter as informações necessárias para o bom entendimento da funcio-nalidade desejada e devem ser bons o suficiente para servirem

Figura 2. Burndown de projeto com block entre os dias 23 e 25/11

como base aos casos de testes (isto também será discutido mais adiante).

Falando de fatores que levam a insucesso, podemos consi-derar alguns fatores que levam estórias a serem mal escritas. O primeiro fator é uma descrição muito longa. A ideia de descrever uma estória é que os principais pontos possam ser tratados como uma “checklist” para futuras discussões du-rante a planning meeting. Descrever com muita informação e muitos detalhes pode levar o time a perda da colaboração e a confiança de que tudo já está escrito (como acontecia em antigas metodologias). O principal papel da estória é levar o time a estar sempre buscando a comunicação e a colaboração. Se estes pontos não surgirem, perde-se o foco do Scrum.

O segundo fator é confundir critérios de aceitação com casos de teste. Critérios de aceitação são úteis para responder pergun-tas do tipo “Quando sabemos que a estória está pronta?” e não para perguntas do tipo “Como testar e como saber se foi feito da maneira correta?”. Estas sim são questões para se pensar no momento da criação dos casos de testes em si. Critérios devem ser o suficiente para se saber o que deve ser feito do momento da planning meeting em diante, mas não podem ser tão detalhados como um documento de Caso de Uso. O uso de ferramentas de criação de estórias também pode ajudar nestes casos, principal-mente nos primeiros projetos dos times com menor experiência ou com Product Owners novos dentro dos times.

Figura 3. Exemplo de User Story

16 Engenharia de Software Magazine - Scrum: Não funcionou para você?

Seguir o exemplo da Figura 3, ainda é a melhor saída para evitar problemas de estórias mal escritas. O padrão da figura pode ser traduzido como: “Eu, como <papel>, quero <funcio-nalidade>, para que <valor gerado ao cliente>”. Este exemplo, por estudos na área e experiência pessoal, é o modelo mais utilizado em times ágeis no mercado até hoje. Abaixo um exemplo de estória que segue o modelo da Figura 3.

“Eu, como Product Owner, quero que a home page tenha uma busca, para que todo usuário possa acessar o conteúdo que deseja rapidamente.“

Várias estórias em desenvolvimento Uma ideia muito utilizada nos processos ágeis é o “one piece

flow”. A tática de atacar todos juntos o mesmo problema, um a um, é um dos motivos da metodologia ser representada por uma foto 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 não estamos “atacando” as estórias uma por vez, este pode ser um dos pontos de atenção para o não cumprimento das metas finais. Tentar realizar todas as estórias de uma vez é um dos maiores problemas e pode ser visto em muitos times na atualidade.

Pode-se perceber pela Figura 5, um exemplo claro de board do time em que muitas estórias estão sendo executadas ao mesmo tempo. Deve-se perguntar: existe mesmo a necessidade de ter pessoas alocadas em tantas estórias ao mesmo tempo? Real-mente não existe nenhuma tarefa que estas pessoas poderiam estar atacando na primeira estória? Se o time é multifuncional, por que não dividir tarefas de teste com desenvolvedores, tarefas de webdesign com testers, etc.? Responder todas estas perguntas pode ser um bom ponto de partida para a solução do problema de não entregar estórias totalmente prontas (done) ao final da sprint e ter várias estórias iniciadas.

Estimativas OtimistasOutro problema frequente que pode ser analisado durante

os projetos ágeis são as estimativas erradas. Quase sempre, as estimativas são otimistas e os resultados são catastróficos. Será que somos mesmo capazes de fazer o trabalho proposto em tão pouco tempo? Esta é uma das perguntas que o time nunca se faz quando está em meio à pressão do Scrum Master e principalmente, do Product Owner. É claro que o cliente (neste caso a figura do Product Owner) sempre terá o interesse em ver o produto final pronto em menos tempo, mas o que temos que ter em mente é que esta pressa por chegar à reta final não faz com que o trabalho fique efetivamente pronto mais rápido, e o pior, acarreta problemas ainda mais sérios como defeitos em produção e regressão no desenvolvimento do software. O que deve ser relembrado durante a planning meeting é o fato de quem estima o esforço é o time. Scrum Master e Product Owner devem participar apenas para facilitar a reunião e solucionar possíveis dúvidas, respectivamente.

Projeto Scrum vendido com prazo e/ou Escopo fechados

Trabalhar com um product backlog que aos poucos vai se transformando em Sprint Backlog e entregar produto com valor ao cliente: este é o formato que buscamos. Fica claro que sempre que se vende projetos em Scrum, estes deveriam ser vendidos por número de sprints, ou valor por sprint, e nunca escopo fechado. Scrum não tem escopo fechado, é incremen-tal, e como tal, tem o direito de ser mutável. Prazos e escopos fechados são uma realidade do passado quando trata-se de projetos ágeis e isso tem que ser respeitado para um bom resultado dos projetos.

Logo, fica a pergunta, como vender projetos Scrum? Existem várias maneiras que vem sendo utilizadas, mas uma das mais simples pode ser vista pela fórmula/exemplo a seguir:

Consideremos um time fixo, com velocidade e tamanho de sprints também definidos. O Product Backlog deste projeto seria algo em torno de 1000 pontos. Se a equipe possui uma velocidade de 50 pontos e as Sprints duram 2 semanas, como seria feito o cálculo de venda deste projeto? Dividimos o nú-mero de pontos do backlog (1000) pelo tamanho das sprints (50) e vamos obter o número das semanas (40 semanas). A este número de semanas, somamos uma sprint a cada 5, para que possíveis defeitos possam ser corrigidos e mudanças de

Figura 4. Time de rugby (representação do SCRUM)

Figura 5. Board com várias estórias sendo feitas ao mesmo tempo


AgilidAdE

escopo possam ser mais bem tratadas. Neste caso, ficaríamos com 24 sprints. O cálculo final seria o número final de sprints (24) vezes o número de horas de todo o time.

Testes ágeis ou método cascata?É claro que o desenvolvimento ágil chegou nos últimos anos

com peso muito forte e que está tomando cada vez mais espaço nas salas em empresas no mundo todo. O que devemos nos perguntar é: Estamos TESTANDO de maneira ágil?

Bem, se desenvolvemos de maneira incremental, por que muitos ainda deixam os testes como a última atividade da cadeia? Sem dúvida, como resultado das pesquisas realizadas nos últimos anos, esta é a principal causa de problemas nos projetos onde o escopo alterado e a falta de qualidade na en-trega foram ressaltados pelo cliente. Como justificar muitos defeitos ao final do projeto? Simples dizer se notarmos que os testes são deixados para o final da sprint da mesma forma como já era feita no método cascata.

Mudamos de metodologia, devemos mudar de paradigma. Casos em que o time todo ajuda a testar e depois o especialista em testes fica bloqueado até o final da sprint ou até mesmo que o testador fica com todos os testes e, por falta de tempo, defeitos acabam não surgindo, são frequentes. É importante ressaltar: temos que mudar o paradigma e começar a fazer tes-tes também de maneira incremental. Deixamos este conteúdo para um próximo artigo, mas esta questão pode ser utilizada como o ponto inicial para que todos nós pensemos em como resolver o problema.

De uma forma geral, pode-se explicar uma possível solução para testes funcionando como uma espécie de gargalo no trabalho do time, com a criação dos Testes Ágeis ou Testes Incrementais. O profissional da área de testes pode e deve começar a atuar desde o primeiro dia da sprint. Segue abaixo uma lista com as atividades do dia a dia deste profissional, fazendo com que todo o time esteja mais engajado na disciplina de testes e que todo o trabalho seja cumprido de forma mais eficaz e incremental:

Dia a dia de testes dentro do Scrum: • Dia 0: Antes mesmo da planning meeting, o analista de testes, aproveitando-se de sua visão geral do produto, poderá revisar os requisitos (estórias), fazendo com que estas fiquem mais claras e completas. Este trabalho pode ajudar tanto o PO como o time todo, já que a planning será muito mais pro-veitosa tendo um requisito mais completo e revisado por um membro do time;• Dia 1: Início do desenvolvimento. Enquanto nada está desen-volvido, criam-se os casos de testes baseados nos critérios de aceitação das estórias. Este trabalho será bem reduzido pelo fato da revisão já ter sido feita anteriormente;• Dia 2 a Dia n: Durante todo o desenvolvimento, os testes serão realizados em duas etapas: durante toda a sprint no ambiente dos desenvolvedores (assim muitos dos defeitos serão antecipados e a comunicação entre desenvolvedores e

testadores fará com que a qualidade do produto fique ainda mais elevada) e logo após a finalização do desenvolvimento, no ambiente separado para testes (o teste funcional que as equipes já fazem), onde todos os defeitos são realmente reportados, às vezes até através de uma ferramenta;• Dia Final: Os testes se concentram em Testes de Regressão, para que se possa confirmar a qualidade verificada anterior-mente no produto e em Retestes, para assegurar que todos os defeitos reportados foram corrigidos.

Este é o início de uma das várias propostas que estão sendo feitas para minimizar os problemas que vem sendo encontra-dos na disciplina de testes em equipes ágeis.

ConclusãoEste 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 conceituação básica do que é a metodologia e como deveria ser tratada, para que todas as equipes tenham a chance de pensar mais sobre o assunto e tentar melhorar em futuros projetos.

Algumas ideias já foram apresentadas como possíveis solu-ções para a maioria das questões citadas, mas claro que seria necessário outro artigo para tratarmos das melhores soluções para cada um dos itens da lista. Assim como o estudo realizado para verificar os pontos que afetavam a qualidade de entrega em projetos Scrum, seriam necessários outros estudos voltados para todas as possíveis soluções. Precedentes para trabalhos futuros já começam a surgir e poderão ser verificados em artigos 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

Referências




Dê

seu Feedback

sob

re esta edição

18 Engenharia de Software Magazine - Modelagem Temporal, de Implantação, de Artefatos e de Componentes através da UML

Geraldo Magela Dutra Gonçalves [email protected]

É graduado em Engenharia Civil e possui es-pecialização em Análise e Desenvolvimento de Sistemas, ambas pela Universidade Federal de Juiz de Fora. É técnico em TI da Universidade Federal de Juiz de Fora onde trabalha com desenvolvimento de sistemas de informação e informática desde 1988. É professor do Curso Superior de Tecnologia em Análise e Desenvol-vimento de Sistemas da Fundação Dom André Arcoverde em Valença/RJ.

De que se trata o artigo?Esse artigo apresenta os Diagramas de Temporiza-ção, que integram o grupo de diagramas da UML destinados a modelar comportamento. Apresenta também os Diagramas de Artefatos, Diagramas de Componentes e Diagramas de Implantação, desti-nados à documentação nas atividades de projeto de desenvolvimento de sistemas.

Para que serve?A mesma visão dos artigos anteriores se aplica aqui. Apresentar a notação de forma clara e objetiva, pro-curando destacar principalmente os elementos mais úteis nas situações reais de modelagem. Procura-se uma maneira prática de aplicação dos recursos, sem grandes ônus para os cronogramas de projeto. Docu-

mentação desenvolvida de modo draft, no início do projeto, pode ser detalhada ao longo dele, paralela-mente às atividades de implementação e testes.

Em que situação o tema é útil?Sistemas com estados tempo-dependentes de forma contínua podem valer-se dos Diagramas de Temporização para especi� cação das transições permitas e das restrições de tempo associadas a es-sas transições. Já sistemas com topologia não trivial e/ou extensa, necessitam modelagem através dos Diagramas de Implantação. Sistemas desenvolvidos com orientação a componentes são cada vez mais comuns e enfatizam a desejada capacidade de reu-so, onde Diagramas de Componentes serão úteis em sistemas de porte médio a grande.

Modelagem Temporal, de Implantação, de Artefatos e de Componentes através da UMLAbordagem Prática – Parte 4

A literatura técnica, hoje vasta e diferenciada, costuma ser unânime em classificar os dia-

gramas da UML (Unified Modeling Language) em dois grandes grupos: Dia-gramas Estruturais e Diagramas Com-portamentais. Não há nada de errado com essa classificação, mas existe uma outra, com mais sub-níveis, que traduz de forma mais completa a natureza de cada diagrama, assim como tipifica mais

acuradamente as abstrações capturadas por cada um deles. Então, classifica os treze diagramas da UML em quatro categorias: • Modelagem Estrutural: Diagramas de Casos de Uso, Diagramas de Classes, Dia-gramas de Objetos, Diagramas de Pacotes e Diagramas de Estrutura Composta. • Modelagem de Interações: Diagramas de Sequência, Diagramas de Comunicação e Diagramas de Visão Geral da Interação.

Desenvolvimento

Nesta seção você encontra artigos voltados para diferentes abordagens de apoio ao desenvolvimento de projetos de software


Neste artigo você encontra o vídeo: “Conhecen-do o diagrama de componentes”.



proJEto

• Modelagem Comportamental: Diagramas de Transição de Estados, Diagramas de Atividades e Diagramas de Temporização. • Modelagem da Implantação: Diagramas de Artefatos, pouco discutidos na literatura técnica mas úteis em sistemas de to-pologia não trivial, Diagramas de Componentes e Diagramas de Implantação.

Nos dois últimos artigos dessa série foram abordados os Diagramas de Transição de Estados e os Diagramas de Ati-vidades. O Diagrama de Temporização completa o grupo de Modelagem Comportamental. Para encerrar essa série de artigos, são apresentados também os três diagramas de mo-delagem da implantação, fase final da execução de um projeto de desenvolvimento de sistemas de informação.

Restrições Temporais Discretas e Restrições Temporais Contínuas

Sistemas com estados ou processos tempo-dependentes po-dem ser classificados em duas categorias bem distintas. Num primeiro grupo, situam-se os sistemas onde os intervalos de tempo (time units) associados às transições entre estados são percebidos de forma discreta. Isto significa que os intervalos de tempo têm durações uniformes e pré-fixadas, não admitindo variações. Como exemplo, no fluxo de controle de uma máquina de lavar moderna, o tempo em que ela estará operando no esta-do ‘lavando’ é sempre igual, ou seja, tem um valor fixo finito e pré-fixado, não admitindo variações entre diferentes sessões de execução. Em termos objetivos, a máquina estará operando em estado ‘lavando’ por 5 minutos, por exemplo. Tais restrições de tempo, presentes nos cada vez mais comuns sistemas embarca-dos, podem ser modeladas pela rica sintaxe dos Diagramas de Transição de Estados e pelos Diagramas de Atividades, como foi demonstrado nos dois artigos anteriores.

Um segundo grupo, reúne sistemas onde as transições entre estados de um objeto ou de um grupo de objetos se darão dentro de um intervalo de tempo não fixo, embora finito. Em termos práticos, o sistema espera por um evento externo ou interno que inicie uma transição dentro de um intervalo de tempo que possui um máximo. O evento deverá ocorrer entre 0 e 5 segundos, por exemplo. Se o intervalo de tempo se es-gotar sem que o evento esperado ocorra, o sistema provocará um evento interno que inicia uma transição alternativa. Para modelar essa segunda categoria de sistemas, a UML disponi-biliza o Diagrama de Temporização.

Diagramas de TemporizaçãoDiagramas de Estados representam os estados possíveis

de apenas um objeto e as transições permitidas entre eles. Diagramas de Atividades são um caso especial de Diagramas de Estados onde os estados são ações/atividades e podem representar a participação de diversos objetos. Diagramas de Temporização são, também, uma variação de diagramas de estados e de transições entre eles, mas onde tais transições estão associadas a restrições de tempo. Em última análise,

representam estados e transições de um objeto ao longo de um período de tempo.

Construindo um Diagrama de TemporizaçãoO período de tempo representado nos Diagramas de Tempori-

zação é chamado de linha de vida (lifeline) e pode ser divido em períodos menores chamados unidades de tempo (time units). Os estados e transições são representados dentro de um qua-dro com rótulo td (timing diagram). Um mesmo quadro pode representar uma única linha de vida (de um objeto) ou várias linhas de vida (de uma colaboração) incluindo interferência de uma linha de vida de um objeto sobre a linha de vida de outro. Essa interferência se dá através da emissão de mensagens de tempo. Isto será tratado à frente, neste artigo.

Diagramas de Temporização podem ser apresentados em duas notações 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 construção de um Diagrama de Temporização, a Figura 1 apresenta um quadro de temporização (timing frame) para um equipamento de caixa eletrônico utilizando a notação linha de vida de estados. Nela aparecem 3 linhas de vida (lifelines), cada uma delas representando a linha de vida de objetos controladores dos componentes do equipamento.

Cada linha de vida deve exibir os estados pelos quais o objeto em questão transita, para que o gráfico de tempo seja apresentado como uma evolução entre eles. Um leitor de car-tões magnéticos e um mecanismo de contagem e entrega de cédulas, são equipamentos físicos controlados por objetos do software de auto-atendimento bancário. Tais objetos vão emitir sinais que serão recebidos e processados pelos equipamentos, ativando ou desativando suas funções. Para executar uma sessão de uso, o software de controle do caixa eletrônico vai instanciar objetos de classes controladoras e ativar um fluxo de controle condizente com a escolha do usuário a partir de um menu de opções. Para realizar um saque, por exemplo, o con-trolador transita, em linhas gerais, entre os seguintes estados: disponível – lendoCartão – esperandoSenha – processando – contandoCédulas – disponível. Além disso, o leitor de cartões e o mecanismo de contagem de cédulas estarão sempre em uma de duas condições possíveis: disponível/operando.

Para representar a evolução da linha de vida ao longo do tempo, deve ser introduzida uma escala de tempo que divide

Figura 1. Timing Frame para um caixa eletrônico


um determinado período em unidades de tempo (time units). A Figura 2 apresenta essa escala, bem como os estados pelos quais transitam os três elementos do equipamento.

O gráfico de tempo é então montado horizontalmente sobre as linhas de vida, com as transições posicionadas nas unidades de tempo. A linha de vida principal, do software controlador do equipamento (realizando um caso de uso), vai estar, a princípio, sincronizada com as linhas de vida das unidades auxiliares apenas pela superposição coincidente dos momentos em que acontecem, mas essa representação pode ser melhorada com a introdução de mensagens de tempo, como será demonstrado.

A Figura 3 apresenta os gráficos representativos da evo-lução pelos estados dos três componentes do caixa. As ope-rações do leitor de cartões e do mecanismo de contagem de cédulas estão sincronizadas com suas referências feitas na linha de vida do software controlador do caixa eletrônico.

Para enriquecer a representação de sincronia e depen-dência entre as três linhas de vida, pode-se lançar mão do recurso de incluir mensagens de tempo, como referido anteriormente. Uma mensagem de tempo deixa uma linha de vida e chega a outra no mesmo diagrama, enfatizando a dependência entre elas. Para fixar em que momentos isso acontece, cada unidade de tempo deve ser quantificada e nomeada. Os lapsos de tempo em que as unidades de tempo representam não são necessariamente iguais, isto é, cada estado permanece ativo por tempos diferentes. A Figura 4 apresenta mensagens de tempo emitidas da linha de vida do controlador principal para os controladores dos equipamentos auxiliares. Apenas os marcos importantes

Figura 2. Estados/Condições para cada linha de vida Figura 3. Gráficos de temporização das três linhas de vida sincronizadas

do tempo foram nomeados, ou seja, apenas aqueles em que se dão as transições de estados.

Finalizando o Diagrama de TemporizaçãoUm último elemento nessa forma de representação de Dia-

gramas de Temporização são as restrições de tempo. Conforme referido anteriormente, essa representação dos Diagramas de Temporização é denominada linha de vida de estados. Ela apre-senta, claramente, estados e transições entre eles, assim como as restrições temporais aplicadas às transições. A Figura 5 apresenta um diagrama de temporização completo, com as restrições de temporização aplicadas.

Comparando Representações Uma segunda maneira de representar Diagramas de Tempo-

rização é denominada linha de vida de valor. Mais adequada quando se está lidando com uma grande quantidade de esta-dos e transições, ela é mais compacta e concisa, embora exiba menos informações do que o formato anterior. A Figura 6 mostra o formato de linha de vida de valor para o caixa ele-trônico apresentado. Nela, cada estado é representado por um hexágono e as transições por cruzamentos das linhas de suas arestas. A escala de tempo pode ser apresentada como no formato anterior ou pode ser omitida, enquanto restrições de tempo e duração aparecem entre chaves.

Diagramas da Fase de ImplantaçãoNum processo de desenvolvimento de sistemas incremental

e iterativo (do qual o Rational Unified Process – RUP é uma instância), quatro grandes fases de desenvolvimento são atra-vessadas por pelo menos 6 atividades diferentes: elicitação


proJEto

de requisitos, análise de requisitos, projeto, implementação, testes e implantação. Nesse tipo de processo de desenvolvi-mento aliam-se as melhores qualidades de duas aproximações diferentes para o desenvolvimento de sistemas de software ro-bustos. A primeira delas é a adoção das ferramentas e técnicas de modelagem, que fornecem documentação de alto nível e de suporte efetivo à implementação. A segunda busca a melhor qualidade dos processos ágeis, rapidez no desenvolvimento sem sacrifício da qualidade.

O processo incremental alia o desenvolvimento de modelos estáveis e robustos da análise orientada a objetos à rapidez de desenvolvimento conseguida com a execução de diversas iterações durante a fase de construção, produzindo a cada ciclo concluído, um incremento que passa a integrar a parte do sistema que já está em operação. Assim, por exemplo, duas semanas após o início da fase de construção (uma duração aproximada de uma iteração), já é possível implantar uma parte do sistema e torná-la operacional.

Para apoiar e documentar essa atividade dos ciclos de desen-volvimento, a UML disponibiliza três tipos diferentes de dia-gramas: Diagramas de Artefatos, Diagramas de Componentes e os Diagramas de Implantação propriamente ditos. Embora não sejam citados e explorados na literatura técnica e nem façam parte das listas oficiais de diagramas da UML, Diagramas de Artefatos são claramente referidos por Booch, Rumbaugh e Ja-cobson em sua obra UML – Guia do Usuário, e podem ser muito úteis para documentação e localização de artefatos em sistemas de médio a grandes portes, como será demonstrado.

Figura 4. Mensagens de tempo emitidas entre linhas de vida Figura 5. Restrições de tempo associadas às transições

Figura 6. Formato de linha de vida de valor para o caixa eletrônico

Artefatos e Diagramas de Artefatos Enquanto modela as diversas visões de um sistema, o desen-

volvedor constrói modelos lógicos, compostos de elementos igualmente lógicos. Assim é a natureza de classes, interfaces, suas associações, casos de uso e outros diversos componentes da linguagem de modelagem. Em determinado momento do processo, estes elementos lógicos terão de ser ‘manifestados’ por componentes físicos, reais, que os implementem e permitam suas operações. Tais elementos físicos são chamados artefatos.

Artefatos são elementos físicos, suportados por uma platafor-ma de implementação. Um artefato pode ser entendido como um pacote físico contendo elementos lógicos tais como classes, interfaces e colaborações. A Figura 7 mostra a notação UML 2 para um artefato.

A ideia de artefato está fortemente ligada à definição de arquivos reais, embora seja mais abrangente do que isso. Mas de uma forma prática, pode-se considerar que artefatos são


simplesmente arquivos individuais que suportam os elemen-tos lógicos e seus relacionamentos. Assim, existem artefatos resultantes do trabalho de desenvolvimento, ou seja, o produto do desenvolvimento. São eles, arquivos fonte e arquivos de da-dos a partir dos quais serão gerados artefatos de implantação. Estes, por sua vez, incluem os arquivos executáveis, arquivos de configuração, arquivos de inicialização e bibliotecas, entre outros. Esse segundo conjunto configura um sistema executá-vel completo, que suporta totalmente as especificações lógicas contidas no primeiro conjunto. Um terceiro e último conjunto de artefatos inclui aqueles que só têm existência em tempo de execução de um sistema. Podem denominar-se transientes ou efêmeros.

Tais tipos de artefatos podem ser reconhecidos pela colocação de estereótipos tais como: <<executable>>, um arquivo com código executável, <<library>>, uma biblioteca convencional ou dinâmica, <<file>>, um arquivo contento código fonte, ou <<document>>, um arquivo em formato texto ou outro formato que contenha uma tabela, um script, entre outros. Na represen-tação de artefatos, o desenvolvedor tem liberdade para criar e usar estereótipos específicos para identificar artefatos inco-muns ou muito particulares de um determinado sistema.

A combinação desses tipos de artefatos permite modelar três aspectos importantes de implantação de sistemas: a mo-delagem de executáveis e bibliotecas, a modelagem de tabelas, arquivos e documentos, e a modelagem de código fonte.

Diagramas de Artefatos admitem dois tipos de relaciona-mento entre artefatos: uma dependência, quando um artefato utiliza serviços oferecidos por outros, ou uma manifestação, quando um artefato é uma manifestação física de um elemento lógico qualquer.

Diagramas de Artefatos de Código FonteO código fonte que implementa as funcionalidades de um

sistema é geralmente desenvolvido em uma série de artefatos que são então relacionados. Tais relacionamentos podem originar-se primariamente das especificações lógicas dos re-lacionamentos entre trechos de código, mas também podem refletir dependências de compilação, ou seja, diretivas obriga-tórias para obtenção do código executável. Em outras palavras, a simples ausência de uma biblioteca de classes pode tornar impossível a compilação de um módulo, de um componente ou de todo um sub-sistema.

A modelagem criteriosa dos artefatos produto do desenvol-vimento oferece uma visão privilegiada dessas dependências. A Figura 8 é um exemplo desse tipo de modelagem aplicado ao caixa eletrônico.

A Figura 8 representa as dependências entre artefatos. Para gerar o artefato software.class, que é um arquivo executável (interpretável no caso do Java). O diagrama mostra também claramente que, para executar, software.class faz uso de uma biblioteca dinâmica, biblioteca.dll, assim como depende de uma conexão a um sistema gerenciador de banco de dados, do qual usa dados de uma tabela denominada nomes.tbl. Para sistemas complexos de software, esta representação pode assumir importância crítica.

Diagramas de Artefatos de Código ExecutávelEsse diagrama pode ser particularmente útil em sistemas

com diversos módulos executáveis que utilizam bibliotecas dinâmicas. Os elementos que têm relação direta são represen-tados, assim como seus relacionamentos, que neste caso são todos de dependência, ou seja, um artefato utilizando serviços oferecidos por outros. A Figura 9 apresenta um exemplo de modelagem onde também estão modeladas as dependências existentes em relação a um arquivo de inicialização assim como de um arquivo de ajuda on-line.

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

do sistema são arquivos fonte, executáveis ou bibliotecas. Uma tabela integrante de um banco de dados relacional, por exemplo, é também um artefato. A rigor, um sistema gerenciador de banco de dados é um componente formado de dezenas de artefatos. Numa outra situação, um arquivo HTML pode ser usado como fonte para implementação de ajuda on-line para um sistema de acesso via WEB. É claro que modelar todo um banco de dados

Figura 7. Um artefato

Figura 8. Diagrama de Artefatos


proJEto

utilizando Diagramas de Artefatos é uma tarefa desnecessária, já que existe toda uma notação apropriada para essa finalidade, mas para destacar a interação entre um elemento executável e uma das tabelas de um SGBD, os Diagramas de Artefatos são de valia e ajuda inestimável. A Figura 10 apresenta um exemplo desse tipo de modelagem.

Existem diversas considerações importantes sobre o emprego de Diagramas de Artefatos, especificamente falando, assim como sobre os inter-relacionamentos entre estes e os Diagramas de Componentes e de Implantação tratados à frente.

Em primeiro lugar, os três tipos de Diagramas de Artefatos não são estanques, isto é, eles podem ser mesclados de forma livre, mostrando relacionamentos entre artefatos fonte, exe-cutáveis e auxiliares e representando dependências, manifes-tações e implantações de forma livre. Isso gera uma riqueza de representação que torna tais diagramas muito úteis em geração de documentação de apoio à manutenção. Diagramas de Artefatos construídos assim podem exibir tags com valores atribuídos que expressam uma série útil de atributos associa-dos aos artefatos, tais como versões, modificações, atualizações e outros elementos.

Uma segunda consideração importantíssima é sobre a pos-sibilidade, e às vezes necessidade, de interseção entre os três diagramas de implantação. Artefatos podem estar contidos dentro de componentes de software (tratados adiante), e estes podem estar contidos dentro de pacotes, dentro de outros com-ponentes ou mesmo dentro de outros artefatos. Componentes de software, assim como artefatos isolados, podem estar alocados a nós de processamento (elementos dos diagramas de implanta-ção apresentados à frente). Elementos lógicos da linguagem de modelagem podem ser “manifestados” pelos artefatos já citados, enquanto artefatos podem ser “implantados” em nós específicos de processamento. Quando se desenvolvem diagramas que as-sociam artefatos, componentes, pacotes e nós de processamento (tratados adiante), os relacionamentos entre artefatos e os demais elementos, além da dependência, podem ser de outros dois tipos: implantação (deployment) ou manifestação (manifestation). Uma implantação indica um nó físico onde um artefato será localizado. Um relacionamento de manifestação representa uma instanciação física de um artefato qualquer.

Componentes e Diagramas de ComponentesNo cerne da ideia de componentes está a reutilização. Em linhas

gerais, o desenvolvimento de software baseado em componentes inspira-se na mesma atividade desenvolvida com sucesso pela engenharia de hardware e eletrônica em geral, que já projeta com sucesso, baseada em componentes, com mais de meio século de vantagem em relação ao desenvolvimento de software. A idéia não é nova e nem engatinha. Já existem padrões de indústria reais e em desenvolvimento. Como elemento fundamental para construção de tais sistemas situa-se o componente.

Um componente de software é um elemento que integra um determinado 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 também



substituído a qualquer momento sem prejuízo para o sistema. A atuação de um componente dentro de um determinado siste-ma se dá através de interfaces fornecidas pelo componente ou requeridas pelo mesmo, através das quais são fornecidos servi-ços daquele componente ou requeridos serviços fornecidos por outros componentes. Interfaces se conectam ao componente através de portas, definidas em sua estrutura encapsulada. Um componente é, assim, totalmente encapsulado, só disponibili-zando suas funcionalidades através de portas específicas que comportam interfaces.

Componentes não são elementos atômicos; eles possuem uma estrutura interna. Sua composição pode ser de classes internas ou de outros componentes, assim como de pacotes. Os elementos da estrutura interna de um componente devem, naturalmente, exibir associações. A forma mais corriqueira de representar estas associações é através de dependências, mas o caminho mais utilizado para isso é a utilização das interfaces. A Figura 11 apresenta a representação de um componente na notação da UML 2. Está representada, além do componente, uma interface requerida, através da qual esse componente poderá se conectar ao sistema. O contexto é o mesmo usado anteriormente. O componente é mostrado utilizando um es-tereótipo que pode ser omitido, já que o símbolo é exclusivo para componentes.


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

atividade é determinar que componentes compõem o siste-ma. Para o contexto do caixa eletrônico, três componentes podem ser listados: o conjunto de classes que implementam as funcionalidades do equipamento, o conjunto de classes que controlam o leitor de cartões e o conjunto de classes que controlam o mecanismo de contagem e liberação de cédulas, embora componentes nem sempre sejam apenas conjuntos de classes. Os equipamentos serão acessados por interfaces requeridas, que serão realizadas pelos controladores (métodos de 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 representada no diagrama. Essa estrutura interna inclui classes de fronteira e controladoras para cada funcionalidade, além de acesso a mecanismo de persistência de objetos. Em última análise, esse importante componente contém o sistema de controle propriamente dito.

As interfaces requeridas pelos equipamentos periféricos são todas fornecidas pelo componente principal, através de por-tas dedicadas que preservam o encapsulamento de todos os componentes. A Figura 12 apresenta um Diagrama de Compo-nentes que modela a arquitetura baseada em componentes do sistema. O diagrama foi desenvolvido dentro de um frame com rótulo cmp (componente). A estrutura interna do componente

Figura 11. Um componente com interface requerida

principal não foi completamente mostrada, pois isso tornaria o diagrama visualmente confuso.

Diagramas de ImplantaçãoSistemas simples, destinados à execução em estações ‘standa-

lone’, têm todos os seus artefatos residentes nessa única estação. Mas estes sistemas praticamente não existem mais. Sistemas modernos de processamento de informações são baseados em acesso via web e residem em ambientes de processamento distribuído, com seus artefatos residindo em diferentes pontos de uma rede de processamento. Estes pontos são denomi-nados nós de processamento e sua localização geográfica já não necessita fronteiras. Uma rede pode estar, e na realidade frequentemente está, localizada em diversas locações, às vezes em países diferentes.

Em casos menos extremos, sistemas de médio a grande portes podem conter-se em um único site, mas ainda assim espalhando-se por diversos servidores diferentes. Para docu-mentar a rede de nós de processamento, assim como determi-nar a localização real (física) dos diversos artefatos que compõe o sistema, a UML disponibiliza o Diagrama de Implantação que, entre outras finalidades, representa as localizações físi-cas (nós) e seu conteúdo (artefatos), exibindo ainda uma série de atributos através de tags. Um nó de processamento é uma localização física que possui alguma quantidade de memória e freqüentemente capacidade de processamento. A notação da UML 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 atribuídos e compartimentos especiais contendo listas de nomes de arte-fatos residentes naquele nó. Na representação da topologia de um ambiente de processamento surgirão nós com capacidade de processamento e nós que simplesmente são dispositivos de armazenamento. Para distinguir entre esses tipos de nós pode-se utilizar os estereótipos <<device>> para dispositivos, e <<executionEnvironment>> para processadores.

As conexões entre nós são normalmente representações de ligações físicas entre os componentes de uma rede, já que os nós representam exatamente estes componentes. Para obter um dia-grama legível e útil não convém representar todos os artefatos e sim aqueles considerados fundamentais para compreensão do funcionamento do sistema. Assim, em vez de representar todas as tabelas de um banco de dados, pode-se representá-lo como um pacote ou como um conjunto de componentes. Para documentar de maneira clara e útil, o desenvolvedor pode lançar mão de todos os elementos dos diagramas de artefatos, de componentes, de pacotes e de implantação, combinando-os à vontade, para gerar documentação rica e útil.

A Figura 14 representa a topologia para o sistema do caixa eletrônico, as conexões (inclusive as remotas) entre os diversos nós, e as residências dos principais artefatos do sistema. Site-Banco representa uma localização física que executa programas de acesso às bases de dados. O nó CaixaEletrônico conecta-se remotamente ao SiteBanco e estabelece uma colaboração que desempenhará a funcionalidade requisitada. Figura 12. Diagrama de Componentes para o caixa eletrônico


proJEto

Figura 13. Representação de um nó de processamento

Dois programas executando no site, exibem um relaciona-mento com este chamado implantação (deploy). Isto significa que o nó SiteBanco é quem implanta os artefatos indicados. Os programas que rodam nos servidores de aplicação no site do banco exibem uma dependência em relação a um pacote que representa todos os artefatos integrantes de um sistema gerenciador de banco de dados (SGBD). O nó CaixaEletrônico conecta-se com dois nós auxiliares que estão rotulados como dispositivos periféricos ou devices. Como os três nós estão geograficamente localizados num espaço único, essa conexão é feita por cabos multivias. Estes nós não possuem capacidade de processamento e eventualmente nem mesmo memória. São dispositivos auxiliares controlados por drivers. Um ou mais componentes RotinaAcesso podem ser instanciados durante uma sessão de execução do software. Isto está evidenciado atra-vés de um relacionamento de agregação entre o componente e o nó. Finalmente, o artefato principal, software.class, exibe um relacionamento com o nó CaixaEletrônico denominado manifestação. Isso significa que o artefato se manifesta através do elemento físico representado pelo nó.

ConclusãoOs diagramas UML mais representativos e largamente

empregados são, sem dúvida, os diagramas de classes, de sequência, de estados e de atividades. Embora todos os outros sejam de igual valia para a equipe de desenvolvimento, um projeto pode sobreviver sem eles, o que acaba por desestimu-lar seu desenvolvimento. Isso é um antigo problema vestindo roupa nova. Dispensar tempo com documentação que pode ser considerada secundária sempre foi uma atividade prete-rida e/ou abandonada. Para mudar essa realidade, que é uma questão de ‘cultura’ dos desenvolvedores, a UML disponibiliza todo um conjunto de modelos com notações apropriadas para modelagem dos mais variados aspectos inerentes ao desenvol-vimento de sistemas.

Diagramas empregados na fase de implantação de siste-mas compreendem Diagramas de Artefatos, Diagramas de Componentes e Diagramas de Implantação. Embora pouco empregados, são de grande importância para modelagem de sistemas de média a alta complexidade e que executam em ambientes de processamento distribuídos. Seu emprego passa a ser quase obrigatório quando tais ambientes são extensos e complexos.

Diagramas de Artefatos de código fonte e executável passam a ser uma espécie de índice para localização de artefatos em uma extensa rede de nós de processamento. Recursos como quantidade de memória e capacidade de processamento podem ser alocados e controlados mediante seu emprego e atualização constante. Já os Diagramas de Componentes são uma obrigato-riedade para instalações que desenvolvem com essa filosofia. A representação dos componentes e seus relacionamentos torna mais amena a difícil tarefa de manutenção.

Por fim, diagramas de temporização encontram seu melhor emprego em especificações de sistemas de controle de am-bientes, geralmente de tempo real e em pequenos (mas não

Figura 14. Diagrama de Implantação

menos complexos) sistemas embarcados, ou seja, programas controladores de dispositivos e aparelhos eletrônicos espe-cíficos. Alguns sistemas comerciais e/ou administrativos podem apresentar processos tempo-dependentes, mas estas dependências podem ser modeladas nos diagramas de estado e atividades.




Dê

seu Feedback

sob

re esta edição

BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 2.ed. Rio de Janeiro:

Campus-Elsevier, 2007. 370p.

BOOCH, Grady; RUMBAUGH, James; Jacobson, IVAR. UML: Guia do Usuário. 2.ed. Rio de Janeiro:

Campus-Elsevier, 2006. 474p.

FOWLER, Martin. UML essencial: um breve guia para a linguagem padrão de modelagem de

objetos. 3.ed., Porto Alegre: Bookman, 2006. 160p.

BLAHA, Michael; RUMBAUGH, James. Modelagem e projetos baseados em objetos com UML

2.2.ed. Rio de Janeiro: Campus-Elsevier, 2006. 496p.

Referências Bibliográficas

26 Engenharia de Software Magazine - Refatoração para Padrões – Parte 5

Marco Antônio Pereira Araújo [email protected]

É Doutor e Mestre em Engenharia de Sis-temas e Computação pela COPPE/UFRJ, Especialista em Métodos Estatísticos Com-putacionais e Bacharel em Informática pela UFJF, professor do curso de Bacharelado em Ciência da Computação da FAGOC, professor dos Cursos de Bacharelado em Sistemas de Informação do Centro de Ensino Superior de Juiz de Fora, da Faculdade Metodista Granbery e da Universidade Severino Som-bra, professor do Curso de Tecnologia em Análise e Desenvolvimento de Sistemas da Fundação Educacional D. André Arcoverde. Analista de Sistemas da Prefeitura de Juiz de Fora, Editor da Engenharia de Software Magazine.

Jacimar Fernandes Tavares [email protected]

É Aluno do Curso de Bacharelado em Ciên-cia da Computação da FAGOC - Faculdade Governador Ozanam Coelho, Microsoft Student Partners.

De que se trata o artigo?Aborda o tema refatoração para padrões com o objeti-vo de mostrar como o desenvolvedor pode usá-lo para melhorar o código-fonte de suas aplicações.

Para que serve?Para prover conhecimento ao desenvolvedor sobre refatoração para padrões e demonstrar através de um exemplo prático a aplicação das técnicas de refa-toração para padrões Substituir Lógica condicional por Strategy.

Em que situação o tema é útil?O tema se torna fundamental para desenvolvedo-res que já estão familiarizados com padrões de pro-jeto e já os implementam em seus softwares e que querem saber mais sobre refatoração para padrões, conhecendo os benefícios que sua utilização traz.

Refatoração para Padrões – Parte 5 Implementando o padrão Strategy com Substituir lógica condicional por Strategy

Uma prática comum a vários de-senvolvedores, principalmente os que não possuem conheci-

mento sobre padrões de projeto, é a de criar extensos métodos com complexa lógica de seleção, com o objetivo de for-necer todos os caminhos para determi-nados comportamentos em um só lugar. Tal prática é funcional e pode ser realiza-da em tempo hábil, mas outras questões devem ser levadas em consideração.

Métodos com extensa lógica de seleção possuem complexidade ciclomática ele-vada, o que pode vir a ser um problema quando se pensa em manutenções futuras. A refatoração para o padrão Strategy forne-ce um mecanismo mais sofisticado que um método com extensa lógica condicional, se bem aplicada. Contudo, refatorar para o padrão Strategy não é uma tarefa simples, visto que há vários conceitos e práticas envolvidas neste processo.

A partir deste momento serão apresen-tados conceitos e práticas que estão dire-tamente ligados ao processo de refatorar para o padrão Strategy com a utilização da técnica de refatoração para padrões

Substituir Lógica condicional por Stra-tegy, uma visão geral do que é o padrão de projeto Strategy, bem como as técni-cas de refatoração Mover Método (ver Nota do DevMan1), Introduzir Objeto Parâmetro, Substituir Condicional por Polimorfismo e Substituir Enumeração por Subclasse. Ao final será abordada a técnica de refatoração para padrões

Desenvolvimento

Nesta seção você encontra artigos voltados para diferentes abordagens de apoio ao desenvolvimento de projetos de software


dESEnvolviMEnto

Substituir Lógica condicional por Strategy, onde um exemplo prático de sua utilização será apresentado.

O padrão de projeto StrategyNome do padrão de projeto: Strategy. Pertencente ao con-

junto dos padrões de projeto classificados como Padrões Comportamentais.

O problema: Em alguns momentos é possível encontrar apli-cações com muito código escrito para determinar como será a tomada de ações mediante algumas solicitações dos clientes da aplicação. O padrão de projeto Strategy pode atuar neste sentido, uma vez que sua implementação possibilita a definição de uma estrutura de classes responsáveis por implementar diferentes algoritmos que serão utilizados para definir novas estratégias para um conjunto de objetos de uma classe, por exemplo.

As consequências: Com isso, consegue-se utilizar diferentes algoritmos de estratégia em tempo de execução, além de per-mitir a definição de algumas variações desses algoritmos na estrutura de classes que compõem a estratégia.

A refatoração Introduzir Objeto ParâmetroEsta refatoração é pertencente ao grupo de refatorações classifi-

cadas como Tornando as Chamadas de Métodos Mais Simples.Nome da refatoração: Introduzir Objeto Parâmetro.Resumo: Algumas classes possuem vários métodos que re-

cebem vários parâmetros em comum. Neste contexto, cria-se um objeto que possua os atributos mais usados pelos métodos e modifique-os para receberem um objeto, no lugar dos vários dados que recebiam como parâmetros.

Motivação: Introduzindo objetos no lugar de vários dados como parâmetro, pode-se reduzir, e muito, o código duplica-do, além de juntar os dados em um só lugar. Pode-se ainda reduzir significativamente o número de parâmetros passados ao método.

Mecânica: • Cria-se a classe que terá atributos que substituirão os parâ-metros passados aos métodos.• Declare nela os atributos que deseja substituir pelos parâmetros.• Modifique os métodos para receberem como parâmetro um objeto da classe criada, apagando os antigos parâmetros.• Execute os testes.

Exemplo: O exemplo a seguir vem de um sistema comercial do qual são extraídas várias informações, onde vários métodos são invocados para obtê-las. A Listagem 1 mostra o código da classe Departamento.

Ao analisar o código da Listagem 1 percebe-se que há vários pontos com código omitido. Isso é necessário para que o foco fique somente na declaração dos métodos e não no corpo do método, que para esta refatoração não é importante.

Os métodos declarados possuem algo em comum: a lista de parâmetros é idêntica entre eles. Primeiramente cria-se a classe que terá atributos equivalentes aos parâmetros utilizados pelos métodos, conforme a Listagem 2.

N o t a d o D e v M a n 1

Refatoração Mover MétodoA técnica de refatoração Mover Método foi apresentada no artigo da edição 29 da

Engenharia de Software Magazine.

listagem 1 – Classe Departamento.

01. public class Funcionarios02. {03. ...04. public Decimal RecuperaTotalSalarios(String nome, DateTime inicio, DateTime final)05. {06. ...07. return total;08. }09. public Boolean DeletarRegistroSalarial(String nome, DateTime inicio, DateTime final)10. {11. ...12. return statusAcao;13. }14. public Decimal RecuperaValorTotalComissao(String nome, DateTime inicio, DateTime final)15. {16. ...17. return comissao;18. }19. ...20. }

listagem 2 – Classe Dados.

01. public class Dados02. {03. private String nome;04. private DateTime dataInicio;05. private DateTime dataFinal;

06. public String Nome07. {08. get { return nome; }09. set { nome = value; }10. }

11. public DateTime DataInicio12. {13. get { return dataInicio; }14. set { dataInicio = value; }15. }16. public DateTime DataFinal17. {18. get { return dataFinal; }19. set { dataFinal = value; }20. }

21. public Dados(String nome, DateTime dataInicial, DateTime dataFinal)22. {23. this.Nome = nome;24. this.DataInicio = dataInicial;25. this.DataFinal = dataFinal;26. }

27. }


O método construtor da classe Dados, Listagem 2, fica res-ponsável por instanciar o objeto Dados. Os métodos da classe Funcionarios, Listagem 1, depois de ter seus parâmetros subs-tituídos por um objeto ficam como mostra a Listagem 3.

Aparentemente o resultado da troca de parametros por um objeto pode não paracer tão satisfatório mas, se aplicado em classes que possuem vários métodos com uma grande lista de parametros em comum, pode reduzir consideravelmente o código duplicado.

A refatoração Substituir comando Condicional por Polimorfismo.

Esta refatoração é pertencente ao grupo de refatorações clas-sificadas como Simplificando Expressões Condicionais.

Nome da refatoração: Substituir Comando Condicional por Polimorfismo.

Resumo: Substitui comandos condicionais que selecionam ações a serem executadas por métodos polimórficos.

Motivação: Usada para remover expressões condicionais para um determinado objetivo que se repetem em vários tre-chos de código. Com isso, simplifica-se o projeto de código e removem-se duplicações.

Mecânica: • Verifique o método que contenha uma sentença switch ou else ifs. Aplica-se a refatoração Extrair Método para que a expressão condicional fique sozinha no método, caso necessário.• Usa-se Mover Método para levar o método que contem a sentença switch para a superclasse.• Cria-se um método em cada uma das subclasses e cola-se nele o trecho de código da lógica condicional que se refere à subclasse em questão. Caso a subclasse já possua um método que possa ser usado para substituir o trecho da lógica condi-cional, desconsidera-se este passo.• Deleta-se o código da lógica condicional que acabou de copiar .• Executa-se todos os passos até remover toda lógica condicional.

Exemplo: A Listagem 4 apresenta a classe Pessoa, que contem uma sentença switch.

Nota-se que o método RecuperaValorSalario não possue nada além da sentença switch, o que descarta a necessidade de aplicação da refatoração Extrair Método.

O segundo passo portanto requer que o método Recupera-ValorSalario seja movido para a superclasse da hierarquia. As Listagens 5, 6 e 7 mostram a hierarquia referida.

Depois da aplicação do segundo passo da refatoração, a classe Funcionário ficará como na Listagem 8.

Nota-se que o método RecuperaValorSalario agora tem um objeto funcionário como parâmetro. Isso é necessário para que o método continue funcionando após ter sido movido para a classe Funcionario.

O próximo passo consiste em criar métodos nas subclasses que tenham as mesmas funções que a logica condicional. O que quer dizer, por exemplo, que a classe Mensalista deve ter um método que retorne o salario de um funcionario mensalista

listagem 3 – Classe Funcionarios refatorada.

01. public class Funcionarios02. {03. public Funcionarios()04. {05. }06. public Decimal RecuperaTotalSalarios(Dados dadosNecessarios)07. {08. Decimal total = 0; 09. return total;10. }11. public Boolean DeletarRegistroSalarial(Dados dadosNecessarios)12. {13. Boolean statusAcao = true; 14. return statusAcao;15. }16. public Decimal RecuperaValorTotalComissao(Dados dadosNecessarios)17. {18. Decimal comissao = 0.0m;19. return comissao;20. }21. }

listagem 4 – Classe Pessoa.

01. public class Pessoa02. {03. private Funcionario funcionario;04. private String RecuperaTipoFuncionario()05. {06. return funcionario.RecuperaTipoFuncionario();07. }08. public Decimal RecuperaValorSalario()09. {10. switch (RecuperaTipoFuncionario())11. {12. case “Mensalista”:13. return funcionario.RecuperaSalario();14. case “Diarista”:15. return funcionario.RecuperaSalario();16. default:17. return 0;18. }19. }20. }

listagem 5 – Superclasse da hierarquia: classe Funcionario.

01. public abstract class Funcionario02. {03. public abstract String RecuperaTipoFuncionario();04. public abstract Decimal RecuperaSalario();05. }

listagem 6 – Subclasse da hierarquia: classe Mensalista.

01. public class Mensalista: Funcionario02. {03. ...04. public override String RecuperaTipoFuncionario()05. {06. return “Mensalista”;07. }08. public override decimal RecuperaSalario()09. {10. return salario;11. }12. }


dESEnvolviMEnto

para substituir o case mensalista da sentença switch . Analisan-do as classes Mensalista e Diarista, perecebe-se que tal método já existe. Agora, portanto, resta modificar o método Recupe-raValorSalario da classe Funcionario para eliminar a lógica condicional. A Listagem 9 mostra o resultado da mudança.

A refatoração Substituir Enumeração por SubclassesEsta refatoração é pertencente ao grupo de refatorações clas-

sificadas como Organizando Dados.Nome da refatoração: Subst ituir Enumeração por

Subclasses.Resumo: Substituição de enumerações por subclasses, pois

enumerações alteram o comportamento de uma classe.Motivação: Usa-se esta refatoração para dividir uma classe

que possui características de uma classe que carrega mais informação do que normalmente deveria carregar. Substi-tuindo as enumerações por subclasses, consegue-se clarificar a intenção do código.

Mecânica: • Analisa-se a enumeração e cria-se uma classe para cada valor contido na enumeração, tornando-as subclasses da classe que contém a enumeração.• Deletam-se os campos da enumeração e movem-se as carac-terísticas que são específicas das subclasses para elas.• Execute os testes.

Exemplo: A classe Pessoa possui uma enumeração chamada TipoPessoa, onde Alunos é representado por 0, e Professores por 1. A classe Pessoa possui ainda métodos que realizam operações para alunos e para professores, o que caracteriza que a classe Pessoa possui comportamentos que poderiam ser divididos por outras classes, conforme será feito nesta refatoração. A Listagem 10 mostra a classe Pessoa.

Aplicando essa refatoração, parte do código da classe Pessoa poderá ser dividido em duas classes: Alunos e Professores. As-sim será possível clarificar o código da classe Pessoa, ao movê-lo para as subclasses. As Listagens 11 e 12 mostram as subclasses criadas a partir da análise dos campos da enumeração.

A classe Pessoa agora é a superclasse das subclasses Alunos e Professores. Agora para clarificar e reduzir a complexidade da classe Pessoa, move-se todo conhecimento específico para as respectivas subclasses que, neste caso, implica em mover o método AlterarSenhaAluno para a classe Alunos e Recuperar-NomeProfessor para Professores, conforme Listagens 13 e 14.

Para finalizar, basta apagar a enumeração da classe Pessoa e ajustar as chamadas à enumeração para as novas mudanças. A partir desse momento, todo código que antes era desti-nado à classe Pessoa, agora dever ser analisado e escrito na subclasse que melhor se encaixar nos objetivos da nova funcionalidade.

Até este ponto foram apresentados os conceitos e práticas que o desenvolvedor precisa para iniciar o processo de aprendizado sobre a refatoração para o padrão Strategy. A partir deste mo-mento será apresentada a técnica de refatoração para padrões Substituir Lógica condicional por Strategy.

listagem 7 – Subclasse da hierarquia: classe Diarista.

01. public class Diarista: Funcionario02. {03. ...04. public override String RecuperaTipoFuncionario()05. { 06. return “Diarista”;07. }08. public override decimal RecuperaSalario()09. {10. return salario;11. }12. }

listagem 8 – Classe Funcionário.

01. public abstract class Funcionario02. {03. public abstract String RecuperaTipoFuncionario();

04. public Decimal RecuperaValorSalario(Funcionario funcionario)05. {06. switch (RecuperaTipoFuncionario())07. {08. case “Mensalista”:09. return funcionario.RecuperaSalario();10. case “Diarista”:11. return funcionario.RecuperaSalario();12. default:13. return 0;14. }15. }16. }

listagem 9 – Classe Funcionario.

01. public abstract class Funcionario02. {03. public abstract String RecuperaTipoFuncionario();

04. public abstract Decimal RecuperaSalario();

05. public Decimal RecuperaValorSalario(Funcionario funcionario)06. {07. return funcionario.RecuperaSalario();08. }09. }

listagem 10 – Classe Pessoa com a enumeração TipoPessoa.

01. public class Pessoa02. {

03. public enum TipoPessoa04. {05. Alunos = 0,06. Professores = 107. }08. public void AlterarSenhaAluno(String novaSenha)09. {10. ...11. }

12. public void RecuperaNomeProfessor(Int32 id)13. {14. ...15. }16. }


A refatoração para padrões Substituir Lógica condicional por Strategy

Resumo: Alguns métodos possuem complexa lógica condi-cional para escolher e executar determinados cálculos. Para lidar com isto, define-se uma hierarquia de classes Strategy onde cada subclasse ficará responsável por executar um tipo de cálculo da lógica condicional.

listagem 11 – Subclasse Alunos.

01. public class Alunos : Pessoa02. {03. }

listagem 12 – Subclasse Professores.

01. public class Professores : Pessoa02. {03. }

listagem 13 – Classe Alunos.

01. public class Alunos : Pessoa02. {03. public void AlterarSenhaAluno(String novaSenha)04. {05. ...06. }

07. }

listagem 14 – Classe Professores.

01. public class Professores : Pessoa02. {03. public void RecuperaNomeProfessor(Int32 id)04. {05. ...06. }07. }

listagem 15. Classe Emprestimos.

01. public class Emprestimos02. {03. public Decimal emprestimoMinimo = 50.00m;04. public Decimal salarioMinimo = 510.0m;

05. public Decimal CalcularEmprestimo(Decimal renda, Decimal taxa)06. {07. if (renda <= (salarioMinimo / 2))08. {09. return emprestimoMinimo;10. }11. else if(renda <= salarioMinimo)12. {13. return ((renda * 10)/ 100) + taxa;14. }15. else if(renda <= (salarioMinimo * 2))16. {17. return ((renda * 20) / 100) + 2* taxa;18. } 19. else20. {21. return ((renda * 50) / 100) - (taxa * 5);22. } 23. }24. }

Motivação: Métodos com lógica condicional de grande complexidade podem dificultar a tarefa de entendimento do método e assim dificultar a análise de qual trecho da lógica condicional será executada e qual ação será efetuada. Esta téc-nica de refatoração para padrões fornece um mecanismo onde a lógica condicional poderá ser eliminada. Isto se torna possível graças à implementação do padrão Strategy que fornecerá um mecanismo baseado em polimorfismo e que possibilitará que as subclasses da estratégia criada possuam cada uma delas uma das ações que a lógica condicional removida possuía.

Vantagens: Permite a remoção de lógica condicional, simpli-ficando o projeto de código existente; torna algoritmos mais claros de se entender; permite que um algoritmo seja trocado por outro em tempo de execução.

Desvantagens: Complica um projeto de código existente quando outro mecanismo mais simples poderia resolver o problema, neste caso, um mecanismo baseado em herança; dificulta a visualização de como dados são passados entre os objetos.

Mecânica: Busca-se por um método que possua lógica con-dicional a ser removida.1. Cria-se uma classe Strategy. Seu nome deve ser compatível com a função do método escolhido e terminado com a palavra Strategy.2. Utiliza-se a refatoração Mover Método levando o método escolhido para a classe criada no passo 1. Deve-se deixar uma cópia do método no seu local de origem e modificá-la para que delegue ao método movido para a classe criada no passo 1. Caso o método escolhido faça referência a outros métodos da classe onde está escrito, devem-se movê-los também para classe criada no passo 1. A refatoração Introduzir Objeto Parâmetro permite a redução de parâmetros a serem passados para as estratégias definidas. Caso necessário, ela deve ser utilizada.3. Modifique o código cliente para se adequar às novas mudanças.4. Utiliza-se a refatoração Substituir Condicional por Polimor-fismo no método presente na classe criada no passo 1. Talvez seja necessária a aplicação da refatoração Substituir Enumera-ção por Subclasses. Para se certificar se o uso desta refatoração se aplica, considera-se o contexto em que ela deve ser aplicada. Compila-se a aplicação e executam-se testes.

Exemplo: A Listagem 15 mostra a classe Emprestimos, onde é possível perceber que o método CalcularEmprestimo possui grande quantidade de lógica condicional para calcular o em-préstimo com base na taxa de juros e na renda do cliente.

Aplicando a refatoração para padrões em questão, tem-se a clas-se CalcularEmprestimoStrategy, como mostra a Listagem 16.

Prosseguindo, tem-se a criação de um método em Calcu-larEmprestimoStrategy que receberá a lógica condicional presente no método CalcularEmprestimo (Listagem 15). A Listagem 17 mostra o resultado.

Move-se o corpo do método CalcularEmprestimo (Listagem 15) para o corpo do método Calcular (Listagem 17). Deve-se também mover todo o código presente na classe CalcularEmprestimo


dESEnvolviMEnto

listagem 16. Classe CalcularEmprestimoStrategy.

1. public class CalcularEmprestimoStrategy2. {

3. }

listagem 17. Classe CalcularEmprestimoStrategy

1. public class CalcularEmprestimoStrategy2. {3. public Decimal Calcular(Decimal renda, Decimal taxa)4. {5. return 0.0m; 6. }7. }

listagem 18. Classe CalcularEmprestimoStrategy

1. public class CalcularEmprestimoStrategy2. {3. public Decimal emprestimoMinimo = 50.00m;4. public Decimal salarioMinimo = 510.0m;

5. public Decimal Calcular(Decimal renda, Decimal taxa)6. {7. if (renda <= (salarioMinimo / 2))8. {9. return emprestimoMinimo;10. }11. else if (renda <= salarioMinimo)12. {13. return ((renda * 10) / 100) + taxa;14. }15. else if (renda <= (salarioMinimo * 2))16. {17. return ((renda * 20) / 100) + 2 * taxa;18. }19. else20. {21. return ((renda * 50) / 100) - (taxa * 5);22. } 23. }24. }

listagem 19. Classe Emprestimos

1. public class Emprestimos2. { 3. private CalcularEmprestimoStrategy calcularEmprestimo;4. public Decimal CalcularEmprestimo(Decimal renda, Decimal taxa)5. {6. return calcularEmprestimo.Calcular(renda, taxa);7. }8. }

listagem 20. Subclasse MeioSalarioMinimoStrategy.

1. public class MeioSalarioMinimoStrategy: CalcularEmprestimoStrategy2. {3. public override Decimal Calcular(Decimal renda, Decimal taxa)4. {5. return ((renda * 10) / 100) + taxa;6. }7. }

listagem 21. Subclasse SalarioMinimoStrategy.

1. public class SalarioMinimoStrategy: CalcularEmprestimoStrategy2. {3. public override Decimal Calcular(Decimal renda, Decimal taxa)4. {5. return ((renda * 10) / 100) + taxa;6. }7. }

listagem 22. Subclasse DoisSalariosMinimosStrategy.

1. public class DoisSalariosMinimosStrategy: CalcularEmprestimoStrategy2. {3. public override Decimal Calcular(Decimal renda, Decimal taxa)4. {5. return ((renda * 20) / 100) + 2 * taxa;6. }7. }

listagem 23. Subclasse RendaAltaStrategy.

1. public class RendaAltaStrategy: CalcularEmprestimoStrategy2. {3. public override Decimal Calcular(Decimal renda, Decimal taxa)4. {5. return ((renda * 50) / 100) - (taxa * 5);6. }7. }

listagem 24. Superclasse CalcularEmprestimoStrategy.

1. public abstract class CalcularEmprestimoStrategy2. {3. public Decimal emprestimoMinimo = 50.00m;4. public Decimal salarioMinimo = 510.0m;

5. public abstract Decimal Calcular(Decimal renda, Decimal taxa);

6. }

(Listagem 15) que o código movido esteja utilizando. O resultado pode ser visto na Listagem 18.

Modifica-se o método CalcularEmprestimo da classe Emprés-timos (Listagem 15), para que ele delegue à classe CalcularEm-prestimoStrategy. A Listagem 19 mostra o resultado.

Utilizando herança e polimorfismo, analisa-se o método Calcular na classe CalcularEmprestimoStrategy (Listagem 18). Para cada tipo de cálculo que ele produz, no caso 4 (um pra cada condicional, cria-se uma subclasse para a classe CalcularEmprestimoStrategy. Tais subclasses devem conter um método Chamado Calcular, e o seu corpo deve conter um dos tipos específicos de calculo

da lógica condicional em questão. Depois, deve-se modificar a classe CalcularEmprestimoStrategy para abstrata e modifica-se seu método Calcular para abstrato, permitindo que os métodos recém criados nas subclasses o implementem. As Listagens 20, 21, 22, 23 e 24 mostram o resultado destas mudanças.

A refatoração para padrões Substituir Lógica Condicional por Strategy está finalizada. Cumpriu-se o objetivo, que era a imple-mentação do padrão Strategy. O benefício citado na descrição da refatoração era o de simplificar o projeto de código existente. Isto se torna visível se analisado o método CalcularEmprestimo (Listagem 15). A lógica condicional que escolhia qual tipo de

cálculo executar foi diluída no padrão Strategy, onde cada sub-classe de CalcularEmprestimoStrategy fica responsável pela implementação de um método, que por sua vez fica responsável por um tipo de cálculo, e o método CalcularEmprestimo (Lis-tagem 15) ficou como mostra a Listagem 19.

ConclusãoUm dos grandes benefícios dos padrões de projeto está re-

lacionado ao fato de permitir a criação de soluções flexíveis e reutilizáveis. A aplicação do padrão Strategy neste artigo mostrou que o mecanismo criado aumentou a flexibilidade do código a partir do momento que tornou mais simples a inserção de novas estratégias para novos tipos de cálculos, e ao mesmo tempo tornou o código reutilizável, permitindo às estratégias definidas serem reutilizadas em outros projetos.

1. GAMMA, Erich, 2000. Padrões de Projeto: soluções reutilizáveis de software orientado a

objetos, 1ed. Porto Alegre: Bookman, 2000.

2. KERIEVSKY, Joshua. Refatoração para Padrões, 1ed. Porto Alegre: Bookman, 2008.

3. FOWLER, Martin. Refatoração: aperfeiçoando o projeto de código existente, 1ed. Porto Alegre:

Bookman, 2004.

Referências Bibliográficas




Dê

seu Feedback

sob

re esta edição


Antonio Mendes da Silva [email protected]

Professor e consultor em área de tecnologia da informação e comunicação com mais de 20 anos de experiência profissional, é autor do livros Introdução a Programação Orientada a Objetos com C++, Arquitetura de Software, Programando com XML, todos pela Editora Campus/Elsevier, tem mais de 30 artigos publicados em eventos nacionais e internacionais, colunista para Ciência e Tec-nologia pela Revista Espaço Acadêmico com mais de 60 artigos publicados, tendo feitos palestras em eventos nacionais e no exterior. Foi Professor Visitante da University of Texas at Dallas e da University of Ottawa. Formado em Engenharia Elétrica pela Universidade de Pernambuco, com Mestrado em Engenharia Elétrica pela Universidade Federal da Paraíba (Campina Grande), Mestrado em Engenharia da Computação pela University of Waterloo e Doutor em Ciência da Computação pela Uni-vesidade Federal de Pernambuco.

De que se trata o artigo?Apresenta a engenharia de software, destacando sua importância no cenário atual de crescimento econômico mundial e apontando a necessidade de educação continuada de engenheiros de software.

Para que serve?Conscientizar o engenheiro de software da ne-cessidade de criar uma “cultura” de engenharia de software que prioriza documentação ade-quada de software para apoiar rastreabilidade, manutenibilidade e reuso de artefatos de sof-tware. Recomenda engenharia reversa e arqui-tetura de software como componentes para sua formação.

Em que situação o tema é útil?O artigo identi� ca diversos fatos e tendências do segmento de TI, discute cenário atual e apresen-ta recomendações para os pro� ssionais de enge-nharia de software que visam atender a deman-da de desenvolvimento de sistemas de software que satisfaçam restrições de custo, tempo (de desenvolvimento) e qualidade.

Engenharia de SoftwareSobre a Necessidade de Educação Continuada

Engenharia

Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros

Ao longo das últimas décadas o software deixou de ser uma parte ínfima e de custo despre-

zível dos sistemas para se tornar parte determinante e dispendiosa. Hoje em dia, tudo o que você ‘toca’ tem softwa-re, seja no uso doméstico quanto nas organizações. Você encontra software nos caixas das farmácias, no mercado da esquina, naquelas pequenas máquinas que permitem milhões de transações com cartão de crédito e nos aviões que levam a pessoas pelos quatro cantos do mundo.

Incrível e intangível é o software. Isso mesmo, software é um produto intangí-vel, o qual é difícil descrever bem como avaliar. Por outro lado, comparativamente ao hardware é facilmente modificado, tornando as manutenções sejam elas de

caráter corretivo ou evolutivo também mais fáceis. Mas, isso é apenas verda-de se o software tiver seu projeto bem


Neste artigo você encontra o vídeo: “Problemas e suas causas no desenvolvimento de software”.


34 Engenharia de Software Magazine - Engenharia de Software

documentado. Documentação de um projeto é essencial para permitir a manutenção e evolução de um sistema de software. Para tanto, torna-se imprescindível ter ou, se ainda não tiver, criar uma cultura (de engenharia de software) para adotar boas práticas da engenharia de software que compreendem os pilares do de-senvolvimento de software de modo a atender às suas premissas básicas: custo, tempo de desenvolvimento e qualidade.

Engenharia de SoftwareDe acordo com o documento IEEE Std 610.12-1990 que apre-

senta o IEEE Standard Glossary of Software Engineering Terminol-ogy (http://standards.ieee.org/findstds/standard/610.12-1990.html), Engenharia de software é definida como “The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.”

Sabe-se que software não é uma entidade física e, portanto, não sofre qualquer tipo de desgaste (físico) como geralmente acon-tece com o hardware. Entretanto, apesar de não sofrer desgaste físico como o hardware, software está sujeito a modificações que ocorrem durante o ciclo de vida. Essas modificações podem acontecer devido à inserção de defeitos decorrentes do desen-volvimento os quais são geralmente corrigidos antes da entrega do produto. Mas, observe que novos defeitos ainda podem ser (e geralmente são) inseridos devido às modificações que o software sofre devido a sua evolução. Por exemplo, toda vez que uma nova funcionalidade é desejada ou solicitada pelo cliente, torna-se necessário adicionar e/ou modificar as instruções já existentes no software. Como resultado dessas mudanças, novos defeitos podem ser introduzidos e, portanto, pode também causar a deterioração na qualidade do software.

Fases genéricas no desenvolvimento de softwareDentro do contexto discutido acima, é importante observar

que a manutenção é uma das fases que certamente o software irá lidar. Outras duas fases são definição e desenvolvimento, como ilustrado na Figura 1.

Cabe destacar que o desenvolvimento de qualquer produto (como, por exemplo, software) ou artefato, requer do enge-nheiro de software saber quais os passos necessários para alcançar o objetivo de ter o produto pronto (desenvolvido). Isso compreende as fases de definição, desenvolvimento e manutenção, mostradas na Figura 1.

A fase de defi nição engloba a identificação de informações que deveriam ser processadas, funções e desempenho desejados, tipo de interface a ser utilizada, tarefas que o sistema deveria prover suporte, perfil de usuários do sistema, dentre outras.

Figura 1. Fases genéricas no desenvolvimento de software

A fase de desenvolvimento concentra-se no projeto de es-truturas de dados e arquitetura de software do sistema (isto é, como ele está organizado), conversão do projeto para uma linguagem de programação específica (ou seja, implementa-ção), realização de testes e avaliação.

Finalmente, a manutenção considera modificações e/ou correções necessárias no sistema a fim de que este atenda aos requisitos do sistema. Perceba que o processo de desenvolvi-mento de um sistema de software tem duas grandes atividades de interesse que envolve o desenvolvimento da porção de software que implementa as funcionalidades do sistema, e a atividade que a antecede e norteia o desenvolvimento, que é o projeto de software. Esta última atividade é resultado do levantamento e análise de requisitos que provê informações para decisões de projeto.

Necessidade da Engenharia de SoftwareNo contexto atual, qual o nível de necessidade da engenharia

de software?A resposta é: crítico. E, mais ainda, há consequente demanda

por profissionais da área qualificados.A adoção das práticas de engenharia de software é essencial

para assegurar a confiabilidade dos produtos e serviços de software. As práticas compreendem instituir uma ‘cultura’ de engenharia de software, onde a equipe de projeto de sistemas de software esteja comprometida com a documentação de to-dos os artefatos de um projeto de modo a prover suporte a:1. Rastreabilidade2. Manutenibilidade3. Reuso

A fase inicial do desenvolvimento de software na qual ocorre a definição do sistema considera o entendimento dos requisitos desejados além de claramente estabelecer a origem do requisito. Essa informação será fundamental para a rastreabilidade.

Observe que rastreabilidade está relacionada aos relacio-namentos entre os requisitos, as fontes dos requisitos, bem como o projeto de sistema. A rastreabilidade das fontes dos requisitos visa identificar e relacionar os requisitos às partes interessadas (ou stakeholders) daqueles requisitos. Além disso, há o relacionamento en tre os requisitos (isto é, a dependência existente entre eles) e a ligação de requisitos aos componentes do sistema em desenvolvimento.

E, quanto a manutenibilidade?Neste momento, é importante distinguir entre manutenção

que compreende um conjunto de atividades planejadas a fim de realizar mudanças, enquanto que a evolução se refere àquilo que de fato acontece com o software. E, nesse sentido, cabe destacar que à medida que o software tem se tornado quase ubíquo nos sistemas, ele tem também crescido em tamanho (isto é, na quantidade de linhas de código) e complexidade. Perceba que esse crescimento dos sistemas de software requer mecanismos apropriados para documentação, rastreamento, e manutenção.


EngEnHAriA dE SoFt WArE

Por outro lado, o reuso de software pode ser entendido como um processo de implementar e atualizar sistemas de software fazendo uso de software existente. Vale lembrar que software compreende componentes, objetos, requisitos, modelos de projeto, arquitetura, documentação do código, cenários de testes, metas de projeto, manuais. Vale ressaltar que reuso de software pode se dar num sistema de software, num conjunto de sistemas similares ou ainda em sistemas completamente diferentes. Note que reuso de software não é desenvolver um sistema de software desde seu início, mas desenvolver um sistema de software a partir dos componentes de software já existentes. Cabe destacar que a meta de reuso de software é utilizar tanto quanto possível o software resultante de esforços de desenvolvimentos anteriores, visando reduzir os custos, tempo e riscos associados com novos desenvolvimentos.

Cultura de Engenharia de SoftwareInstituir uma ‘cultura’ de Engenharia de Software significa

adotar suas práticas e obter da equipe de projeto um compro-metimento de documentar adequadamente todos os artefa-tos de um projeto. Talvez você possa estar imaginando que dedicar esforço em documentar todos os artefatos produzidos seja um esforço fútil e desnecessário. E, concordo com você se estiver considerando desenvolver um pequeno sistema de software para uma pequena farmácia ou mesmo para o ‘mer-cadinho da esquina’. Tal tarefa pode ser comparada ao esforço de você construir uma casinha de madeira para seu cachorro de estimação. Você, sozinho, pode dar conta do recado.

No entanto, se você tiver a necessidade de informatizar um sistema de uma biblioteca de uma instituição que possui cerca de 10.000 usuários (onde há renovação de quase 2.000 usuários por ano) e tem mais de 50.000 títulos entre livros, revistas e outros itens (com aquisição regular de novos títu-los), então você terá a necessidade de trabalhar em equipe a fim de desenvolver esse software. Aqui, torna-se prudente documentar o projeto. Aqui, documentação não é um ‘luxo’, mas sim uma necessidade, pois tal sistema com certeza terá modificações.

Agora, pode-se considerar uma situação ainda mais extrema de documentação de projeto. Você tem noção de quantas linhas de código há num Boeing 777?

Um Boeing 777 tem mais de 4 milhões de linhas de código (isto é, software) rodando em cerca de 1.300 processadores. Agora, você imagina desenvolver tudo isso sem qualquer planejamento ou documentação de projeto?

Desenvolver um sistema como de uma biblioteca ou similar requer atividades de modelagem para apoiar o projeto, um processo de desenvolvimento com atividades bem definidas, além de ferramentas que automatizem atividades do proces-so. E, isso será ainda mais essencial no desenvolvimento de sistemas de grande porte como, por exemplo, software utili-zado em aviões, sistemas de comércio eletrônico e sistemas de administradoras de cartão de crédito.

Perceba que desenvolvimento de software tem sido e ain-da permanece uma atividade difícil, pois ela requer que o

engenheiro de software considere os elementos influenciadores sobre o software, destacados na Figura 2.

Esse conjunto de ‘forças’ ilustradas na Figura 2 influenciam o software. Todavia, três dentre elas têm impacto determinante sobre o software que compreendem custo, prazo e qualidade (caracterizada pela confiabilidade que constitui atributo es-sencial da qualidade).

Afinal, qual o problema com o software?Falibilidade de software (ou possibilidade de existência de

falhas) e a consequente falta de confiabilidade, além do fato de que software é quase sempre modifi cado, resultando num produto quase sem garantia. Observe que a única certeza que se tem é a de que o software será modificado e, portanto, a documentação do projeto é essencial para permitir a rastrea-bilidade e, mais importante, a manutenibilidade.

Para lidar com essa demanda, a engenharia de software provê um conjunto de procedimentos, formalismos e técnicas que visa a construção de sistemas de software que atendam os requisitos funcionais e não funcionais. Note que a proposta da engenharia de software compreende estabelecer e utilizar princípios de engenharia a fi m de obter software de baixo custo que seja confi ável e opere de maneira efi ciente nas máquinas onde for empregado.

Como há uma certeza de que o software sofrerá modificações, então os artefatos do projeto serão constantemente alterados durante o desenvolvimento de software. Nesse sentido, o desenvolvimento de várias versões do sistema requer que a equipe estabeleça mecanismos para controlar a evolução do software pois, do contrário, a rastreabilidade do que foi alte-rado pode ser comprometida.

Reuso de SoftwareReuso é considerado como uma espécie de ‘palpite’ para o

futuro do software. Perceba que o aumento da produtividade decorrente de uma adoção de cultura de reuso de artefatos de software pode implicar num conjunto de benefícios listados abaixo:• Melhor qualidade;• Maior produtividade;• Melhor uso de recursos;

Figura 2. Influências sobre o software


• Atendimento a demanda de negócios;• Menos tempo para entrega do produto;• Auxílio a questões complexas de sistemas (o reuso de forma sistemática implica numa recuperação de investimento de qualquer tecnologia).

Da mesma forma que se podem identificar as vantagens des-tacadas acima, as empresas podem se deparar com limitações como, por exemplo:• Exige investimento inicial;• Um tanto de ‘aposta’ no futuro;• Pode induzir a erros se não for adequadamente conduzido;• Pode resultar em custos maiores se não for devidamente realizado;• Deve ser empregado de maneira cautelosa em sistemas que requerem confiabilidade operacional.

A certeza que existe de que software é quase sempre modifi-cado requer do engenheiro de software o cuidado de documen-tar adequadamente o projeto para futura manutenção, futura necessidade de rastrear parte dos requisitos do projeto (para adição ou alteração de funcionalidades), além de futuro reuso, implicando em possível redução de custo de desenvolvimento e aumento de produtividade.

Sobre a necessidade de educação continuadaNesse cenário de elevada demanda por software, quais os

componentes de qualificação profissional fundamentais para um engenheiro de software? Perceba que o cenário atual e de décadas vindouras requer educação continuada.

Tecnologia da informação e, mais especifi camente, software tem sido e continuará a ser um produto demandado no mer-cado global. Apesar da volatilidade verifi cada em segmentos do mercado, os cenários indicam crescimento de demanda por software e seus profi ssionais. De acordo com pesquisa da rea-lizada pela Forrester Research, Inc. informa que gastos a nível mundial no ano de 2009 foram de US$ 1,469 bilhões no setor de TI, sendo US$ 362 bilhões referentes a software, havendo previsão que nos anos de 2010 e 2011 os gastos com software serão de aproximadamente US$ 400 e 440 bilhões, como mos-trado na Figura 3. Desse total, quase metade do mercado de software é pertinente aos EUA, enquanto que cerca de 10% do total é pertinente à América Latina.

Dentro do contexto destacado acima, o profissional de enge-nharia de software deve considerar participar de programas de educação continuada de modo a atender a demanda por produtos inovadores, maiores e mais complexos. Nesse sentido, um aspecto de suma importância no projeto de sistemas de sof-tware de grande porte é sua organização a qual é representada como um modelo arquitetural que consiste de componentes computacionais e de conectores que permitem a interação entre esses componentes. Esta percepção corresponde à visão arquitetural de software num projeto de sistema.

É importante também considerar que uma questão antece-dente a importância que a área de arquitetura de software tem no contexto atual diz respeito à natureza do software, bem como seu crescimento em termos de tamanho e complexidade. Vale lembrar que os problemas de desenvolvimento de sistemas de software de larga escala foram inicialmente reconhecidos durante a década de 60. Em razão disto, na década de 70, houve grande atenção dos desenvolvedores e pesquisadores para o projeto de software. Uma das idéias da época era que a atividade de projeto era separada da implementação, bem como exigia notações e técnicas específicas.

Já na década de 80, a pesquisa em engenharia de software deixou o foco em projeto de software e esteve mais concen-trada na integração de projetos, bem como no processo de projeto e gerenciamento de software. Como resultado desse foco de pesquisa, houve o surgimento de várias técnicas de modelagem e projeto de software, sendo essas incorporadas às linguagens de programação. Além disso, houve pesquisa e avanços nos métodos de análise, fazendo uso de técnicas de descrição formais, o que permitiu lidar melhor com problemas de inconsistência e ambiguidades.

No início da década de 90, houve um trabalho de catalogação de padrões de projeto do grupo conhecido como “Gang of Four”. Tais padrões são considerados como experiência de projeto que pode ser reutilizada. Ainda na década de 90, porém em sua segunda metade, a tecnologia baseada em componentes tem ganhado proeminência. Isto pode ser justificado, em parte, de-vido à aceitação das abordagens orientadas a objetos. É impor-tante observar que a abordagem orientada a objetos tem sido difundida com a tecnologia de componentes de software.

Adicionalmente, o desenvolvimento de técnicas de abstração tem sido uma das principais fontes de avanço em termos de desenvolvimento e programação de sistemas de software e a década de 90, notoriamente, marcada pelo surgimento de uma nova disciplina – arquitetura de software, que aponta um conjunto de aspectos discutidos a seguir.

Foco da Disciplina - A disciplina de arquitetura de software tem seu interesse concentrado na organização do software em sistemas de grande porte, diferentemente, do principal foco de interesse em ciência da computação que recai sobre as estruturas de dados e projetos de algoritmos. Dessa forma, arquitetura de software requer notações, técnicas e ferramentas específicas. Num projeto arquitetural de software, os esforços concentram-se na organização do sistema, distribuição dos

Figura 3. Gastos em TI a nível mundial. (Fonte: Global IT Market Report, Forrester Research, Inc., 2010)


EngEnHAriA dE SoFt WArE

componentes, protocolos de comunicação, mecanismos de sincronização e acesso a dados, dentre outros.

Tipo de Representação - Uma descrição de arquitetura de software faz uso de notações baseadas em grafos, onde se tem um conjunto de componentes e conectores interligando esses componentes. Os componentes compreendem unidades de computação que realizam tarefas tais como clientes, servi-dores, banco de dados e objetos. Os conectores atuam como mecanismos de interligação dando suporte à interação entre os componentes. Exemplo disto são as chamadas de procedi-mentos, pipes e protocolos de acesso.

Estilo Arquitetural - Um estilo arquitetural descreve os tipos de componentes e conectores pertinentes a uma família arquitetural bem como características topológicas e semânticas de seus elementos.

Projeto a nível Arquitetural - O projeto arquitetural tem seu foco nos compromissos assumidos durante o projeto, onde o projetista ou arquiteto de software busca casar as propriedades de uma arquitetural a um conjunto de funcionalidades e atri-butos de qualidade desejados no sistema a ser desenvolvido. Esta abordagem difere dos métodos de projeto de software que definem um conjunto de passos que orientam o projetista desde a análise de requisitos até a implementação.

É importante observar que o projeto a nível arquitetural vem para complementar os métodos de projeto, uma vez que no projeto arquitetural é feita a seleção de um estilo arquitetural (ou combinação de estilos) de modo a satisfazer um conjunto de funcionalidades e atributos de qualidade. Não é difícil identificar as contribuições que a disciplina de arquitetura de software tem proporcionado ao processo de desenvolvimento de software. O projeto arquitetural tem papel relevante, principalmente, no desenvolvimento de sistemas de grande porte, pois uma escolha inadequada de uma arquitetura em detrimento de outra pode acarretar em resultados insatisfatórios em termos de desempenho, confiabilidade, interoperabilidade e outros requisitos não funcionais que são diretamente relacionados à arquitetura de software do sistema. Perceba que a arquitetura de software de um sistema atua com um elo entre os requisitos e a imple-mentação. Esta visão é ilustrada na Figura 4.

Fornece ainda uma descrição abstrata do sistema, expondo um conjunto de propriedades e ocultando outras. A arquite-tura de software permite que engenheiros ou arquitetos de software possam avaliar se um sistema pode ou não satisfazer um conjunto de requisitos. Um conjunto de contribuições ao processo de desenvolvimento de software, observadas ao longo da década de 90, são destacadas abaixo.

Compreensibilidade - A arquitetura de software consiste de uma descrição de projeto em nível elevado de abstração, o que simplifica a apresentação e entendimento de sistemas de grande porte. Adicionalmente, um modelo arquitetural ajuda a expor as restrições existentes no projeto.

Natureza Evolutiva - A natureza evolutiva dos sistemas de software requer que haja separação de interesses entre os

arquitetura de software

Implementação

requisitos

Figura 4. Arquitetura como elo entre requisitos e implementação

componentes de um sistema de modo a minimizar o custo e esforço de atualização e manutenção em um sistema. Assim, uma descrição arquitetural pode separar a funcionalidade de um componente de outros levando em conta as formas nas quais esses componentes interagem uns com os outros. Isto permite que modificações nos componentes ou no mecanismo de conexão possam acontecer, possibilitando a adição de novas características e/ou funcionalidades com custos de modifica-ção devidamente estimados.

Reuso - As descrições arquiteturais oferecem suporte ao reuso em múltiplos níveis. Podem-se ter arquiteturas reutili-záveis que fornecem a organização e o modelo de coordena-ção usado em diversos sistemas. Também, tem-se o reuso de componentes que possibilita a reutilização de componentes em vários sistemas. Além disso, pode-se ainda considerar os trabalhos existentes sobre arquiteturas de domínio específico, que oferece suporte ao reuso.

Análise - Uma descrição da arquitetura fornece mais subsídios à análise, possibilitando-se checar a consistência e conformidade com estilo arquitetural. Além disso, é verificado se requisitos não funcionais são suportados pela arquitetura sob análise.

Gerenciamento - Considerar a obtenção da arquitetura de software de um sistema como marco num processo de desenvolvimento constitui em assegurar as possibilidades de expansão do sistema e custos envolvidos, bem como que os requisitos de capacidade operacional do sistema serão atendidos. Caso contrário, se este marco não existe, pode-se deparar com a situação na qual a arquitetura não acomoda futuras expansões no sistema e/ou a capacidade operacional do sistema fica aquém do desejado.

Um aspecto de suma importância a ser considerado é a natu-reza evolutiva do processo de desenvolvimento de software, bem como as novas possíveis aplicações onde software pode ser usado. Esta característica evolutiva do software também precisa ser considerada a nível arquitetural. Nesse sentido, duas prováveis demandas incluem: (i) a crescente necessidade de integração de subsistemas e componentes de software e (ii) o uso de sistemas baseado em rede.

Vale ressaltar que a necessidade de disponibilizar novos produtos, novos serviços e atualizar os existentes em função da demanda e pressão do mercado tem influenciado a forma na qual os sistemas de software são desenvolvidos.


Colocar um novo sistema no mercado com um, dois ou três meses de antecedência em relação aos concorrentes pode sig-nificar o sucesso de um produto e/ou a sobrevivência de uma empresa. Em função deste cenário, tem havido a tendência de adquirir partes do sistema que já tenham sido desenvol-vidas por outros. Isto implica na possibilidade de concluir o desenvolvimento mais cedo de um produto, colocando-o no mercado. Isto, contudo, implica na necessidade de efetuar a integração do sistema. Resultado disto tem sido o interesse por parte de empresas em buscar profissionais qualificados para realizar este trabalho de integração de subsistemas, onde ele desenvolve código de integração, fazendo a ‘colagem’ dos subsistemas e/ou componentes.

ConclusãoEngenharia de software é uma área fascinante, mas consi-

dero que devida atenção não tem sido dada à formação dos profissionais, objetivando conscientizá-los da importância da documentação do projeto. Sem uma documentação adequada de projeto, a rastreabilidade dos artefatos, a manutenibilidade e reuso de software fica comprometida.

Observo que a maioria dos cursos de engenharia de software, tanto a nível de graduação quanto pós-graduação, dedicam nenhuma ou uma ínfima parcela do tempo para a disciplina de engenharia reversa de software, a qual considero como essen-cial na formação do profissional de engenharia de software.

Finalizando, este autor recomenda que a disciplina de en-genharia reversa de software deva fazer parte da grade dos cursos de Engenharia de Software, Computação e correlatos. Por que? Observe que muitas empresas possuem sistemas (legados ou não) que requer manutenção e, para tanto, você engenheiro de software necessita da documentação de projeto.




Dê

seu Feedback

sob

re esta edição

Software and higher educationhttp://portal.acm.org/citation.cfm?id=1107458.1107486

Creating a Software Engineering Culturehttp://www.processimpact.com/articles/culture.pdf

Software Engineering Body of Knowledgehttp://www.computer.org/portal/web/swebok

The Nature of Software: What’s So Special About Software Engineering?http://www.ibm.com/developerworks/rational/library/4700.html

Curriculum Guidelines for Undergraduate Degree Programs in Software Engineeringhttp://sites.computer.org/ccse/

Measuring and Sustaining the New Economy, Software, Growth, and the Future of the U.S Economy: Report of a Symposium (2006)http://www.nap.edu/catalog.php?record_id=11587

Referências

Do contrário, você será obrigado a fazer engenharia reversa a fim de atender a necessidade de evolução do software. Por outro lado, os conceitos e técnicas de engenharia reversa (que serão apresentados em artigo futuro) ajudam a ‘conscientizar’ o profissional da importância de se ter um projeto de software adequadamente documentado.


Rodrigo Oliveira Spínola [email protected]

Editor Chefe – Engenharia de Software MagazineDiretor de Operações - Kali Software (www.kalisoftware.com)Doutor e Mestre em Engenharia de Software pela COPPE/UFRJ. Autor de diversos artigos científicos sobre Engenharia de Software pu-blicados em revistas e conferências renoma-das, dentro e fora do país. Experiência de parti-cipação em mais de 20 projetos de consultoria para diferentes empresas tendo atuado com gerência de projetos, requisitos e testes de software. Implementador certificado do MPS.BR, tendo também experiência atuando junto a empresas certificadas CMMI.

De que se trata o artigo?Este artigo apresenta inicialmente algumas de� nições associadas à engenharia de requisitos e à especi� cação de requisitos através de casos de uso. Em seguida, são apresentados alguns exemplos reais de especi� cação de requisitos utilizando casos de uso. Além disso, este artigo também apresenta algumas de� nições impor-tantes sobre o diagrama de casos de uso e exempli� -cará seu uso através de um exemplo prático.

Para que serve?O objetivo do artigo é explicitar de forma prática como a especi� cação dos requisitos do software

através de casos de uso podem ser efetuadas em um nível de detalhe tal que informações importantes para outras etapas do desenvolvimento como pla-nejamento de testes, projeto e desenvolvimento não sejam omitidas.

Em que situação o tema é útil?O assunto abordado é útil no dia a dia do analista de requisitos na realização de suas atividades.

Especificação de Casos de UsoAprenda através de alguns exemplos reais

Engenharia


A engenharia de requisitos é um termo usado para descrever as atividades relacionadas à

produção (levantamento, registro, vali-dação e verificação) e gerência (controle de mudanças, gerência de configuração, rastreabilidade, gerência de qualidade dos requisitos) de requisitos. A Figura 1 representa essa definição.

Mas o que podemos entender por re-quisitos? Existem diferentes definições encontradas na literatura técnica:• Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir os seus objetivos;• As descrições das funções e restrições são os requisitos do sistema.

Para ter acesso à esse artigo na íntegra acesse o leitor digital:



Neste artigo você encontra o vídeo: “Trabalhan-do com requisitos e casos de uso com a UML”


40 Engenharia de Software Magazine - Entendendo melhor SOA e ESB

Lenildo Morais [email protected]

É analista de sistemas e analista de testes. Atualmente está cursando mestrado no cen-tro de informática da UFPE em engenharia de software com ênfase em testes e qualidade de software.

De que se trata o artigo?Apresentar, através de uma visão geral, os conceitos, diferenças e algumas características de SOA (Service Oriented Architecture) e ESB (Enterprise Service Bus) e como estes podem ser úteis nas empresas que os adotam.

Para que serve?Proporcionar às empresas um maior planejamento para implementação de seus sistemas distribuídos,

possibilitando uma maior integração entre seus mo-delos de negócio.Em que situação o tema é útil?Quando se pretende otimizar os recursos disponí-veis nas empresas, através do reuso de componen-tes e integração de serviços, sobretudo quando se deseja buscar uma aproximação das áreas de negócio e de TI, aumentando a visão e o poder de decisão por parte de seus gestores.

Entendendo melhor SOA e ESBImportantes conceitos para demandas de negócio

Engenharia


As empresas estão percebendo cada vez mais a necessidade de ter e manter suas infraestru-

turas de TI prontas para acompanhar as mudanças do mercado. Este fator implica diretamente no crescimento e na competitividade diante de seus concorrentes, independentemente do segmento de atuação da mesma. Neste contexto, o SOA é uma abordagem arquitetural corporativa que permite

a criação de serviços de negócio inte-roperáveis que podem facilmente ser reutilizados e compartilhados entre as diversas aplicações utilizadas nas empresas.

O Service-Oriented Architecture (SOA), ou Arquitetura Orientada a Serviços, é um estilo de arquitetura utilizado no desenvolvimento de softwares onde uma aplicação é definida como um conjunto de serviços.

Para ter acesso à esse artigo na íntegra acesse o leitor digital:



Neste artigo você encontra o vídeo: “Projeto de Arquitetura de Software“



ArquitEtur A

42 Engenharia de Software Magazine - Entendendo melhor SOA e ESB

Documents

Revista Engenharia de Software 32