Человеческий фактор в программировании
Шрифт:
Другой областью, в которой можно применять сущностные модели, является модернизация процессов. Если модернизация процессов не является простым эвфемизмом, за которым скрывается приостановка производства или сокращение штата, то она позволяет сделать бизнес-процессы более эффективными и результативными. Для успешной модернизации некоторого процесса вы должны знать, для чего этот процесс предназначен, каким фундаментальным задачам или какой организационной цели он служит. Самым существенным вопросом в любом процессе или системе является телеологический вопрос: почему это существует? Почему это должно существовать? Для чего оно, вообще говоря, нужно?
Рассмотрим процесс обмена валюты в банке. В некоторых странах в некоторых банках бывает необходимо два или даже три раза встать в очередь, заполнить многостраничные
Вовсе необязательно, чтобы клиент банка или банковский служащий заполнял бланки в трех экземплярах с указанием имен, адресов и с личными подписями и суммами (в цифрах и прописью) на каждом экземпляре. Курсы обмена не нужно проверять вручную, если они поступают из центральной базы данных. Дисплей, на который смотрит клиент, может служить для подтверждения суммы — подобная услуга практикуется в магазинах. Распечатка о выполненной операции, выдаваемая клиенту, может пригодиться ему для отчетности. Сохранение информации об операции в архиве может использоваться для аудиторского отслеживания выполненных сделок. И в самом деле, в Европе я пользовался автоматами по обмену валюты, которые работали именно по такому, ускоренному методу.
К сожалению, многие профессионалы испытывают затруднения в выявлении сути задач. Не каждый способен к абстрактному мышлению, необходимому для сущностного моделирования. Обдумывание сути требует отказа от технических шор, мешающих увидеть предметы в новом свете. Меилир Пейдж-Джонс (Meilir Page-Jones) называет это «разыменовыва-нием», мысленным выходом за рамки принятых понятий и представлений. Особенно это удается одаренным комедийным актерам и талантливым дизайнерам.
Вспоминаю, как однажды я ехал с Меилиром на машине вдоль реки Рейн. По дороге он переводил мне смысл надписей на немецком языке, мимо которых мы проезжали. На одном из знаков какая-то черная масса клонилась влево к волнистым линиям. Между изображениями насыпи и самой реки была показана машина, зависшая в воздухе.
Меилир сразу же перевел мне: «Остерегайтесь машин, выпрыгивающих из воды слева».
Разыменовывайтесь. Попробуйте. И старайтесь думать по существу. Из журнала Software Development, том 2, № 11, ноябрь 1994 г.
23
Будущие формы
CASE умер? Многие жрецы программирования объявляли, что смерть уже наступила. Однако на каждого плакальщика всегда находится тот оптимист, который верит в воскресение из мертвых, а на каждого очернителя находится свой ликующий поборник. Ведомое духом времени, в 1994 году Австралийское компьютерное сообщество (Australian Computer Society, ACS) собрало в Мельбурне две звездных команды австралийских консультантов и специалистов-практиков. Руководили командами сторонник Грэме Симшн (Graeme Simsion) и скептик Роб Томсет (Rob Thomsett). В ходе дискуссии, названной «великим спором о CASE», обсуждались все «за» и «против» в вопросе, как обстоит дело с CASE в Австралии. Этот спор стал весьма значительным событием для такого консервативного сообщества, как ACS, — настолько, что привлек даже больше внимания, чем презентация книги бывшего премьер-министра, которая проводилась в этом же зале несколькими часами ранее. По неизвестным причинам меня втянули в этот спор в качестве члена опровергающей команды. Томсет, которого Симшн называл самым диким консультантом Австралии, привел нашу команду к победе, хотя к концу обсуждения было видно, что обе стороны находились приблизительно на одном уровне.
Действительно, слухи о грядущем погребении CASE вызывают непонимание, поскольку CASE — это (дословно) не более чем проектирование и создание программ с помощью компьютеров. Неужели компьютеры перестали оказывать в этом помощь? Или отрасль проектирования и создания программ прекратила свое существование? Будем надеяться, что не случилось ни то ни другое. CASE не исчез и не обречен, хотя и может заметным образом declasse. [30] Следуя своему вечному стремлению приукрашивать
и восхвалять то, что они когда-то вознесли до уровня святости, ученые мужи от промышленности все чаше заменяют термин CASE на «интегрированные среды разработки». Во всяком случае в последний месяц это было так.30
Быть деквалифицированным (фр.)
Конечно, отчасти проблема заключается в необоснованных ожиданиях, которые подогревались рекламными кампаниями производителей программного обеспечения, а также в надеждах, питаемых любителями выдавать желаемое за действительное. Даже самый великолепный из реальных инструментов будет вызывать разочарование, поскольку почти каждый в нашем деле находится в вечном поиске меча короля Артура для программирования. Другая трудность состоит в том, что разработчики и производители инструментов CASE часто не разбирались ни в моделях и моделировании, ни в тех методах, для поддержки которых предназначались их инструменты. Более того, эти CASE-инструменты просто-напросто не были тем, что необходимо для ускорения разработки и повышения качества программ. Необходимо нечто, дающее одновременно и больше и меньше того, что дает большинство инструментов CASE. Нам следует посмотреть на визуальные среды разработки, чтобы понять, чем должны были и чем еще могут стать инструменты CASE.
Визуальные среды разработки — это одни из самых ярких и крепких нитей в клубке современных методов и продуктов. Визуальная разработка связана с большим разнообразием инструментов и подходов, позволяющих разработчикам создавать код посредством прямого манипулирования визуальными объектами в графическом пользовательском интерфейсе (ГПИ). Самым старым и известным образчиком этого жанра является Visual Basic компании Microsoft. Более поздние продукты, такие как Vis-ualAge компании IBM и Delphi компании Borland, стали вбирать все лучшее из возможностей визуального проектирования. Хотя изначально большинство таких продуктов в основном предназначались для разработчиков приложений, парадигма визуального проектирования может в конце концов стать будущим каждого.
Программное обеспечение для визуальной разработки является всего лишь технологией, но такой технологией, которая может радикально изменить методику разработки программного обеспечения. В самом чистом виде визуальное проектирование позволяет создавать полностью рабочие системы — в значительной степени или исключительно с помощью перемещения визуальных объектов по экрану монитора. Прямое манипулирование графическими элементами является очевидным подходом к разработке графических пользовательских интерфейсов. Именно здесь и началось визуальное проектирование — с применением так называемых конструкторов графических пользовательских интерфейсов. При использовании многих ранних инструментов сложность состояла в том, что за внешней стороной приятного на вид интерфейса скрывался самый отвратительный или беспорядочный код на Basic или С++ из всех, что когда-либо придумывались. Код «за экраном» был в полной неразберихе, и вам приходилось пробираться через это месиво, чтобы заставить работать хоть что-то.
Когда проектируемые системы становятся действительно сложными, разработчики стремятся строить модели на более высоких уровнях абстракции, чтобы описывать и отражать архитектуру системы, а не только ее конструкцию или поверхностные проявления в виде пользовательского интерфейса. Для этого программные единицы и взаимосвязи между ними должны быть представлены визуально. Вам нужно видеть модули, классы и объекты, а также сообщения и ссылки, которые возникают между ними. Вам нужно видеть структуру вашего кода, выраженную с помощью знакомой системы обозначений. Необходима возможность перемещения по этой структуре с помощью устройства, названного Дж. Д. Хилдебрэндом визуальным броузером (J. D. Hildebrand, 1994). Вам нужно, чтобы вы могли, проведя линию, передать информацию из одного места в другое. Вам хочется иметь возможность перенести метод из одного класса в другой с помощью перетаскивания мышью. В общем, вам нужен неизменно активный инструмент CASE с динамическими встроенными механизмами конвертации кода, которые позволяют сразу переводить в код все то, что вы делаете в виде картинок, и наоборот.
31
ГПИ — графический пользовательский интерфейс