Escolar Documentos
Profissional Documentos
Cultura Documentos
Edição32 2011
Edição32 2011
Edição32 2011
PS- GRADUAO
Engenharia de Software:
Desenvolvimento Java
Engenharia de Software:
Desenvolvimento .NET
GRADUAO
Engenharia de Computao
Anlise e Desenv. de Sistemas
F ORMAES
Desenvolvedor Java
Desenv. Java: Sist. Distribudos
Gestor de TI
Desenvolvedor Web .NET 2008
MCITP Server Administrator
SQL Server 2008
r/esti
Acesse nosso site e conhea todos os nossos programas: www.infnet.edu.br/esti
TURMAS
NO RIO DE
JANEIRO
www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800
EDITORIAL
impresso no brasil
Corpo Editorial
Colaboradores
Rodrigo Oliveira Spnola
Marco Antnio Pereira Arajo
Eduardo Oliveira Spnola
Capa e diagramao
Romulo Araujo - romulo@devmedia.com.br
Coordenao geral
Daniella Costa - daniella@devmedia.com.br
revisor e Supervisor
Thiago Vincenzo - thiago.v.ciancio@devmedia.com.br
Jornalista responsvel
Kaline Dolabella - JP24185
na Web
www.devmedia.com.br/esmag
Apoio
Atendimento ao leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor.
Se voc tiver algum problema no recebimento do seu exemplar ou precisar de
algum esclarecimento sobre assinaturas, exemplares anteriores, endereo de
bancas de jornal, entre outros, entre em contato com:
isabelle Macedo e uellen goulart Atendimento ao Leitor
www.devmedia.com.br/mancad
(21) 2220-5338
Kaline dolabella
Gerente de Marketing e Atendimento
kalined@terra.com.br
(21) 2220-5338
publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
Cristiany queiroz
publicidade@devmedia.com.br
Caro Leitor,
NDICE
Por trs do bvio
06 Tenho um Chefe difcil: e agora?
Glnio Cabral
Agilidade
08 - Modelagem em uma Viso gil
Lenildo Morais
Desenvolvimento
18 - Modelagem Temporal, de Implantao, de Artefatos e de Componentes
atravs da UML
Geraldo Magela Dutra Gonalves
Tipo: Processo
Ttulo: Especificao de casos de uso na prtica Partes 6 a 10
Autor: Rodrigo Oliveira Spnola
Mini-Resumo: Definir requisitos no uma atividade trivial. Uma das
formas de realizar esta atividade atravs da especificao de casos de
uso. Neste sentido, nesta srie de vdeo aulas apresentaremos um conjunto
de especificaes de casos de uso. Os cenrios sero especificados passo
a passo considerando tpicos como fluxo principal, fluxo alternativo e
regras de negcios.
Engenharia
33 - Engenharia de Software: Sobre a Necessidade de Educao Continuada
Antonio Mendes da Silva Filho
Administrador de Empresas, ps-graduado em Gesto de Pessoas e msico. Idealizador do site de educao infantil www.novainfancia.com.br.
o mercado atual, todos os lderes sabem como motivar suas equipes estabelecendo um timo clima
organizacional, certo? Errado!
Parece estranho, mas ainda h lderes que possuem um
grande talento para promover a desmotivao geral de suas
equipes. Pesquisas apontam que chefes considerados difceis
nunca admitem seus erros, no costumam dar feedbacks, so
ditadores e esto sempre insatisfeitos com o desempenho dos
seus subordinados. Ser que voc, caro leitor, tem sido premiado com um chefe assim? Na dvida, a vo algumas dicas para
que voc saiba lidar melhor com um chefe complicado.
1. Certifique-se de que voc no a nica pessoa a ter
dificuldades de lidar com seu chefe. Lderes que so comprovadamente um problema costumam ser encarados dessa
forma por todos, e no 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 relaes
pessoais tm 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 razo? Ainda assim bater de frente
nunca ser uma boa. V com calma e pelas beiradas.
3. Faa sempre o dever de casa e no d brechas para puxes de orelha. A produtividade e a competncia sempre
sero recompensadas e desejadas, mesmo que seu chefe
seja um Hitler. Seu chefe insensvel e nunca reconhece
seus mritos? Ento d o melhor de si e continue fazendo
seu trabalho com responsabilidade e seriedade, porque no
h chefe que resista ao charme de um bom profissional.
Essa postura de excelncia costuma inclusive abrir portas
para outras possibilidades profissionais.
4. No se envolva em fofocas nem fique falando mal de
seu chefe para os colegas de trabalho. Essas coisas costumam chegar aos ouvidos dele, o que pode tornar a situao
ainda mais difcil. A maledicncia corporativa nunca uma
boa postura profissional. Alm do mais, numa possvel
transferncia de departamento ou de funo a fama de
encrenqueiro s ir dificultar as coisas.
5. Sempre que possvel, solicite do seu chefe o feedback
de suas aes. Se tem algo que os chefes complicados no
se sentem vontade para fazer dar um feedback. Isso
acontece porque eles so pssimos no quesito comunicao, e como dar um feedback basicamente comunicarse, a coisa acaba emperrando. Por isso, em alguns casos
preciso arrancar o feedback do chefe. Atravs desse
retorno o colaborador ter informaes importantes para
aprimorar suas aes e ser mais produtivo. O que, diga-se
Feedback
eu
edio
ta
D
s
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 difceis esto com os dias
contados. No h mais espao para eles num mercado de
trabalho globalizado e dinmico. E segundo, voc pode at
deixar uma empresa por causa de um chefe difcil, mas se for
um bom profissional o mercado de trabalho nunca o deixar.
Siga em frente.
www.devmedia.com.br/esmag/feedback
sobre e
s
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
A
Lenildo Morais
lenildojmorais@gmail.com
Contedo Multimdia!
Neste artigo voc encontra o vdeo: Uma viso
geral da UML.
www.devmedia.com.br/esmag
Agilidade
No entanto, no nosso contexto rascunho um esboo, delineamento, trabalho prvio de redao feito antes de passar
a limpo.
Por alguma razo, profissionais de informtica possuem
um vcio por artefatos digitais. comum ter preferncia
por arquivos que esto em algum lugar do HD. Contudo,
a indstria sobreviveu vrias dcadas sem o computador, e vrias reas de atuao vivem em paz sem o uso
das mquinas. Na rea de desenvolvimento de software
podemos tambm utilizar meios que no so digitais.
Quando falamos em modelagem de um software, uma
das grandes dvidas das equipes de projeto quo longe
devemos nos aprofundar em detalhes. Como ponto de
partida (apoio) podemos nortear nosso raciocnio atravs
de questionamentos como:
1. Qual o nome do projeto?
2. Qual a dvida 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 estamos 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. Logicamente quem ajudar a obter essas respostas o cliente.
Estando, portanto, o analista de requisitos e o cliente reunidos, o ponto principal da reunio ter uma compreenso
em alto nvel do sistema, e no todos os detalhes. No
conveniente nessa reunio discutir as mincias. Detalhes
sero adicionados iterativamente e de maneira incremental
durante todo o projeto.
Modelos tambm so formas de decises ou percepes.
Nesse caso, a forma da percepo das funcionalidades e
deciso do escopo inicial do projeto. Um dos valores da
modelagem gil modelar com um propsito e, muitas
vezes, modelar com um propsito significa buscar os critrios de sucesso do projeto. A modelagem busca atender
ao usurio apresentando qualidade e reduzindo custo
ou prazo do projeto. altamente questionvel quando se
modela s para cumprir etapas do processo ou porque
o processo de desenvolvimento exige tal modelo.
Uma das questes relevantes, vistas anteriormente, Qual
o modelo certo?. importante ressaltar que h uma quantidade infinita de maneiras de se modelar. Um esboo feito de
forma conjunta com as partes interessadas um meio muito
eficiente de capturar requisitos e descobrir como atingir o
objetivo de fazer um software com qualidade externa (ver
Nota 2), que atenda s expectativas dos usurios.
10
Agilidade
11
Concluso
12
Feedback
eu
sobre e
s
Este artigo apresentou que artefatos simples podem ser utilizados para aplicar boas prticas 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.
Referncias
D
s
Prticas Suplementares
Produtividade: Utilizar padres e normas de modelagem,
aplicando padres com sabedoria e reutilizando recursos
existentes;
Documentao: Descartar modelos temporrios, formalizando os modelos de contrato;
Propsito: Modelar para entender e para se comunicar;
Boas Ideias: Conhecer bem as ferramentas, refactoring e
Test-First Design.
edio
ta
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
D
Gabriela de Oliveira Patuci
opgabi@gmail.com
urante muitos anos, as metodologias tradicionais foram utilizadas amplamente pela maioria
dos projetos e das empresas de desenvolvimento de software, e o modelo cascata
era tido como o mais completo e efetivo.
Essa situao se modificou assim que
surgiram os primeiros projetos geis,
logo aps 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 comearam a
aparecer os primeiros estudos de caso
que apresentavam problemas utilizando
tais metodologias e, principalmente, o
13
Conceitos da Metodologia
Antes de apresentar os problemas decorrentes do mau uso
da metodologia citada, faz-se necessrio entender os conceitos
bsicos envolvidos no trabalho com projetos geis e a origem
das ideias que definem o SCRUM.
No ano de 2001, logo aps um encontro onde profissionais
e acadmicos da rea de desenvolvimento de software demonstraram 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 incio
para os principais conceitos das metodologias que viriam a
seguir. Ele foi traduzido para muitas lnguas, inclusive para o
portugus, e citado em vrios artigos da rea de Engenharia
de Software [1].
O Manifesto deu origem a metodologias como XP, Scrum
entre outros e junto com estes conceitos tambm nasceram os
papis envolvidos neste processo. Estes papis so:
Time: Quem realmente desenvolve e produz com qualidade.
Os membros do time devem ser comprometidos com o trabalho
e responsveis por atingir a meta de uma sprint (perodo de
desenvolvimento). Devem ser cada vez mais auto-gerenciveis
e multidisciplinares. Um time normalmente no ultrapassa o
nmero de nove pessoas e atua em um ambiente adequado
afim de facilitar a comunicao 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 noo do produto e das
necessidades do cliente. Responsvel por manter o product
backlog sempre atualizado e priorizar o trabalho das sprints
que viro. Tambm so atividades do PO definir a viso do
projeto, metas e objetivos das sprints e repassar para o Scrum
Master o objetivo do produto;
14
AgilidAdE
15
Estimativas Otimistas
Outro problema frequente que pode ser analisado durante
os projetos geis so as estimativas erradas. Quase sempre,
as estimativas so otimistas e os resultados so catastrficos.
Ser que somos mesmo capazes de fazer o trabalho proposto
em to pouco tempo? Esta uma das perguntas que o time
nunca se faz quando est em meio presso 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 no
faz com que o trabalho fique efetivamente pronto mais rpido,
e o pior, acarreta problemas ainda mais srios como defeitos
em produo e regresso no desenvolvimento do software. O
que deve ser relembrado durante a planning meeting o fato
de quem estima o esforo o time. Scrum Master e Product
Owner devem participar apenas para facilitar a reunio e
solucionar possveis dvidas, respectivamente.
16
agilidade
Concluso
Este artigo apresentou um estudo sobre quais os principais
problemas encontrados em projetos utilizando a metodologia
Scrum.
Foi apresentada uma lista de problemas frequentes, juntamente com a conceituao bsica 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 possveis solues para a maioria das questes citadas, mas claro que seria
necessrio outro artigo para tratarmos das melhores solues
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 necessrios outros estudos voltados
para todas as possveis solues. Precedentes para trabalhos
futuros j comeam a surgir e podero ser verificados em
artigos futuros.
Referncias
[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
Feedback
eu
www.devmedia.com.br/esmag/feedback
17
sobre e
s
D
s
edio
ta
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
Contedo Multimdia!
Neste artigo voc encontra o vdeo: Conhecendo o diagrama de componentes.
www.devmedia.com.br/esmag
18
Engenharia de Software Magazine - Modelagem Temporal, de Implantao, de Artefatos e de Componentes atravs da UML
proJEto
Diagramas de Temporizao
Diagramas de Estados representam os estados possveis
de apenas um objeto e as transies permitidas entre eles.
Diagramas de Atividades so um caso especial de Diagramas
de Estados onde os estados so aes/atividades e podem
representar a participao de diversos objetos. Diagramas de
Temporizao so, tambm, uma variao de diagramas de
estados e de transies entre eles, mas onde tais transies
esto associadas a restries de tempo. Em ltima anlise,
19
20
Comparando Representaes
Uma segunda maneira de representar Diagramas de Temporizao denominada linha de vida de valor. Mais adequada
quando se est lidando com uma grande quantidade de estados e transies, ela mais compacta e concisa, embora exiba
menos informaes do que o formato anterior. A Figura 6
mostra o formato de linha de vida de valor para o caixa eletrnico apresentado. Nela, cada estado representado por
um hexgono e as transies por cruzamentos das linhas de
suas arestas. A escala de tempo pode ser apresentada como
no formato anterior ou pode ser omitida, enquanto restries
de tempo e durao aparecem entre chaves.
Engenharia de Software Magazine - Modelagem Temporal, de Implantao, de Artefatos e de Componentes atravs da UML
proJEto
21
simplesmente arquivos individuais que suportam os elementos lgicos e seus relacionamentos. Assim, existem artefatos
resultantes do trabalho de desenvolvimento, ou seja, o produto
do desenvolvimento. So eles, arquivos fonte e arquivos de dados a partir dos quais sero gerados artefatos de implantao.
Estes, por sua vez, incluem os arquivos executveis, arquivos
de configurao, arquivos de inicializao e bibliotecas, entre
outros. Esse segundo conjunto configura um sistema executvel completo, que suporta totalmente as especificaes lgicas
contidas no primeiro conjunto. Um terceiro e ltimo conjunto
de artefatos inclui aqueles que s tm existncia em tempo
de execuo de um sistema. Podem denominar-se transientes
ou efmeros.
Tais tipos de artefatos podem ser reconhecidos pela colocao
de esteretipos tais como: <<executable>>, um arquivo com
cdigo executvel, <<library>>, uma biblioteca convencional
ou dinmica, <<file>>, um arquivo contento cdigo fonte, ou
<<document>>, um arquivo em formato texto ou outro formato
que contenha uma tabela, um script, entre outros. Na representao de artefatos, o desenvolvedor tem liberdade para criar
e usar esteretipos especficos para identificar artefatos incomuns ou muito particulares de um determinado sistema.
Figura 7. Um artefato
22
Engenharia de Software Magazine - Modelagem Temporal, de Implantao, de Artefatos e de Componentes atravs da UML
proJEto
23
24
Diagramas de Implantao
Sistemas simples, destinados execuo em estaes standalone, tm todos os seus artefatos residentes nessa nica estao.
Mas estes sistemas praticamente no existem mais. Sistemas
modernos de processamento de informaes so baseados
em acesso via web e residem em ambientes de processamento
distribudo, com seus artefatos residindo em diferentes pontos
de uma rede de processamento. Estes pontos so denominados ns de processamento e sua localizao geogrfica j
no necessita fronteiras. Uma rede pode estar, e na realidade
frequentemente est, localizada em diversas locaes, s vezes
em pases diferentes.
Em casos menos extremos, sistemas de mdio a grande
portes podem conter-se em um nico site, mas ainda assim
espalhando-se por diversos servidores diferentes. Para documentar a rede de ns de processamento, assim como determinar a localizao real (fsica) dos diversos artefatos que compe
o sistema, a UML disponibiliza o Diagrama de Implantao
que, entre outras finalidades, representa as localizaes fsicas (ns) e seu contedo (artefatos), exibindo ainda uma srie
de atributos atravs de tags. Um n de processamento uma
localizao fsica que possui alguma quantidade de memria
e freqentemente capacidade de processamento. A notao 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 atribudos
e compartimentos especiais contendo listas de nomes de artefatos residentes naquele n. Na representao da topologia de
um ambiente de processamento surgiro ns com capacidade
de processamento e ns que simplesmente so dispositivos
de armazenamento. Para distinguir entre esses tipos de ns
pode-se utilizar os esteretipos <<device>> para dispositivos,
e <<executionEnvironment>> para processadores.
As conexes entre ns so normalmente representaes de
ligaes fsicas entre os componentes de uma rede, j que os ns
representam exatamente estes componentes. Para obter um diagrama legvel e til no convm representar todos os artefatos
e sim aqueles considerados fundamentais para compreenso
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
lanar mo de todos os elementos dos diagramas de artefatos,
de componentes, de pacotes e de implantao, combinando-os
vontade, para gerar documentao rica e til.
A Figura 14 representa a topologia para o sistema do caixa
eletrnico, as conexes (inclusive as remotas) entre os diversos
ns, e as residncias dos principais artefatos do sistema. SiteBanco representa uma localizao fsica que executa programas
de acesso s bases de dados. O n CaixaEletrnico conecta-se
remotamente ao SiteBanco e estabelece uma colaborao que
desempenhar a funcionalidade requisitada.
Engenharia de Software Magazine - Modelagem Temporal, de Implantao, de Artefatos e de Componentes atravs da UML
proJEto
Dois programas executando no site, exibem um relacionamento com este chamado implantao (deploy). Isto significa
que o n SiteBanco quem implanta os artefatos indicados.
Os programas que rodam nos servidores de aplicao no site
do banco exibem uma dependncia em relao a um pacote
que representa todos os artefatos integrantes de um sistema
gerenciador de banco de dados (SGBD). O n CaixaEletrnico
conecta-se com dois ns auxiliares que esto rotulados como
dispositivos perifricos ou devices. Como os trs ns esto
geograficamente localizados num espao nico, essa conexo
feita por cabos multivias. Estes ns no possuem capacidade
de processamento e eventualmente nem mesmo memria. So
dispositivos auxiliares controlados por drivers. Um ou mais
componentes RotinaAcesso podem ser instanciados durante
uma sesso de execuo do software. Isto est evidenciado atravs de um relacionamento de agregao entre o componente
e o n. Finalmente, o artefato principal, software.class, exibe
um relacionamento com o n CaixaEletrnico denominado
manifestao. Isso significa que o artefato se manifesta atravs
do elemento fsico representado pelo n.
Concluso
Referncias Bibliogrficas
BEZERRA, Eduardo. Princpios de anlise e projeto de sistemas com UML. 2.ed. Rio de Janeiro:
Campus-Elsevier, 2007. 370p.
BOOCH, Grady; RUMBAUGH, James; Jacobson, IVAR. UML: Guia do Usurio. 2.ed. Rio de Janeiro:
Campus-Elsevier, 2006. 474p.
FOWLER, Martin. UML essencial: um breve guia para a linguagem padro de modelagem de
objetos. 3.ed., Porto Alegre: Bookman, 2006. 160p.
Feedback
eu
edio
ta
D
s
BLAHA, Michael; RUMBAUGH, James. Modelagem e projetos baseados em objetos com UML
2.2.ed. Rio de Janeiro: Campus-Elsevier, 2006. 496p.
www.devmedia.com.br/esmag/feedback
25
sobre e
s
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
U
Jacimar Fernandes Tavares
jacimar.tavares@studentpartners.com.br
26
Aborda o tema refatorao para padres com o objetivo de mostrar como o desenvolvedor pode us-lo para
melhorar o cdigo-fonte de suas aplicaes.
Substituir Lgica condicional por Strategy, uma viso geral do que o padro
de projeto Strategy, bem como as tcnicas de refatorao Mover Mtodo (ver
Nota do DevMan1), Introduzir Objeto
Parmetro, Substituir Condicional por
Polimorfismo e Substituir Enumerao
por Subclasse. Ao final ser abordada
a tcnica de refatorao para padres
dESEnvolviM Ento
Nota do DevMan 1
Refatorao Mover Mtodo
A tcnica de refatorao Mover Mtodo foi apresentada no artigo da edio 29 da
Engenharia de Software Magazine.
{
}
{
}
22. {
23.
this.Nome = nome;
24.
this.DataInicio = dataInicial;
25.
this.DataFinal = dataFinal;
26. }
27. }
27
28
O mtodo construtor da classe Dados, Listagem 2, fica responsvel por instanciar o objeto Dados. Os mtodos da classe
Funcionarios, Listagem 1, depois de ter seus parmetros substitudos por um objeto ficam como mostra a Listagem 3.
Aparentemente o resultado da troca de parametros por um
objeto pode no paracer to satisfatrio mas, se aplicado em
classes que possuem vrios mtodos com uma grande lista
de parametros em comum, pode reduzir consideravelmente
o cdigo duplicado.
A refatorao Substit uir comando Condicional por
Polimorfismo.
Esta refatorao pertencente ao grupo de refatoraes classificadas como Simplificando Expresses Condicionais.
Nome da refatorao: Substituir Comando Condicional por
Polimorfismo.
Resumo: Substitui comandos condicionais que selecionam
aes a serem executadas por mtodos polimrficos.
Motivao: Usada para remover expresses condicionais
para um determinado objetivo que se repetem em vrios trechos de cdigo. Com isso, simplifica-se o projeto de cdigo e
removem-se duplicaes.
Mecnica:
Verifique o mtodo que contenha uma sentena switch ou else
ifs. Aplica-se a refatorao Extrair Mtodo para que a expresso
condicional fique sozinha no mtodo, caso necessrio.
Usa-se Mover Mtodo para levar o mtodo que contem a
sentena switch para a superclasse.
Cria-se um mtodo em cada uma das subclasses e cola-se
nele o trecho de cdigo da lgica condicional que se refere
subclasse em questo. Caso a subclasse j possua um mtodo
que possa ser usado para substituir o trecho da lgica condicional, desconsidera-se este passo.
Deleta-se o cdigo da lgica condicional que acabou de
copiar .
Executa-se todos os passos at remover toda lgica
condicional.
Exemplo: A Listagem 4 apresenta a classe Pessoa, que contem
uma sentena switch.
Nota-se que o mtodo RecuperaValorSalario no possue
nada alm da sentena switch, o que descarta a necessidade
de aplicao da refatorao Extrair Mtodo.
O segundo passo portanto requer que o mtodo RecuperaValorSalario seja movido para a superclasse da hierarquia. As
Listagens 5, 6 e 7 mostram a hierarquia referida.
Depois da aplicao do segundo passo da refatorao, a classe
Funcionrio ficar como na Listagem 8.
Nota-se que o mtodo RecuperaValorSalario agora tem um
objeto funcionrio como parmetro. Isso necessrio para que
o mtodo continue funcionando aps ter sido movido para a
classe Funcionario.
O prximo passo consiste em criar mtodos nas subclasses
que tenham as mesmas funes que a logica condicional. O
que quer dizer, por exemplo, que a classe Mensalista deve ter
um mtodo que retorne o salario de um funcionario mensalista
Desenvolvimento
para substituir o case mensalista da sentena switch . Analisando as classes Mensalista e Diarista, perecebe-se que tal mtodo
j existe. Agora, portanto, resta modificar o mtodo RecuperaValorSalario da classe Funcionario para eliminar a lgica
condicional. A Listagem 9 mostra o resultado da mudana.
A refatorao Substituir Enumerao por Subclasses
Esta refatorao pertencente ao grupo de refatoraes classificadas como Organizando Dados.
Nome da r efatorao: Subst it u i r Enu merao por
Subclasses.
Resumo: Substituio de enumeraes por subclasses, pois
enumeraes alteram o comportamento de uma classe.
Motivao: Usa-se esta refatorao para dividir uma classe
que possui caractersticas de uma classe que carrega mais
informao do que normalmente deveria carregar. Substituindo as enumeraes por subclasses, consegue-se clarificar
a inteno do cdigo.
Mecnica:
Analisa-se a enumerao e cria-se uma classe para cada valor
contido na enumerao, tornando-as subclasses da classe que
contm a enumerao.
Deletam-se os campos da enumerao e movem-se as caractersticas que so especficas das subclasses para elas.
Execute os testes.
Exemplo: A classe Pessoa possui uma enumerao chamada
TipoPessoa, onde Alunos representado por 0, e Professores
por 1. A classe Pessoa possui ainda mtodos que realizam
operaes 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
refatorao. A Listagem 10 mostra a classe Pessoa.
Aplicando essa refatorao, parte do cdigo da classe Pessoa
poder ser dividido em duas classes: Alunos e Professores. Assim ser possvel clarificar o cdigo da classe Pessoa, ao mov-lo
para as subclasses. As Listagens 11 e 12 mostram as subclasses
criadas a partir da anlise dos campos da enumerao.
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 especfico para
as respectivas subclasses que, neste caso, implica em mover o
mtodo AlterarSenhaAluno para a classe Alunos e RecuperarNomeProfessor para Professores, conforme Listagens 13 e 14.
Para finalizar, basta apagar a enumerao da classe Pessoa e
ajustar as chamadas enumerao para as novas mudanas.
A partir desse momento, todo cdigo que antes era destinado 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 prticas que
o desenvolvedor precisa para iniciar o processo de aprendizado
sobre a refatorao para o padro Strategy. A partir deste momento ser apresentada a tcnica de refatorao para padres
Substituir Lgica condicional por Strategy.
29
30
Desenvolvimento
1. p
ublic class CalcularEmprestimoStrategy
2. {
1.
2.
3.
4.
5.
6.
7.
3. }
Listagem 17. Classe CalcularEmprestimoStrategy
1.
2.
3.
4.
1. p
ublic class Emprestimos
2. {
3. private CalcularEmprestimoStrategy calcularEmprestimo;
4. public Decimal CalcularEmprestimo(Decimal renda, Decimal taxa)
5. {
6. return calcularEmprestimo.Calcular(renda, taxa);
7. }
8. }
1.
2.
3.
4.
5.
6.
7.
1.
2.
3.
4.
5.
6.
7.
1.
2.
3.
4.
5.
6.
7.
1.
2.
3.
4.
31
clculo executar foi diluda no padro Strategy, onde cada subclasse de CalcularEmprestimoStrategy fica responsvel pela
implementao de um mtodo, que por sua vez fica responsvel
por um tipo de clculo, e o mtodo CalcularEmprestimo (Listagem 15) ficou como mostra a Listagem 19.
Concluso
3. FOWLER, Martin. Refatorao: aperfeioando o projeto de cdigo existente, 1ed. Porto Alegre:
Bookman, 2004.
Feedback
eu
edio
ta
D
s
2. KERIEVSKY, Joshua. Refatorao para Padres, 1ed. Porto Alegre: Bookman, 2008.
sobre e
s
Um dos grandes benefcios dos padres de projeto est relacionado ao fato de permitir a criao de solues flexveis
e reutilizveis. A aplicao do padro Strategy neste artigo
mostrou que o mecanismo criado aumentou a flexibilidade do
cdigo a partir do momento que tornou mais simples a insero
de novas estratgias para novos tipos de clculos, e ao mesmo
tempo tornou o cdigo reutilizvel, permitindo s estratgias
definidas serem reutilizadas em outros projetos.
Referncias Bibliogrficas
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
Engenharia de Software
Sobre a Necessidade de Educao Continuada
Contedo Multimdia!
Neste artigo voc encontra o vdeo: Problemas
e suas causas no desenvolvimento de software.
www.devmedia.com.br/esmag
33
Engenharia de Software
De acordo com o documento IEEE Std 610.12-1990 que apresenta o IEEE Standard Glossary of Software Engineering Terminology (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 no uma entidade fsica e, portanto, no
sofre qualquer tipo de desgaste (fsico) como geralmente acontece com o hardware. Entretanto, apesar de no sofrer desgaste
fsico como o hardware, software est sujeito a modificaes
que ocorrem durante o ciclo de vida. Essas modificaes podem
acontecer devido insero de defeitos decorrentes do desenvolvimento os quais so geralmente corrigidos antes da entrega
do produto. Mas, observe que novos defeitos ainda podem ser (e
geralmente so) inseridos devido s modificaes que o software
sofre devido a sua evoluo. Por exemplo, toda vez que uma nova
funcionalidade desejada ou solicitada pelo cliente, torna-se
necessrio adicionar e/ou modificar as instrues j existentes
no software. Como resultado dessas mudanas, novos defeitos
podem ser introduzidos e, portanto, pode tambm causar a
deteriorao na qualidade do software.
34
A fase de desenvolvimento concentra-se no projeto de estruturas de dados e arquitetura de software do sistema (isto
, como ele est organizado), converso do projeto para uma
linguagem de programao especfica (ou seja, implementao), realizao de testes e avaliao.
Finalmente, a manuteno considera modificaes e/ou
correes necessrias no sistema a fim de que este atenda aos
requisitos do sistema. Perceba que o processo de desenvolvimento de um sistema de software tem duas grandes atividades
de interesse que envolve o desenvolvimento da poro 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 anlise de requisitos que prov informaes
para decises de projeto.
Reuso de Software
Reuso considerado como uma espcie de palpite para o
futuro do software. Perceba que o aumento da produtividade
decorrente de uma adoo de cultura de reuso de artefatos de
software pode implicar num conjunto de benefcios listados
abaixo:
Melhor qualidade;
Maior produtividade;
Melhor uso de recursos;
35
36
Dentro do contexto destacado acima, o profissional de engenharia de software deve considerar participar de programas
de educao continuada de modo a atender a demanda por
produtos inovadores, maiores e mais complexos. Nesse sentido,
um aspecto de suma importncia no projeto de sistemas de software de grande porte sua organizao a qual representada
como um modelo arquitetural que consiste de componentes
computacionais e de conectores que permitem a interao
entre esses componentes. Esta percepo corresponde viso
arquitetural de software num projeto de sistema.
importante tambm considerar que uma questo antecedente a importncia 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 dcada de 60. Em razo disto, na dcada de 70,
houve grande ateno dos desenvolvedores e pesquisadores
para o projeto de software. Uma das idias da poca era que
a atividade de projeto era separada da implementao, bem
como exigia notaes e tcnicas especficas.
J na dcada de 80, a pesquisa em engenharia de software
deixou o foco em projeto de software e esteve mais concentrada na integrao de projetos, bem como no processo de
projeto e gerenciamento de software. Como resultado desse
foco de pesquisa, houve o surgimento de vrias tcnicas de
modelagem e projeto de software, sendo essas incorporadas
s linguagens de programao. Alm disso, houve pesquisa
e avanos nos mtodos de anlise, fazendo uso de tcnicas de
descrio formais, o que permitiu lidar melhor com problemas
de inconsistncia e ambiguidades.
No incio da dcada de 90, houve um trabalho de catalogao
de padres de projeto do grupo conhecido como Gang of Four.
Tais padres so considerados como experincia de projeto que
pode ser reutilizada. Ainda na dcada de 90, porm em sua
segunda metade, a tecnologia baseada em componentes tem
ganhado proeminncia. Isto pode ser justificado, em parte, devido aceitao das abordagens orientadas a objetos. importante observar que a abordagem orientada a objetos tem sido
difundida com a tecnologia de componentes de software.
Adicionalmente, o desenvolvimento de tcnicas de abstrao
tem sido uma das principais fontes de avano em termos de
desenvolvimento e programao de sistemas de software e
a dcada 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 organizao do software
em sistemas de grande porte, diferentemente, do principal
foco de interesse em cincia da computao que recai sobre
as estruturas de dados e projetos de algoritmos. Dessa forma,
arquitetura de software requer notaes, tcnicas e ferramentas
especficas. Num projeto arquitetural de software, os esforos
concentram-se na organizao do sistema, distribuio dos
requisitos
arquitetura de software
Implementao
37
38
Feedback
eu
sobre e
s
Engenharia de software uma rea fascinante, mas considero que devida ateno no tem sido dada formao dos
profissionais, objetivando conscientiz-los da importncia da
documentao do projeto. Sem uma documentao 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 nvel de graduao quanto ps-graduao, dedicam
nenhuma ou uma nfima parcela do tempo para a disciplina de
engenharia reversa de software, a qual considero como essencial na formao do profissional de engenharia de software.
Finalizando, este autor recomenda que a disciplina de engenharia reversa de software deva fazer parte da grade dos
cursos de Engenharia de Software, Computao e correlatos.
Por que? Observe que muitas empresas possuem sistemas
(legados ou no) que requer manuteno e, para tanto, voc
engenheiro de software necessita da documentao de projeto.
Referncias
D
s
Concluso
edio
ta
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
engenharia de requisitos um
termo usado para descrever
as atividades relacionadas
produo (levantamento, registro, validao e verificao) e gerncia (controle
de mudanas, gerncia de configurao,
rastreabilidade, gerncia de qualidade
dos requisitos) de requisitos. A Figura 1
representa essa definio.
Contedo Multimdia!
Neste artigo voc encontra o vdeo: Trabalhando com requisitos e casos de uso com a UML
www.devmedia.com.br/esmag
www.devmedia.com.br/esmag
Edio 32 - Engenharia de Software Magazine
39
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
A
Lenildo Morais
lenildojmorais@gmail.com
Contedo Multimdia!
Neste artigo voc encontra o vdeo: Projeto de
Arquitetura de Software
www.devmedia.com.br/esmag
www.devmedia.com.br/esmag
40
arquitetu r a
41
42