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

Что же производят программисты? Программисты производят программный продукт. В терминах автоматизированных систем программисты создают программное обеспечение.

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

Программное изделие — программа на носителе данных, являющаяся продуктом промышленного производства. Термин утвержден Государственным стандартом.

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

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

Необходимость в проекте вызвана сложностью задачи.

Следующий пример показывает нелинейную зависимость роста сложности задачи от ее размера. Необходимо в уме сложить числа 4 и 3. Ответ, разумеется, — 7. Необходимо в уме перемножить числа 7 и 9. Ответ, конечно, — 63. Но если не знаете таблицу умножения, то надо выполнить нестандартное преобразование в виде многократного сложения. Трудно ли оно для вас? Необходимо в уме перемножить числа 289 и 347. Если вы не феноменальный счетчик, то хватит ли в вашей голове оперативной памяти? А сможете ли вы перемножить в уме шестизначные числа? Но если декомпозировать данную задачу на вычисление ряда произведений одного из сомножителей на отдельные цифры другого сомножителя и затем найденные произведения сложить (при этом записывать на бумаге все промежуточные результаты), то с этой задачей вполне может справиться заурядный человек.

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

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

В табл. 1.1 приведены пять признаков сложной системы вместе с примерами. Эти признаки инвариантны как для осязаемой системы из реального мира «музыкальный центр», так и для программной системы — текстового редактора.

Таблица 1.1.

Примеры музыкального центра и текстового редактора как сложных систем

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

Спецификация в сфере проектной деятельности — это какое-либо описание в точных терминах.

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

Проект (от лат. projectus — брошенный вперед) — совокупность проектных документов в соответствии с установленным перечнем, которая представляет результат проектирования.

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

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

— информация об условии (условие задачи) — что задано;

— информация о решении (признаки исходной ситуации) — что требуется получить;

— информация о технологии преобразования условия в решение — как решить.

Проектная задача (англ. Engineering Task) характеризуется неопределенностью априори информации: что требуется получить, что задано. Более того, способ решения задачи является объектом проектирования. И наконец, решение проектной задачи должно быть найдено в рамках ограничений внешней среды проектирования: доступных денежных средств, заранее заданных сроков, возможностями технических средств и инструментария программирования, научных знаний, программных заделов и т. д.

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

Источником, первопричиной всякой проектной деятельности является субъект — человек или группа людей, испытывающие дискомфорт в существующей ситуации.

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

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

Для удовлетворения потребности нужен некоторый объект проектирования (в нашем случае программный продукт), наличие которого, его свойства и состояние удовлетворяют потребностям субъекта.

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

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

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

Методика (от греч. methodike) — упорядоченная совокупность методов практического выполнения чего-нибудь.

Методики проектирования излагаются в виде описаний проектных процедур и проектных операций.

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

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

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

Алгоритм — строго однозначно определенная для исполнителя последовательность действий, приводящих к решению задач.

Современное значение слова «алгоритм» во многом аналогично таким понятиям, как рецепт, процесс, методика, способ. Согласно Д. Кнуту [17], алгоритм имеет пять важных свойств.

Конечность. Алгоритм всегда должен заканчиваться после выполнения конечного числа шагов.

Определенность. Каждый шаг алгоритма должен быть точно определен.

Наличие входных данных. Алгоритм имеет некоторое число входных данных, задающихся до начала его работы или определяющихся динамически во время его выполнения.

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

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

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

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

Инженерия программирования (англ. software engineering, в терминах автоматизированных систем — разработка программного обеспечения) — инженерное дело, творческая техническая деятельность. Инженерия опирается на специфические методы и методики, в том числе эвристические. Инженерия [20] изучает различные методы и инструментальные средства с точки зрения определенных целей, т. е. имеет очевидную практическую направленность. Основная идея инженерии программирования в том, что разработка программного обеспечения является формальным процессом, который можно изучать, выражать в методиках и совершенствовать.

Инженерия программирования имеет четкую определенную дату рождения — 1968 г. Причина ее появления — реакция на так называемый «кризис программного обеспечения», вызванный достижением непреодолимого уровня сложности. Характерные вопросы и задачи инженерии программирования, изложенные Фредериком Бруксом, актуальны и по сегодняшний день.

Как проектировать и строить программы, образующие системы?

Как проектировать и строить программы и системы, являющиеся надежным, отлаженным, документированным и сопровождаемым продуктом?

Как осуществлять интеллектуальный контроль в условиях большой сложности?

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

Важными при разработке процессов проектирования являются такие понятия, как стратегия и тактика.

Стратегия (от греч. stratos — войско и ago — веду) — наука, искусство генерации наиболее существенных общих долгосрочных целей и наиболее общего плана достижения преимущества, курса действий и распределения ресурсов еще до выполнения реальных действий.

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

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

Стратегия выполнения конкретного проекта описывается в программном документе — техническом задании.

Методология (от греч. methodos и logos — слово, учение о методах) — система принципов и способов организации и построения теоретической и практической деятельности, а также учение об этой системе.

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

Технология (от греч. techne — искусство, мастерство, умение и logos — слово, учение) — совокупность производственных процессов в определенной отрасли производства, а также научное описание способов производства, совокупность приемов, применяемых в каком-либо деле, мастерстве, искусстве.

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

Технология программирования как наука изучает технологические процессы и порядок их прохождения (с использованием знаний, методов и средств). Технологический процесс — последовательность направленных на создание заданного объекта действий (технологических процедур и операций), каждое из которых основано на каких-либо естественных процессах и человеческой деятельности. Знания, методы и средства могут использоваться в разных процессах и, следовательно, в технологиях.

Технология программирования — для инженера это научная и практически апробированная стратегия создания программ, содержащая описание совокупности методов и средств разработки программ, а также порядок применения этих методов и средств.

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

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

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

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

Перед нами стоит вопрос, ранее уже упоминавшийся: «Как определить, достигнута ли цель, привела ли деятельность к желаемому результату: тот ли объект создан, который нам нужен, обладает ли нужными свойствами?» Для этого используются показатели качества (иногда их называют критериями) — величины, свойства, понятия, характеризующие систему с точки зрения субъекта, позволяющие оценить степень удовлетворения его потребностей. На начальном этапе проектирования анализ потребностей позволяет определить вид объекта; его функции (что объект делает при функционировании), свойства и состояние, при которых удовлетворяются потребности, а также уровень качества объекта.

При исследовании систем решаются задачи анализа и синтеза.

Анализ (от греч. analysis — разложение, расчленение) — прием умственной деятельности, связанный с мысленным (или реальным) расчленением на части предмета, явления или процесса.

Синтез (от греч. synthesis — соединение, сочетание, составление) — метод научного исследования явлений действительности в их единстве и целостности, во взаимодействии их частей, обобщение, сведение в единое целое.

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

В теории проектирования используются следующие понятия анализа и синтеза.

Анализ — процесс определения функционирования по заданному описанию системы.

Синтез — процесс построения описания системы по заданному функционированию.

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

По своей природе программа (т. е. набор инструкций) гораздо ближе к технологии (точнее, к описанию технологического процесса преобразования входной информации в выходную информацию), чем к изделию. Это означает, что для оценки производительности труда программиста не нужно искать способ оценки количества продукции, выпускаемой им, поскольку никакая физическая продукция не производится и, следовательно, нет ее объема. При использовании стандартного термина «программное изделие» возникают методологические, правовые и чисто технические сложности. Так, например, программисту не составит никакого труда вставить в программу любое количество модулей с любым объемом незадействованных операторов. Товарные свойства программного продукта — не товарные свойства этого изделия, а товарные свойства технологии. Причем технологии это тоже объекты, традиционно проектируемые инженерами.

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

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

Частотный принцип. Принцип основан на выделении в алгоритмах и данных особых групп по частоте использования. Для действий, наиболее часто встречающихся при работе программ, создаются условия их быстрого выполнения. К часто используемым данным обеспечивается наиболее быстрый доступ. «Частые» операции стараются делать более короткими. Следует отметить, что лишь не более 5 % операторов программы оказывают ощутимое влияние на скорость выполнения программы. Этот факт позволяет значительную часть операторов программы кодировать без учета скорости вычислений, обращая основное внимание при этом на «красоту» и наглядность текстов.

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

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

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

Принцип функциональной избыточности. Этот принцип учитывает возможность проведения одной и той же работы различными средствами. Особенно важен учет этого принципа при разработке пользовательского интерфейса для выдачи одних и тех же данных разными способами вызова из-за психологических различий в восприятии информации.

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

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

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

Структурный анализ — выявление элементов объекта и связей между ними.

Функциональный анализ — рассмотрение объекта как комплекса выполняемых им полезных и вредных функций.

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

Генетический анализ — исследование объекта на его соответствие законам развития программных систем. В процессе анализа изучается история развития (генезис) исследуемого объекта: конструкции аналогов и возможных частей, технологии изготовления, объемы тиражирования, языки программирования и т. д.

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

Методология блочно-иерархического подхода базируется на трех концепциях: разбиения и локальной оптимизации, абстрагирования, повторяемости.

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

Локальная оптимизация подразумевает улучшение параметров внутри каждой простой задачи.

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

Повторяемость — в использовании существующего опыта проектирования.

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

Главным недостатком блочно-иерархического подхода является то, что на верхних уровнях имеют дело с неточными моделями объекта, и решения принимаются в условиях недостаточной информации. Следовательно, при этом подходе высока вероятность проектных ошибок.

При создании и развитии программного обеспечения (ПО) рекомендуется применять следующие общесистемные принципы:

1) принцип включения, предусматривающий, что требования к созданию, функционированию и развитию ПО определяются со стороны более сложной, включающей его в себя системы;

2) принцип системного единства, состоящий в том, что на всех стадиях создания, функционирования и развития ПО его целостность будет обеспечиваться связями между подсистемами, а также функционированием подсистемы управления;

3) принцип развития, предусматривающий в ПО возможность его наращивания и совершенствования компонентов и связей между ними;

4) принцип комплексности, заключающийся в том, что ПО обеспечивает связанность обработки информации как отдельных элементов, так и всего объема данных в целом на всех стадиях обработки;

5) принцип информационного единства, т. е. во всех, подсистемах, средствах обеспечения и компонентах ПО используются единые термины, символы, условные обозначения и способы представления;

6) принцип совместимости, состоящий в том, что язык, символы, коды и средства программного обеспечения согласованы, обеспечивают совместное функционирование всех подсистем и сохраняют открытой структуру системы в целом;

7) принцип инвариантности, предопределяющий, что подсистемы и компоненты ПО инвариантны к обрабатываемой информации, т. е. являются универсальными или типовыми.

Томас Кун в 1977 г. определил термин «парадигма» как свод норм научного мышления. Парадигма — это правило (modus operandi) развития научного знания. Оно в течение определенного времени дает научному сообществу модель постановки проблем и их решений.

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

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

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

— процедурно-ориентированные — алгоритмы;

— объектно-ориентированные — классы и объекты;

— логически-ориентированные — цели, выраженные в исчислении предикатов;

— ориентированные на правила — правила «если…, то…»;

— ориентированные на ограничения — инвариантные соотношения;

— параллельное программирование — потоки данных. Существуют и другие парадигмы. Почему же их столько? Отчасти потому, что программирование — сравнительно новая

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

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

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

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

Группа стандартов ГОСТ «Единая система программной документации» (ЕСПД) претерпела мало изменений с момента ее создания, пережила несколько поколений ЭВМ и революционных изменений технологий разработки программ. При этом она до настоящего времени никогда не затрудняла новаций.

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

В области программирования общепризнанной ведущей организацией по разработке стандартов является институт ANSI (Американский национальный институт стандартов). Данный институт является лидером по установке стандартов языков программирования, кодовых таблиц клавиш и символов, выводимых на экран, и еще многих других. Необходимо также отметить стандарты ISO.

К сожалению, самое благородное дело стандартизации — достижение всеобщей унификации и взаимозаменяемости — может также стать тормозом развития. Вводя новый стандарт, надо учитывать последствия ввода, особенно если стандарт является опережающим и опережает практику развития или если стандарт является слишком «узким» и тормозит эволюцию прогресса. Во всем мире руководствуются следующим отношением к стандартам: или полностью им следуй, или делай свой собственный стандарт. Стандарты дают дополнительные ограничения.

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

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

Жизненный цикл — совокупность взаимосвязанных процессов создания и последовательного изменения состояния продукции от формирования к ней исходных требований до окончания ее эксплуатации или потребления.

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

Рис. 1.1. Жизненный цикл программных изделий

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

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

ГОСТ 19.102—77 регламентирует стадии и этапы программных разработок в течение всего жизненного цикла. Данный стандарт сформировался на основе анализа удачных и неудачных программных разработок и содержит основные рекомендации по проведению новых разработок. Стандарт уже пережил несколько технологий программирования. При этом, практически не изменяясь, он не являлся тормозом прогресса. Помимо наименований стадий и этапов проектирования ГОСТ 19.102—77 фактически содержит описание аналитико-синтетического эвроритма (алгоритма действий проектировщика с использованием методов анализа и синтеза) по временным этапам проекта.

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

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

Стадии и этапы разработки программ по ГОСТ 19.102—77 на момент написания книги даны в приложении 1.

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

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

«Технический проект» (ТП) выполняется для получения однозначного описания конечного (оптимального) варианта построения программного изделия и порядка его реализации.

«Рабочий проект» (РП) необходим для реализации изделия в соответствии с ранее намеченным планом.

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

Научно-исследовательская работа (НИР) может быть самостоятельным этапом. НИР в основном проводится для выявления последних научных достижений с целью их использования в проекте, проверки реализуемости изделия и уточнения отдельных его характеристик.

В соответствии с ГОСТ 19.102—77 допускается исключать стадию ЭП, а в технически обоснованных случаях — стадии ЭП и ТП. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком. Это позволяет разумно построить проект конкретной разработки (ход проекта также является объектом проектирования).

Пример 1. Разработка наукоемкой подпрограммы может вестись по следующим стадиям:

• ТЗ (ТЗ основное плюс ТЗ на отдельную НИР);

• ожидание результатов НИР, выполняемой в другой организации специалистами-математиками (срок от месяца до нескольких лет);

• РП (около месяца);

• внедрение.

Пример 2. Требуется разработать программное изделие средней или большой сложности. При средней сложности изделия необходимо проведение ТП, а при большой сложности — и ЭП, и ТП. В отличие от примера 1 в данном случае ТЗ может не содержать законченных требований.

Пример 3. Требуется создать программные средства, автоматизирующие отдельные виды работ. Разработка такого проекта может проводиться по следующим стадиям:

• ТЗ;

• ЭП с НИР по исследованию существующих программных средств, автоматизирующих выполнение отдельных видов работ;

• РП по разработке только документации без реализации каких-либо программ, если НИР показала, что можно обойтись только существующими программными средствами;

• внедрение.

Пример 4. Разработка таких информационных систем, как САПР или АСУ должна осуществляться в соответствии с соответствующими стандартами. ТП САПР или АСУ может содержать технические задания на разработку отдельных программных изделий. Как правило, такие ТЗ очень конкретны. На этапе РП САПР или АСУ сначала ведется контроль над разработкой программных изделий по всем необходимым для этого стадиям разработки программных изделий, затем проводится совместная проверка всех разработанных программ.

Обычно основанием для заключения договора между заказчиком и исполнителем служит гарантийное письмо заказчика. На основании гарантийного письма составляется договор. Обязательным приложением к договору является ТЗ.

Некоторые отечественные и зарубежные источники предлагают выделять следующие этапы:

1) анализ требований, предъявляемых к системе (системный анализ). (Обычно проводится на основе первичного исследования потоков информации при традиционном проведении работ с фиксацией видов этих работ и их последовательности.);

2) определение целей, достигаемых разрабатываемыми программами;

3) выявление аналогов, обеспечивающих достижение подобных целей, их достоинств и недостатков;

4) постановка задачи на разработку новых программ, определение внешних спецификаций (т. е. описаний входной и выходной информации, а иногда и их форм) и способов (алгоритмов, методов) обработки информации;

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

6) рассмотрение возможных вариантов структурного построения программного изделия: или в виде нескольких программ, или нескольких частей одной программы; результатом этой работы являются варианты архитектуры программной системы и (или) требования к структуре отдельных программных компонент; организация файлов для межпрограммного обмена данными;

7) разработка окончательного варианта архитектуры системы и разработка окончательной структуры программных компонент;

8) составление и проверка спецификаций модулей;

9) составление описаний логики модулей;

10) составление окончательного плана реализации программ;

11) кодирование и тестирование отдельных модулей и совокупности готовых модулей до получения готовой программы;

12) комплексное тестирование;

13) разработка эксплуатационной документации на программу;

14) проведение приемо-сдаточных и других испытаний;

15) корректировка программ по результатам испытаний;

16) окончательная сдача программного изделия заказчику;

17) тиражирование программного изделия;

18) сопровождение программы.

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

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

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

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

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

Ниже приведены типовые ошибки обучаемых при написании требований к функциональным характеристикам:

• непонимание термина «функциональные характеристики» (Смысл этого термина характеризуется следующим предложением: «Проектируемый завод в нормальном режиме работы должен обеспечить выпуск за одну 8-часовую смену не менее 40 пропашных тракторов». Эта фраза содержит как назначение проектируемого объекта — завода, так и то, что выпускает завод и при каких ограничениях. Применительно к программам, для правильного написания требований к функциональным характеристикам необходимо сторонними глазами будущего пользователя рассмотреть, что делает полезного программное изделие и при каких ограничениях.);

• описание требований к функциональным характеристикам всеобщего, универсального объекта (если по конкретным требованиям можно реализовать целый спектр изделий, то они не конкретны);

• написание заведомо нереализуемых требований.

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

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

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

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

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

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

Любые достаточно большие программы являются сложными системами. Проблема сложности преодолевается путем декомпозиции задачи. Базовая парадигма в подходе к любой большой задаче ясна: необходимо «разделять и властвовать».

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

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

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

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

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

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

Спецификация может описывать соглашение между программистами и заказчиками (пользователями). Программист берется написать программу, а пользователь соглашается не полагаться на знания о том, как именно эта программа реализована, т. е. не предполагать ничего такого, что не было бы указано в спецификации. Такое соглашение позволяет разделить анализ реализации от собственно использования программы. Спецификации дают возможность создавать логические основы, позволяющие успешно «разделять и властвовать».

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

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

Уже в первичных спецификациях можно выделить две части: функциональную и эксплуатационную.

Первичная функциональная спецификация в первую очередь описывает:

— объекты, участвующие в задаче (что делает программа и что делает человек, работающий с этой программой);

— процессы и действия — эвроритмы для человека, алгоритмы методов решения задачи в машине с указанием сути и порядка обработки информации (с занимаемым информацией и программой размером оперативной памяти);

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

То есть вначале фиксируются внешние функциональные спецификации, а затем и внутренние.

В общем случае внешние функциональные спецификации включают:

— описание того, что делает программа;

— определение, что делает человек, а что машина (по каким эвроритмам работает человек, откуда он берет информацию и как ее готовит к вводу в ЭВМ);

— спецификации входных и выходных данных;

— реакции на исключительные ситуации.

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

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

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

Изложенные далее абстракции процедуры, данных и объектов лежат в основе многих методов разработки программного обеспечения. В общем случае любую программу можно представить набором процедурных абстракций (рис. 1.2). Анализируя рис. 1.2, можно получить обобщенную абстракцию процедуры, изображенную на рис. 1.3. Абстракции процедур наиболее полно воплотились в технологии структурного программирования.

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

Рис. 1.2. Абстракция программы как набора процедур, обрабатывающих данные

Рис. 1.3. Абстракция процедуры

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

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

При анализе спецификации для уяснения смысла обращения к процедуре нужно придерживаться следующих двух правил.

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

Правило 2. Можно ограничиться только той информацией, которую подразумевает конечное условие.

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

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

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

Например, абстракцию SQRT (извлечение квадратного корня) можно сравнить с операцией: она абстрагирует отдельное событие или задачу. Мы будем ссылаться к абстракциям такого рода, как к процедурным абстракциям. Отметим, что абстракция SQRT включает в себя как абстракцию через параметризацию, так и абстракцию через спецификацию.

На процедурной абстракции основана разработка структуры программы в технологии структурного программирования. Базовая компонента технологии структурного программирования — модуль, которому обычно соответствует подпрограмма (процедура или функция на языках программирования высокого уровня).

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

В технологии абстрактных данных Дейкстры применяется функциональная модель в виде набора диаграмм потоков данных (далее — ДПД; DFD — Data Flow Diagram), которые описывают смысл операций и ограничений. ДПД отражает функциональные зависимости значений, вычисляемых в системе, включая входные значения, выходные значения и внутренние хранилища данных. ДПД — это граф, на котором показано движение значений данных от их источников через преобразующие их процессы к их потребителям в других объектах. Фрагменты ДПД показаны на рис. 1.6.

Рис. 1.4. Абстракция программы как набора данных, обрабатываемых процедурами

Рис. 1.5. Абстракция данных

Поток данных соединяет выход объекта (или процесса) с входом другого объекта (или процесса). Он представляет промежуточные данные вычислений.

Хранилище данных — это пассивный объект в составе ДПД, в котором данные сохраняются для последующего доступа. Хранилище данных допускает доступ к хранимым в нем данным в порядке, отличном от того, в котором они были туда помещены. Агрегатные хранилища данных, как, например, списки и таблицы, обеспечивают доступ к данным в порядке их поступления либо по ключам.

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

Рис. 1.6. Фрагменты диаграммы потоков данных (ДПД):

а — копирование данных (числа); б — расщепление данных; в — активный объект «Клиент» посредством операции «Нахождение цены» работает с хранилищем «Прайс-лист»

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

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

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

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

Шаг 1. Основываясь на потоке данных в задаче, выделите 3—10 смысловых частей обработки данных.

Шаг 2. Доопределите главный входной и выходной потоки данных задачи.

Шаг 3. Проследите, как следует входной поток от части к части, от входа к концу обработки, найдите эту точку. Проследите от конца к началу, как следует выходной поток; найдите абстрактную точку, где он появился (рис. 1.7).

Найденные точки делят задачу на две или три наиболее независимые (по данным) части.

Шаг 4. Представьте независимые части подпрограммами и определите их функции. Эти подпрограммы будут подчиненными по отношению к модулю, разбиение которого выполняется.

Шаг 5. Определите сопряжения подпрограмм по данным.

Рис. 1.7. Превращение главного входного потока информации в выходной поток:

1 — участок соответствует преобразованию информации входного потока в промежуточную информацию; 2 — участок соответствует получению выходной и промежуточной информации из входной и промежуточной информации; 3 — участок соответствует получению выходной информации из промежуточной информации

Современная, вытесняющая технологии структурного программирования и абстракции данных объектно-ориентированная технология сочетает в себе абстракции процедур и данных в новой абстракции — объекте (рис. 1.8). Понятие абстракции данных расширено до того, что как внутренние данные, так и код процедур рассматриваются как новый тип данных — объект.

Объектная модель базируется на двух постулатах: все есть объекты; объекты взаимодействуют передачей сообщений.

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

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

Рис. 1.8. Абстракция объекта

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

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

Размещенный в отдельном файле набор связанных процедур вместе с данными, которые они обрабатывают, называют программной единицей (Unit). Часто слово «Unit» переводят как модуль. Так возник термин «модульное программирование». В модульном программировании акцент сместился от проектирования процедур в сторону организации данных. Помимо прочего, это явилось отражением факта увеличения размеров программ. Парадигма: реши, какие требуются модули; разбей программу так, чтобы скрыть данные в модулях.

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

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

— соответствовать назначению (из имени должно однозначно следовать его назначение и, наоборот, из назначения — его имя);

— обладать узнаваемостью (это свойство имени позволяет улучшить читаемость исходных текстов программ);

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

— быть краткими (слишком длинные имена не запоминаемы и, несмотря на повышенную узнаваемость по сравнению с короткими именами, усложняют чтение исходного текста программы);

— обладать уникальностью (как следствие, «соответствовать назначению»: имена должны составляться таким образом, чтобы во всей системе не было двух одинаковых глобальных имен).

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

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

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

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

Итак, имя состоит из слов. Пусть длина имени — это количество слов, использованных в этом имени. Имя А является родительским по отношению к имени Б, если длина имени Б больше, чем длина имени А, и первые (слева) слова имени Б совпадают со словами имени А в том же порядке. Имя А можно рассматривать как общий префикс для имен группы Б. Например, имя debug является родительским для имен debug_info, debug_mode, debug_log, debug_error_get, debug_error_set и т. п. Имя debug_error, в свою очередь, является родительским для debug_error_get, debug_error_set.

Имя А является дочерним по отношению к имени Б, если имя Б является родительским по отношению к имени А.

Имена принадлежат одной группе, если эти имена имеют одинаковую длину и одного общего предка А. Длина имени А на единицу меньше длины имен этой группы. В таком случае А будет являться именем этой группы. Например, имена debug_error_get, debug_error_set являются именами группы debug_error. Имена debug__info, debug_mode, debug_log и debug_error, в свою очередь, являются именами группы debug.

Пусть мощность группы А — общее количество имен в этой группе. Префикс имени — это слово, которое записывается самым первым в имени и не учитывается при определении длины, родства и принадлежности группе. Префиксы используют, например, для указания типов переменных или полей: i_count, b_valid, is_protected. i, b, is — префиксы.

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

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

В некоторых случаях имена объектов могут быть глаголами. Например, подсистему очистки базы данных логично было бы назвать слово "clear" (очистить). В таком случае глагол "очистить" будет стоять в середине имени.

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

Пример 2. passport_password_change или passport_password_change — хорошие имена. В системе есть подсистема управления аккаунтами пользователей, называемая passport. Часть этой подсистемы, занимающаяся управлением паролями, называют passport_password. Одну из функций этой части — изменение пароля — называют passport_password_change.

Длина имени должна быть минимальной. Не используйте в именах лишних слов. Каждое слово, использованное в имени, должно означать конкретный объект, которому принадлежит это имя или конкретное действие или свойство, которому соответствует это имя. Имена объектов, действий и свойств, в свою очередь, должны состоять из имен, длина которых равна одному слову.

Пример 1. ConvertlntegerDateToSQLStrDate — плохое имя. Как вы думаете, вспомните ли вы его с точностью до символа через день?

Слова "Convert" и "То" чаще всего можно вообще опустить, поскольку очевидно, что если есть два формата даты, то, следовательно, происходит преобразование из одного формата в другой.

Слово "Date" повторять два раза не нужно, поскольку и исходное данное, и результат являются датой.

Все SQL-запросы в программе — это строки. Поэтому слово "Str" — лишнее.

Пример 2. IntegerDateSQL — приемлемое имя. Есть подсистема управления датами, и эта функция конвертирует дату, представленную в виде целого числа в строку, которую можно использовать в SQL-запросе. Недостатком этого имени является отсутствие активного глагола. Сравните это имя с исходным вариантом примера 1.

В системе не может появиться группа имен мощностью 1.

Пример 1. PASSPORT_DEAD_REMOVE_TIMEOUT — плохое имя, если с умершими пользователями (так на сайте названы пользователи, которые слишком долго не появляются) нельзя производить никаких других операций, кроме удаления.

Пример 2. PASSPORT_DEAD_TIMEOUT — хорошее имя.

Пример 3. passport_is_login_valid — плохое имя. Слово "is" — лишнее.

Пример 4. passport_login_valid — хорошее имя. Есть подсистема управления аккаунтами passport. В ней есть часть, которая занимается управлением логинами пользователей passport_login. Функция passport_login_valid проверяет, является ли "логин" правильным.

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

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

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

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

Слова не в начальной форме могут быть использованы только в том случае, если они используются МНОГО раз и при этом во ВСЕХ местах — одинаково.

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

Пример 1. StrToFloat — плохое имя. В ряде языков программирования есть зарезервированное слово "String". В таком случае получается, что в некоторых случаях к строкам обращаемся по полному имени, а в некоторых — по сокращению. Однако сокращение "Str" — общепринятое в системах программирования фирмы "Borland". При использовании этих систем, но не в SQL-запросах, такое сокращение резонно использовать, и имя StrToFloat становится хорошим именем.

Пример 2. StringToFloat — хорошее имя (если не учитывать наличие лишнего слова "То", но "То" хорошо показывает, что это имя процедуры конвертора типов).

Пример 3. mp_pagelist — хорошее имя, если в группе "mp" много имен или это сокращение используется в таком же написании и таком же смысле большое количество раз в других именах (mp — сокращение от "main page").

Пример 4. PASSPORT_PASSWORD_LENGTH_MIN — хорошее имя, сокращение в конце — общепринятое и везде в системе используется именно в таком варианте написания.

Пример 5. TPassportPrivileges — плохое имя для таблицы, в которой хранится список привилегий. Очевидно, что в таблице хранится много всяких привилегий, и множественное число в данном случае излишне.

Пример 6. TPassport_Privilege — хорошее имя, однако если бы не велась речь о базах данных, префикс "T" соответствовал бы типу, а не переменной.

Не допускается использование префиксов без особой на то необходимости.

Случаи, в которых использование префиксов оправдано:

• если это не имена переменных, а имена типов переменных, можно использовать префикс "T";

• если имена ваших сущностей будут перемешиваться с посторонними именами;

• в случае локальных имен.

Имена, используемые в ограниченном контексте, могут быть очень короткими. Традиционно имена i и j используются для обозначения счетчиков, p и q — для указателей, s — для строковых, а ch — для литерных переменных. Эти традиционные кратчайшие имена могут соответствовать префиксам, поясняющим тип переменных.

Пример 1. is_passport_privilege_valid — плохое имя. Префикс в глобальном имени излишен.

Пример 2. passport_privilege_valid — хорошее имя.

Пример 3. i_order — хорошее имя для поля в таблице, указывающее на порядок чего-либо. Префикс "i" характеризует тип целый.

Дополнительные рекомендации по составлению имен:

• не начинайте и не заканчивайте имена символом подчеркивания;

• не используйте имена, состоящие только из строчных букв (исключения составляют имена констант и макроопределений);

• не следует в одной и той же программе использовать имена, различающиеся лишь написанием букв — строчной или прописной;

• в зависимости от возможностей языка программирования можно разделять части имен символом подчеркивания или написанием с большой буквы очередной части имени;

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

Ряд понимаемых трудно имен следует тщательно комментировать. Такой комментарий лучше приводить справа от описания имени.

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

Рефакторинг (от англ. refactoring) — оптимизация, улучшение реализации программы без изменения ее функциональности.

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

Применительно к именам под рефакторингом понимается изменение имен таким образом, чтобы они соответствовали новым требованиям. Имена — это очень важная часть программы. Многие программисты склонны преуменьшать значимость имен.

Непонятные имена — это нечитаемая программа, а нечитаемую программу тяжело сопровождать.

Рассмотрим случаи, в которых может потребоваться рефакторинг имен:

Случай 1 — изменение правил. Можно составить разные правила образования имен и следовать сначала одним правилам, потом, уточнив эти правила, следовать другим. Неизменным должно оставаться только одно правило: все имена в проекте должны быть построены по одним правилам.

Случай 2 — частичный рефакторинг имен. Если по каким-либо причинам изменили правила составления имен, то следует обновить все имена, не подходящие под новые правила.

Случай 3 — невозможность однозначного предсказания будущего. Любой проект развивается. На этапе создания может оказаться, что спроектированная структура не полна или сначала предполагалась одна структура, а затем стала очевидной другая, более предпочтительная структура.

Случай 4 — рефакторинг имен, на ваш взгляд, не нужен: вы уже заканчиваете работу над проектом, не планируете в будущем его поддерживать и вам все равно, что о вас подумают люди, которым придется разбираться в вашем коде.

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

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

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

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

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

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

Для тиражирования таких элементов программ, как редактор текстов, система иерархического меню, элементов диалога типа "заполнения бланков" фирма "Borland Inc." предложила применять TPU — Turbo Pascal Unit (модуль OBJ в ряде языков). TPU-файл позволил использовать механизм сокрытия в секции Implementation неинтересных внутренних подпрограмм и внутренних данных и, наоборот, вне файла механизм сокрытия обеспечил открытость вызова только полезных для пользователя процедур и использование внутренних глобальных переменных, описанных в секции Interface. После этого нововведения программисту для использования, например, редактора, написанного не им, надо знать лишь информацию, описанную в секции Interface. Механизм сокрытия информации в пределах файла был введен еще в целый ряд компиляторов разных языков. Реализация механизма сокрытия упростила задачу использования "кубиков".

Объектно-ориентированные языки программирования дали четыре новых механизма использования кубиков:

1) механизм классов, порождающих при выполнении любое количество однотипных объектов, например, ряд однотипных кнопок;

2) возможность тиражирования объектов от породившей программы во все новые программы;

3) динамически линкуемые библиотеки с порождающими объекты классами;

4) механизм сборки программ из "кубиков" — объектов в процессе их выполнения.

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

Второй механизм привел к возникновению объектно-ориентированных СУБД, поставляющих программам не только данные, но и код, обрабатывающий эти данные.

Третий и четвертый механизмы позволили попытаться строить гибкие программы, обладающие свойством возможного развития при изменении условий их эксплуатации. Впервые возможность реализации получили идеи эволюционного программирования. Идеи прошлых технологий эволюционного программирования были явно недостаточными для обеспечения гибкости программ, что для длительного развития в изменчивой внешней среде требовало невозможного однозначного предсказания будущего. Согласно третьему механизму возникли СОМ-технологии. На основе четвертого механизма из базы готовых "кубиков П-объектов" создаются все новые "кубики" и из них новые программы.

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

ВЫВОДЫ

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

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

• При разработке программного обеспечения следует использовать следующие общие принципы: частотный; модульности; функциональной избирательности; генерируемости; функциональной избыточности; "по умолчанию".

• Одной из важнейших составляющих успешного проектирования является системный подход, предусматривающий всестороннее исследование сложного объекта.

• При создании и развитии ПО рекомендуется применять следующие общесистемные принципы: включения; системного единства; развития; комплексности; информационного единства; совместимости; инвариантности.

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

• Необходимо помнить, что проектирование неотъемлемо от различных стандартов (ГОСТ, ANSI, проекта) и их следует соблюдать как при оформлении документации, так и для унификации вашего проекта.

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

• В процессе выполнения проекта предусматриваются отдельные моменты времени, которые характеризуются законченным оформлением результатов всех работ, выполненных разработчиками до данного момента. Согласно ГОСТ возможны следующие стадии разработки: ТЗ; ЭП; ТП; РП; внедрение. Возможны также и нестандартные этапы и стадии. Набор этапов и стадий отражает результаты проектирования самого процесса проектирования.

• Модели играют важнейшую роль в проектировании программ. При построении моделей используется абстрагирование и декомпозиция.

• Каждая стадия проекта завершается утверждением программных документов. Документы включают описания (спецификации). Спецификации являются моделями. Спецификации делятся на внешние и внутренние.

• Рациональный выбор стандартных элементов ("кубиков") имеет два аспекта: удобство при повторном использовании и возможность осуществления синтеза из малых элементов более общих элементов.

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

Контрольные вопросы

1. Дайте определение проектированию.

2. Что такое эвристика?

3. В чем состоит схожесть и различие алгоритма и эвроритма?

4. Что решает задача оптимизации разработки программ?

5. Назовите пять признаков сложной системы.

6. На чем основан частотный принцип разработки программ?

7. Какие виды анализа используются при системном подходе?

8. Что такое принцип совместимости?

9. Для чего необходима стандартизация проектирования и программирования?

10. Назовите основные этапы жизненного цикла программных изделий.

11. Назовите основные стадии и этапы разработки программ по ГОСТ 19.102-77.

12. В чем суть моделирования?

13. Какие типы абстракций вы знаете?

14. Что такое первичная функциональная спецификация?

15. Какие механизмы использования "кубиков" дали объектно-ориентированные языки программирования?

16. Что такое рефакторинг?

17. Зачем нужен рефакторинг имен?

18. Почему трудно определять идеальные имена?