|
 Há
muitos anos que os analistas de negócio, os engenheiros,
os cientistas e outros profissionais que constróem estruturas
ou sistemas complexos, criam modelos daquilo que constróem.
Por vezes, os modelos são físicos, como réplicas à escala
de aviões, casas, ou automóveis. Outras
vezes, os modelos são menos tangíveis, como acontece
com os modelos financeiros, as simulações de mercados,
e os diagramas de circuitos eléctricos. No entanto,
em qualquer dos casos, um modelo serve como abstracção
- uma réplica aproximada da coisa real que vai ser construída.
Porque devemos modelar
algo antes de o construir? Por vezes, esse trabalho
não é necessário. As coisas simples não precisam necessariamente
de um modelo que preceda a sua construção - por exemplo,
um utilitário de conversão de moeda, ou uma macro simples
num processador de texto que abre um conjunto de ficheiros
utilizados de forma rotineira.
Durante muitos anos,
a prática de desenvolvimento de software esteve isenta
de muitas destas questões de modelação. Pela sua própria
natureza, o software pode ser facilmente criado e alterado.
É necessário pouco equipamento e, virtualmente, não
existem custos de construção. Estes atributos promoveram
uma cultura do tipo "faça você mesmo" - imaginar o software,
construí-lo e alterá-lo de acordo com as necessidades.
Na realidade, não existe um sistema "final". Como tal,
para quê tentar conceber um sistema antes de escrever
o código?
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
|
|
