Человеческий фактор в программировании

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

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

Создание эскизов

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

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

Альтернативы и альтернативные точки зрения

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

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

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

Даже так называемые «интегрированные» наборы CASE-инструментов обычно не дают возможности просто и быстро переходить от одной модели системы к другой. Такие переходы должны осуществляться одним нажатием клавиши. Еще лучше, если будет предусмотрена возможность наглядного сопоставления. Окна не очень подходят для этого. К тому времени, как вы откроете два окна в CASE-инструменте, работающем в оконном режиме или среде, на экране уже не останется места, чтобы хорошо рассмотреть что-либо. Или будет виден только небольшой кусочек каждой схемы, или на экране будут отображены маленькие, нечитаемые символы и текст. Вряд ли компьютер может помочь[24] в разработке программного обеспечения!

Создание и оценивание

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

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

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

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

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

Следует ли нам оставить надежды и поставить CASE-инструменты на полку? Нет, надежда все же остается. Современные CASE-инструменты — это примитивные предшественники тех инструментов, которые нам действительно нужны. Они еще появятся.

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

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

Из журнала Computer Language Magazine, том 9, № 1, январь 1992 г.

19

Вопросы моделирования

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

Многие разработчики — особенно те, которые ломают головы над созданием микрокомпьютеров и рабочих станций, — имеют очень смутное представление о структурных схемах, диаграммах объектных коммуникаций, схемах информационных потоков и блок-схемах. Довольно многие из них никогда не рисовали функциональных иерархий и растерялись бы, обнаружив такие схемы на своем столе. Увидев Booch-грамму,[25] они подумали бы, что это какая-нибудь плохая новость, доставленная на желтой бумаге курьером из компании Booch Telecommunications.

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

коренной объектно-ориентированной разработке программ на основе создания прототипов. Схемы и диаграммы не находят своего места в быстро меняющемся мире скороспелых микроприложений, разрабатываемых с помощью методов визуального программирования и быстрого создания приложений. «У нас нет времени на рисование картинок. Нас поджимают жесткие сроки выпуска новой версии!» «Зачем вообще рисовать схемы, если можно просто писать код?» Это хороший вопрос. Для чего нужны эти рисунки?

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

На практике не все графические модели работают таким образом. Некоторые, например HIPO-схемы[26] и их вспомогательные методы от компании IBM, вполне заслуженно канули в лету. Другие страдают от громоздкости и сложности обозначений или механизмов их рисования. Первоначально CASE-инструменты появились как специальные инструменты рисования, облегчающие создание схем. Со временем они превратились в более комплексные средства, облегчающие разработку программного обеспечения.

Изобразите это

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

То же самое можно сказать и о компьютерных программах. В те времена, когда 64 Кбайт оперативной памяти было пределом, а в качестве операционной среды использовалась СР/М, было вполне возможно и разумно удерживать всю программу в своей голове. Но тот, кто говорит, будто сможет запомнить все детали в сотнях тысяч строк программы на С, говорит неправду — если не вам, то себе. Именно здесь возникает необходимость в моделях проектирования.

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

Управление сложностью

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

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

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

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

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

Как же отличить хорошую модель от плохой, а плохую от безобразной? Оставайтесь с нами.

Из журнала Software Development, том 2, № 2, февраль 1994 г.

20

Свет мой, зеркальце

«Свет мой, зеркальце, скажи, да всю правду доложи: я ль на свете всех милее»? Злой королеве из «Белоснежки» достаточно было посмотреть в зеркало, чтобы получить точную картину. Разработчики программного обеспечения тоже должны иметь такую возможность. Им нужны хорошие зеркала, которые просто и точно отражают создаваемое программное обеспечение. Злая королева могла быть недовольна тем, что видела в зеркале; тем не менее ее зеркало давало достоверную и понятную картину.

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

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

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

Получение картины

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

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

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

.

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

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

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

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

Система обозначений и юзабилити

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

Разработка хорошей системы обозначений подобна разработке хорошего графического интерфейса. Целью здесь является сокращение нагрузки на человеческую память. Великий закон юзабилити утверждает, что система должна быть доступной для использования человеком, который знает о ее назначении, но не знаком с ее программным обеспечением. При этом не должно возникать необходимости в обучении, помощи или руководствах (Constantine, 1991 [14]). Таким образом, по-настоящему хорошая система обозначений — это такая система, которую опытный разработчик, знающий, как проектировать и писать программы, сможет интуитивно понять без шпаргалок и недельных курсов обучения. Вы не должны запоминать разные условные обозначения (например, то, что прямоугольник с двойной рамкой означает динамический объект, а прямоугольник с флажком в углу — компонент библиотеки).

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

Сильные связи между частями должны выглядеть, как сильные связи; слабые связи должны выглядеть, как более слабые. Устойчивые объекты должны быть показаны сплошными фигурами, а динамические объекты должны выражать смысл активности или изменяемости. Например, наследование одним классом свойств и характеристик другого класса означает, что подкласс в большой степени зависит от родительского класса — подобно тому как генетические особенности ребенка сильно зависят от особенностей обоих родителей. Для точного отражения характеристик программного обеспечения, использующего наследование, этот механизм должен быть показан более четко, чем передача сообщения объекту или ссылка на него как на атрибут (Page-Jones, Constantine и Weiss, 1990 [57]).

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

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

Подумайте об этом.

Из журнала Software Development, том 2, № 3, март 1994 г.

21

Методичное сумасшествие

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

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

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

Шаг первый

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

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

Разбиение

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

Мы имеем. Если мы сталкиваемся с неподатливой сложностью, то что мы делаем? То же, что делали наши предки, когда имели дело с огромной ногой мастодонта, которую нельзя проглотить: мы откусываем часть и начинаем ее пережевывать. Для того чтобы справиться с большой задачей, мы разбиваем ее на более мелкие. Здесь есть некоторая магия ума, махание руками, которое, вообще говоря, нисколько не уменьшает сложность задач, возникающих при программировании. Но зачастую это так или иначе помогает, создавая у перегруженного разработчика иллюзию, что большие, сложные системы можно построить из множества маленьких, простых кусочков кода.

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

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

В традиционном структурном проектировании эти принципы воплощены в общепризнанных понятиях связывания и сцепления. Связывание — это мера взаимосвязи и взаимозависимости между компонентами программного обеспечения; сцепление определяет, в какой мере компонент является четко определенным функциональным целым. Эти давно известные понятия были заново открыты в новом мире объектной технологии. Хорошие объектно-ориентированные методы напоминают программистам об уменьшении объектного связывания и об увеличении сцепления методов с помощью инкапсуляции всего необходимого в отдельный объект (Henderson-Sellers и Constantine, 1996 [39]). В противном случае вы получите запутанный клубок переплетенных между собой объектов, не поддающихся анализу и повторному использованию.

Структурное соответствие

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

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

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

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

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

Из журнала Software Development, том 2, № 5, май 1994 г.

22

Говоря по существу

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

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

Понятие сущностного моделирования в разработке программ происходит, по крайней мере, от идей структурного проектирования. Схемы потоков данных были придуманы в качестве непроцедурной модели вычислений, которая отделяла суть того, что должен был выполнить компьютер, от того, как это должно быть исполнено посредством алгоритма или процедуры. Модульная конструкция, соответствующая сути задачи, позволяет создавать более надежное программное обеспечение, основа которого сохраняется при изменениях в деталях процесса. По крайней мере, такова была идея. На практике схемы потоков данных зачастую превращались чуть ли не в обыкновенные блок-схемы с забавными символами. Последующие дополнения, такие как сохранение данных и управляю-щая логика, неявным образом способствовали процедурному мышлению. В конце концов сущностные модели получили признание с появлением книги «Essential Systems Analysis» (Основы системного анализа) (МсМе-namin и Palmer, 1984). Эта книга, признанная сегодня классической, сделала сущностные модели краеугольным камнем перестроенного и обновленного метода структурного анализа.

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

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

Сущностные интерфейсы

Разработка пользовательских интерфейсов — это одна из областей, где сущностные модели могут найти хорошее применение. Моделирование сущностных пользовательских ситуаций при проектировании интерфейсов является подходом, расширяющим разработанный Джекобсоном (Jacobson и др., 1992 [44]) метод объектно-ориентированных пользовательских ситуаций. Сущностная пользовательская ситуация — это абстрактный сценарий одного законченного и полезного взаимодействия с системой, рассматриваемого с точки зрения намерений или цели пользователя. Это обобщенное описание вида или категории использования системы, которое передает действия пользователя и ответы системы[28] в упрощенной и обобщенной форме. Суть идеи состоит в том, что разрабатываемые интерфей-сы должны соответствовать намерениям пользователей — тому, что пользователи хотят достичь. Исходные условия, связанные с технологией, — форма визуальных компонентов или даже вид устройств, применяемых для взаимодействия, — должны быть минимальны.

Для примера возьмем задачу по извлечению наличных денег из банкомата. Физическая модель может быть следующей: клиент вставляет карту; система читает информацию с магнитной полоски и запрашивает PIN-код;[29] пользователь вводит PIN-код; система подтверждает PIN-код и предлагает меню возможных операций; пользователь выбирает нужную операцию; система предлагает меню счетов; пользователь выбирает счет; система запрашивает сумму; пользователь вводит сумму и нажимает на кнопку подтверждения; система выдает наличность; пользователь берет деньги и убегает. Что может быть проще?

Магнитные полоски

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

Эта сущностная пользовательская ситуация также прокладывает путь к более простому интерфейсу, поскольку выделяет суть дела с точки зрения пользователя, а именно получение наличных денег, что является самой распространенной операцией, выполняемой с помощью карточек. Большинство пользователей регулярно снимают одну и ту же сумму с одного и того же счета. Первый вариант действия, предлагаемый системой, может соответствовать типичному выбору данного пользователя и воспроизводиться из памяти: «Обычные 250 долларов с текущего счета, мистер Чат-ворт?». Или что-то в этом роде.

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

Re: редизайн

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

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

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

Транс-действия