Методологические аспекты проектирования
и разработки программных систем

 

Е.Е. Моисеев

 

Введение

 

В наше время компьютерные технологии стали играть важнейшую роль в жизни человека. Компьютерная обработка данных уже давно применяется повсеместно. С каждым днем ожесточается конкуренция среди структур, разрабатывающих программное обеспечение, что порождает целую систему требований к его разработке – от организационных до конкретно-научных и философско-методологических. Так, если раньше созданием программных систем (ПС) занимались преимущественно научно-исследовательские институты или “большие” организации, то сегодня, поскольку компьютер используется во всех сферах человеческой деятельности начиная от управления спутниками и заканчивая компьютерными играми и поскольку повышается компьютерная грамотность населения и появляются все новые высокоуровневые языки программирования, хотя бы простейшим программированием может заниматься любой человек, изучивший тот или иной из этих языков. Тем более, что постоянно требуются все новые и новые программы.

Профессия программиста превратилась из экзотической в повсеместную, причем во многих случаях хорошо оплачиваемую. Постепенно стала проявляться проблема качества программных продуктов. Для повышения эффективности процесса создания программ был разработан ряд систем, которые позволяют достаточно эффективно контролировать процессы их проектирования и создания, управляя такими факторами, как ресурсы (время, затраты) и качество разрабатываемого продукта.

Поводом для написания настоящей работы послужила неожиданная для автора попытка сопоставить процессы проектирования и создания программных систем с аналогичными процессами, происходящими в сфере научных теорий. Конечно, эта попытка была обусловлена не только любопытством по отношению к данной теме, но и желанием почерпнуть наработанные идеи и решения из “уже разработанной” философии науки, и в частности философии научных теорий.

Попробуем проследить основные этапы проектирования и создания ПС, выявить возникающие при этом проблемы и связать их с подобными проблемами, затрагивающими эволюцию научных теорий. Проведем также анализ имеющихся методик и методов программирования для разных (по размеру) программных систем, что, на наш взгляд, дает возможность сделать интересные выводы. Конечно, анализ такого рода основывается на уже существующих системах научного познания, и в частности разработки научных теорий. Объем статьи не позволяет подробно остановиться на деталях каждого подхода, но позволяет оценить ситуацию в целом.

Итак, с чего начинается создание программы и почему вообще стоит браться за этот труд? Предпосылками для разработки программы выступает желание “заказчика” (или потенциального пользователя в случае, когда программа создается без участия конкретного заказчика) получить функциональность, которой нет в уже существующих программных продуктах. Конечно, нередко имеются и другие причины: цена, дальновидность фирмы-разработчика (перспективы развития данного программного продукта) и иные факторы, но мы пока остановимся только на первом  из них – функциональном наборе.

Таким образом, мы имеем ситуацию, когда появляется необходимость в применении пока еще не существующей программы. В этом состоит первое отличие от предпосылок создания новых научных теорий. Развитие науки нельзя объяснить одним определением или предложением. В разное время наука занимала разное место в жизни человечества. Раньше приходилось применять результаты наблюдений и просто замеченных закономерностей без попытки объяснить (описать) что-либо. В наше время, напротив, мало что делается без участия научных достижений в той или иной степени. Разработка абстрактных теорий, которые пока не нашли практического применения, составляет достаточно весомую часть всех научных исследований. В то же время в области разработки программных систем трудно себе представить, чтобы какой-либо коллектив создавал программу “ненужную” с точки зрения настоящего, но с какими-то планами на будущее. Первое, что приходит на ум при обсуждении данной проблемы, – это то, что компании, занимающиеся автоматизацией деятельности человека или просто созданием пользовательских программ, не хотят “терять деньги”, когда их можно, наоборот, заработать (даже с учетом того, что именно в сфере высоких технологий распространено венчурное финансирование, поскольку венчурный капитал тоже предполагает отдачу с определенной долей риска).

Можно заключить, что предпосылки создания программных систем в основном похожи на первые стадии становления научных теорий, т.е. производится только то, что необходимо. Конечно, для обычных программ другой путь разработки скорее всего не нужен, но сегодня в мире все большее внимание уделяется искусственному интеллекту, что может вывести сам процесс проектирования и создания программ на новый качественный уровень.

Автор не зря обратил внимание на сходство и различие между созданием ПС и разработкой научных теорий в самом начале, поскольку именно этот момент является точкой опоры для дальнейших рассуждений.

 

 

Проектирование программной системы

 

Подготовка к созданию конкретной программной системы. Переходя от общих рассуждений к частным проблемам, предположим, что у нас существует заказ на разработку программного комплекса. Как это принято формально, прежде всего заказчик представляет разработчику техническое задание. Конечно, это идеальная ситуация, когда заказчик сам все прекрасно знает и в состоянии написать подробное техническое задание, по которому сделать конкретную программу не составляет труда (основные проблемы уже решены и программа спроектирована с должной детализацией). Однако в реальной жизни такие ситуации бывают нечасто, и техническое задание приходится писать не заказчику, а исполнителю. Плюсом при таком раскладе, безусловно, является профессионализм исполнителя в рамках разработки программных систем, но, к сожалению, нельзя быть профессионалом во всем, поэтому нюансы предметной области, которые в конечном итоге так или иначе влияют на структуру конечного продукта, обычно не входят в сферу знаний конкретного исполнителя. В подобных случаях важно, чтобы заказчик и исполнитель объединили свои усилия и решили основные проблемы, связанные с проектированием структуры и исполнением программного комплекса.

Здесь можно опять обратиться к опыту развития научных теорий. Когда возникает необходимость реализации (проработки) программы исследования конкретной предметной области, ученые используют собственный опыт, накопленный в рамках уже реализованных проектов (“удачной” научной деятельности), и хорошо, если этого достаточно. В наше время, когда в науке наработано уже очень много начиная от отдельных алгоритмов и заканчивая целыми теориями, порой уместным оказывается использование тех или иных алгоритмов, выработанных совсем в другой области (или абстрактной теории). Такие результаты тоже считаются значимыми, поскольку нужно уметь не только разрабатывать теории, но и применять их.

Возвращаясь к разработке программных систем, можно отметить, что в этой сфере существуют проблемы, аналогичные упомянутым выше. Например, участие в проектировании структуры программы такого человека, который имеет опыт в данной предметной области, даже если у него нет навыков работы с конкретным языком программирования, только приветствуется, а часто становится просто необходимым.

Выше была затронута проблема использования “неизвестных” в данной предметной области методик и подходов, но еще раньше, на практике, встает вопрос о применении наработок исполнителя именно в данной области (этот аспект имеет большое влияние на выбор заказчиком исполнителя). Чем больше наработано, тем выше уровень профессионализма команды разработчиков в выбранной предметной области (здесь имеется в виду профессионализм в разработке программ для решения проблем предметной области, а не работа в самой предметной области).

Нужно обратить внимание на то, что наработки не есть “однотипное вещество”, которым можно и нужно решать возникающие при проектировании проблемы. Конечно, накопленный опыт может иметь разные формы и быть в разных состояниях готовности. В процессе разработки программ можно использовать очень широкий спектр готовых решений начиная с методик организации труда и создания рабочей атмосферы для команды программистов и заканчивая уже готовыми программными библиотеками, которые были реализованы на предыдущих этапах работы или в рамках других проектов.

При разработке научных теорий вообще не возникает подобных проблем, поскольку только при условии использования уже готовых частей теории, опоры на них можно продвинуться вперед и таким образом приблизиться к цели. Можно предположить, что разработка “интеллектуальной” части программных систем может достаточно близко соприкасаться с процессом создания (и эволюции) научных теорий.

Правомерно заключить, что нужно пользоваться уже наработанным материалом, но при этом не ограничиваться только уже имеющимся, – такой подход просто тривиален (о нем даже не задумываются) в рамках создания научных теорий, однако он столь же эффективен и при создании программных комплексов. Данный подход особенно плодотворен, когда имеется возможность сделать проект менее требовательным к ресурсам (время, оперативная память) и более масштабируемым, что позволяет использовать ранее не использованные методы.

Продолжая параллельно рассматривать научные теории и программные комплексы, перейдем к этапу проектирования.

Проектирование структуры и внутренних взаимодействий. На данном этапе эволюции программирования как деятельности существенно обострился вопрос “повторяемости кода”, при котором все построение системы разделяется на более мелкие части, наименьшим образом зависящие друг от друга. Такой подход в идеале позволяет единожды реализовать конкретный компонент или конкретную возможность и в будущем использовать наработки в рамках других проектов*. Обсуждению части этой концепции и был посвящен предыдущий раздел.

Продолжая разговор на эту тему, попробуем рассмотреть проектирование системы как процесс правильного разделения сущности программы на более мелкие части, что нередко приводит к хорошей масштабируемости и позволяет сделать каждую из частей программы более универсальной. После удачного внутреннего проектирования почти все компоненты будущей системы, за исключением сугубо специализированных, обладают самостоятельностью в той или иной степени, что значительно увеличивает частоту их повторного использования в следующих проектах.

В процессе проектирования из программы сначала выделяются те части, которые заведомо должны быть разделены (например, подсистема ввода-вывода и т.п.). При принятии этого решения команда проектировщиков руководствуется своим опытом и сопоставляет данную задачу с уже реализованными, выискивая точки их соприкосновения. Тем самым при проектировании одной системы переосмысливаются структура и реализация уже созданных программных систем. Это имеет большое значение, поскольку здесь наблюдается тенденция перехода количественных изменений в качественные.

Похожие проблемы присущи и научным теориям. Когда ученый генерирует “базу” для новой теории, он переосмысливает все то, что он знает и может применить в данном контексте. Это происходит не только в том случае, когда на смену одной научной теории приходит другая (замена старой теории из-за ее несостоятельности), но и когда осуществляется рывок в пока еще неизведанное.

Начинающие программисты (автор сам испытывал подобные ощущения) слишком мало внимания уделяют вопросу “инвентаризации” накопленных знаний. Ведь опыт человека лучше работает, когда его составные части расставлены по местам. Здесь уместно провести аналогию с библиотекой: если библиотека хорошо организована и структурирована, то она эффективно работает, даже имея большой запас литературы, а с другой стороны, неразобранная стопка книг на рабочем столе может заставить подумать об уборке.

Последнее утверждение можно добавить к списку тех, которые справедливы и для научных исследований, и для разработки программных систем.

Обратившись к работам авторов, занимающихся подобными проблемами, можно сказать, что почти все эти авторы придерживаются мнения, согласно которому проектирование и создание программ должны напоминать процесс сборки детской игрушки из деталей конструктора. Интересно, что проектирование всей системы и каждой “детали” соотносится скорее с самими научными исследованиями, а “строительство” программы из “готовых кубиков” напоминает решение конкретных задач (научных или бытовых) при помощи готовых методик. Но если при разработке программных продуктов обе фазы очень часто сливаются в одну, то в случае научных разработок присутствует явное “разделение обязанностей”. Возможно, именно такая расстановка сил и повлияла на качество производимых сегодня программ, не удивляющих своими ошибками даже начинающего пользователя. Организации, которые могут себе позволить осуществлять мероприятия по повышению качества производимых ими программных продуктов (а самое главное, делают это с должным акцентом), встречаются не так часто, как хотелось бы, поскольку в случае разработки программ все упирается в деньги, тогда как научные исследования, особенно фундаментальные, в меньшей степени зависят от этого сдерживающего фактора. К этому вопросу мы еще вернемся в конце статьи, а пока перейдем к другим проблемам проектирования.

Моделирование. В рамках научных исследований ученые проводят опыты, выявляют закономерности и строят теории, основываясь на модельном представлении явления. Всегда приходится пренебрегать теми или иными факторами, которые незначительно влияют (или вообще не влияют) на общую картину в конкретной изучаемой ситуации. Одновременно с построением научной теории строится и ее модель, т.е. то модельное представление явления, описание которого заключает в себе разработанная теория. Без такого упрощения нельзя было бы вообще что-либо изучать и объяснять, поскольку каждое из исследуемых явлений оказалось бы очень сложным клубком взаимосвязей различных факторов.

Подобный подход необходим и при разработке программных систем, но в этом случае причины его применения немного другие. Прежде всего нужно отметить, что в подготовленном техническом задании обязательно описано не только то, что нужно сделать, но и то, как это нужно сделать или как готовый программный продукт должен работать. Это оставляет свой отпечаток именно на проектировании программы, поскольку почти все ее параметры можно предсказать, имея только спроектированную структуру. В данном аспекте процесс проектирования можно сопоставить с моделированием, или построением модели, а реализацию программы – с конкретным опытом (экспериментом). Если придерживаться такого мнения, то получается, что значение любого проектирования очень велико, поскольку именно проектирование определяет границы возможного в рамках конкретной реализации программы.

Сопоставив проектирование с подготовкой базы для научной теории, можно продолжить эту цепочку аналогий и рассмотреть идеальную ситуацию, когда готовый продукт (программа) составляется из слабо связанных между собой частей. Обычно в качестве составных частей выступают программные библиотеки (ПБ), ориентированные на широкий круг задач, обладающих той или иной степенью универсальности. Если взять за основу такое назначение программных библиотек, то сразу наблюдается сходство между ПБ и теоретической частью науки, поскольку для того чтобы использовать уже готовую библиотеку в своих нуждах, надо иметь соответствующую ПБ, которая подходила бы по функционально­сти для выбранного конкретного использования. Универсальность определяется главным образом при проектировании такой библиотеки, но немаловажное значение имеет и ее конкретная реализация, поскольку именно ПБ и будет использоваться при построении программных систем.

Следует отметить, что степень универсальности и абстрактности программного модуля (некоторой единицы измерения в программировании) может существенно изменить его значение и предназначение. Поэтому программирование (вместе проектирование и реализация) какого-либо модуля должно сильно зависеть от того, чтó именно нужно реализовать и с какой целью. Очень часто именно про цель программисты забывают, а это влечет за собой необходимость перепроектирования и повторной реализации неудачно сделанных частей программы. Хорошим подтверждением того, что программисты зачатую не думают о подобных последствиях, является мнение о том, что каждую часть программы нужно переписывать полностью как минимум три раза. Между тем подобная методика расточительна и может быть изменена на совершенно противоположную с целью повышения качества и скорости выработки готовых программных продуктов.

Идеология программных систем. При создании новой теории всегда используется какой-то набор аксиом, или заведомо истинных утверждений, которые могут быть и ложными в перспективе, но в жизненном цикле данной теории считаются истинными. Для проектирования любой программы или системы характерно то же самое.
В самом простом случае в качестве базы для начала проектирования берутся уже известная модель или ее части, обобщая которые можно получить модель новой системы.

Такой подход хотя и прост, но применяется редко из-за плохой “повторяемости кода”, т.е. при отсутствии существующих в других проектах идей невозможно построить новую модель. Как же поступают в этом случае? В подобных ситуациях сначала стараются как можно глубже понять предметную область (впрочем, это делается всегда), после чего становится возможным сформулировать стартовый набор идей или аксиом, а в некоторых случаях даже построить отдельные части модели, которые будут использованы в ходе дальнейшего проектирования.

Разделяя становление научных теорий и процесс проектирования программных систем, можно отметить, что поскольку программирование в известном смысле не есть предметная область сама по себе, постольку при проектировании возможен “старт с нуля”, когда программист не обладает знанием практически ни о никаких свойствах новой системы.

Помимо стартового набора начальных данных существуют еще и ограничения (кстати, это характерно, пожалуй, только для процессов программирования). К подобным ограничениям можно отнести такие свойства будущей системы, как

– совместимость с существующим программным и аппаратным обеспечением;

– поддержка мультиплатформенности, т.е. множества операционных систем. В этом случае логика программы должна оставаться одинаковой для разных платформ и зависимость в идеале проявляется только в ходе конкретной реализации программы;

– ориентация на определенный слой пользователей;

– строго определенный пользовательский интерфейс. Это свойство вообще имеет мало общего с наукой, поскольку касается удобства использования программного продукта.

Приведенный перечень можно расширить, но основная идея и так понятна: при проектировании проектировщик не имеет такой свободы, как исследователь, будучи лимитированным некоторым набором ограничений, наложенных техническим заданием (заказчиком). Этот фактор существенно влияет на проектирование всей системы в целом, особенно если не поддерживается хорошая “повторяемость кода”.

 

 

Неоднозначность реализации

 

Еще одно различие между разработкой программных систем и созданием научных теорий заключается в существовании или отсутствии неоднозначных реализаций. Рассмотрим ситуацию, когда у программиста имеются разные инструменты, с помощью которых он делает почти одно и то же, но с некоторыми различиями. Эти различия могут иногда существенно влиять на выбор того или иного компонента, и хорошо, если выбор в конечном итоге детерминирован. Нередко имеют место ситуации, когда выбор между двумя или несколькими компонентами не может увенчаться успехом, т.е. не может быть однозначно выбран один из них. Обычно программист попадает в такое положение не потому, что на данный момент существует слишком много реализаций именно этого компонента. Являясь специалистом в данной области, он без труда может выявить положительные и отрицательные стороны всех компонентов, что обеспечит однозначность выбора. Иначе поворачиваются события, когда программист не имеет опыта в предметной области компонента, но хочет использовать его функциональность. Такое использование обычно называется “черным ящиком”, поскольку у программиста или нет возможности “посмотреть” внутрь компонента или не хватает для этого знаний (подобная ситуация все чаще возникает при появлении языков программирования высокого уровня).

В случае с научными теориями такой проблемы не существует. Если кем-то однажды открыт какой-то факт или разработана теория, которая на данный момент не имеет опровержения, то любой исследователь, узнавший о соответствующем достижении, сможет применить его в своих исследованиях (здесь не идет речь о тех результатах, которые патентуются).

Рассматривая программирование именно в плане использования сторонних компонентов, можно сказать, что наиболее приближены к идее свободного использования достижений разработки “свободно распространяемого программного обеспечения” (СРПО). Само по себе СРПО имеет определенные ограничения, что позволяет контролировать качество производимого продукта. Часто СРПО распространяется именно с исходными кодами, что более способствует его разно­образному использованию.

Если говорить об эффективности создания СРПО, то, по мнению автора, такие подходы в программировании должны существовать, поскольку создание подобного программного обеспечения очень похоже на научно-исследовательскую деятельность, а значит, большую роль играет фактор идейной заинтересованности, а не финансовой, что переводит программирование совсем в другое русло. Здесь хотелось бы зафиксировать внимание на том факте, что какая-то часть деятельности программистов схожа с научно-исследовательским процессом.

 

 

Тестирование

 

Этап тестирования очень важен для всего технологического процесса создания программных комплексов. Уже давно крупные организации, занимающиеся разработкой программ, уделяют тестированию большое внимание. К сожалению, не все разработчики вовремя встраивают элементы проверки программных проектов в процесс разработки, что, несомненно, могло бы существенно улучшить качество производимых продуктов.

Первый вопрос, связанный с тестированием, – это вопрос его своевременности и необходимости. Существует несколько систем организации труда программистов и соответственно несколько типов его регламента. В рамках одного типа тестирование является этапом программирования (чаще всего одним из самых последних), в рамках другого оно осуществляется на протяжении всего процесса, в рамках третьего для тестирования выделяется специальная группа людей – тестеров, которая занимается исключительно проверкой производимого программного обеспечения. Интересно, что тестеры получают заработную плату, в несколько раз большую, чем зарплата программистов, что показывает степень заинтересованности компаний в качестве программных продуктов. К сожалению, такая организация тестирования встречается очень редко, даже у крупных компаний, поскольку для того чтобы содержать отдельную команду тестеров, необходимы средства, которых или нет, или их жалко отдавать. Но независимо от того, как компании организуют контроль качества, ясно, что тестирование является важным этапом в производстве программного обеспечения.

Рассмотрим теперь проблему тестирования применительно к созданию научных теорий. И в процессе создания новой теории, и при получении менее значимого результата ученому требуется постоянно соизмерять формулируемую теорию, другие получаемые результаты с уже существующими. Это вынуждает научных работников заниматься “тестированием” своих достижений. Важно отметить, что в роли тестеров кроме самого исследователя выступают остальные члены научного сообщества. Как известно, научный результат фиксируется, если он был опубликован, что однозначно отражается на процессе исследования. Эффективность научного поиска существенно зависит от того, насколько оперативно публикуются открытые результаты. Здесь мы опять приходим к ситуации, когда сообщество ученых представляется как единый организм, объединяющим началом в котором служат общие цели. В отличие от науки производство программного обеспечения не имеет такой гибкости, и потому требуется обращать особое внимание на организацию труда в этой сфере и контроль качества.

Завершая обсуждение этого момента, следует еще раз упомянуть о производстве “свободно распространяемого программного обеспечения”. В связи с тем, что производство СРПО зачастую не сулит финансовых выгод, этот процесс регулируется отдельно. Для того чтобы получить подобный статус, необходимо осуществить ряд мероприятий, связанных именно с контролем качества сторонними специалистами. Конечно, речь идет не об организации труда (если не имеются в виду большие проекты), но все же о жесткой отчетности. Последняя обеспечивает хорошее качество, поскольку каждый может проверить или просто посмотреть исходный код программы и сформулированную идею, что перекликается с открытостью работы ученых.

В защиту коммерческого программирования можно сказать следующее. Выделяются три особо интересные группы программных систем и их разработчиков, на примере которых можно прокомментировать уровень контроля качества:

· малые и средние программные продукты, разрабатываемые относительно маленькими командами разработчиков;

· большие продукты, поддерживаемые средними компаниями;

· большие продукты, которые разрабатывают программисты большой организации.

В первом случае мы имеем дело с продуктом, тестирование которого может обеспечить на нормальном уровне сама команда разработчиков, и это приводит к удовлетворительным результатам. Во втором случае компания не в состоянии организовать должный контроль качества, поскольку ей не хватает “свободных рук”: все участники проекта полностью заняты разработкой продукта. Эта ситуация не является утешительной. Третий случай соответствует такому уровню компании-разработчика, при котором она может себе позволить (а без этого становится невозможным продвижение вперед) тратить какую-то часть бюджета проекта на поддержание продукта “в хорошей форме”. В этих обстоятельствах проект вырастает до огромных размеров и уже нельзя вести производство старыми методами.

Сегодня существует несколько типов организации и контроля хода разработки программных продуктов. Каждый из них имеет свои плюсы и свои минусы – при определенных обстоятельствах. Автор не будет рассматривать здесь конкретные типы и их специфику, поскольку в задачу настоящей статьи входит обсуждение только самой проблемы тестирования и основных вариантов ее решения без определенной детализации.

 

 

Проблемы, возникающие при реализации
и сопровождении программных систем

 

В процессе эволюции программы разработчики усовершенствуют ее. Существует несколько причин для изменения исходного кода программы, среди которых мы выделим три: 1) исправление неглобальных ошибок; 2) внесение мелких изменений в функциональность системы; 3) изменения в функциональности системы, которые влекут за собой серьезные изменения в самой системе.

Легкоустранимые проблемы. Первая из упомянутых причин – исправление текущих мелких ошибок системы, которые были выявлены в процессе тестирования или указаны пользователями системы. Большей части ошибок такого рода можно избежать, применив регламент программирования, в который входят правила составления и оформления программных единиц (функций, модулей и т.д.), техническая документация на систему, регламент тестирования и типовые программные решения. Приведенный перечень не полон, но все то, что в него включено, в той или иной степени не только позволяет контролировать процесс программирования и сопровождать систему в будущем, но и организует сам этот процесс, а результатом оказываются продукты с меньшим числом типовых ошибок. Конечно, в программировании существует представление об опыте, т.е. разработчик оценивается в первую очередь на основе своего положительного опыта, но введение подобных документов и правил помогает даже начинающим программистам избежать ошибок, которые допускали их более опытные коллеги. Интересно, что в случае эволюции научных теорий мелкие ошибки не учитываются. Во внимание берутся только глобальные заблуждения.

Вторая причина связана с необходимостью расширить функциональность уже готовой системы мелкими или незначительными функциями. Такой подход одинаково характерен как для развития научной теории, так и для совершенствования программных систем.

Изменения, влияющие на структуры системы. Безусловный интерес представляет третий тип изменений, которые приходится вносить в программу, – изменения, влекущие за собой значительную переработку системы в целом. Здесь начинают сказываться результаты одного из самых важных этапов программирования – проектирования. В случае хорошего проектирования ситуаций, когда необходимо перепроектировать значительную часть или всю систему в целом, становится минимальное количество (в идеале их нет вообще). Удачное проектирование уже как бы предполагает – на основе опыта и интуиции – подобные изменения функциональности.

Если посмотреть на процесс изменения существующих научных теорий, то данного этапа как такового там тоже не существует, поскольку если он есть, то на свет рождается уже другая теория. Однако процесс смены теорий, когда никакие незначительные изменения в теории не могут помочь достигнуть цели, очень важен, потому что при этом происходит полное переосмысление всего контекста теории и ее самой. В новую теорию могут войти какие-то идеи из предшествующей, но никак не вся старая теория, иначе эту смену нельзя было бы назвать революцией.

Подобный путь неизбежен и в случае эволюции программ. Уже упомянутое мнение о том, что любая часть программы должна переписываться полностью как минимум три раза, основана на реальном опыте программистов. По сути, это суждение подготавливает начинающего программиста к тому, что ему, возможно, придется переделать все, что он делает в данный момент.

В отличие от научных теорий программирование имеет одно преимущество – возможность модульного проектирования. Система, построенная в модульном исполнении, оказывается гораздо устойчивее и мобильнее, чем если бы она была сделана в виде монолита. В процессе изменения хорошо сделанной программы не должно быть переломных моментов, которые заставляют разработчиков переписывать систему в значительной степени. Именно это условие на сегодня активно обсуждается и начинает привлекать к себе интерес коммерческих компаний, поскольку выгоднее потратить средства на хорошее проектирование, чем потом оплачивать повторное программирование всей системы.

 

 

Методы реализации

 

До сих пор основной акцент в этой статье был сделан на проектировании, тестировании системы и других этапах программирования, теперь же специально остановимся на реализации программ.

Сам процесс реализации программ начинается только после детального проектирования системы, иначе возрастает вероятность возникновения ситуации, когда придется перепроектировать и переделывать всю систему целиком. В разработке научных теорий на первый взгляд все происходит точно так же. Вначале прорабатываются база теории и основные направления развития, после этого теория детализируется до необходимого предела и наконец производятся контрольные эксперименты, подтверждающие (объясняющие) результаты, полученные в ходе разработки теории. Однако если пристальнее посмотреть на процесс разработки теорий, особенно фундаментальных, можно увидеть, что доказательство того или иного факта, утверждения становится самоцелью. По мере того как утверждение или теорема эволюционирует и используется, другой исследователь разрабатывает аналогичное доказательство, но более изящное и понятное. В программировании же такая ситуация почти невозможна. Это связано с тем, что изначально плохо реализованный (здесь не имеется в виду плохое проектирование) компонент продукции может принести много неприятностей при отладке и просто использовании. Используя или создавая подобные компоненты, необходимо помнить все их недостатки и при необходимости исправлять их. Поэтому многие опытные программисты стараются реализовывать компоненты максимально корректно и полно, чтобы впоследствии их использование не до­ставляло неудобств.

Наряду с только что описанным подходом существует и еще один – экстремальное программирование. Отдельные моменты этой системы программирования в настоящей статье уже затрагивались. Данная систему существует не очень давно, но перспективы ее использования обозначились и уже имеются первые положительные результаты. Интересно отметить, что в рамках экстремального программирования даже этап проектирования разбит на подэтапы, которые чередуются с другими этапами программирования. В отличие от принятого во многих коллективах программирования по спирали (проектирование – реализация – тестирование) здесь основные этапы перемешиваются и на каждом отдельном отрезке времени проектируется только та часть системы, которую необходимо реализовать следующим шагом. Приверженцы экстремального программирования считают правильным постепенное развитие компонентов. Уже спроектированные части системы реализуются только по мере необходимости, тем самым вся система приобретает динамический характер, что не обеспечивается при использовании других систем программирования.

Выбор пути решения конкретной проблемы зависит от многих факторов. В одном случае необходима реализация в “научном” стиле, в другом, наоборот, обоснованно осуществляется одношаговая реализация.

 

 

Заключение

 

Завершая свои рассуждения, автор хотел бы подчеркнуть, что на любое исследуемое явление или полученный результат необходимо смотреть с разных сторон, сравнивая их с результатами, полученными ранее. Такой подход очень важен, поскольку невозможно все время изобретать что-то совсем новое. Когда-то нужно проникнуть глубже в уже достигнутое, дабы почерпнуть дополнительные знания об интересующем предмете.

Если сравнивать создание и развитие научных теорий и разработку программных систем, то надо отметить, что эти процессы взаимосвязаны, причем не случайным образом, поскольку и тот, и другой являются интеллектуальной деятельностью человека. Конечно, между ними есть и различия, но все же их сходство трудно оспаривать. Поэтому имеет смысл заняться сравнением этих двух феноменов и в конце концов выработать некоторую основу для дальнейших размышлений относительно программирования. Конечно, многие идеи, приведенные в настоящей статье, ранее уже высказывались, но, будучи собранными вместе, они могут послужить толчком для обоснования тех или иных подходов в программировании, для постановки и решения конкретных проблем в этой области. Иными словами, интегрируя некоторые положения из разных отраслей знания, можно получить дополнительный импульс к так называемому правильному программированию.

 

                                                                                       Объединенный институт геологии,

                                                                                       геофизики и минералогии

                                                                                       СО РАН, Новосибирск

 

 

Moisseiev, E.E. Methodological aspects of design and development of program systems

In this paper an attempt is made to review and analyze successively main stages of design and development of program systems, as well as the problems arising in this process. At the same time, the author tries to connect these problems with those which concern the evolution of scientific theories. The conclusion is grounded that by integrating some theses of different disciplines one may get another positive impetus to “correct” programming.