Capítulo 7 – Projeto e implementação
7.4 Desenvolvimento open source
O desenvolvimento open source é uma abordagem de desenvolvimento de software em que o código-fonte de um sistema de software é publicado e voluntários são convidados a participar no processo de desenvolvimento (RAYMOND, 2001). Suas raízes estão no Free Software Foundation (<http://www.fsf.org>), que defende que o códi- go-fonte não deve ser proprietário, mas deve estar sempre disponível para os usuários analisarem e modificarem como quiserem. Havia uma suposição de que o código poderia ser controlado e desenvolvido por um pequeno grupo central, em vez de ser desenvolvido por usuários do código.
Os softwares open source estenderam essa ideia, usando a Internet para recrutar uma população muito maior de desenvolvedores voluntários. Muitos deles também são usuários do código. Pelo menos em princípio, qualquer contribuinte para um projeto open source pode relatar e corrigir bugs e propor novas características e funcionalida- de. No entanto, na prática, sistemas open source de sucesso ainda contam com um grupo de desenvolvedores que controlam as mudanças no software.
O produto open source mais conhecido é, naturalmente, o sistema operacional Linux, amplamente usado como um sistema de servidor e, cada vez mais, como um ambiente de desktop. Outros importantes produtos open source são o Java, o servidor Web Apache e o sistema de gerenciamento de banco de dados mySQL. Os principais com- petidores da indústria da computação, como a IBM e a Sun, apoiam o movimento open source e baseiam seus pro- dutos em software desse tipo. Existem milhares de outros sistemas e componentes open source menos conhecidos que também podem ser usados.
A aquisição de software open source costuma ser bastante barata ou gratuita, pois geralmente é possível baixar esses softwares sem custos. No entanto, se você precisar de documentação e suporte, você pode ter de pagar por isso, embora os custos sejam usualmente bastante baixos. O outro benefício-chave do uso de produtos open source é que sistemas open source maduros geralmente são muito confiáveis. A razão para isso é que eles têm uma grande população de usuários dispostos a corrigir os problemas em vez de os reportar ao desenvolvedor e esperar por novo release do sistema. Os bugs são descobertos e reparados mais rapidamente do que é possível, em geral, com softwares proprietários.
Para uma empresa envolvida no desenvolvimento de software, há duas questões de open source que devem ser consideradas:
1. O produto que está sendo desenvolvido deve fazer uso de componentes open source? 2. Uma abordagem open source deve ser usada para o desenvolvimento de software?
As respostas a essas perguntas dependem do tipo de software que está sendo desenvolvido, bem como dos antecedentes e da experiência da equipe de desenvolvimento.
140 Engenharia de software
Se você estiver desenvolvendo um produto de software para a venda, time to market e redução de custos são críticos. Se você estiver desenvolvendo em um domínio no qual existem sistemas open source de alta qualidade disponíveis, você pode economizar tempo e dinheiro usando esses sistemas. No entanto, se você estiver desen- volvendo software para um conjunto específico de requisitos organizacionais, usar componentes open source pode não ser uma opção. Você pode ter de integrar seu software com sistemas existentes que são incompatíveis com os sistemas open source disponíveis. Mesmo assim, pode ser mais rápido e mais barato modificar o sistema open source do que desenvolver novamente a funcionalidade que você precisa.
Mais e mais empresas de produtos estão usando uma abordagem open source para o desenvolvimento. Seu modelo de negócios não depende da venda de um produto de software, mas da venda de suporte para esse produto. Acredita-se que o envolvimento da comunidade open source permitirá o desenvolvimento de software de forma mais barata e mais rápida e criará uma comunidade de usuários para o software. Porém, repito, isso só é realmente aplicável para produtos gerais de software, e não para aplicações específicas da organização.
Muitas empresas acreditam que a adoção de uma abordagem open source vai revelar informações confiden- ciais de negócios a seus concorrentes, e por isso são relutantes em adotar esse modelo de desenvolvimento. No entanto, se você estiver trabalhando em uma pequena empresa, abrir o código-fonte de seu software poderá tranquilizar os clientes, que serão capazes de apoiar o software caso sua empresa saia do negócio.
Publicar o código-fonte de um sistema não significa que as pessoas da comunidade em geral, necessariamen- te, ajudarão com seu desenvolvimento. Os produtos open source mais bem-sucedidos têm sido os produtos de plataforma, e não os sistemas de aplicação. Há um número limitado de desenvolvedores que possam estar inte- ressados em sistemas de aplicação especializada. Assim, fazer um sistema de software open source não garante o envolvimento da comunidade.
7.4.1 Licenças open source
Apesar de o livre acesso ao código-fonte ser um princípio fundamental do desenvolvimento open source, isso não significa que qualquer um pode fazer o que quiser com esse código. Legalmente, o desenvolvedor do código (seja uma empresa ou um indivíduo) ainda é seu proprietário. Desse modo, em uma licença de software open source, o proprietário pode colocar restrições em como o código é usado, incluindo as condições vinculadas legal- mente (St. LAURENT, 2004). Alguns desenvolvedores open source acreditam que, se um componente open source é usado para desenvolver um novo sistema, esse sistema também deve ser open source. Outros estão dispostos a permitir que seu código seja usado sem essa restrição. Os sistemas desenvolvidos podem ser proprietários e ven- didos como sistemas de código fechado.
A maioria das licenças open source derivam de um dos três modelos gerais:
1. A GNU General Public License (GPL). Essa é a chamada licença ‘recíproca’; de forma simplista, significa que se
você usar um software open source que esteja licenciado sob a licença GPL, você deve fazer um software open source.
2. A GNU Lesser General Public License (LGPL). Essa é uma variação da licença GPL, segundo a qual você pode
escrever componentes que se ligam com código open source sem publicar a fonte desses componentes. No entanto, se você alterar o componente licenciado, você deve publicá-lo como open source.
3. A Berkley Standard Distribution (BSD) License. Essa é uma licença não recíproca, o que significa que você não é
obrigado a republicar quaisquer alterações ou modificações feitas no código open source. Você pode incluir o código em sistemas proprietários que sejam vendidos. Se você usar componentes open source, deve reconhe- cer o criador original do código.
Questões de licenciamento são importantes porque, se você usar o software open source como parte de um produto de software, você pode ser obrigado pelos termos da licença a fazer seu próprio produto como open sour- ce. Se você está tentando vender seu software, você pode querer mantê-lo em segredo. Isso significa que, em seu desenvolvimento, você pode querer evitar o uso de software open source licenciado sob GPL.
Se você está construindo um software que roda em uma plataforma open source, como o Linux, as licenças não são um problema. No entanto, logo que você começa a incluir componentes open source em seu software, é necessário definir os processos e bancos de dados para manter o controle do que está sendo usado e suas con- dições da licença. Bayersdorfer (2007) sugere que as empresas de gerenciamento de projetos que usam código open source devem:
141
Capítulo 7 Projeto e implementação
1. Estabelecer um sistema para manter informações sobre os componentes open source que são baixados e usa-
dos. É preciso manter uma cópia da licença para cada componente que era válido no momento em que foi usado. As licenças podem mudar, de modo que você precisa saber as condições com as quais concordou.
2. Estar ciente dos diferentes tipos de licenças e compreender como um componente é licenciado antes de ser
usado. Você pode decidir usar um componente em um sistema, mas não em outro, porque você pretende usar esses sistemas de diferentes maneiras.
3. Estar ciente dos caminhos da evolução para os componentes. Você precisa saber um pouco sobre o projeto
open source no qual os componentes são desenvolvidos para compreender como eles podem mudar no futuro.
4. Educar as pessoas sobre open source. Para assegurar o cumprimento das condições da licença não é suficiente ter
os procedimentos em dia; você também precisa educar os desenvolvedores sobre código e licenças open source.
5. Ter os sistemas de auditoria em vigor. Os desenvolvedores com prazos apertados podem ser tentados a quebrar
os termos de uma licença. Se possível, você deve ter um software para detectar e encerrar esse procedimento.
6. Participar da comunidade open source. Se você confia em produtos open source, deve participar da comunida-
de e ajudar a apoiar seu desenvolvimento.
O modelo de negócio de software está mudando. É cada vez mais difícil construir um negócio com a venda de sistemas de software especializados. Muitas empresas preferem fazer seu software open source e depois vender suporte e consultoria para os usuários do software. Isso tende a crescer com o uso cada vez maior de software open source e de softwares disponíveis.
PONTOS IMPORTANTES
t O projeto e a implementação de software são atividades intercaladas. O nível de detalhamento no projeto de- pende do tipo de sistema a ser desenvolvido e se está sendo usada uma abordagem ágil ou dirigida a planos. t O processo de projeto orientado a objetos inclui atividades para projetar a arquitetura do sistema, identificar
objetos no sistema, descrever o projeto usando diferentes modelos de objetos e documentar as interfaces dos componentes.
t Vários modelos diferentes podem ser produzidos durante um processo de projeto orientado a objetos. Estes incluem modelos estáticos (modelos de classes, modelos de generalização, modelos de associação) e modelos dinâmicos (modelos de sequência, modelos da máquina de estado).
t As interfaces de componentes devem ser definidas precisamente, de forma que outros objetos possam usá-las. Um estereótipo de interface da UML pode ser usado para definir as interfaces.
t Ao desenvolver um software, você sempre deve considerar a possibilidade de reusar um software existente, como seus componentes, serviços ou sistemas completos.
t O gerenciamento de configuração é o processo de gerenciamento de mudanças para um sistema de software em evolução. É essencial quando uma equipe está cooperando no desenvolvimento de software.
t A maioria dos desenvolvimentos de software é desenvolvimento host-target. Um IDE é usado em uma máquina host para desenvolver o software, que é transferido para uma máquina target para a execução.
t O desenvolvimento open source envolve a disponibilização pública do código-fonte de um sistema. Isso signi- fica que muitas pessoas podem propor alterações e melhorias no software.
LEITURA COMPLEMENTAR
Design Patterns: Elements of Reusable Object-Oriented Software. Esse é o manual original, que apresentou os pa- drões de software para uma vasta comunidade. (GAMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.)
Applying UML and Patterns: An Introduction to Object-oriented Analysis and Design and Iterative Development, 3rd edition. Larman escreve claramente sobre o projeto orientado a objetos, assim como discute o uso da UML. Essa é uma boa introdução ao uso de padrões no processo de projeto. (LARMAN, C. Applying UML and Patterns: An Intro- duction to Object-oriented Analysis and Design and Iterative Development. 3. ed. Prentice Hall, 2004.)
Producing Open Source Software: How to Run a Successful Free Software Project. Esse livro é um guia completo para
142 Engenharia de software
a base do software open source, para as questões de licenciamento e para os aspectos práticos da execução de um projeto de desenvolvimento open source. (FOGEL, K. Producing Open Source Software: How to Run a Successful Free Software Project. O’Reilly Media Inc., 2008.)
Outras leituras sobre reúso de software são sugeridas no Capítulo 16 e no Capítulo 25 (gerenciamento de configuração).
EXERCÍCIOS
7.1 Usando a notação estruturada do Quadro 7.1, especifique casos de uso da estação meteorológica para Relatar
status e Reconfigurar. Você deve fazer suposições razoáveis sobre a funcionalidade necessária.
7.2 Suponha que o MHC-PMS está sendo desenvolvido por meio de uma abordagem orientada a objetos. Dese-
nhe um diagrama de caso de uso mostrando pelo menos seis possibilidades para esse sistema.
7.3 Usando a notação gráfica da UML para classes de objetos, projete as classes de objeto a seguir, identifican-
do atributos e operações. Use sua experiência para decidir sobre os atributos e operações que devem ser associados a esses objetos.
t um telefone;
t uma impressora para um computador pessoal; t um sistema de som estéreo pessoal;
t uma conta bancária; t um catálogo de biblioteca.
7.4 Usando como ponto de partida os objetos da estação meteorológica identificados na Figura 7.5, identifique
outros objetos que possam ser usados nesse sistema. Projete uma hierarquia de herança para os objetos que você identificou.
7.5 Desenvolva o projeto da estação meteorológica para mostrar a interação entre o subsistema de coleta de dados
e os instrumentos que coletam dados meteorológicos. Use diagramas de sequência para mostrar essa interação.
7.6 Identifique possíveis objetos nos sistemas seguintes e desenvolva um projeto orientado a objetos para eles.
Você pode fazer suposições razoáveis sobre os sistemas ao derivar o projeto.
t Um sistema de gerenciamento do tempo e agenda de grupo é destinado a apoiar o calendário de reuniões e compromissos de um grupo de colegas de trabalho. Quando um compromisso que envolve várias pesso- as precisa ser marcado, o sistema localiza uma janela comum em cada um de suas agendas e faz o agenda- mento para esse momento. Se não houver janelas comuns disponíveis, ele interage com o usuário para que este possa reorganizar sua agenda pessoal a fim de criar espaço para o compromisso.
t Uma estação de abastecimento (posto de gasolina) deve ser configurada para operar de forma total- mente automatizada. Os motoristas passam seu cartão de crédito através de um leitor ligado à bomba, o cartão é verificado por comunicação com o computador da empresa de crédito e um limite de com- bustível é estabelecido. O motorista pode, então, colocar o combustível solicitado. Quando a liberação do combustível está completa, a mangueira da bomba é devolvida a seu coldre, e a conta do cartão de crédito do motorista é debitada no valor do combustível. O cartão de crédito é devolvido após o débito. Se o cartão for inválido, a bomba de combustível devolve-o antes de liberar o combustível.
7.7 Desenhe um diagrama de sequência que mostre as interações dos objetos em um sistema de agenda de
grupo quando um grupo de pessoas está organizando uma reunião.
7.8 Desenhe um diagrama de estado da UML mostrando as possíveis mudanças de estado na agenda de grupo
ou no sistema do posto de gasolina.
7.9 Usando exemplos, explique por que o gerenciamento de configuração é importante quando uma equipe
está desenvolvendo um produto de software.
7.10 Uma pequena empresa desenvolveu um produto especializado que se configura especialmente para cada
cliente. Novos clientes geralmente têm requisitos específicos para serem incorporados a seu sistema, e eles pagam para que estes sejam desenvolvidos. A empresa tem a oportunidade de concorrer a um novo contra- to, que deverá mais que dobrar sua base de clientes. O novo cliente também deseja ter algum envolvimento com a configuração do sistema. Explique por que, nessas circunstâncias, para a empresa propreitária do software, pode ser uma boa ideia tornar o software open source.
143
Capítulo 7 Projeto e implementação
REFERÊNCIAS
ABBOTT, R. Program Design by Informal English Descriptions. Comm. ACM, v. 26, n. 11, 983, p. 882-894.
ALEXANDER, C.; ISHIKAWA, S.; SILVERSTEIN, M. A Pattern Language: Towns, Building, Construction. Oxford: Oxford University Press, 1977.
BAYERSDORFER, M. Managing a Project with Open Source Components. ACM Interactions, v. 14, n. 6, 2007, p. 33-34. BECK, K.; CUNNINGHAM, W. A Laboratory for Teaching Object-Oriented Thinking. Proc. OOPSLA’89 (Conference on
Object-oriented Programming, Systems, Languages and Applications), ACM Press, 1989, p. 1-6.
BELLAGIO, D. E.; MILLIGAN, T. J. Software Configuration Management Strategies and IBM Rational Clearcase: A Practical Introduction. Boston: Pearson Education (IBM Press), 2005.
BUSCHMANN, F.; HENNEY, K.; SCHMIDT, D. C. Pattern-oriented Software Architecture. v. 4. A Pattern Language for Distributed Computing. Nova York: John Wiley & Sons, 2007a.
______. Pattern-oriented Software Architecture. v. 5. On Patterns and Pattern Languages. Nova York: John Wiley & Sons, 2007b.
BUSCHMANN, F.; MEUNIER, R.; ROHNERT, H.; SOMMERLAD, P. Pattern-oriented Software Architecture. v. 1. A System of Patterns. Nova York: John Wiley & Sons, 1996.
CARLSON, D. Eclipse Distilled. Boston: Addison-Wesley, 2005.
CLAYBERG, E.; RUBEL, D. Eclipse: Building Commercial-Quality Plug-Ins. Boston: Addison Wesley, 2006. COAD, P.; YOURDON, E. Object-oriented Analysis. Englewood Cliffs, NJ: Prentice Hall, 1990.
GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Design Patterns: Elements of Reusable Object-oriented Software. Reading, Mass.: Addison-Wesley, 1995.
HAREL, D. Statecharts: A Visual Formalism for Complex Systems. Sci. Comput. Programming, v. 8, n. 3, 1987, p. 231-274. KIRCHER, M.; JAIN, P. Pattern-oriented Software Architecture. v. 3. Patterns for Resource Management. Nova York: John
Wiley & Sons, 2004.
MASSOL, V. JUnit in Action. Greenwich, CT: Manning Publications, 2003.
PILATO, C.; COLLINS-SUSSMAN, B.; FITZPATRICK, B. Version Control with Subversion. Sebastopol, Calif.: O’Reilly Media Inc., 2008.
RAYMOND, E. S. The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. Sebastopol. Calif.: O’Reilly Media, Inc., 2001.
SCHMIDT, D.; STAL, M.; ROHNERT, H.; BUSCHMANN, F. Pattern-oriented Software Architecture. v. 2. Patterns for Concurrent and Networked Objects. Nova York: John Wiley & Sons, 2000.
SHLAER, S.; MELLOR, S. Object-oriented Systems Analysis: Modeling the World in Data. Englewood Cliffs, NJ: Yourdon Press, 1998.
St. LAURENT, A. Understanding Open Source and Free Software Licensing. Sebastopol, Calif.: O’Reilly Media Inc., 2004. WIRFS-BROCK, R.; WILKERSON, B.; WEINER, L. Designing Object-oriented Software. Englewood Cliffs, NJ: Prentice Hall,
1990.
CAPÍTULO
1 2 3 4 5 6
7
8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
8.1 Testes de desenvolvimento 8.2 Desenvolvimento dirigido a testes 8.3 Testes de release 8.4 Testes de usuário
Cont
eúdo
Testes de software
Objetivos
O objetivo deste capítulo é introduzir testes de software e proces- sos de testes de software. Com a leitura deste capítulo, você:
t compreenderá os estágios de teste durante o desenvolvimento para os testes de aceitação por parte dos usuários de sistema; t terá sido apresentado a técnicas que ajudam a escolher casos de
teste orientados para a descoberta de defeitos de programa; t compreenderá o desenvolvimento test-first, em que você projeta
testes antes de escrever o código e os executa automaticamente; t conhecerá as diferenças importantes entre teste de componen- tes, de sistemas e de release, e estará ciente dos processos e téc- nicas de teste de usuário.
O
teste é destinado a mostrar que um programa faz o que é proposto a fazer e para descobrir os defeitos do programa antes do uso. Quando se testa o software, o programa é executado usando dados fictícios. Os re- sultados do teste são verificados à procura de erros, anomalias ou informações sobre os atributos não funcionais do programa.O processo de teste tem dois objetivos distintos:
1. Demonstrar ao desenvolvedor e ao cliente que o software atende a seus requisitos. Para softwares customizados,
isso significa que deve haver pelo menos um teste para cada requisito do documento de requisitos. Para softwares genéricos, isso significa que deve haver testes para todas as características do sistema, além de suas combinações, que serão incorporadas ao release do produto.
2. Descobrir situações em que o software se comporta de maneira incorreta, indesejável ou de forma diferente das
especificações. Essas são consequências de defeitos de software. O teste de defeitos preocupa-se com a eliminação de comportamentos indesejáveis do sistema, tais como panes, interações indesejáveis com outros sistemas, pro- cessamentos incorretos e corrupção de dados.
O primeiro objetivo leva a testes de validação, nos quais você espera que o sistema execute corretamente usando determinado conjunto de casos de teste que refletem o uso esperado do sistema. O segundo objetivo leva a testes de de- feitos, nos quais os casos de teste são projetados para expor os defeitos. Os casos de teste na busca por defeitos podem ser
145