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

Модель команды равных является составной частью Microsoft Solutions Framework (MSF) — методологии разработки программных проектов фирмы Microsoft. Это наиболее демократичная модель, поскольку в ней нет явно выделенного центра. Модель команды MSF — это команда равных. Схематически ее принято изображать в виде цикла (рис. 32), где все роли равноправны и связаны друг с другом.

Модель команды MSF (цикл) пользователей Рис. 32. Модель команды равных Замечание Чтобы подчеркнуть отсутствие иерархии в команде равных, роли в команде обозначаются не названиями должностей, а названиями функций.

Преимущества модели команды равных.

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

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

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

Основные недостатки модели MSF являются продолжением ее достоинств.

Для формирования команды MSF нужны равные (равно квалифицированные и равно заинтересованные) участники.

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

Демократичная модель команды MSF плохо сопрягается с жесткой иерархической моделью подразделения (предприятия).

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

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

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

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

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

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

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

На данном этапе развития организация ориентирована на разработку вертикальных приложений масштаба предприятия. Типичный объем таких проектов составляет от 2 месяцев 1 человек до 9 месяцев 3-5 человек. Сверх оперативные (on-line) и сверх большие проекты не рассматриваются. Организация выполняет параллельно 5-10 таких проектов. Таким образом, модель команды должна допускать масштабирование в пределах 10–50 человек.

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

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

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

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

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

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

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

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

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

Проектирование. Составление бумажных и/или электронных человеко- и/или машинночитаемых концепций, моделей, спецификаций и планов.

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

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

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

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

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

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

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

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

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

Аналитик. Функции: планирование, администрирование. Вехи: Концепция, Обследование, Техническое задание, Функциональные спецификации, Внутренний язык, Дополнительные требования, План тестирования, План внедрения, Логический проект, Схема базы данных, Документация.

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

Администратор. Функции: администрирование, планирование. Вехи: Техническое задание, Календарный план-график, План тестирования, План внедрения, Документация.

Программист. Функции: проектирование, кодирование, тестирование, сопровождение. Вехи: Прототип, Логический проект, Схема базы данных, Дизайн интерфейса, Физический проект, Код готов, Нет известных ошибок, Исходные тексты, Документация.

Тестировщик. Функции: тестирование. Вехи: Выпуск, Нет известных ошибок, Исходные тексты, Документация.

Эксплуатационник. Функции: сопровождение, тестирование. Вехи: Документация, Решение развернуто, База данных загружена, Пользователи обучены.

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

Перечисленный список ролей может быть расширен в соответствии со спецификой проекта.

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

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

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

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

Должность — это сертифицированная способность играть определенные роли и выполнять определенные функции.

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

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

Начальник (отдела).

Руководитель (группы).

Исполнитель (инженер, технический специалист).

Замечание по конструированию Наличие именно трех уровней иерархии должностей обусловлено ограничением на масштабируемость: 10-50 человек и наличием известной константы, ограничивающей ширину ветвления в дереве субординации: 7±2. Т.е. в иерархической структуре руководитель любого уровня должен иметь не менее 5 и не более 9 прямых подчиненных.

Замечание по конструированию Высшее руководство (дирекция) моделью команды не охватывается.

Конструируемая модель команды предусматривает назначение каждому участнику проекта функции, роли и должности, причем это назначение не является постоянным, а меняется со временем по определенным правилам:

• функция (функции) назначается динамически на каждую фазу, • роль (роли) назначается статически на время проекта • должность назначается статически, т.е. постоянно.

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

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

Назначение на должность не зависит от участия или не участия сотрудника в проектах.

Замечание по конструированию Изобразить на одной диаграмме статико-динамическую структуру модели команды оказывается затруднительным. Поэтому ниже приведены примеры трех указанных структур для некоторого условного проекта. В приведенных на рис. 33-35 диаграммах латинские буквы A, B, C… обозначают конкретных людей, одних и тех же на всех диаграммах. Таким образом, из примеров видно, как может меняться функция и роль конкретного человека по ходу проекта.

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

E F G H I J

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

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

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

Организационный порядок назначения Руководителя проекта описан в разделе Порядок проведения типового проекта.

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

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

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

4.5.5. Распределение полномочий и ответственности Распределение полномочий и ответственности в модели команды имеет статикодинамический характер.

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

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

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

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

Замечание по конструированию Согласование по транзитивности (т.е. только со старшим начальником, а не с непосредственным начальником) не рекомендуется моделью команды.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таким образом, весь материал этой темы является развернутым примером, в который вкраплены некоторые теоретические отступления.

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

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

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

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

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

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

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

Приведенный абзац является кратким упрощенным пересказом некоторых положений знаменитого письма Дейкстры GO TO statements considered harmful, которое положило начало технологии программирования, как самостоятельному направлению программистской мысли (см. разд. 1.2.2).

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

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

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

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

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

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

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

Замечание Д. Кнут назвал свое выдающееся произведение The Art of Computer Programming (Искусство программирования для ЭВМ) не случайно. Эта монография является, по-видимому, наиболее представительным собранием шедевров искусства программирования.

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

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

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

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

отсутствие унифицированной и сертифицированной технологии производства;

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

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

отсутствие стандартной системы измерений (метрологии);

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

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

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

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

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

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

Как следствие ремесленного характера производства, в программировании наблюдаются:

широчайший разброс в показателях производительности и продуктивности труда;

низкая трудовая и производственная дисциплина;

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

очень высокая себестоимость продукции;

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

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

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

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

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

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

Исторически первой оформленной парадигмой принято считать так называемое структурное программирование. Выявленная42 Э. Дейкстрой обратная зависимость между долей неограниченных операторов перехода Go To и качеством (надежностью, скоростью отладки) программы привела к бурному развитию концепции структурного программирования, которое большинством рядовых программистов было понято как "программирование без go to".

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

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

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

Рис. 36. Базовые структуры управления программирования без Go To Каждая из базовых структур обладает свойством один вход – один выход; этой свойство сохраняется при суперпозиции двух базовых структур; следовательно, свойством один вход – один выход обладает любая суперпозиция и, таким образом, любая структура обладает таким свойством. Наличие свойства один вход – один выход ценно тем, что позволяет установить простое соответствие между статическим текстом программы и динамическим протоколом ее выполнения. Для линейных программ взаимно-однозначное соответствие очевидно; для линейно ветвящихся программ очевидно однозначное соответствие из текста в протокол, для циклических программ соответствие устанавливается, если добавить к естественной координате в тексте (от начала к концу) еще по одной целочисленной координате (обычно называемой счетчиком цикла) для каждого уровня вложенности циклов. Таким образом, программирование без go to позволяет разрешить (до некоторой степени) первое противоречие – между статикой и динамикой.

Замечание Различного рода синтаксический сахар (Switch, Repeat, For Next, For Each и т.д.) не меняет сути дела, потому что принцип один вход – один выход сохраняется. Поэтому наличие или отсутствие структур управления в языке почти не влияет на программирование. Замечание Наличие или отсутствие в языке ограниченных операторов перехода (break, exit, signal и т.д.) также не меняет сути дела по той же причине. Ограниченные переходы полезны, потому что позволяют писать более короткие и эффективные программы той же степени структурности. Наличие иерархической структуры вложенности позволяет (до некоторой степени) разрешить и второе противоречие. А именно, последовательное развертывание структуры вложенности обеспечивает деление задачи на подзадачи и, таким образом, на каждом шаге ограничивает комбинаторную сложность. Это называется программированием методом пошагового уточнения. Все системы программирования (кроме уже забытых самых ранних) в той или иной форме поддерживают понятие модуля. В разных системах программирования модули называются и определяются по разному: подпрограмма, функция, класс, модуль, компонента и т.д.

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

Это наглядно продемонстрировано в известной статье Д. Кнута Structured programming with go to.

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

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

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

Программирование сверху вниз – это обобщающее название для модульного программирования без Go To методом пошагового уточнения. Английское название – Top-down approach – более точно акцентирует важнейшее достижение технологической программистской мысли, аккумулированное в этом подходе: проектирование и реализация (кодирование) программы являются двумя неразрывно связанными фазами одного процесса, причем проектирование первично, а реализация вторична. При программировании сверху вниз процесс программирования заключается в следующем. Исходная задача разлагается на подзадачи до тех пор, пока подзадача не станет столь простой, что ее реализация становится очевидной.

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

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

По-английски это называется bottom-up approach.

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

Лавров Святослав Сергеевич (1923–2004) – российский ученый, член-корреспондент РАН (1991; член-корреспондент АН СССР с 1966). Труды по механике, автоматическому управлению, вычислительной математике. Ленинская премия (1957).

Научная биография С. С. Лаврова в определенном смысле уникальна. Совсем в молодом возрасте С. С. Лавров стал основоположником ракетно-космической баллистики в СССР и неоспоримым авторитетом Лавров С.С. Программирование.

в области динамики управляемого полета Математические основы, средства, и автоматического управления. Появление теория. – СПб., БХВ-Петербург, цифровой вычислительной техники приве- Лавров С. С. Лекции по теории ло к резкому повороту в деятельности программирования. – СПб, НЕСТОР, сделало его классиком программирования в СССР. Он разработал первый отечественный транслятор Алгола и программное обеспечение первых полетов человека в космос.

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

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

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

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

Т.е. нет никакой автономной отладки, отладка с самого начала комплексная.

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

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

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

Собственно логическое программирование базируется на следующем фундаментальном факте: из конструктивного доказательства теоремы существования x(P(x)yQ(x,y)) может быть эффективно извлечена (аннотированная) программа {P(x)}y:=f(x){Q(x,y)}.

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

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

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

Продукционная программа состоит из набора продукций (правил) вида if P(D) then D:=f(D), которые применяются к глобальной базе данных D, пока не будет удовлетворено условие окончания. Продукционные программы обладают предельной модульностью, являются чрезвычайно легко модифицируемыми и часто применяются для программирования экспертных систем. Управление неявное (определяется стратегией), а переменные всегда глобальные (база данных D).

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

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

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

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

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

5.2.3. Объектно-ориентированное программирование Парадигма объектно-ориентированного программирования (далее ОО программирование) — это наиболее популярная в данный момент парадигма, которая является консервативным расширением упомянутых выше подходов.

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

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

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

См. Н.Вирт. Программы = Алгоритмы + Структуры данных.

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

Замечание Интересно и поучительно проследить историю развития ОО программирования. Все перечисленные понятия и идеи известны с 1968 года (СИМУЛА-67), в рафинированном виде были оформлены в теоретических работах к 1978 году (Б. Лисков и многие другие), получили общепризнанное языковое выражение к 1988 году (С++) и стали естественным инструментом для профессиональных программистов к 1998 году.

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

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

Из сказанного следует важный вывод:56 объектная ориентированность является атрибутом стиля программирования, присущего конкретному программисту, а не предопределяется используемым языком или системой программирования. В любой системе программирования, даже в той, где нет никаких специальных средств поддержки объектов и классов, можно создавать ОО программы, используя все преимущества ОО программирования, равно как и в самой современной ОО системе никто не застрахован от безнадежно недисциплинированного манипулирования объектами. Более того, в некоторых случаях слишком автоматизированные средства ОО программирования мешают ОО программированию, поскольку навязывают программисту конкретные решения. Например, в большинстве современных систем ОО программирования требуется, чтобы метод был отнесен в точности к одному классу, хотя это отнюдь не всегда естественно и удобно. С парадигмой ОО программирования связано развитие и практическое воплощение важной мысли, (уже упомянутой в разделе Структурное программирование) о неразрывной связи проектирования и кодирования и о примате проектирования. Человек мыслит реальный мир состоящим из объектов.58 Кодированию всегда59 предшествует проектирование, важнейшей частью которого является моделирование, т.е. вычленение в предметной области задачи объектов и связей, которые существенны для решения задачи. ОО программирование позволяет установить прямое соответствие между программными конструкциями и объектами реального мира через объекты модели. Таким образом, ОО система программирования поддерживает не только кодирование, но и (до некоторой степени) проектирование. При написания ОО программы основные усилия программист тратит на определение состава классов, их методов и свойств. Эта информация является в чистом Впервые этот термин был введен И.В. Романовским в статье "Программирование в терминах служб" (1974). Часто используемый сейчас эквивалентный термин "сервис", полученный прямой транслитерацией, гораздо менее удачен с точки зрения чистоты русского языка.

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

Утрируя, можно сказать, что самым ОО языком является Фортран, поскольку он не навязывает никаких ОО решений.

Это свойство нашего мышления, но не свойство реального мира.

У неумелых программистов неявно и бессознательно, у умелых – явно и осознанно.

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

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

Дисциплина программирования нацелена на решение следующей экстремальной задачи:

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

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

Повышение продуктивности программирования возможно за счет двух основных факторов:

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

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

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

синтаксические ошибки — нет исполнимой программы;

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

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

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

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

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

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

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

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

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

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

Центральной идеей дисциплины программирования является выбор уровня формализации информации, циркулирующий в циклах повышения продуктивности (см. рис. 38), проходящих через программистов и заказчиков. Если информация, циркулирующая в левом цикле, представлена совершенно формально, например, в виде программного кода, то она оказывается недостаточно гибкой (т.е. недостаточно легко модифицируемой) для повторного использования при проектировании. Если информация, циркулирующая в правом цикле, представлена совершенно неформально, например, в виде текстов (устных или письменных) на естественном языке, то она оказывается слишком гибкой (т.е. неоднозначной и неопределенной) для использования при анализе и последующем проектировании. Опыт и принцип экономии мышления подсказывают, что в обоих случаях следует использовать один и тот же уровень формализма. Более того, в обоих циклах можно и нужно использовать одно и то же средство представления информации, каковым на сегодняшний день может и должен служить в унифицированный язык моделирования UML (Unified Modeling Language).

В циклах повышения продуктивности можно выделить типы информации и направление ее движения, как показано на рис. 38: Пользовательские требования (или внешние спецификации) — от заказчиков на фазы анализа и проектирования; Пользовательская документация (или детальные спецификации) — от фаз стабилизации и внедрения к заказчику; Реализованный компонент со спецификацией (важно наличие кода) — от фазы реализации к программистам; Специфицированный компонент (важно наличие спецификации)64 — от программистов (или из репозитория) к фазе проектирования.

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

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

Рис. 38 немного уточняет рис. 4.

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

На рис. 4 и 38 отсутствуют фазы опытной эксплуатации и внедрения. Это сделано только для наглядности рисунка. На самом деле эти фазы подразумеваются.

Или в репозиторий.

При проектировании вполне можно использовать еще не реализованные компоненты, лишь бы они были хорошо специфицированы!

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

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

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

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

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

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

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

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

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

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

Замечание Традиционно считается, что самым понятным является текст с иллюстрациями. Но иллюстрации с текстом еще понятнее, т.к. короче — из текста удалена связующая "вода".

Диаграммы UML хорошо подходят для спецификации интерфейсов.

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

Графическая форма моделей UML является наиболее наглядной из известных.

Замечание Конечно, использование UML не избавляет от риска составить совершенно ненаглядную, перегруженную и непонятную модель. Но это уже проблема субъекта моделирования, а не средства моделирования.

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

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

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

На архитектуру приложения (или программного решения иного типа) оказывают влияние множество факторов:

тип приложения (информационная система, система управления, встроенная система и т.п.);

характер использования (одноразовая, индивидуальная, групповая, массовая программа);

дополнительные требования (надежность, секретность и пр.);

предметная область (бизнес, наука, транспорт и т.п.);

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

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

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

Рассматриваемые приложения имеют следующие характерные особенности:

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

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

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

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

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

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

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

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

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

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

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

наличием в современных системах программирования и операционных системах для данной архитектуры развитого механизма поддержки, называемого событийным управлением69 (event-driven), который описан ниже;

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

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

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

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

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

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

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

Поэтому событийное управление называют еще асинхронным.

В современных системах программирования имеются богатые и все время развивающиеся библиотеки готовых компонент, которые называются элементы управления (controls), и которые тесно интегрированы со встроенными механизмами событийного управления.

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

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

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

Существуют три основных метода решения этой проблемы.

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

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

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

Мастер — это активный сценарий (как правило, линейный), выраженный средствами пассивного интерфейса.

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

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

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

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

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

активный сервер: сервер опрашивает клиентов на предмет наличия запроса.

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

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

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

Служба (service) — это программная конструкция, обеспечивающая набор выполнение набора операций (или услуг) с некоторыми объектами (или одним объектом).

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

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

Служба без памяти, т.е. служба не управляет временем жизни объектов, с которыми оперирует (например, машинная арифметика).

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

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

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

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

Служба обслуживает статически определенный набор объектов (как, правило, именованных).

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

Динамичность интерфейса: может ли меняться интерфейс службы, т.е. может ли меняться сигнатура и/или семантика услуг службы. Возможные значения этой характеристики:

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

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

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

В таблице 6 приведены некоторые примеры способов реализации служб.

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

Так называемая "преемственность снизу-вверх".

Распространен предрассудок, что только синтаксис вида Object.Method(Arguments) является допустимым в ОО программировании. Синтаксис Method(pObject,Arguments) ничуть не хуже, а зачастую лучше. Например, если объект Человек имеет свойство Семейное_положение и метод Вступить_в_брак(супруг:Человек), то обеспечить необходимую целостность данных не просто. Эта проблема исчезает, если имеется служба (без памяти!) ЗАГС, у которой есть метод Регистрация_брака(муж,жена:Человек).

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

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

Таблица 7. Трехслойная архитектура приложения Пользовательский интерфейс (User Services) Ввод и отображение информации, навигация в приложении Бизнес-правила (Business Services) Принятие решений, обработка данных Управление данными (Data Services) Доступ к данным Трехслойная архитектура обладает целым рядом очевидных структурирующих достоинств:

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

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

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

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

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

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

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

Замечание Приведенная аналогия носит условный характер. Например, для современного CAD/CAM производства чертежи могут быть электронными моделями, а воплощение "в металле" может иметь форму перфоленты для станка с ЧПУ. Тем не менее, эта аналогия полезна, поскольку показывает направление, в котором ориентированы методы проектирования программ в дисциплине программирования. Целью является приближение моделей программ к тем значениям показателей управляемости, повторного использования, надежности и качества, которые достигнуты в схемах инженеров-электронщиков или чертежах инженеровавтомобилестроителей. Проектирование программы (в широком смысле этого слова) имеет различные цели и может принимать разные формы. В дисциплине программирования различаются следующие виды проектирования: • концептуальное проектирование;

• логическое проектирование;

• детальное проектирование.

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

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