| << Chapter < Page | Chapter >> Page > |
Consideremos que um cliente deseje um sistema com um único objetivo: o sistema deve decidir se um programa, cuja descrição é informada como parâmetro de entrada, termina sua execução ou não.
Um designer inexperiente pode até tentar encontrar alguma alternativa de design para esse requisito – mas podemos ter certeza que a tentativa será em vão. Como é bem conhecido, há uma restrição teórica em Ciência da Computação, conhecida como o problema da parada , que impede o desenvolvimento de um programa capaz de alcançar o objetivo proposto. Como essa restrição impede a criação de qualquer alternativa de design que satisfaça o cliente, podemos observar que um design pode ser se tornar inviável mesmo que seus objetivos sejam bem claros.
Já no segundo exemplo, o sistema também tem um objetivo claro. No entanto, uma restrição torna uma possibilidade de design inviável.
Um cliente especifica o seguinte requisito para seu sistema de software: ele deve ser capaz de ler dados de um leitor de cartões de um modelo específico. No entanto, ao estudar o requisito e, consequentemente, o leitor de cartões, o designer encontra a seguinte restrição. O fabricante do leitor em questão não o fornece driver necessário para um dos sistemas operacionais em que o sistema deve executar.
Podemos observar que, se não fosse por essa restrição, o design para o módulo de entrada de dados do sistema seria simples: apenas dependeria do driver do leitor para obter os dados dos cartões. No entanto, agora o designer terá que criar um design alternativo para contornar a restrição encontrada. Para isso, podemos citar algumas possibilidades desse design. Uma possibilidade seria emular um dos sistemas operacionais suportados quando o software estivesse executando num ambiente não suportado. Isso significa que seria necessária a criação de uma camada de abstração entre o driver do leitor e o sistema operacional onde o software está executando, onde essa camada representaria o ambiente operacional suportado. Essa camada de abstração, então, seria implementada pelo sistema nativo ou por um emulado, caso o nativo fosse o não-suportado pelo driver . Outra possibilidade de design seria o projeto e implementação do próprio driver para o ambiente não-suportado.
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.
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.
Notification Switch
Would you like to follow the 'Arquitetura de software' conversation and receive update notifications?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|