Parte I | Parte II | Parte III | Parte IV | Parte V | Parte VI
O que esperamos de um software? Com
certeza, valor. Neste artigo vou falar um pouco sobre a importância do projeto
de software, de como esta atividade agrega valor, e também sobre alguns
critérios que podem ser utilizados para a avaliação do projeto, finalizando com
uma visão geral sobre princípios importantes no uso da orientação a objetos,
denominados SOLID (os quais pretendo
retomar com detalhe nos próximos posts).
O
que esperar do software
Os usuários sempre esperam obter alguma
espécie de valor do software em uso. Esta noção de valor é
determinada pela capacidade do software
em: auxiliar o usuário a fazer algo melhor ou mais rápido ou ambos; o que
significa aumentar a produtividade do usuário e, com isso, aumentar ganhos (de
tempo, de qualidade ou financeiros) e reduzir também retrabalho e desperdícios
(que representa reduzir custos, que também é outra forma de aumentar os
ganhos).
Assim, o valor do software decorre dos ganhos que seu uso pode proporcionar.
Para que o software possa, de fato, possibilitar ganhos, as necessidades do
cliente, vistas em seu contexto, devem ser entendidas com clareza. Mas isto não
basta.
Projeto
de software
Dado um problema para o qual se pretende
obter uma solução por meio de um software, é necessário realizar sua análise e,
depois, o projeto da solução desejadas.
A análise
se ocupa do entendimento do (domínio do) problema e pretende determinar o que
deve ser feito para solucioná-lo. Para tanto a etapa de análise constrói um modelo
conceitual da solução determinada.
O propósito do projeto é determinar
como construir uma solução para o modelo definido pela análise, ou seja, seu
objetivo é definir como tal modelo pode ser construído (ou programado, no caso
do desenvolvimento de software).
A principal diferença entre a análise e o projeto é que a primeira
envolve contato e a discussão com o cliente sobre a construção da solução
conceitual. Já o projeto engloba detalhes relativos ao trabalho do programador,
que em geral, não são de interesse do cliente.
Deve ficar claro que precisamos tanto de um
trabalho de análise, como de projeto, bem feitos. É bastante típico
que seja desejado que a análise e o projeto de software sejam realizados de
maneira rápida, produzindo um software que atenda plenamente as necessidades de
seus clientes, além de ser robusto, seguro e interoperável.
Outra maneira de observar a questão é
procurar as características indesejáveis de um projeto de software, ou seja,
aquilo que identifica um projeto ruim. Um projeto ruim é algo que,
inevitavelmente leva ao software rot.
Software
ROT
A expressão software rot, algo como "software
podre", é semelhante aos termos code rot, bit rot, software
erosion, software decay. Todas as expressões mencionadas descrevem a
percepção do usuário sobre a deterioração da performance ou da funcionalidade
do software ao longo do tempo, que progressivamente reduz sua utilidade, até
que este se torne obsoleto ou inutilizável. Mas como isso pode ser verdade se
um programa de computador não sofre qualquer tipo de envelhecimento físico? A
questão aqui não é física, mas contextual.
Uma das principais causas do envelhecimento
de um software é a evolução do seu contexto de utilização. Um programa pode ser
bem projetado e implementado, atendendo plenamente as necessidades de seus
usuários no momento em que é introduzido no mercado. A percepção nesta situação
é o programa atende ou excede as expectativas existentes. Mas à medida que em
que é usado, é bastante natural que os usuários percebam novas possibilidades
para sua utilização, nem todas sendo atendidas pelo projeto inicial. Agora a
percepção do usuário é que o software, mesmo que ainda bom e útil, poderia ser
melhor. Esta piora da percepção é um sinal de envelhecimento.
Quanto maior o tempo, maior será a
deterioração percebida em função da evolução das condições de uso do software.
Produtos concorrentes que exibam diferenciais, além de defeitos observados no
produto, acelerarão o processo de percepção de deterioração, quando, de fato, o
software continua exatamente o mesmo.
A manutenção contínua do software, no
sentido de corrigir-se os defeitos percebidos e, principalmente, incorporação
de novas funcionalidades evolutivas, possibilitarão restaurar, no todo ou em
parte, a percepção inicial de qualidade.
Sendo assim, a ausência ou insuficiência de
manutenção causa a degradação do software, não em decorrência de envelhecimento
real, mas sim da alterações nos requisitos de uso deste software.
Outro sentido de software rot, e das expressões semelhantes, se refere a implementação
de aplicações que, por conta de deficiências no projeto, na documentação e na
própria manutenção, se tornam uma massa desorganizada de código improvisado que
os desenvolvedores tem dificuldade crescente em manter.
Projetos
de Software::critérios de avaliação
Existem quatro critérios importantes para
avaliar a qualidade de um projeto de software:
- Rigidez;
- Fragilidade;
- Imobilidade; e
- Viscosidade.
Critério da Rigidez
Este
critério representa a imprevisibilidade do impacto relativo a uma mudança. Em um projeto rígido, toda e qualquer alteração causa uma sucessão
de mudanças em módulos dependentes, produzindo um efeito dominó ou cascata,
que representa a propagação indesejada da alteração efetuada. Assim, uma
tarefa, em tese, simples, torna-se um trabalho hercúleo e, com isto os custos
das alterações são imprevisíveis, bem como o tempo necessário para sua
realização.
Critério da Fragilidade
Dizemos
que um software é frágil quando tende a apresentar problemas em muitos pontos
em cada mudança. Ou seja, as alterações efetuadas em um
ponto do software acabam por causar problemas em outros pontos não relacionados
conceitualmente. Assim, em cada reparo o software apresenta novos problemas não
previstos, novamente com implicações negativas no custo e no tempo da
manutenção.
Critério da Imobilidade
Em função
de como um software é projetado, pode se tornar muito difícil, ou quase
impossível, reutilizar partes do software em outros projetos, caracterizando a
imobilidade (as parte de um software não podem ser movidas para outros). Desta
maneira, mesmo os módulos úteis exibem muitas
dependências com outras partes do software, dificultando ou impedindo seu reuso
em outros projetos. Nesta situação, o custo de reescrever (refazer) acaba
sendo menor do que o risco de separação das partes em função da imobilidade
+ rigidez + fragilidade.
Critério da Viscosidade
Também
existem situações onde as deficiências no projeto ou em sua documentação,
acabam estimulando a realização de pequenos consertos improvisados. Tais remendos
(patches) são mais baratos de implementar do que os reparos maiores que
proporcionariam soluções mais efetivas no projeto como um todo. Assim, a preservação consistente do projeto vai se tornando cada
vez mais difícil de idealizar e implementar, tornando-o viscoso.
A razão central de todos esses problemas é
o projeto mal feito, ingênuo, apressado, improvisado ou incompleto.
Bons projetos não são rígidos,
possibilitando alteração que não se propagam no código; não são frágeis,
garantindo que mudanças em um ponto não façam surgir problemas em módulos não
correlatos; nem impõe a imobilidade; pois suas partes podem ser reutilizadas em
outros projetos; muito menos viscosos; favorecendo que a manutenção seja
realizada de maneira adequada. Então, bons projetos requerem conhecimento
técnico, dedicação e, tão importante quanto isso, que práticas ruins sejam
evitadas, enquanto práticas boas sejam adotadas.
Projeto
de Software::características desejadas
Existem algumas características de são
desejadas em qualquer projeto de software, independentemente de seu tamanho ou
complexidade. Aqui podemos destacar dois conceitos centrais na construção de
software: coesão e acoplamento. Além destes, também se
deseja a componibilidade, a independência de contexto e a facilidade para teste.
Projeto
de Software::características desejadas::coesão
O termo coesão (cohesion) foi
definido por Tom DeMarco em 1979 e afirma que:
Cada módulo
deve possuir apenas uma responsabilidade.
Isso implica em dividir as diversas
responsabilidades identificadas na análise e no projeto em módulos distintos,
de maneira que cada um possua apenas as características e funcionalidades estritamente
necessárias à sua responsabilidade.
Num projeto orientado a objetos isto nos
faria pensar sobre:
- Quão bem os métodos e atributos de uma classe se articulam para definir seus propósitos?
- Como uma classe se articula com as outras, sem descaracterizar seus próprios objetivos?
Assim, idealmente no projeto OO, cada
classe deve possuir apenas uma responsabilidade, ficando claro seu
próprio papel e propósito.
As implicações da coesão em um projeto são
boas, pois:
- As alterações necessárias se
concentram em módulos específicos;
- Torna-se mais fácil reutilizar
aquilo que tem funcionalidade claramente delimitada.
Como é provável que a coesão absoluta seja
difícil de obter, deseja-se que seja a maior ou mais alta possível, pois mais
benefícios trará para o projeto durante sua implementação e também durante sua
manutenção.
Projeto
de Software::características desejadas::acoplamento
Esta
outra característica se relaciona às dependências entre os módulos (classes num
projeto OO) de um sistema. Deseja-se que cada módulo possua o menor número
possível de dependências com outros módulos, ou seja, que os módulos sejam o
mais independentes possíveis e, desta maneira, o acoplamento seja pequeno ou
baixo.
As
implicações do baixo acoplamento são:
·
Concentração das alterações em
módulo específicos;
·
Menor a propagação das
alterações efetuadas; e
·
Maior a chance de
reaproveitamento (reuso) dos módulos.
No entanto, deve-se observar que o acoplamento não é um mal em si, pois algum grau de acoplamento é inerente a
criação de um sistema. Se um módulo não depende de nenhum outro, temos
que seu acoplamento é zero. Mas se todos os módulos são assim, não existe um
sistema, mas um amontoado, provavelmente inútil, de classes.
Isto significa que o acoplamento também é a extensão com que duas ou mais partes de um
sistema estão relacionadas para criar mais valor do que partes individuais.
Um grau adequado de acoplamento permite criar um sistema funcional,
compreensível e manutenível.
Projeto::características
desejadas::componibilidade
Deseja-se
que os módulos de um projeto sejam componíveis, ou seja, que possam ser
combinados de maneiras diferentes, produzindo funcionalidades distintas. Esta
característica implica em:
·
Acrescentar novos módulos e,
com isso, novas funcionalidades;
·
Modificar, no sentido de corrigir
ou melhorar, os módulos existentes; e
·
Também facilitar o teste de
cada componente.
O grande valor da componibilidade é o reuso das partes elaboradas para um sistema na
construção de outros sistemas.
Projeto::características
desejadas::contexto
Além do
interesse em criar componentes que possam ser rearranjados e reutilizados,
também se deseja que tal reuso possa ocorrer em contextos diferentes, ou seja,
para auxiliar na solução de problemas existentes em outros domínios.
A independência
de contexto possibilita:
·
Reutilizar os componentes do
projeto para outros propósitos, em domínios diferentes;
·
Reuso ampliado, o que é um
grande benefício.
Projeto
de Software::avaliação das características desejadas
Observando-se em conjunto as
características boas e ruins dos projetos, nota-se que estão correlacionadas.
Muito da rigidez, da fragilidade, da imobilidade e da viscosidade são
decorrentes da multiplicidade de papeis dos módulos existentes (i.e., de sua baixa
coesão) e também da interdependência excessiva entre suas partes (i.e., de seu
alto acoplamento). Tudo decorrência de projetos descuidados nesse sentido.
No projeto orientado a objetos (OO
Design) as classes tem papel fundamental, pois são os elementos
construtivos dos sistemas. Como modificações no escopo de qualquer sistema
são inevitáveis com o passar do tempo, classes bem projetadas permitirão:
- Codificação mais rápida;
- Teste mais abrangente; e
- Manutenção facilitada.
Para projetar boas classes e, com isso,
construir bons sistemas, existem aspectos importantes que podem e devem ser
observados, como indicam os princípios SOLID.
Princípios
SOLID
Em 1995 Robert C. Martin (também conhecido
como Uncle Bob) propôs um amplo
conjunto de princípios de projeto e programação orientada a objetos que,
posteriormente, tornaram-se conhecidos como SOLID, um acrônimo criado por Michael
Feathers para designar os primeiros cinco dos princípios propostos.
A intenção destes princípios é orientar o
programador na construção de sistemas mais fáceis de manter e ampliar com o
passar do tempo, pois sem isso os softwares envelhecem e são percebidos como
deteriorados.
Os princípios enunciados por Martin constituem
um guia para refatoração do código, e também se enquadram nas estratégias ágeis
e na abordagem adaptativa de construção de software.
O acrônimo SOLID é formado por:
- Single Responsability Principle (Parte II)
- Open-Closed Principle (Parte III)
- Liskov`s Substitution Principle (Parte IV)
- Interface Segregation Principle (Parte V)
- Dependency Inversion Principle (Parte VI)
Estes cinco princípios podem ser,
resumidamente, entendidos como segue.
O Single
Responsability Principle ou Princípio
da Responsabilidade Única afirma que uma classe deve ter uma, e apenas uma,
razão para mudar. Assim, cada classe deve representar apenas um ator ou
entidade, devendo ser escrita, modificada e mantida para apenas um propósito
específico.
O Open
Closed Principle ou Princípio
Aberto-Fechado indica que os componentes de um software devem ser abertos
para extensão e fechados para modificação. Isto significa que as classes e
interfaces devem ser pensadas para permitir que sejam estendidas (pela
mecanismo da herança), mas não para modificações nelas próprias.
O Liskov’s
Substitution Principle ou Princípio
da Substituição de Liskov determina que quaisquer tipos derivados (subclasses
ou classes derivadas) devam ser completamente substituíveis por seus tipos base,
de modo que tais substituições sejam transparentes e não causem qualquer erro.
O Interface
Segregation Principle ou Princípio
da Segregação de Interfaces requer que os clientes de módulos de software
não devam ser forçados a
implementar métodos desnecessários que não sejam
usados, reduzindo a burocracia .
O Dependency
Inversion Principle ou Princípio da Inversão de Dependência estabelece a
conveniência de um módulo depender de outros módulos mais abstratos, ao invés
de elementos concretos (de substituição mais complexa).
A aplicação destes cinco princípios permite
melhorar, e muito, a qualidade do software construído para qualquer projeto e,
por isso, cada um merece mais atenção. Mas isto fica para os próximos posts!
Para
Saber Mais
- LARMAN, Craig. Utilizando
UML e padrões: uma introdução à análise
e ao projeto orientados à objetos e ao Processo Unificado. Porto Alegre:
Bookman, 2007.
- MARTIN, R. C.; et. al. Clean Code: a handbook of agile software craftsmanship. Boston:
Pearson Education, 2009.
- MARTIN, R. C. The Clean Coder. Upper Sadle River: Prentice-Hall, 2011.
- MARTIN, R. C. Principles of OOD.
Disponível em http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod,
recuperado em 17/02/2017.
- MARTIN, R. C. Get a SOLID start.
Disponível em http://objectmentor.com,
recuperado em 17/02/2017.
- PAGE-JONES, Meilir. Fundamentos do
Desenho Orientado a Objetos. São Paulo: Makron Books, 2001.
- SOMMERVILLE, I. Software Engineering. 9th. Ed. Boston: Addison-Wesley, 2011.
