Текст книги "Человеческий фактор в программировании"
Автор книги: Ларри Константин
сообщить о нарушении
Текущая страница: 10 (всего у книги 26 страниц) [доступный отрывок для чтения: 10 страниц]
23
Будущие формы
CASE умер? Многие жрецы программирования объявляли, что смерть уже наступила. Однако на каждого плакальщика всегда находится тот оптимист, который верит в воскресение из мертвых, а на каждого очернителя находится свой ликующий поборник. Ведомое духом времени, в 1994 году Австралийское компьютерное сообщество (Australian Computer Society, ACS) собрало в Мельбурне две звездных команды австралийских консультантов и специалистов-практиков. Руководили командами сторонник Грэме Симшн (Graeme Simsion) и скептик Роб Томсет (Rob Thomsett). В ходе дискуссии, названной «великим спором о CASE», обсуждались все «за» и «против» в вопросе, как обстоит дело с CASE в Австралии. Этот спор стал весьма значительным событием для такого консервативного сообщества, как ACS, – настолько, что привлек даже больше внимания, чем презентация книги бывшего премьер-министра, которая проводилась в этом же зале несколькими часами ранее. По неизвестным причинам меня втянули в этот спор в качестве члена опровергающей команды. Томсет, которого Симшн называл самым диким консультантом Австралии, привел нашу команду к победе, хотя к концу обсуждения было видно, что обе стороны находились приблизительно на одном уровне.
Действительно, слухи о грядущем погребении CASE вызывают непонимание, поскольку CASE – это (дословно) не более чем проектирование и создание программ с помощью компьютеров. Неужели компьютеры перестали оказывать в этом помощь? Или отрасль проектирования и создания программ прекратила свое существование? Будем надеяться, что не случилось ни то ни другое. CASE не исчез и не обречен, хотя и может заметным образом declasse.[30]30
Быть деквалифицированным (фр.)
[Закрыть] Следуя своему вечному стремлению приукрашивать и восхвалять то, что они когда-то вознесли до уровня святости, ученые мужи от промышленности все чаше заменяют термин CASE на «интегрированные среды разработки». Во всяком случае в последний месяц это было так.
Конечно, отчасти проблема заключается в необоснованных ожиданиях, которые подогревались рекламными кампаниями производителей программного обеспечения, а также в надеждах, питаемых любителями выдавать желаемое за действительное. Даже самый великолепный из реальных инструментов будет вызывать разочарование, поскольку почти каждый в нашем деле находится в вечном поиске меча короля Артура для программирования. Другая трудность состоит в том, что разработчики и производители инструментов CASE часто не разбирались ни в моделях и моделировании, ни в тех методах, для поддержки которых предназначались их инструменты. Более того, эти CASE-инструменты просто-напросто не были тем, что необходимо для ускорения разработки и повышения качества программ. Необходимо нечто, дающее одновременно и больше и меньше того, что дает большинство инструментов CASE. Нам следует посмотреть на визуальные среды разработки, чтобы понять, чем должны были и чем еще могут стать инструменты CASE.
Визуальные среды разработки – это одни из самых ярких и крепких нитей в клубке современных методов и продуктов. Визуальная разработка связана с большим разнообразием инструментов и подходов, позволяющих разработчикам создавать код посредством прямого манипулирования визуальными объектами в графическом пользовательском интерфейсе (ГПИ). Самым старым и известным образчиком этого жанра является Visual Basic компании Microsoft. Более поздние продукты, такие как Vis-ualAge компании IBM и Delphi компании Borland, стали вбирать все лучшее из возможностей визуального проектирования. Хотя изначально большинство таких продуктов в основном предназначались для разработчиков приложений, парадигма визуального проектирования может в конце концов стать будущим каждого.
Программное обеспечение для визуальной разработки является всего лишь технологией, но такой технологией, которая может радикально изменить методику разработки программного обеспечения. В самом чистом виде визуальное проектирование позволяет создавать полностью рабочие системы – в значительной степени или исключительно с помощью перемещения визуальных объектов по экрану монитора. Прямое манипулирование графическими элементами является очевидным подходом к разработке графических пользовательских интерфейсов. Именно здесь и началось визуальное проектирование – с применением так называемых конструкторов графических пользовательских интерфейсов. При использовании многих ранних инструментов сложность состояла в том, что за внешней стороной приятного на вид интерфейса скрывался самый отвратительный или беспорядочный код на Basic или С++ из всех, что когда-либо придумывались. Код «за экраном» был в полной неразберихе, и вам приходилось пробираться через это месиво, чтобы заставить работать хоть что-то.
Между ГПИ[31]31
ГПИ – графический пользовательский интерфейс
[Закрыть] и гравием
Когда проектируемые системы становятся действительно сложными, разработчики стремятся строить модели на более высоких уровнях абстракции, чтобы описывать и отражать архитектуру системы, а не только ее конструкцию или поверхностные проявления в виде пользовательского интерфейса. Для этого программные единицы и взаимосвязи между ними должны быть представлены визуально. Вам нужно видеть модули, классы и объекты, а также сообщения и ссылки, которые возникают между ними. Вам нужно видеть структуру вашего кода, выраженную с помощью знакомой системы обозначений. Необходима возможность перемещения по этой структуре с помощью устройства, названного Дж. Д. Хилдебрэндом визуальным броузером (J. D. Hildebrand, 1994). Вам нужно, чтобы вы могли, проведя линию, передать информацию из одного места в другое. Вам хочется иметь возможность перенести метод из одного класса в другой с помощью перетаскивания мышью. В общем, вам нужен неизменно активный инструмент CASE с динамическими встроенными механизмами конвертации кода, которые позволяют сразу переводить в код все то, что вы делаете в виде картинок, и наоборот.
Другими словами, вы хотите иметь истинно интегрированную среду визуальной разработки – сочетание CASE-инструментов и приложений WYSIWYG,[32]32
WYSIWYG (What You See Is What You Get) – что видишь, то и получаешь
[Закрыть] полученное в результате добавления в среды разработки приложений возможностей CASE и более тесной интеграции средств построения ГПИ и генерации кода внутри самих CASE-инструментов. Vis-ualAge представляет собой направление, согласно которому моделирование осуществляется в самих конструкторах приложений. В таких средах с помощью линий можно соединять ГПИ-объекты, а также невидимые объекты, которые скрыты за экраном. В свете основных принципов CASE такие инструменты, как Together С++, позволяют синхронизировать все составляющие модели реализации – код, проектные модели, схемы и диаграммы.
Вместо обособления генерации кода от построения модели и графического дизайна истинная графическая среда разработки должна поддерживать в полной синхронизации визуальные элементы системы (ГПИ), ее визуализированную архитектуру (схемы анализа и проектирования) и лежащий в основе всего этого код. Разработчику нужна возможность легко перемещаться между моделями разработки и реализации и говорить на языке либо кода, либо картинок, в зависимости от того, что соответствует текущей задаче, приоритетам или просто его настроению. Такие возможности значительно приблизят инструменты разработки к тому, как люди решают задачи. Обычно люди излагают мысли как с помощью слов, так и с помощью картинок, разрываясь между ясностью высокоуровневой абстракции и мелким гравием деталей решения (см. также главу 18).
Визуальная разработка в полной форме – это важная новая парадигма в отношениях между программистами и компьютерами. Потенциально она позволяет аналитикам и разработчикам применять одни и те же ментальные и ручные навыки для описания задачи, разработки ее решения и построения системы. Это выглядит возвратом к прошлому, когда код проектировался при кодировании, однако в этом подходе проектные решения кодируются с помощью простого проектирования. Действительное отличие, которое несет в себе новая парадигма, заключается в том, что визуальная разработка позволяет создавать и манипулировать на более высоком уровне, большими частями, с большим числом видимых связей и последствий. Это может помочь вам в буквальном смысле видеть, где вы находитесь, что вы делаете и как все это соответствует общей схеме проектируемой системы.
Двойственные процессоры
Визуальное проектирование дает возможность думать в двух режимах одновременно. Первый режим – аналитический, последовательный – сопровождается использованием языка и выражением процессов в виде кода. Второй режим – пространственно-визуальный – мы применяем, когда что-то рисуем, или строим с помощью конструктора Lego, или составляем диаграмму. Таким образом, визуальное программирование напоминает апгрейд центрального процессора вашего мозга, позволяя увеличить скорость ваших ментальных процессов и давая возможность решать более сложные задачи или быстрее строить системы.
Среды визуальной разработки также дают возможность изменять ход разработки. Люди, содействующие продвижению объектной технологии, го-ворят, что она обеспечивает «бесшовность» процесса разработки – прежде всего потому, что для разработки и описания программного решения применяются те же самые понятия и термины, которые используются для описания задачи и для взаимодействия с пользователями и клиентами. Но это просто объекты. Однако исполнение обещания – совсем другое дело, и традиционные объектно-ориентированные инструменты разработки сами по себе не были настолько бесшовными. Сочетание визуального проектирования с методами объектно-ориентированной разработки и программирования может в конце концов появиться на практике. Вы получите возможность выполнения всей задачи с помощью прямого манипулирования объектами. Кроме того, будущее поколение инструментов может предоставить возможность изменять и расширять сами инструменты при помощи тех же методов визуального программирования, которые вы применяете для построения приложений.
Вместо того чтобы устраивать поминки по CASE, может быть, есть смысл визуализировать процесс разработки.
Из журнала Software Development, том 3, № 5, май 1995 г.
24
Цели программного обеспечения
Программист, проспавший большую часть последних десяти или двадцати лет, наверное, не знает о том, что такое объектно-ориентированное программирование. Остальные из нас уже сыты этими объектами по горло. Я испытываю некоторое сочувствие к этим ван Винклям[33]33
Рип ван Винкль (Rip van Winkle) – герой одноименной новеллы В. Ирвинга (W. Irving, 1819), житель голландской колонии в Америке, который проспал 20 лет, выпив волшебное вино, поднесенное ему гномами.
[Закрыть] нашей отрасли, поскольку в 1986 году, когда я имел неосторожность вернуться в компьютерную индустрию, объектная технология уже была звездой, восходившей с головокружительной скоростью. А ведь за десять лет до этого, в пору моего последнего отсутствия в компьютерной области, объектно-ори-ентированное программирование было неизвестным хмурым карликом, скрытым в космосе непонятных компьютерных методов. Конечно, спустя десяток лет очень легко определять, какие тенденции проявлялись ранее.
Нельзя сказать, что объектно-ориентированный подход является особенно новым. Хотя некоторые авторы связывают провал структурных методов с возникновением объектно-ориентированных, на самом деле, структурное программирование и проектирование появилось почти одновременно с объектами, возникнув из одного первобытного болота неструктурных методов. Дейкстра (Dijkstra), Константин (Constantine), Кэй (Кауе), Даал (Dahl) и Сатерленд (Sutherland) – все эти люди работали параллельно в конце 60-х и начале 70-х годов, разрабатывая и распространяя основные понятия новых способов мышления о программах и программировании.
К середине 80-х годов концепции объектно-ориентированных методов уже сложились, хотя они и были не всегда понятными. Конечно, не было недостатка и в тех, кто уже тогда хорошо освоил ООП и мог решить с его помощью любую задачу. Не хватало только людей, которые могли бы дать ясные объяснения. В соответствии с риторикой того времени следовало сжиться с объектами, чтобы научиться думать и проектировать с их помощью.
«Как же можно объект уподобить информационному кластеру или модулю с информационным сцеплением?», – может спросить дотошный студент.
«Послушайте, – отвечает нетерпеливый преподаватель, – я же сказал вам забыть обо всей этой старой структурной чепухе. Это не работало. И пока вы не очистите кору головного мозга от этих вещей, вы ничего не поймете». (Подразумевается, что преподаватель даже и не знает, о чем спрашивает студент, поэтому пусть студент закроет рот и слушает.)
Многие из педагогов и демагогов, которые в то время занимались 00, утверждали, что единственный путь к «объектной эффективности» – это отказ от старых способов. Нужно забыть все, что вы знаете (или думаете, что знаете) о разработке программного обеспечения, и изучить совершенно новую парадигму. Следовало начать все сначала – с чистой грифельной доски в голове.
Если бы это было возможно! Предложения этих людей были больше похожи на религиозное обращение, чем на приобретение новых технических навыков и изучение новых понятий. Некоторые гуру объектно-ориентированной парадигмы все еще проповедуют таким образом. «Их нужно привлекать еще молодыми, пока их сознание еще не замутнено процедурами, и тогда вы сможете сделать из них истинных верующих». Приблизительно так говорят эти евангелисты.
Конечно, вплотную занявшись ОО, я быстро понял, что многие из тех ранних поборников были вынуждены занять такую евангелическую позицию. Ничего не зная о структурных методах или реляционных моделях данных, они не могли сказать что-то разумное о связи этих понятий с ОО и поэтому не могли рисковать, отвечая на серьезные вопросы своих более опытных студентов. Когда они все же упоминали принятые в то время методы разработки программного обеспечения, это всегда были нападки, напоминающие легкую игру в стрельбу по хорошо поставленным и структурированным целям.
Некоторая расплывчатость определений и полное отсутствие консенсуса относительно того, что можно считать основными понятиями в ОО, не улучшали положения бедного странника, ищущего объектно-ориентиро-ванного просветления. Однако со временем все установилось, и сегодня есть общепринятая терминология и концепции объектно-ориентированной парадигмы.
Упаковка
В 00 есть множество аспектов. Для некоторых этот подход является способом прожить, для других это образ жизни. Для того чтобы постичь 00 в полном его великолепии, следует понимать не только инкапсуляцию или сокрытие описания, но также и наследование, делегирование, универсальность, динамическое связывание и полиморфизм. (И люди еще говорят, что структурная революция навязала слишком много новых терминов!) Все эти понятия представляют собой важные аспекты данной парадигмы и ее практического применения, но реальная причина того, что в разработке программ объекты ждет большое будущее, намного проще.
В короткой статье невозможно описать все тонкости объектно-ориентированной парадигмы, но главные вопросы, связанные с человеческим фактором в программировании (peopleware), являются довольно простыми. (Написав эти строки, я уже слышу, как стучат клавиши, чтобы подготовить негодующие электронные письма, которые скоро будут переполнять мой ящик.)
Забудьте о шумихе, которую поднимают истинные верующие, говорящие вам, что объектно-ориентированные методы – это новый подход к обдумыванию задач. На самом деле это всего лишь «новый, улучшенный» завтрак из хлопьев – все дело в хорошей упаковке. Классы, которые являются необходимым компонентом объектно-ориентированного программирования, – это всего лишь улучшенные контейнеры для кода. Объектные классы имеют ряд преимуществ в сравнении с функциями и подпрограммами. Во-первых, классы – это большие и средние контейнеры. Чем больше составные блоки, тем большие системы можно построить из данного набора компонентов. Хотя объектные классы имеют большие размеры, они выглядят меньше и проще потому, что все объекты хитрым образом плотно упакованы в соответствии с каким-то одним общим понятием (например, КомпьютерныйКлиент или ЛазерныйПринтер). Благодаря этому образуется необходимая связка, которую легко узнать и перемещать. Да, вы складываете данные и процедуры в один блок, но это как раз те необходимые данные и процедуры, которые все вместе принадлежат одному блоку.
У такого блока даже есть утешительная надпись, во многом напоминающая о реальном мире клиентов и пользователей, что является вторым большим преимуществом объектов. Все остальное – это дополнительные преимущества, лежащие на дне коробки с хлопьями. Брад Кокс (Brad Сох), один из первопроходцев 00, имел обыкновение говорить всем, кто смотрел в его сторону хотя бы с малейшим интересом, что объектно-ориентированная революция в упаковке – это абсолютно то же самое, что и переход от дискретной электроники к микросхемам, то есть от транзисторов к чипам. Это небольшая разница, которая имеет большое значение.
Остальные детали этого подхода можно найти у Роланда Рако (Roland Racko), Меилира Пейдж-Джонса (Meilir Page-Jones) и других настоящих ОО-гуру. В своих статьях и книгах они показывают, что даже во всей своей красе 00 не обязательно должно быть трудным – даже для тех заржавелых, старых умов, которые до основания заражены структурными методами.
Субъективное программирование
Основным свойством объектно-ориентированного программирования является сама идея. Она настолько потрясающа, что в конце концов останется практически единственный способ, с помощью которого будет создаваться серьезное программное обеспечение. Поэтому если только вы не занимаетесь разработкой примитивного и глупого программного обеспечения, рано или поздно вы обязательно сориентируетесь. Хороших источников знаний и советов по объектно-ориентированным методам предостаточно.
Если в глубине души вы программист, то, следуя своим наклонностям, вы захотите написать кусок кода. Использование правильного языка может быть очень полезным. В качестве такого языка можно выбрать почти любой, но, вероятно, больше всего для этого подходит Eiffel – язык, который заслуживает большей известности и большего коммерческого успеха. Хотя он и не является самым лучшим языком из тех, что создавались для разработки программного обеспечения, этот язык является виртуальной противоположностью намного более известного языка С++. Eiffel помогает научиться думать и проектировать с помощью объектов, тогда как С++ помогает заставить себя думать, что вы изменились, даже если вы выдаете все тот же старый гуталин. В отличие от С++, Eiffel – это четкий и компактный язык. С помощью Eiffel легко программировать хорошо и трудно программировать плохо. Если бы Eiffel применяли больше производителей и на большем количестве платформ, этот язык мог бы выиграть за счет своей жизнеспособной и разнообразной среды визуальной разработки, а его инструменты поддерживали бы принятые методы и системы обозначений. Вероятно, собственный компилятор кода также был бы полезен. А еще языку не помешало бы, чтобы некоторые из его сторонников были менее жесткими. Smalltalk – больше, Java – это напиток дня, a Eiffel – это тот язык, который по-прежнему любят многие. (Je suis ton ami1, Bertrand.)
В качестве учебника по ОО для начинающих программистов я многие годы рекомендовал книгу, написанную человеком, который в конце концов сделал структурное проектирование доступным для обычных смертных. «What Every Programmer Should Know About Object-Oriented Design» (Что должен знать каждый программист об объектно-ориентированном проектировании) (Page-Jones, 1995 [55]) была не первой книгой на эту тему, но никогда не поздно писать о сложных предметах ясно и понятно. (Сейчас ее заменила другая, не менее полезная книга того же автора: «Fundamentals of Object-Oriented Design» (Основы объектно-ориентированного проектирования) (Page-Jones, 2000 [56])).
Так что сориентируйтесь и вы.
Из журнала Software Development, том 3, № 6, июнь 1995 г.
25
Шито белыми нитками
Время от времени в некоторых старых и никуда не годных фантастических фильмах можно заметить швы или застежки-молнии на том, что должно казаться кожным покровом инопланетного мутанта. Несмотря яа частые возражения, в объектно-ориентированной разработке программного обеспечения швы нередко не менее заметны, чем на дрянных костюмах пучеглазых инопланетян в низкопробных научно-фантасти-теских картинах. Если судить о процессе по конечному продукту, то обещание бесшовности объектно-ориентированного проектирования в значительной степени остается невыполненным.
Согласно современным мифам об объектной технологии, бесшовное про-эктирование обеспечивает создание более качественного программного эбеспечения с помощью более простого процесса. Каким образом? На про-гяжении всего процесса разработки применяется один общий и согласованный набор компонентов – понятий предметной области. Понятия представлены согласно их трактовке реальными пользователями, обитающими в сказочной стране, называемой «реальным миром». На основе гаких понятий создаются модели, с помощью которых разработчики анализируют и решают свои задачи. Таким образом, понятия воплощаются в замой структуре кода. Разработчики упрощают свою задачу благодаря мышлению в терминах объектов и непрерывному использованию одного я того же набора идей на всех этапах процесса. Так во всяком случае это преподносится.
Эднако не только разработчики выиграли бы от бесшовности процесса проектирования, будь она когда-либо материализована на этой планете.
Большая часть моей работы связана с облегчением участи пользователей, ограждением их от страданий и унижений, приносимых плохим программным обеспечением с непостижимыми инопланетными интерфейсами. Пользователи вкушают плоды, которые может дать бесшовное проектирование. В свою очередь, компоненты предметной области, которые заполняют классы и объекты программного обеспечения, могут быть отражены в пользовательских интерфейсах, организованных на основе тех же понятий. Это удивительно, но продукт бесшовной разработки, ориентированный с помощью объектов из мира пользователя, является продуктом, говорящим на его языке. Такой продукт представляет собой узнаваемое продолжение мира, в котором работает пользователь. В нем объединены как раз те предметы, которые пользователь воспринимает или применяет одновременно (см. главы 24 и 28).
Как пользователи, так и разработчики предпочитают программное обеспечение, которое легко освоить и которое не требует активной технической поддержки. Однако для многих организаций оказалось трудным улучшить юзабилити своих продуктов. Пользователи и клиенты не получают удобство и простоту программного обеспечения по многим причинам. Тем не менее можно выделить и общие препятствия, стоящие на пути к успеху. В одних случаях проблемой является сама организация, в других – неэффективные методы и инструменты.
Некоторые организации становятся жертвами нехватки собственной решимости. Эти организации, так же как и их конкуренты, готовы прислушиваться к голосу потребителя или приспосабливать интерфейс под нужды пользователя, если только это не потребует дополнительных расходов или времени. Такие группы могут говорить и говорить в защиту разумных пользовательских интерфейсов или программного обеспечения, дружественного пользователю. Однако без последовательного и устойчивого внимания организации к вопросам юзабилити дело не сдвинется с места. Все чаще мне встречаются организации, в которых разработчики программного обеспечения более привержены улучшению юзабилити, чем само руководство. Такое руководство не выделяет средств на обучение. Оно не считает, что улучшение юзабилити – это часть работы проектировщиков и программистов. Оно отдает предпочтение большему количеству примочек в программе, а не удобству ее использования.
Другие проектные группы, несмотря на свое сильное стремление улучшить юзабилити программного обеспечения, могут испытывать трудности из-за применения неадекватных методов. Например, они могут уповать на тестирование с целью выявления изъянов в юзабилити, а не на хорошие методы проектирования, позволяющие избежать таких изъянов. Они готовы расходовать средства на юзабилити, но не знают, на что именно их следует потратить. В некоторых отношениях таким группам помочь легче всего – они уже стремятся идти в этом направлении и готовы тратить на это свои ресурсы. Им нужно только показать дорогу. Как только они поймут, как применять эффективные модели, они смогут достичь чрезвычайных успехов с точки зрения юзабилити конечных продуктов.
Время инструментов
Однако даже сильного и целенаправленного стремления к улучшению юзабилити и правильному структурированию процесса бывает недостаточно. Зачастую современные средства разработки сами по себе создают препятствия на пути к повышению юзабилити программного обеспечения и бесшовному проектированию. Некоторые инструменты не только не поддерживают действительно бесшовный процесс разработки, но и затрудняют применение системного подхода к проектированию, который основан на моделировании с учетом юзабилити.
Инструменты для создания программного обеспечения продолжают совершенствоваться, особенно визуальные средства разработки. Начиная с Visual Basic и Delphi и заканчивая Visual С++ и J-Builder, визуальные инструментальные средства сделали большой шаг вперед в области разработки приложений и программного обеспечения. Это относится не только к технологии, но и к тому, как такие инструменты соответствуют методам, с помощью которых люди решают задачи. Лучшие из этих инструментов помогают разработчикам легко перемещаться между визуальным представлением программного продукта (пользовательским интерфейсом) и кодом, лежащим в его основе. Другими словами, они позволяют думать либо о видимых объектах, либо о невидимом коде – в зависимости от того, что требуется для решения текущей задачи.
Швы в инструментах начинают проявляться именно между пользовательским интерфейсом и теми моделями, которые разработчики применяют для представления объектов, взаимосвязей и задач. Обещание полной и совершенной интеграции, о которой шла речь в главе 23, еще не материализовалось. Инструменты моделирования все еще являются лишь инструментами моделирования, а инструменты проектирования – лишь инструментами проектирования. Даже если они импортируют файлы друг у друга и способны обмениваться информацией через API, швы и молнии зачастую очень заметны. Более того, инструменты не способны распознать ключевые связи и отношения. Например, пользовательские ситуации повсеместно признаны в качестве модели, имеющей важное значение для объектно-ориентированного проектирования. Они поддерживаются некоторыми инструментами моделирования, однако связь пользовательских ситуаций с пользовательским интерфейсом не распо-знается большинством таких инструментов и пребывает исключительно в умах разработчиков.
Что же в таком случае мы хотим получить от наших инструментов, чтобы создавать высококачественные программы с помощью бесшовного проектирования? Нужно, чтобы поставщики инструментов выходили за пределы своих привычных представлений. Нужно, чтобы они поняли саму идею визуального проектирования – идею, которая так долго ждала своего часа (см. главу 18).
Ракурсы
Программную систему можно рассмотреть с различных ракурсов. Каждый ракурс или точка зрения высвечивает определенные характеристики или аспекты системы, игнорируя или затеняя другие. Модель процесса, например, известная всем блок-схема, удобным образом описывает структуру алгоритмов, но почти (или совсем) не показывает данные. Модель предметной области эффективно представляет объектные классы и взаимосвязи между ними, но является бесполезной для дизайна экранных изображений. Тот факт, что общепринятые модели, применяемые в проектировании программного обеспечения, столько внимания уделяют конкретным аспектам систем, является не изъяном, а достоинством. Каждый ракурс позволяет упростить систему для определенных целей, тем самым помогая разработчикам говорить и думать о конкретных вопросах и задачах, возникающих при создании программного обеспечения.
Пользовательский интерфейс сам по себе является одним из таких ракурсов, представляя программу так, как она будет выглядеть с точки зрения конечного пользователя. Контент-модель показывает пользовательский интерфейс с точки зрения проектировщика и моделирует его содержание в отрыве от визуального представления или каких-либо графических интерфейсов (Constantine, 1998 [29]). Карта контекстной навигации представляет собой отображение всех составных частей пользовательского интерфейса и взаимосвязи между ними (более подробно о контент-моделях и навигационных моделях рассказано в главе 44).
На самом деле даже справочные файлы и документация представляют собой альтернативный взгляд на программное обеспечение. Хотя зачастую эти ракурсы считаются у разработчиков раздражающими мелочами, они являются частью пользовательского интерфейса, поскольку служат связующим звеном между пользователями и системой. На практике юзабилити программного обеспечения зависит не только от компоновки элементов на экране и дизайна диалоговых окон, но и от качества справочных файлов и руководств.
Конечно, все модели и ракурсы данной системы очень тесно взаимосвязаны между собой – хотя бы потому, что они описывают одну и ту же систему. Визуальные объекты в пользовательском интерфейсе связаны с внутренними объектами и их методами, а абстрактные компоненты в контент-модели могут проявляться в виде всяких «штучек» в пользовательском интерфейсе. Различные контексты, в которых происходит взаимодействие с пользователем (окна, формы, диалоговые окна и т. п.), связаны переходами, осуществляемыми с помощью элементов управления в пользовательском интерфейсе. Пользовательские ситуации моделируют не только взаимодействие между пользователем и системой, но и взаимодействие между коммуникационными программными объектами.
В редких случаях, когда в наличии есть точная онлайновая и оффлайновая документация, она тоже тесно связана с другими ракурсами. Документация описывает видимые и невидимые характеристики системы с помощью той же терминологии, которая применялась в объектной модели и в дизайне пользовательского интерфейса. Документация сообщает о пользовательских ситуациях, которые можно вызвать с помощью данного программного обеспечения.
Согласно методам разработки программ на основе ракурсов, целью разработчика становится построение системы с помощью различных ракурсов, которые полностью ее описывают и конкретизируют. Назначение инструментов проектирования – поддерживать создание основы программы, обеспечивая согласование между кодом (одним ракурсом) и всеми другими ракурсами. В любой момент каждый ракурс может применяться для обзора и модификации системы. Измените код, и вместе с ним изменится интерфейс. Измените модель, и изменится код. Создадите новую контент-модель, и в интерфейсе появится пустая форма. Добавите пользовательскую ситуацию, и в файле справки появится еще один раздел. Разработчик, который испытывает затруднения в одном ракурсе, может мгновенно переключиться на другой ракурс и продолжить свою работу.
