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

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

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

Все дело в том, что объектная технология испытывает затруднения из-за наивной мифологии. Айвар Джекобсон (Ivar Jacobson), гуру в объектной технологии, отмечает, что наивные объектные модели приводят к программному обеспечению, которое ненадежно в условиях изменяющихся требований и целей. Наивные объектные модели основаны на примитивном поиске программной среды для объектов из «реального мира». Далее поведение объектов отображается в объектных классах. Практика описания поведения с помощью кнопок и пиктограмм, представляющих объекты из реального мира, является не менее наивной и ведет к созданию ненадежных интерфейсов.

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

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

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