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 [link] , mostra a dimensão estrutural de uma alternativa de design usando UML Unified Modeling Language (UML) . 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.
Já a segunda representação, [link] , 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.
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 [link] , 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.
Soluções
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.
-
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.