Para definir design de software, alguns autores o fazem em dois sentidos distintos: quando design de software é usado como produto e quando é usado como processo. Quando usado no primeiro sentido, o termo design de software indica o produto que emerge do ato (ou processo) de projetar um sistema de software e sendo assim algum documento ou outro tipo de representação do desejo do projetista (ou designer). Esse produto é o resultado das decisões do designer para formar uma abstração do sistema que é desejado no mundo real. Existem diversas formas de como representar essa abstração do sistema. Podemos citar, por exemplo, desenhos usando caixas e setas, textos descritivo, ou ainda uso de linguagens ou ferramentas criadas para este propósito, como linguagens de modelagem de software, redes de petri, pseudocódigo, etc. Já quando o termo é usado no segundo sentido, fazer design indica o processo seguido para se obter um projeto. Esse é um processo que faz parte do processo de desenvolvimento e que é orientado aos objetivos do software. Ele deve ser realizado tendo em mente os diversos stakeholders do sistema e deve ser fundamentado no conhecimento do designer sobre o domínio do problema.

A partir da visão de design como artefato, podemos observar que ele deve descrever diversos aspectos do software para que, assim, possibilite sua construção. Entre estes aspectos, estão:

Podemos perceber que, apesar dos exemplos anteriores descreverem apenas parte do design de dois sistemas, eles mostram boa parte dos aspectos que esperamos no design de um software.

Por fim, citamos uma definição de design que engloba todos estes aspectos:

Definição 1: design de software

"É tanto o processo de definição da arquitetura, módulos, interfaces e outras características de um sistema quanto o resultado desse processo.”3

Projetar os diversos aspectos de um sistema de software é um processo trabalhoso. No entanto, pode proporcionar diversos benefícios.

Design de software permite avaliação prévia. Como desenvolver software custa tempo e dinheiro, não parece sensato alguém investir seus recursos no desenvolvimento de um sistema que não soluciona os problemas propostos pelos interessados. Dessa maneira, a avaliação prévia do sistema se torna imprescindível para garantir que ele alcance os objetivos desses interessados. Como o design descreve diversos aspectos que estarão presentes no sistema quando construído, ele permite esse tipo de avaliação. Além disso, fazer o design de um sistema é, geralmente, mais barato que construí-lo.

Design de software estimula modelagem. Ao modelar um sistema, o designer se concentra no domínio do problema, ignorando temporariamente detalhes menos significativos para se alcançar a solução. Isso facilita na separação da complexidade essencial da complexidade acidental do problema. E, como já dito por Fred Brooks em The Mythical Man-Month, essa separação é benéfica para a qualidade final do sistema projetado.

Design de software envolve planejamento. Uma vez que o design serve de guia para a construção do sistema, o designer deve então antecipar o que será necessário para tanto. Esse planejamento ajuda na estimativa dos diversos custos envolvidos no desenvolvimento do sistema. Entre esses custos, podemos citar:

Design de software facilita a comunicação, pois contém conhecimento sobre o sistema que pode ser gravado, transmitido e discutido entre os interessados. Um caso bem comum é o de apresentar um sistema a novos membros de um time de desenvolvimento. Informações valiosas, como por exemplo, quais os principais módulos e seus diversos comportamentos, lhes podem ser passadas através do design do sistema antes de mostrá-los o código-fonte. Dessa maneira, essas informações de alto nível de abstração ajudarão a situá-los no código posteriormente. No entanto, o design não serve apenas para os desenvolvedores. Um usuário do sistema pode procurar no design informações de um nível ainda maior de abstração, como quais funções o sistema é capaz de realizar, ou qual o desempenho delas.

Por outro lado, design de software também demanda algumas observações importantes.

O problema a ser resolvido pode não permanecer o mesmo durante todo o processo de design. Ao passo que o design é implementado, o cliente, que é o stakeholder interessado em que o software construído solucione um problema em particular, (1) pode mudar de ideia quanto à natureza do problema; (2) pode ter descrito o problema incorretamente; ou ainda (3) pode decidir que o problema mudou ou mesmo que já fora resolvido enquanto o design é feito. Essas possibilidades não devem ser ignoradas durante o desenvolvimento, uma vez que elas podem ocasionar em perda de tempo e dinheiro durante a fase de design ou ainda ocasionar o fracasso no atendimento das necessidades do cliente.

Há diferenças entre o design e o sistema construído a partir dele. O design de um software é apenas um modelo, do qual o nível de detalhes pode não ser adequado para certos tipos de avaliação. Por sinal, avaliar um design insuficientemente detalhado pode levar a resultados errôneos e, consequentemente, há sistemas que não resolvem os problemas da forma esperada. Isso é comum acontecer, por exemplo, quando por erro do projetista, detalhes importantes para a avaliação não são incluídos no design. O exemplo a seguir ilustra um caso em que a avaliação inadequada resultou em um produto com problemas.

Por mais eficaz que um design seja, sua implementação pode não ser. O fato de haver um design bem elaborado para um determinado software não garante que na fase de implementação os desenvolvedores sigam as regras previamente especificadas e que o código produzido reflita fielmente o que foi especificado. Isto é certamente um grande problema na construção de sistemas de software, pois pode acarretar a construção de um produto que não era o esperado, e até mesmo levar ao insucesso em sua construção. Felizmente, na Engenharia de Software existem dois mecanismos que visam diminuir as divergências entre design e implementação. O primeiro mecanismo diz respeito à verificação de software, isto é, verificar se o software foi construído corretamente, se atendeu às especificações do design. Por outro lado, a validação de software está ligada à satisfação do cliente diante do produto, isto é, se o software construído é o desejado, se atende aos requisitos do cliente.

O processo de design tem início com uma necessidade. Se algo é projetado, e consequentemente construído, é porque o produto proveniente do projeto suprirá essa necessidade. Em Engenharia de Software, a necessidade parte do cliente que especifica quais suas necessidades5 e, portanto, quais os objetivos a serem atingidos pelo sistema de software a ser projetado. Assim, o objetivo do processo de design pode ser definido como:

Definição 2: objetivo de design

Aquilo que se pretende alcançar para resolver as necessidades do cliente.

Em design de software, objetivos também são chamados de requisitos. O design se preocupa com dois tipos de requisitos: requisitos funcionais e requisitos não-funcionais. Um requisito funcional especifica a funcionalidade que um sistema exibe.

Definição 3: requisito funcional

É a declaração de uma função ou comportamento providos pelo sistema sob condições específicas.

Em outras palavras, o que o sistema faz para alcançar às expectativas do cliente. Por exemplo, um requisito funcional de um programa de ordenação de números pode ser descrita como sua capacidade de ordenar inteiros; ou, se estamos falando de um sistema de informação de uma locadora de filmes em DVD, temos como requisitos funcionais, entre outros, a capacidade de buscar um filme usando palavras-chave, a capacidade de realizar o aluguel de um ou vários DVDs, ou a capacidade de realizar a devolução de um ou vários DVDs.

Por outro lado, um requisito não-funcional, especifica propriedades ou características que o sistema de software deve exibir diferentes dos requisitos funcionais. Os requisitos não-funcionais são atendidos pelos atributos de qualidade do software.

Definição 4: requisito não-funcional

É a descrição de propriedades, características ou restrições que o software apresenta exibidas por suas funcionalidades.

Em outras palavras, é basicamente como o sistema funcionará. De volta ao exemplo do programa de ordenar números, um requisito não-funcional que podemos mencionar é o tempo de execução da função de ordenação do sistema (por exemplo, é aceitável que o tempo de execução do algoritmo de ordenação tenha uma taxa de crescimento de O(nlogn)O(nlogn), onde n é a quantidade de elementos a serem ordenados). Já no sistema da locadora de filmes, um exemplo de atributo de qualidade é a exposição de algumas de suas funcionalidades via internet (e.g., busca e reserva de filmes através de um site disponibilizado pelo sistema).

Como os requisitos não-funcionais e os atributos de qualidade têm um papel importante na arquitetura do software, nós dedicaremos um capítulo a eles, onde serão descritos, categorizados e exemplificados em detalhes, além de serem relacionados aos stakeholders que os demandam.

O produto de design deve ser viável. Dessa maneira, restrições são as regras, requisitos, relações, convenções, ou princípios que definem o contexto do processo de design, de forma que seu produto seja viável.

Definição 5: restrição de design

A regra, requisito, relação, convenção, ou princípio que define o texto do processo de design.

É importante saber que restrições são diretamente relacionadas a objetivos e que, em alguns casos, eles são até intercambiáveis. No entanto, uma vez que não são apenas os objetivos que guiam o processo de design, é necessário diferenciar objetivos de restrições. Em outras palavras, um sistema pode ter objetivos claros, mas seu design ou algumas alternativas dele podem ser inviáveis devido às restrições.

A seguir, apresentamos dois exemplos que nos ajudarão a entender o papel das restrições no design. No primeiro exemplo, apesar do sistema ter um objetivo claro, seu design não é viável devido a uma restrição.

Já no segundo exemplo, o sistema também tem um objetivo claro. No entanto, uma restrição torna uma possibilidade de design inviável.

Uma alternativa de design é uma possibilidade de solução. Uma vez que problemas de design geralmente possuem múltiplas soluções possíveis, é comum que sejam geradas mais de uma alternativa para a solução de um único problema. Note que o designer não necessariamente documentará todas as possibilidades de solução, mas, ao menos, considerará algumas delas para eleição de uma solução, mesmo que informalmente.

Definição 6: alternativa de design

Uma possibilidade de solução representada em nível de conhecimento.

O que precisamos observar é que o designer deve realizar duas tarefas essenciais após entender os objetivos e restrições envolvidos no problema de design: gerar alternativas de design e eleger a solução do problema dentre as alternativas geradas.

A geração de alternativas é o real desafio para os designers. Diferente dos problemas de decisão, onde alternativas são conhecidas ou buscadas através de métodos conhecidos, problemas de design pedem a criação de alternativas. O processo de criação deve ser controlado por princípios de design, pela experiência e imaginação do designer e deve ser guiado pelos objetivos do produto impostos pelos stakeholders. Alguns princípios essenciais de design serão apresentados ainda neste capítulo.

Já a eleição da solução é simplesmente a escolha de uma dentre as alternativas geradas, desde que essa sirva para a solução do problema. A escolha da solução deve ser realizada baseada em avaliações e experiência.

Devemos observar que a geração de alternativas poderia continuar indefinidamente caso o designer considerasse outros aspectos do problema. Dessa maneira, quando parar a geração de alternativas é um problema também a ser resolvido pelo designer, uma vez que problemas de design geralmente têm um número infinito de soluções em potencial. Essa noção de quando parar o processo de geração de alternativas, certamente, é adquirida com a experiência.

A representação é a linguagem do design. Apesar do real produto do processo de design ser a representação de um sistema de software que possibilita sua construção, descrever o sistema não é o único propósito das representações. A representação também facilita o próprio processo de design, uma vez que ajuda na comunicação dos interessados e também serve como registro das decisões tomadas.

Definição 7: representação de design

A linguagem do processo de design que representa o produto do design para sua construção e também dá suporte ao processo de design como um todo.

A representação facilita a comunicação porque torna as alternativas em produtos manipuláveis, que podem ser comunicados, avaliados, e discutidos, não só por seus criadores, mas também por outros interessados.

É importante observar que existem diversas dimensões a serem representadas numa única alternativa de design. Essas dimensões abrangem comportamento, estrutura, relações entre entidades lógicas e entidades físicas, entre outros. Essas dimensões são normalmente descritas em diferentes tipos de representações, que, em outro momento, serão chamadas de visões.

Para exemplificar representações de design, apresentaremos duas dimensões derivadas do nosso programa-exemplo de ordenação usando duas representações diferentes. A primeira representação, ilustrada pela Figura 2, mostra a dimensão estrutural de uma alternativa de design usando UML6. Examinando essa representação, podemos observar alguns aspectos da solução: como a solução foi decomposta em classes funcionais, como as diversas classes da estrutura se relacionam entre si, ou até em que pontos poderíamos reusar pedaços de software prontos para a construção, desde que implementem as mesmas interfaces descritas na representação. No entanto, devemos também observar que essa representação não é autocontida, uma vez que é necessário conhecimento em UML para entendê-la completamente.

Figura 2: Representação estrutural do programa de ordenação

Já a segunda representação, Figura 3, mostra parte do comportamento do programa de ordenação com alto nível de detalhe. Apesar de não conseguirmos extrair dessa representação a mesma informação apresentada na figura anterior, essa nos permite analisar seu comportamento assintótico em relação ao crescimento do tamanho dos dados de entrada. Além disso, podemos também analisar o espaço consumido na execução do algoritmo.

Figura 3: Pseudocódigo do Merge sort

Ambas as representações mostram aspectos importantes do design de um software. No entanto, os stakeholders envolvidos no seu desenvolvimento podem ainda estar interessados em outros aspectos além da estrutura ou análise assintótica do algoritmo. Por isso, outras representações podem ainda ser necessárias para mostrar outros aspectos do sistema, e é papel do processo de design – e do designer – provê-las.

Por fim, se considerarmos múltiplas versões ao longo do tempo de uma única representação, poderemos observar a evolução das decisões de design feitas ao longo desse período. Assim, se considerarmos as diversas versões obtidas até se alcançar o algoritmo descrito na Figura 3, perceberíamos a evolução desde o merge sort padrão até o merge sort in-place considerado pelo designer. Então, o histórico do design se torna peça fundamental para se entender quais decisões passadas levaram ao estado atual do design e, consequentemente, do sistema.

A solução do design não é nada além do que a descrição que permite desenvolvedores construir um sistema de software a partir dos detalhes especificados por uma ou diversas representações. Suas principais características serão descritas nos parágrafos a seguir.

Definição 8: solução do design

A descrição do design que permite a construção do sistema de software que alcança os objetivos do design.

Soluções de design refletem a complexidade do problema, geralmente por mostrar diversos elementos e relações que compõem o problema. É possível observar essa característica quando, por exemplo, fazendo o design do sistema de informação de uma locadora que já mencionamos anteriormente. Qualquer que seja a solução, ela conterá elementos como filmes, DVDs, clientes ou gêneros de filmes, pois todos eles são inerentes ao problema em questão. No entanto, só os elementos não são o bastante para compor a solução. A solução deve também conter relações do tipo: “um cliente pode alugar um ou mais DVDs”, “um filme pode ter um ou mais gêneros”, ou “um DVD pode conter um ou mais filmes”. Em outras palavras, a solução deve conter relações similares às relações encontradas no domínio do problema. Vale lembrar que, quando diversos elementos têm diversas relações diferentes entre si, a complexidade emerge e é por isso que fazer design é difícil. Adicionalmente, para complicar ainda mais, é comum que os problemas tenham muitos elementos e relações que não são completamente conhecidos.

É difícil validar soluções de design. A complexidade inerente ao problema faz surgir diversos pontos de possível validação em relação aos objetivos de design. No entanto, o problema reside na precisão da descrição dos objetivos. Normalmente, para problemas complexos, objetivos são descritos num alto-nível de abstração que dificulta ou impossibilita bastante a avaliação das soluções.

E, por fim, a maioria dos problemas de design aceita diversas soluções. Isso é algo natural a problemas de design: uma vez que diversas alternativas podem ser geradas a partir de um único problema de design, diversas soluções podem ser obtidas.

Divisão e conquista é uma técnica para resolução de problemas que consiste em decompor um problema em subproblemas menores e independentes a fim de resolvê-los separadamente, para que, posteriormente, as soluções sejam combinadas e formem a solução do problema inicialmente proposto.

A estratégia é baseada na ideia de que atacar um problema complexo por diversas frentes é mais simples e factível de resolução do que tentar resolvê-lo completamente de uma só vez. A técnica de divisão e conquista possui três etapas bem definidas:

Em Ciência da Computação, essa estratégia é muito utilizada no projeto de algoritmos e, normalmente, é instanciada através do uso de recursão, uma vez que os problemas devem ser decompostos e as soluções dos subproblemas devem ser combinadas ao final da execução para compor a solução do problema inicial. Por exemplo, o algoritmo de ordenação mergesort se utiliza dessa técnica para ordenar uma sequência de inteiros de maneira eficiente. Esse algoritmo se baseia na idéia de quem dadas duas sequências ordenadas, é trivial ordená-las em uma única sequência. Portanto, a estratégia do mergesort é particionar uma sequência em várias subsequências até que seja trivial ordená-las, isto é, sequências de dois elementos. Por fim, o algoritmo combina as sequências em uma só sequência ordenada.

No entanto, como este livro foi escrito com foco em arquitetura de software, nada mais apropriado do que trazermos exemplos em nível arquitetural dos assuntos que abordamos. A estratégia de divisão e conquista também é aplicada constantemente em decisões de mais alto nível no projeto de software. Por exemplo, a decisão de organizar uma aplicação web em camadas nada mais é que dividir um problema maior em diferentes níveis de abstração, onde cada camada será responsável por implementar um serviço mais básico e específico (apresentação, lógica de negócio e armazenamento).

Vários são os benefícios providos pela estratégia de divisão e conquista. No nosso exemplo, a divisão da arquitetura em camadas propicia a implementação de cada camada separadamente. Além disso, as camadas podem ser tratadas como componentes reusáveis de software, uma vez que implementam um serviço único e bem definido. Portanto, divisão e conquista também viabiliza o reuso de software.

Abstração é um princípio essencial para se lidar com complexidade. Esse princípio recomenda que um elemento que compõe o design deva ser representado apenas por suas características essenciais, de forma que permita a distinção de outros elementos por parte do observador. Como resultado, temos a representação de um elemento do design mais simples, uma vez que detalhes desnecessários são descartados, facilitando então o entendimento, comunicação e avaliação.

O que poderemos observar é que a maioria das técnicas empregadas por designers ajudam na elevação do nível de abstração do design e, assim, baixam o nível de complexidade da solução.

Encapsulamento está relacionado à ocultação de detalhes de implementação de um elemento de um sistema aos que usarão esse elemento. Fazendo isso, o acoplamento entre os elementos é minimizado e sua contribuição para a complexidade do sistema é restringida às informações que eles expõem.

Encapsulamento pode ser obtido de diferentes maneiras: modularizando o sistema, separando suas preocupações, separando interfaces de implementações, ou separando políticas da execução de algoritmos.

Modularização é a decomposição significativa do sistema em módulos. A modularização introduz partições bem-definidas e documentadas ao sistema ao decidir como estruturas lógicas do sistema serão divididas fisicamente. Podemos citar alguns benefícios da modularização:

A separação de preocupações está fortemente ligada ao princípio da modularização. De certa maneira, a separação de preocupações define a regra para definir os módulos de um sistema: preocupações diferentes ou não-relacionadas devem se restringir a módulos diferentes. Assim, separando preocupações, obtemos benefícios semelhantes aos da modularização.

Acoplamento e coesão são princípios usados para medir se módulos de um design foram bem divididos.

Acoplamento é a medida de interdependência entre módulos de software. Ou seja, quanto mais dependente um módulo A é da implementação do módulo B, maior é o acoplamento entre os módulos A e B. Alto acoplamento implica que (1) os módulos envolvidos serão mais difíceis de entender, uma vez que precisam ser entendidos em conjunto; (2) os módulos envolvidos serão mais difíceis de modificar, uma vez que as mudanças impactarão mais de um módulo; e (3) os módulos envolvidos serão mais difíceis de manter, uma vez que um problema num módulo se espalhará pelos módulos com quem está altamente acoplados.

Por outro lado, coesão é uma medida intramódulo. Ela é a medida da relação entre tarefas realizadas dentro de um mesmo módulo. As tarefas de um módulo podem estar relacionadas entre si por diferentes motivos. Esses motivos são usados para classificar os diferentes tipos de coesão:

Para alcançarmos bons designs, podemos ordenar os tipos de coesão dos mais desejáveis para os menos desejáveis: funcional, sequencial, comunicativa, temporal, procedural, lógica, e coincidente.

Essa técnica realiza a separação de preocupações apresentando uma abordagem simples: ou um módulo deve se preocupar com as decisões sensíveis ao contexto do problema ou com a execução de algoritmos, mas não ambos. Em outras palavras, alguns módulos devem apenas executar algoritmos sem fazer qualquer decisão sensível ao domínio do problema. Essas decisões devem ser deixadas para os módulos específicos para realização dessas decisões e que também serão responsáveis por suprir parâmetros para os módulos de execução de algoritmos.

Essa separação facilita o reuso e manutenção, principalmente dos módulos de algoritmos, uma vez que eles são menos específicos que os módulos de decisões sensíveis a contexto.

A separação entre interfaces e implementações também beneficia a modularização. Essa técnica recomenda a descrição da funcionalidade a ser implementada por algum módulo por meio de contratos, chamados interfaces. Assim, os módulos implementarão as interfaces de forma a comporem o sistema.

Usando essa técnica, o acoplamento entre módulos e seus clientes é diminuído, uma vez que os clientes estarão ligados apenas a interfaces – e não implementações –, e benefícios como facilidade no reuso, melhor entendimento do código, e menor custo de manutenção são alcançados.

Recomendamos o livro Software Design [6], de Budgen, aos interessados em mais informações sobre a teoria em design de software. Dois artigos que apresentam discussões úteis sobre o assunto são Software Design and Architecture – The Once and Future Focus of Software Engineering[11], de Taylor e Van der Hoek, e Conceptual Foundations of Design Problem Solving[10], de Smith e Browne. Inclusive, este último é a nossa referência sobre o arcabouço conceitual de design usado neste capítulo.

Em nível mais prático da execução do processo de design, citamos as seguintes referências: The Mythical Man-Month: Essays on Software Engineering[5], de Brooks, que discute as causas da complexidade que assola o processo de design de software; Software Design: Methods and Techniques[2], que descreve as etapas que podemos encontrar no processo de design; e o Guide to the Software Engineering Body of Knowledge (SWEBOK) [1], que apresenta os níveis de design.

Por fim, citamos referências que descrevem ferramentas e técnicas que podemos usar durante o processo de design.

Sobre a linguagem de modelagem UML, mais informações podem ser encontradas no site do Object Management Group (OMG) [8].

Já sobre técnicas de design, citamos o livro de Booch et al, Object-Oriented Analysis and Design with Applications[3], o de McConnell, Code Complete[7] e o de Buschmann et al, Pattern-Oriented Software Architecture, Volume 1: A System of Patterns[4]. Este último é mais específico ao design arquitetural.