Бьерн Страуструп.
Язык программирования С++
285
Очевидно, большая часть рассуждений относится к программным проектам большого объема.
Читатели, которые не участвуют в таких разработках, могут сидеть спокойно и радоваться, что все эти
ужасы их миновали, или же они могут выбрать вопросы, касающиеся только их интересов. Нет нижней
границы размера программы, начиная с которой имеет смысл заняться проектированием прежде, чем
начать писать программу. Однако все-таки есть нижняя граница, начиная с которой можно использовать
какие-либо методы проектирования. Вопросы, связанные с размером, обсуждаются в $$11.4.2.
Труднее всего в программных проектах бороться с их сложностью. Есть только один общий способ
борьбы со сложностью: разделяй и властвуй. Если задачу удалось разделить на две подзадачи,
которые можно решать в отдельности, то можно считать ее решенной за счет разделения более, чем
наполовину. Этот простой принцип применим для удивительно большого числа ситуаций. В частности,
использование модулей или классов при разработке программных систем позволяет разбить программу
на две части: часть реализации и часть, открытую пользователю – которые связаны между собой (в
идеале) вполне определенным интерфейсом. Это основной, внутренне присущий программированию,
принцип борьбы со сложностью. Подобно этому и процесс проектирования программы можно разбить
на отдельные виды деятельности с четко определенным (в идеале) взаимодействием между людьми,
участвующими в них. Это основной, внутренне присущий проектированию, принцип борьбы со
сложностью и подход к управлению людьми,занятыми в проекте.
В обоих случаях выделение частей и определение интерфейса между частями - это то место, где
требуется максимум опыта и чутья. Такое выделение не является чисто механическим процессом,
обычно оно требует проницательности, которая может появиться только в результате досконального
понимания системы на различных уровнях абстракции (см. $$11.3.3, $$12.2.1 и $$13.3). Близорукий
взгляд на программу или на процесс разработки программного обеспечения часто приводит к
дефектной системе. Отметим, что как программы, так и программистов разделить просто. Труднее
достигнуть эффективного взаимодействия между участниками по обе стороны границы, не нарушая ее
и не делая взаимодействие слишком жестким.
Здесь предложен определенный подход к проектированию, а не полное формальное описание метода
проектирования. Такое описание выходит за предметную область книги. Подход, предложенный здесь,
можно применять с различной степенью формализации, и он может служить базой для различных
формальных спецификаций. В тоже время нельзя считать эту главу рефератом, и здесь не делается
попытка рассмотреть каждую тему, относящуюся к процессу разработки программ или изложить каждую
точку зрения. Это тоже выходит за предметную область книги. Реферат по этой тематике можно найти в
[2]. В этой книге используется достаточно общая и традиционная терминология. Самые "интересные"
термины, как: проектирование, прототип, программист - имеют в литературе несколько определений,
часто противоречащих друг другу, поэтому предостерегаем вас от того, чтобы, исходя из принятых в
вашем окружении определений терминов, вы не вынесли из книги то, на что автор совершенно не
рассчитывал.
Достарыңызбен бөлісу: