«Учебно-методическое пособие по дисциплине Технологические подходы к разработке программного обеспечения Новиков Ф.А., канд. физ.-мат. наук, доцент кафедры Технологии программирования Санкт-Петербург 2007 УМП ...»

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

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

Аналогичная классификация видов проектирования используется в MSF.

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

Сценарии являются основным выходом стадии концептуального проектирования. Сценарий — это фиксация на языке, в равной мере понятном как пользователям, так и разработчикам, существа процесса бизнеса, для которого разрабатывается решение. Используются два вида сценариев: "как есть" и "как должно быть". Если речь не идет о разработке абсолютно нового приложения, то сценарий "как есть" является наиболее надежным средством установления взаимопонимания между пользователями и разработчиками, а сценарий "как должно быть" является одним из самых эффективных средств определения требований. Рекомендуемым средством построения сценариев являются диаграммы использования (use-cases) на языке UML с подробными текстовыми комментариями.

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

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

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

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

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

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

удобна для описания служб приложения. Проектирование служб обычно начинается с определения номенклатуры услуг, затем производится группировка услуг по службам и, наконец, определяется структура объектов, обеспечивающих службы. В терминах диаграмм UML это означает, что начинать проектирование следует с диаграмм использования, которые по большей части создаются уже на стадии концептуального проектирования и могут уточняться на стадии логического проектирования. Затем диаграммы использования дополняются соответствующими диаграммами взаимодействия, где появляются объекты, структура которых уточняется с помощью диаграмм классов. Сложные услуги, которые требует выполнения многошаговых транзакций, удобно описывать с помощью диаграмм деятельности, а поведение сложных объектов с памятью удобно описывать с помощью диаграмм состояний. Диаграммы последовательности при логическом проектировании вертикальных приложений типа информационных систем используются сравнительно редко. Замечание На заре программирования программисты писали программы, то есть буквально рисовали код (или псевдокод, иногда с блок-схемами) на бумаге и этот код в бумажном виде некоторое время жил, подвергаясь обсуждению и модификации. Видимая причина "бумажного" программирования заключалась в технической трудоемкости непосредственного кодирования и высокой трудоемкости отладки плохо написанной программы. Дело в том, что работа велась в пакетном режиме. Цикл исправления пустяшной описки (трансляция – пропуск теста – локализация ошибки – исправление ошибки – трансляция – пропуск теста) мог занимать часы, а не секунды, который такой цикл занимает в современной интерактивной интегрированной системе программирования. Написать программу и пару раз просмотреть ее «в сухую», без прогона на машине, а не запускать ее сразу бывало выгоднее. Таким образом, написание программ являлось своеобразной формой проектирования. Развитие инструментальных средств избавило современных программистов от технических трудностей (сейчас никто программ на бумажке не пишет), но одновременно породило дурную, но, к сожалению, распространенную привычку проскакивать стадию логического проектирования и начинать "лепить" код, имея только смутную "концептуальную модель" в голове.

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

• маленькая программа (существенно меньше 1000 строк);

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

• выдающиеся индивидуальные способности78 (объем сверхоперативной памяти превосходит мировую константу 7±2 более чем на порядок).

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

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

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

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

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

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

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

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

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

скелет кода;

схема базы данных;

прототип интерфейса.

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

5.5.3.1. Распределение компонентов Компонент – это элемент физической структуры кода приложения, т.е. исполнимый файл, библиотека динамического связывания, командный файл и т.п.79 Проектирование компонентов требует решения двух вопросов:

• какие службы (объекты, функции) должны быть упакованы в одном компоненте;

• какие компоненты должны выполняться на каких компьютерах (в случае распределенной системы).

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

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

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

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

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

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

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

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

Рис. 39. Варианты распределения компонентов Код программы не пишется от начала к концу: у умелого программиста, даже не использующего инструментальные средства CASE, заголовки всех81 процедур появляются раньше, чем тело первой процедуры. Та часть кода, которая отражает модульную и объектную структуру программы, но еще не содержит деталей реализации, в дисциплине программирования относится к проектной документации стадии детального проектирования и называется скелет кода.82 Современные развитые инструментальные средства разработки (см.

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

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

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

Стандартный язык программирования реляционных СУБД SQL является языком очень высокого уровня и не позволяет программисту контролировать выполнение примитивов.

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

Хорошие системы программирования поддерживают скелет кода в явном виде, хотя называют его по разному: заголовочные файлы в С, interface в Паскале и т.п.

Особенно если используются не эквисоединения по не ключевым атрибутам. В этом случае просто трудно сказать a priori как быстро будет выполняться запрос.

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

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

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

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

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

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

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

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

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

согласованность (consistency) интерфейса;

низкую трудоемкость;

независимость интерфейса от прочих служб.

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

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

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

Кодирование, т.е. непосредственное составление и ввод текста программы на языке программирования, выполняется на фазе реализации.

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

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

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

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

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

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

сокращение доли внепланово изменяемого кода;

увеличение доли повторно использованного кода.

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

Таблица 8. Формы представления и использования образцов Параметризованная Стек, Двусвязный спи- Шаблон Подстановка Регламентируется Разовая многошаго- Просмотр текстового Пример Вставка текста с Ручное выделение и Абстрактный объект Конечный автомат, таб- Идея в го- Фиксированная Код создается заново К сожалению, последнее не всегда просто сделать, как показывает следующий классический английский анекдот. Капитан вызывает юнгу и приказывает: "Найди мой серебряный кофейник". Юнга спрашивает: "Если я знаю, где находится вещь, можно ли считать, что я ее нашел?". "Разумеется", – отвечает капитан. "В таком случае, ваш кофейник на дне моря, сэр".

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

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

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

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

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

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

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

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

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

GoF — Gang of Four (Gamma, Helm, Johnson, Vlissides) Design Pattern — в программистский жаргон уже довольно прочно вошла калька с английского — "паттерн" (pattern), но мы, насколько это возможно, избегаем использования жаргона.

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

Рассмотрим подробнее понятие образца проектирования применительно к UML. Синтаксически в UML образец проектирования — это параметрическая кооперация классов (т. е.

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

Рассмотрим все это более подробно на конкретном примере, в качестве которого мы используем классический образец проектирования, описанный в упоминавшейся книге «банды четырех» под именем Observer, а в других источниках упоминаемый под именем Publish-Subscribe.

Задача. Поведение некоторых объектов системы (подписчиков — экземпляров класса Subscriber) должно зависеть от изменения состояния (события) другого объекта (издателя — экземпляра класса Publisher). Однако издатель не должен прямо взаимодействовать с подписчиками. Решение. Ввести службу уведомления о событиях, с тем чтобы издатель мог опосредованно уведомлять подписчиков о наступлении события. Для этого вводится (единственный) объект класса EventManager, реализующий данную службу. Класс EventManager имеет метод subscribe, вызывая который подписчик подписывается на уведомлении о наступлении события, и метод signalEvent, посредством которого издатель уведомляет о наступлении события. При вызове метода signalEvent объект EventManager посылает уведомления о событии всем подписчикам, вызывая метод notify, переданный в качестве параметра при подписке. На рис. 40 приведена диаграмма кооперации, описывающая данный шаблон взаимодействия.

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

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

Рис. 40. Диаграмма кооперации для образца проектирования Publish-Subscribe Результат. Класс Publisher не зависит от класса Subscriber. Возможны различные модификации образца: при необходимости получать уведомления о различных событиях, нужно добавить соответствующий параметр (например, имя события); для увеличения эффективности можно обязанности ведения службы уведомления о событиях перепоручить прямо классу Publisher, но в этом случае снижается гибкость, поскольку реализовывать данную службу придется в каждом классе-издателе.

ЗАМЕЧАНИЕ

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

Допустим теперь, что описано некоторое множество образцов проектирования и мы хотим применить один из них в конкретном контексте. Как происходит применение образца, если моделирование ведется средствами UML?

Рассмотрим пример из информационной системы отдела кадров – типичного вертикального приложения масштаба предприятия. Пусть в нашей системе требуется уведомлять сотрудников об изменении состояния подразделения — вполне естественное требование, поскольку поведение сотрудников существенно зависит от состояния подразделения, и мы не хотим нагружать руководителя подразделения обязанностью персонально извещать каждого подчиненного — у руководителя и без того хлопот полон рот. В этом случае мы можем на диаграмме кооперации показать (рис. 41), что к классам Department и Person следует применить образец проектирования Publish-Subscribe, причем класс Department играет роль Publisher, а класс Person играет роль Subscriber.

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

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

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

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

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

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

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

Замечание Вставка утверждений в программу иногда называется аннотированием программ.

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

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

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

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

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

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

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

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

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

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

отсутствие стадии автономной отладки и, как следствие, более тщательное и дисциплинированное оформление программистами кода с самого начала;

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

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

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

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

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

синтаксически ориентированный текстовый редактор;

комментарии;

дисциплина имен;

расположение текста.

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

Например, могут предусматриваться следующие возможности:

автоматическое завершение ввода стандартных лексем языка;

клавиатурные комбинации для ввода стандартных лексем языка;

автоматический ввод парных ограничителей (скобок);

автоматическое выравнивание и отступ;

автоматические выделение (например, цветом) лексических и синтаксических конструкций;

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

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

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

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

Современные императивные языки программирования, которые называются языками "высокого уровня"94 на самом деле имеют очень низкий уровень. Низкий уровень языка проявляется в том, что смысл программы не так просто усмотреть в ее тексте. Причина заключается в очень низком (можно сказать, примитивном) уровне архитектуры (системы команд) современных массовых компьютеров и незначительных алгоритмических возможностях компиляторов языков программирования. Замечание Формальный язык совсем не обязательно должен иметь низкий уровень. Вот два примера:

язык алгебраических формул, UML.

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

Комментарий – это неопределяемое расширение языка.

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

Замечание Этот принцип особенно хорош для распространенных императивных процедурно ориентированных языков, в которых все семантически существенные объекты (модули, процедуры, переменные и константы) именованы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Специфические особенности (например, области видимости или времени жизни имени).

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

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

различение регистра букв в идентификаторах;

ограничения на общую длину и/или на длину распознаваемой части идентификатора.

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

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

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

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

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

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

Окончание используется для индивидуализации имен, которые по всем остальных признакам совпадают. Например, следуя венгерской нотации, переменные для хранения вещественных корней квадратного уравнения в процедуре Visual Basic можно было бы назвать dblRoot_1 и dblRoot_2 (здесь dbl – это приставка, задающая тип, Root – это корень, а _1 и _2 – окончания; префикс и суффикс не использованы). Кроме того, в конкретной дисциплине имен регламентируются (часто в виде предопределенных списков) наборы возможных значений кодовых частей (таких как префикс и приставка), определяются правила (неформальные) выбора корней, суффиксов и окончаний, а также правила, по которым можно опускать те или иные части идентификатора. Для многих языков и систем программирования имеются детальные описания конкретных диалектов венгерской нотации. Венгерская нотация является неплохой дисциплиной имен и ее можно рекомендовать к использованию, особенно в следующих обстоятельствах:

венгерская нотация уже строго описана (имеется стандарт) для данного языка и системы программирования;

проект предусматривает передачу кода и заказчик не возражает против данной дисциплины имен;

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

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

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

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

Локализованные версии языков программирования не популярны. Язык программирования далек от естественного и не должен быть к нему близок. Служебные слова языка программирования – это иероглифы, а не слова из букв. Иероглифы легче выучить и использовать, если они ни на что не похожи.

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

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

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

Замечание Величина отступа должна строго соответствовать семантической вложенности конструкций. Решение вопроса о том, что с чем следует выравнивать по вертикали должно опираться на семантику языка, а не на случайные особенности синтаксиса. Очень удобно придерживаться следующего принципа: удаление и вставка вложенных конструкций всегда выполняется над целой строкой. Например, function Next (x : integer) : integer; begin end;{Next} существенно лучше, чем более привычная запись function Next (x : integer) : integer;

Пробелы и пустые строки. В большинстве языков почти все пробелы, равно как и пустые строки, игнорируются, а несколько пробелов эквивалентно одному. Разумное употребление пробелов и пустых строк позволяет до некоторой степени компенсировать убожество Высший класс – записывать русские слова латинскими буквами, которые по написанию совпадают с кириллическими буквами. К сожалению, таковых немного (например, среди прописных: A, B, C, E, H, K, M, O, P, T, X) и этот метод требует невероятной изобретательности.

Например, в таком стиле: CurRecNum означает "номер текущей записи".

моноширинных шрифтов фиксированного кегля, которые навязывают некоторые (даже сравнительно современные) системы программирования.

Замечание При употреблении пробелов и пустых строк важны единообразие и чувство меры.

Ширина строки. Большинство читателей программ привыкло, что основная конструкция языка (оператор) занимает одну строку программы, во всяком случае начинается с новой строки.102 Отступление от этого принципа сейчас вряд ли можно чем-либо оправдать. Однако бумага и экран, на которых отображается текст программы, имеют весьма ограниченную ширину.103 Это не составляет проблемы в лаконичных языках типа Форт, но в многословном Visual Basic приходится пользоваться такими устаревшими приемами, как символ продолжения строки и т.п. Текст программы хорошо читается, если примерно половина знакомест пусты, а по ширине в среднем занято примерно две трети отведенного пространства.

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

За прошедшие четверть века ситуация изменилась, но все еще оставляет желать лучшего:

доля тестирования и отладки в среднем неприемлемо велика.

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

Развитие технологии программирования за прошедший период, ориентированное на повышение продуктивности, шло по трем основным направлениям:

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

совершенствование методов тестирования и отладки с целью снижения трудозатрат на этот процесс (при заданном объеме);

совершенствование самого программирования с целью уменьшения объема тестирования и отладки.

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

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

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

(см. раздел Инструментальные средства) и обеспечить их освоение и использование программистами.

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

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

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

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

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

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

заданного интервала времени t количество известных ошибок не превышает пороговой величины n (обычно полагают n=0). Такой подход к управлению тестированием, применяет, например, Microsoft, подробности описаны в дополнительных материалах MSF. Понятно, что как и в любом другом статистическом методе, для получения значимых результатов нужно прогнать достаточно много тестов,105 поэтому тестирование оказывается весьма трудоемким процессом. Предлагается использовать автоматическое тестирование и генерацию тестов, что требует разработки специального инструментального средства (отладочного средства). Регрессионное тестирование наиболее целесообразно использовать в больших проектах и в проектах, связанных с разработкой горизонтальных приложений.

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

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

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

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

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

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

щищенность данных, способность к восстановлению после ошибки, понятность интерфейса и др.

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

Ход тестирования, выявленные ошибки и приятые меры по их исправлению фиксируются в базе данных тестирования.

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

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

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

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

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

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

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

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

Локализованную ошибку надлежит исправить. Исправление ошибок также имеет различные формы:

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

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

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

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

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

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

Это не bug, а feature.

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

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

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

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

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

• Модель жизненного цикла программы в дисциплине программирования согласована с моделью процесса.

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

• Дисциплина программирования постулирует примат проектирования над кодированием, тестированием и отладкой.

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

• Кодирование в дисциплине программирования следует общепринятым правилам хорошего стиля и рассматривается как публичная деятельность, а код является корпоративным достоянием.

• Тестирование в дисциплине программирования является планируемым и протоколируемым.

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

40-часовая рабочая неделя

Автоматическая верификация программы Кодирование

Акт сдачи-приемки

Активный интерфейс

Аннотирование программ

Артефакт

Архитектура клиент/сервер..................106 Конструктор

Архитектура приложения

Архитектура программного обеспечения Контроль качества

Архитектурная метафора

Безошибочное программирование.......130 Линейная стратегия

Бригада проекта

Валидация

Венгерская нотация

Верификация

Веха

Взаимодействие

Виртуальные машины

Виток

Выпуск

Декларативное программирование........96 Модель водопада

Дерево субординации

Деструктор

Диаграмма "сущность-связь"...............116 Модель звезды

Дизайнер форм

Динамическое планирование.................38 Модель команды равных

Динамичность интерфейса

Дисциплина имен

Дисциплина программирования 12, 89, 99 Модель процесса

Доказательство правильности программ Модуль

Должностная структура

Должность

Доступный заказчик

Жизненный цикл программы.................13 Непрерывная интеграция

Заинтересованное лицо

Иерархическая модель

Императивное программирование.........96 Обзор

Инженерный анализ программы............28 Образец

Инкапсуляция

Инкремент

Инкрементная модель процесса.............35 программирование

Инспектирование

Инструмент

Инструментальная программа................20 Отладка

Интерфейс

Информатика

Итерационная стратегия

Оценка риска

Пакетный режим

Парадигма программирования...............92 Сопровождение программы

Парное программирование

Пассивный интерфейс

Периодическая отчетность

Полиморфизм

Постоянство объектов

Потоки данных

Представительное тестирование..........130 Стандарты кодирования

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

Принцип единоначалия

Пробел

Программирование

Программирование без go to..................93 Тестирование применимости................ Программирование вширь..............94, 123 Тестирование удобства и простоты Программирование по образцу............119 использования

Программирование сверху вниз.............94 Тестирование устойчивости................. Программирование снизу вверх.............94 Тестирование функциональности........ Продолжающаяся разработка.................32 Технология программирования................ Продукционное программирование......96 Трассировка

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

Проектно-ориентированная организация Трехслойная архитектура

Простое проектирование

Прототип интерфейса

Процедурное программирование...........96 Учет рабочего времени

Процесс

Пустая строка

Работник

Реализация

Регрессионное тестирование..........31, 131 Частые выпуски

Репозиторные архитектуры

Рефакторинг

Роль

Руководитель проекта

Системное тестирование

Системный аналитик

Скелет кода

Служба

1. Бек К. Экстремальное программирование. – Спб.: Питер, 2002.

2. Брауде Э. Технология разработки программного обеспечения. – СПб. : Питер, 2004.

3. Брукс-мл. Ф. П. Как проектируются и создаются программные комплексы. М.:

Наука, 1975; новое издание перевода: Мифический человеко-месяц. СПб.:

4. Вирт Н. Алгоритмы + структуры данных = программы. М., Мир, 1978.

5. Вирт Н. Систематическое программирование. Введение. М.: Мир, 1977.

6. Дал У., Дейкстра Э., Хоор К. Структурное программирование. М.: Мир, 1975.

7. Дейкстра Э. Дисциплина программирования. М.: Мир, 1978.

8. Орлов С. Технологии разработки программного обеспечения. – СПб.: Питер, 2002.

9. Терехов А.Н. Технология программирования. М.: БИНОМ, 2006.

10. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. СПб : Питер, 2002.