Как описать интерфейс программы

model 2614569 1920 Советы на день
Содержание
  1. Описание интерфейса программы
  2. Программы и описание интерфейса
  3. Интерфейс
  4. Меню и панель инструментов
  5. Word в Help (doc to chm)
  6. Интерфейс программы
  7. Шаги преобразования Doc-2-Help
  8. Дополнительные возможности
  9. Две дополнительные кнопки
  10. Ссылки на другие справки
  11. Раскрывающиеся группы текста
  12. Изменение размеров изображения
  13. Техническая документация
  14. разработка техдокументации по ГОСТ
  15. Как описать графический интерфейс пользователя?
  16. Исходные данные
  17. Группы пользователей и уровень подготовки пользователей
  18. Лирическое отступление
  19. Связка «общие сведения, назначение и состав»
  20. Реализация практических приемов описания графического интерфейса пользователя
  21. Интерфейсы — важнейшая концепция в разработке ПО
  22. Что такое интерфейс?
  23. Интерфейс как договор
  24. Патенты, авторские права и интерфейсы
  25. Что такое «модуль», или «абстракция»?
  26. Дырявые абстракции
  27. Оценка и сравнение интерфейсов
  28. Дырявые и ограниченные интерфейсы
  29. Асимптотическая сложность технического долга
  30. Почему всё ещё пользуются командной строкой?
  31. Выбор правильного языка
  32. Почему так популярен Python?
  33. Почему корпоративное ПО обычно пишут на Java/C++?
  34. Как эффективнее срезать углы

Описание интерфейса программы

dark fb.4725bc4eebdb65ca23e89e212ea8a0ea dark vk.71a586ff1b2903f7f61b0a284beb079f dark twitter.51e15b08a51bdf794f88684782916cc0 dark odnoklas.810a90026299a2be30475bf15c20af5b

caret left.c509a6ae019403bf80f96bff00cd87cd

caret right.6696d877b5de329b9afe170140b9f935

Запуск программы осуществляется через главное меню Windows. Программа обычно располагается в папке “Трансфинплан” и имеет значок (рис. 8.1).

image744

Рис. 8.1. Значок программы

Общий интерфейс программы.

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

Рис. 8.2. Общее назначение областей экрана программы

Область меню состоит из меню окна, заголовка окна, главного меню и кнопок управления окном (рис.8.3).

image748

Рис. 8.3. Область меню

Меню “Файл” содержит следующие пункты (рис. 8.4):

image750

Рис. 8.4. Меню “Файл”

“Новый” – создает новый файл данных парка автомобилей, дублирующая клавиша F2;

“Выход” – закрывает программу расчета техтрансфинплана, дублирующая комбинация клавиш Alt+X.

Закладка “Парк”

Интерфейс закладки “Парк” составляют кнопки выбора вида техники “База данных”(рис.8.5, а), типа техники “Тип агрегата” (рис.8.5, б), удаление из таблицы для расчета агрегата (рис.8.5, в), добавление в таблицу для расчета агрегата (рис.8.5, г) и кнопки “Далее” (рис.8.5, д) для перехода на следующий этап работы с программой расчета.

Кроме того, область закладки “Парк” содержит раскрывающийся список для просмотра содержащихся в базе наименований агрегатов с указанием базового шасси, количество агрегатов данной марки, участвующих в расчете, а также кнопки подтверждения изменений в базе парка ü и отмены изменений û.

image751

Рис. 8.5. Интерфейс закладки “Парк”

Формирование списка агрегатов происходит в окне справа, где создается список агрегатов с указанием исходных данных по ним.

Источник

Программы и описание интерфейса

OneClickHelp это набор программ, с одним окном и 5 закладками, по числу программ.

1. Преобразование Word файла в Справку ( Word2Help ).

2. Преобразование Chm в Word документ ( Chm2Word, chm to doc ).

Интерфейс

Все общие элементы интерфейса показаны ниже, а элементы интерфейса каждой программы описаны далее.

image009

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

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

Меню и панель инструментов

Загрузить файл проекта. Открыть диалоговое окно выбора файла типа *.1ch для загрузки файла проекта (параметров программы).

Сохранить файл проекта. Сохранить все параметры программы в файле типа *.1ch.

Сохранить файл проекта как. Сохранить файл под другим именем.

Последние файлы. Файлы проекта (до 10 штук), с которыми вы работали в последнее время.

Выход. Закрыть приложение.

Параметры проекта. Редактировать параметры в файле проекта.

Параметры OneClickHelp. Редактировать параметры программы OneClickHelp.

Очистить форму. Все параметры на форме очищаются.

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

Индекс. Показать указатель справки.

Поиск. Показать справку с окном для поиска фраз.

Коллекция справок. Показать коллекцию справок программы OneClickHelp.

О программе. Показать окно с информацией о программе.

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

Регистрация… Открыть форму для ввода регистрационного ключа.

Обновление. Проверить последняя ли версия установлена у вас.

image011

Word в Help (doc to chm)

На рисунке ниже представлен Word документ (документация OneClickHelp) как он выглядит в режиме Схема документа, и как он был скомпилирован в Справку в формате Chm, Aspx, Html (Word2Chm, Word2Aspx, Word2Html).

image012

Интерфейс программы

image013

Поле Папка проекта – Выбор папки, где будет построена Справка (Help) и вспомогательные файлы. Тащите сюда папку или используй кнопку image015. Если папка не указана, программа сама создаст каталог с именем имя вашего Word файла + “_Word2Help”, например, 1Ch_Word2Help.

Поле Открыть справку – при выставленном флажке, image018после создания справки, она будет открыта, если имеется программа, которая зарегистрирована для работы с расширением файла CHM или Html.

Шаги преобразования Doc-2-Help

Word файл (*.docx, *.doc, *.rtf, …) преобразуется в компилированный файл/файлы в формате Chm, Aspx, Html. Этот процесс состоит из следующих шагов:

1. Word файл преобразуется в html файл.

2. Html файл преобразуется в набор html файлов (если в документе есть заголовки (heading) различных уровней).

3. Набор html файлов связывается (если разрешено) гиперссылками Назад/Домой/ Следующая.

5. Компилируется справка в формате Chm.

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

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

Папка _css – папка, куда помещается стиль документа, как он был определен вами в Word (с последующим преобразованием в html). Папка 1ch-ru.files – папка с графикой из вашего документа.

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

Дополнительные возможности

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

Две дополнительные кнопки

К Справке можно добавить две фиксированных кнопки, для быстрого перехода к каким-либо разделам, например.

image019

1. В Файле, который вы используете для определения имен, впишите две строки
TTFAQ»Jump1Url
TTglossary»Jump2Url

TTFAQ, TTglossary – произвольные имена (вы можете выбрать свои), Jump1Url и Jump2Url – фиксированные.

2. В Word документе создайте две закладки с именами TTFAQ и TTglossary

3. В секции файла проекта заполните две строки Jump1Text и Jump2Text именами кнопок, как на рисунке ниже.

image020

Эти слова будут появляться под названиями кнопок.

Ссылки на другие справки

Вы в документ можете вставить ссылку на другую справку в виде:

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

Раскрывающиеся группы текста

2. Имя = expandBegin, размер шрифта = 1, все остальное как хотите. В _style.css не определен, так как удаляется из html.

3. Имя = expandEnd, все остальное как хотите. В _style.css не определен, так как удаляется из html.

4. Имя = sweepToggle, все остальное как хотите. В _style.css не определен, так как удаляется из html.

Эти определения стилей в виде изображения можно представить следующим образом.

image021

Изменение размеров изображения

Для создания такого свойства в Help надо в MS Word.

1. Определить два стиля

· Имя = ExpandPictureBegin, основан на обычном, размер = 1.

· Имя = ExpandPictureEnd, основан на обычном, размер = 1.

2. Вставить эти два стиля и между ними картинку.

3. Для этой картинки определить закладку, например, xxx.

Источник

Техническая документация

разработка техдокументации по ГОСТ

Как описать графический интерфейс пользователя?

Приемы описания графического интерфейса пользователя. Впервые опубликована 09.03.2005 года под названием «Графический интерфейс пользователя». За весь срок своего существования статья уверенно удерживает 2 место в рейтинге просмотров, уступая лишь циклу статей к.т.н. В. А. Глаголева о стоимости разработки техдокументации. Редакция от 10.05.2021.

Создан 05.03.2005 10:47:42

krivoj graficheskij interfejs polzovatelja

Графический интерфейс пользователя по определению должен быть кривым 🤪

Исходные данные

kak pisat rukovodstvo polzovatelja otzyv

Речь шла о графическом интерфейсе пользователя, о приемах его описания в руководствах пользователей программ. Руководство пользователя, как таковое, имеет место быть только в ГОСТ 34.ххх, а в ГОСТ 19.ххх есть руководство оператора, руководство программиста и руководство системного программиста, которые, в совокупности, и являются руководством пользователя, см. «Как писать руководство пользователя? Часть I» и «Как писать руководство пользователя? Часть II».

Итак, что мы имеем? Имеем:

Группы пользователей и уровень подготовки пользователей

Куда вы руки лезете свои?!

Надо отдать должное телевизионной рекламе. Если отбросить перлы про активный кислород и гигиеническую чистоту туалета, можно заметить, что реклама (по-своему) четко классифицирует материальный мир. Реклама убеждает нас, что существуют, к примеру, Tide и обычный стиральный порошок, Fairy и обычное моющее средство. И так далее.

группа Power (Advanced) users

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

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

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

(Печальный факт стремительного сокращения числа Administrators и роста числа Users налицо).

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

Второй вариант, очевидно, можно считать приемлемым. Именно поэтому не стоит сорить в рунете страничками вроде «Как сделать хорошее руководство пользователя», а следует детально и без спешки проработать обобщенную структуру руководства пользователя (см. «Как писать руководство пользователя? Часть I» и «Как писать руководство пользователя? Часть II»).

Лирическое отступление

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

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

У наших заокеанских «партнеров» ситуация впятеро хуже:

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

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

Было бы величайшей ошибкой думать.

В.И. Ленин, ПСС, т. 41, с. 55

В ГОСТ 19.ххх указанная схема представлена структурой смежных разделов:

В IEEE Std 1063-2001 имеется ключевая фраза «Documentation shall explain the formats and procedures for user-entered software commands, including. Examples should illustrate the use of commands».

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

И все получится, бездумно и без напряжения. И все будут счастливы.

Не следует детально расписывать, как «согнуть пальцы», чтобы удержать отвертку. Хватательный рефлекс в равной степени развит и у Users, и у Power (Advanced) users с пеленок. (Неспроста же дети мгновенно осваивают действия с графическим интерфейсом пользователя). Сведения о выполнении операций вида drag-and-drop и им подобных читатель сможет самостоятельно почерпнуть из руководства пользователя операционной системы.

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

Связка «общие сведения, назначение и состав»

Связка «общие сведения, назначение и состав» многим известна по статье Как писать техническое задание?! Связка, как было показано, не противоречит ни манифесту, ни IEEE Std 1063-2001, ни (упаси боже!) ГОСТ 19.ххх. Переходим к решению поставленной задачи.

Реализация практических приемов описания графического интерфейса пользователя

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

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

со списком значений , вставленная в топик AuthorIT, в зависимости от пожелания разработчика документа, будет «выглядеть» так:

Источник

Интерфейсы — важнейшая концепция в разработке ПО

cb97c2aeaf7755a9a723134708259831

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

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

Что такое интерфейс?

Большинству из нас знакомы две краткие формулировки:

Интерфейс — это договор между системой и внешним окружением.
Интерфейс — это сопряжение системы с внешним окружением.

Интерфейс = Система ∩ Окружение

image loader

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

image loader

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

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

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

Применим ту же методику цветовой дифференциации штанов для описания окружения, системы add_numbers и интерфейса:

image loader

image loader

image loader

image loader

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

Реализация — это система минус интерфейс.

Implementation = System ∖ Interface
Implementation = System ∖ (System ∩ Environment)

image loader

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

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

Интерфейс как договор

Если рассматривать интерфейс функции add_numbers в виде договора, то гарантии будут такие:

unsigned int add_numbers();

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

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

Патенты, авторские права и интерфейсы

Я не буду давать вам советы в области права. Возможно, что-то из мною сказанного даже будет противоречить законам. Всё нижеследующее — лишь частное мнение автора.

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

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

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

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

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

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

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

Все эти разговоры о законах напомнили мне дело Oracle против Google. По приведённой ссылке вы можете найти интересные для разработчиков подробности, так что я буду опираться на них в своём анализе. Учитывая все аспекты, не вижу причин не соглашаться с решением дела в пользу Oracle. Не могу сказать, что безоговорочно их поддерживаю, поскольку нам доступно не так много деталей разбирательства.

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

«Окружной суд заключил, что „есть лишь один способ написания“ объявлений для взаимодействия с Java. Если это так, то использование одинаковых объявлений не подлежит защите авторским правом. В Google не оспаривают тот факт, что они могли бы написать свои собственные API для доступа к Java, за исключением трёх». И наконец, «В Google признали, что они дословно скопировали объявления».

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

Об этой тяжбе я знаю лишь из открытых сетевых источников, но, судя по всему, в Google полностью скопировали исходный Java-код, включая интерфейсы. Похоже, они и сами считали, что нужно лицензировать своё использование Java, поскольку это было предметом переговоров по лицензионным соглашениям с Sun ещё до 2010 года. Но эти соглашения потерпели неудачу после того, как Sun была приобретена Oracle. Тем не менее Google продолжала использовать «дословные» копии кода, что явно не пошло ей на пользу при судебном разбирательстве. Подозреваю, что их адвокаты знали о слабости своей позиции, поэтому выбрали стратегию защиты, основанную на законном требовании о нераспространении авторского права на интерфейсы. Надеялись выиграть дело за счёт представления интерфейса в виде исходного кода и его объединения с более философской концепцией.

Что такое «модуль», или «абстракция»?

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

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

4b4fe978ec7e417c829c9a3f484c6e14

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

Вы можете считать отдельную функцию модулем в языке С, «модулем» — в Python, классом или пакетом — в Java. Чем угодно, лишь бы оно имело внешний интерфейс и «скрытую» реализацию. Причём «скрытость» может быть следствием правил языка или даже решения программиста.

Дырявые абстракции

Насколько я знаю, идею дырявых абстракций выдвинул Джоел Сполски. В его эссе есть несколько хороших примеров, но я хотел бы привести свой. В программировании очень часто встречается концепция «карты»: представление структуры данных, состоящей из пар ключей и значений. Важное ограничение: карта гарантирует, что все ключи должны быть уникальными. Попытка записи нового значения для существующего ключа приведёт к ошибке или перезаписи предыдущего значения. Суть в том, что ключи не должны дублироваться. Чаще всего от программистов требуется желание перебирать все эти ключи. А поскольку карты не могут гарантировать определённый порядок сортировки ключей, то иногда приходится задаваться вопросом, в каком порядке они будут после перебора? Это — следствие того, что интерфейс карты не даёт гарантий по сортировке. И хотя считается, что это не имеет значения, но на практике всё же хочется отсортировать. Так нужно для более эффективной организации данных, например для облегчения проверки уже имеющихся ключей.

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

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

Хочу предложить своё собственное определение утечки абстракций.

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

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

Идея дырявости большинства абстракций не является необоснованной. Это подразумевал и Джоел Сполски в своём «The Law of Leaky Abstractions»:

«Все нетривиальные абстракции являются дырявыми до определённой степени».

Раз все абстракции дырявые, то о чём говорить? Проблемы возникают только тогда, когда часть окружения начинает опираться на один из непредусмотренных способов воздействия системы на окружение. Именно о таких утечках все и говорят.

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

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

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

Оценка и сравнение интерфейсов

Как мы уже видели выше, в интерфейсах на С задаются такие вещи, как тип возвращаемого значения и количество параметров, которые могут быть переданы функции. А что насчёт Python? Я использую термин «интерфейс» в соответствии с контекстом статьи, то есть в более широком понимании по сравнению с тем, что пишут в книгах об «интерфейсах» в Python.

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

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

Через интерфейс В обход интерфейса
Описание характеристики Кол-во возможных состояний Описание характеристики Кол-во возможных состояний
Тип параметра 1 1 (unsigned int) Состояния глобальной переменной (кол-во глобальных переменных) * (кол-во состояний глобальных переменных)
Тип параметра 2 1 (unsigned int) Файловая система Кол-во состояний файловой системы
Тип возвращаемого значения 1 (unsigned int) Время использования процессора Не ограничено
Значение параметра 1 2^(кол-во бит в unsigned int) Состояние кучи Кол-во состояний кучи
Значение параметра 2 2^(кол-во бит в unsigned int) Многие другие. .
Возвращаемое значение 2^(кол-во бит в unsigned int)

И есть ряд вещей, которые могут коммуницировать с add_numbers через интерфейс Python.

Передача информации через интерфейс Python Передача информации в обход интерфейса Python
Описание характеристики Кол-во возможных состояний Описание характеристики Кол-во возможных состояний
Тип параметра 1 Практически бесконечное Состояния глобальной переменной Кол-во состояний файловой системы
Тип параметра 2 Практически бесконечное Файловая система Не ограничено
Тип возвращаемого значения Практически бесконечное Время использования процессора Кол-во состояний кучи
Значение параметра 1 Практически бесконечное Состояние кучи .
Значение параметра 2 Практически бесконечное Многие другие. (кол-во глобальных переменных) * (кол-во состояний глобальных переменных)
Возвращаемое значение Практически бесконечное

А теперь взгляните на количество типов интерфейсов, которые мы можем описать в Haskell:

Учитывая этот код, интерфейс add_numbers может получить следующую информацию:

Передача информации через интерфейс Haskell Передача информации в обход интерфейса Haskell
Описание характеристики Кол-во возможных состояний Описание характеристики Кол-во возможных состояний
Тип параметра 1 1 (Int) Время использования процессора Не ограничено
Тип параметра 2 1 (Int) Влияние на кэши процессора/памяти Не ограничено
Тип возвращаемого значения 1 (Int) Прочие. .
Значение параметра 1 1 (значение 3)
Значение параметра 2 1 (значение 4)
Возвращаемое значение Как минимум 2^30[1]

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

folders

Передача информации через GUI Передача информации в обход GUI
Описание характеристики Кол-во возможных состояний Описание характеристики Кол-во возможных состояний
Клик по Папке 1 Кол-во пикселей на экране, занимаемых Папкой 1 * кол-во кликов Скрытые возможности UI Не ограничено
Клик по Папке 2 Кол-во пикселей на экране, занимаемых Папкой 2 * кол-во кликов Нестандартные комбинации быстрого вызова Кол-во пикселей на экране, занимаемых Кнопкой 2
Наведение курсора на Папку 1 Кол-во пикселей на экране, занимаемых Папкой 1 Прочие неожиданные возможности UI .
Наведение курсора на Папку 2 Кол-во пикселей на экране, занимаемых Папкой 2
Время между наведением и кликом Бесконечно
Стандартные клавиатурные события Кол-во стандартных комбинаций клавиш
Площадь экрана, занимаемая GUI Кол-во пикселей, используемых для отображения GUI

А теперь рассмотрим ту же задачу смены папки с помощью командной строки и cd :

Передача информации через GUI Передача информации в обход GUI
Описание характеристики Кол-во возможных состояний Описание характеристики Кол-во возможных состояний
Кол-во названий папок, которые можно набрать Не ограничено Переменные окружения Не ограничено

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

Можно ещё больше усложнить анализ, если оценивать изменение доли ошибок у пользователей с физическими отклонениями.

Итак, мы рассмотрели один из возможных способов оценки и сравнения интерфейсов. На основании приведённых примеров и собственного опыта позволю себе сделать несколько экстраполяций:

Дырявые и ограниченные интерфейсы

Я опишу несколько наблюдений на основании анализа из предыдущего раздела. Но сначала приведу пару определений:

Дырявый интерфейс (leaky interface) — интерфейс, который игнорируется в ходе любых взаимодействий между системой и окружением.

Ограниченный интерфейс (specific interface) — интерфейс с относительно небольшим количеством возможных входов и выходов.

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

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

image loader

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

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

Асимптотическая сложность технического долга

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

В самом начале проект содержит один-два модуля, и для проработки договора хорошего интерфейса вам понадобится выполнить объём работы О(1). Если ваш интерфейс плох, то объём технического долга тоже будет равен О(1), так что вам не придётся потратить слишком много времени на приведение в порядок договора интерфейса. Но при линейном росте количества модулей объём межмодульных связей может достигать О(N^2). Следовательно, при плохом интерфейсе, если каждый модуль взаимодействует со всеми остальными модулями, количество обращений к интерфейсу в худшем случае будет пропорционально N^2.

image loader

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

Обычно уровень межмодульного взаимодействия растёт медленнее, чем О(N^2), но определённо быстрее, чем О(N). Также есть один фактор, сдвигающий начало быстрого роста в будущее: это человеческая память. Даже когда в вашем проекте 20 модулей, вы, вероятно, ещё помните, что делает каждый из них. Так, из всех договоров вам нужны лишь туманные названия функций и эзотерические соглашения. Но как только проект становится достаточно большим, то многие детали забываются, или когда в проект приходят новые люди — и начинается степенной рост трудовых затрат.

Почему всё ещё пользуются командной строкой?

На этот вопрос вы получите от людей разные ответы, ни один из которых мне не кажется самым важным:

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

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

Выбор правильного языка

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

Насколько вероятно изменение требований к вашему проекту?

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

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

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

Когда-то было сломано немало копий относительно того, что Twitter начали создавать на Ruby on Rails, а потом это стало причиной затруднений при масштабировании проекта. Позднее Twitter был переведён на Scala. Кто-то может считать, что разработчики совершили ошибку и им следовало сразу выбрать Scala. Я так не думаю. В основе Twitter’а лежит очень простая идея, и в условиях большого количества конкурентов им нужно было завоевать доминирующую позицию на рынке. Им требовалось расти как можно быстрее, невзирая на расходы. Циклы разработки новых возможностей должны были проходить максимально быстро, поскольку это позволяет в кратчайшие сроки понять, что именно нужно пользователям, какой продукт они хотят в результате получить. Трудности масштабирования – это признак не неудачи, а успеха. Было сформулировано видение Twitter’а как готового продукта, и оставалось только реализовать его. С точки зрения разработчиков, это просто нирвана, все о таком мечтают, но мало кому удаётся поработать в таких условиях: «Перепиши это дерьмо с нуля на своём любимом языке, как тебе удобно, лишь бы в будущем с ним было легче работать». Гораздо проще переписывать что-то с нуля, имея перед глазами более слабую реализацию, чем пытаться нащупать облик продукта, который позволит компании взлететь. К сожалению, большинство участников рынка идут только путем избегания «ненужных» расходов на создание с нуля и тратят массу сил и времени на масштабирование того, что изначально не предполагало масштабирования.

Почему так популярен Python?

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

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

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

Почему корпоративное ПО обычно пишут на Java/C++?

В разделе про дырявые и строгие интерфейсы я говорил о компромиссах, связанных с разными типами интерфейсов. Java и С++ относятся больше к строгой части спектра, в отличие от Python или Ruby. Да, в них могут возникать утечки, и есть более строгие языки (тот же Haskell), но зато Java и С++ более сбалансированы с точки зрения масштабируемости, дружелюбности и продолжительности итерирования. Кроме того, эти два языка позволяют гибче управлять дырявостью интерфейсов в зависимости от проектных соглашений. Например, делая переменные или функции частными, публичными или защищёнными.

Как эффективнее срезать углы

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

Источник

Оцените статью
Добавить комментарий

Adblock
detector