Словарик философствующего информатика: различия между версиями

Содержимое удалено Содержимое добавлено
викификация и замена названия шаблона
Строка 1:
Человеческая речь не только носит [[информация|информацию]], но также направляет мысли и действия людей. В науках иные термины и выражения обладают энергией почти волшебного свойства. Одно лишь слово «нейроэтология» в беседе с биологами вызывает волнение,  — видимо, напоминая о неразрешённом споре. Подобные спорные понятия многи в каждой из наук: «тёмная материя», «скрытая переменная», «эмерджентность», «сложность», «семантическая сеть», «нейролингвистика», «синдром Аспергера», «экономическая социология», «бихевиоризм», «стволовые клетки», «этика», «справедливость», «а в глаз»…
 
Энергия бывает не только волнующей, но также и объединяющей, умиротворяющей, вводящей ученых в ощущение понимания основ устройства Вселенной. Например, «принцип неопределённости», «преобразование Фурье», «теория категорий», «экономические циклы», «полнота по Тьюрингу», «аттрактор», «ещё по одной» и много других.
Строка 7:
Так вот, мы стремимся собрать здесь слова, задающие философскую, интуитивно универсальную основу информатики.
 
Эти слова достаточно неожиданно всплывали из небытия и удивительным образом исполнялись смыслом. Они стали своебразными точками входа в храм философствующих информатиков. Конечно, будут встречаться слова и поприземлённее: азбучные концепции, полезные слова-связки  — слова, которые из песни не выкинешь.
 
== Введение ==
Успехи в систематизации чего-либо нередко заслуживают внимания лишь медицинского. Однако, некая произвольная ассоциативная сеть понятий может весьма облегчить понимание темы, не навязывая при этом гипнотизирующего брильянта в виде единственно верной «объединяющей теории всего».
 
Строка 24:
# полезность для образования думающего информатика.
 
=== Почему не в Википедии? ===
Википедия, будучи толковой энциклопедией, стремятся к контекстности и многоаспектности в своих описаниях понятий и явлений, то есть к снабжению каждого факта метафактом, а каждого примера контрпримером.
 
Строка 48:
Действительно, если посмотреть крупным планом на то, что сейчас представляет собой информатика, и постараться вычленить её основную задачу, то по большому счёту остаётся только одно: информатика учит осуществлять [[#Формализация|формализацию]] сущностей и процессов (приводить в порядок мысли).
 
В каждой науке стараются обозначить главную задачу. Например, главная задача механики  — по текущему состоянию механической системы определить её состояние через заданное время. В геометрии  — это определение положений точек и соотношений геометрических объектов по данным соотношениям. Задача физики  — это прогноз, объяснение и использование физических явлений. Задачу всей математики сформулировать сложнее, но с ней всё понятно  — это царица наук, которая есть ткань всех естественных наук, и кроме всего прочего, математика есть удивительный мир для игр разума, близкий к поэзии и изобразительному искусству. Эта поэтичность математики и есть причина, по которой мы осмелились заменить слово в высказывании Ломоносова.
 
У химии, биологии, физики задача, по сути, одна  — описать, объяснить, вывести законы, предсказать свойства (поведение) соответственно веществ, жизни на Земле и физического мира.
 
А чему посвящена информатика?
В прикладной её части она может показаться свалкой умерших и вновь зарождающихся технологий. Но кроме этого имеется в ней некоторое глубокая и важная составляющая, которой она по праву может гордиться — это методы формализации и борьбы с возрастающей сложностью.
 
Аналогом материи в информатике стала информация  — множество бит.
И также как в биологии клетки объединяются в ткани, ткани  — в органы, а органы  — в живые организмы, также в информатике «безличные» биты организуются в информационные блоки, те, в свою очередь, объединяются на новом уровне, и так далее. В результате информация обретает значение, законченную форму и начинает работать на человека.
 
Аналогичная ситуация имеет место и с информационными системами (программами), обрабатывающими информацию — в них также неоднократно происходит переход от клеток к тканям, органам и живым организмам.
 
Конечно, инженер может заметить, что у него возникают аналогичные образы, когда он думает о том, что завод по производству минеральных удобрений состоит, в конечном счёте, из болтиков, скоб, труб и металлических пластин. Но я хотел бы отметить, что по количеству метасистемных переходов информатика, всё же, является победителем.
В то время как в большинстве наук стараются строить всеохватывающие модели, в информатике давно занимаются построением моделей моделей, разработкой методов построения моделей и  т.  п.
 
Видимо, наиболее близким к сути является следующее определение:
 
{{Рамка}}
Информатика — это наука о методах формализации, обработки и организации больших объемов информации.
{{акмар}}
 
Прилагательное “больших”«больших» в этом определении несёт смысловую нагрузку, а не просто вставлено для красного словца.
 
=== Формализация ===
 
Формализация  — это строгое описание (процесс создания описания) чего-либо с целью использования этого описания в деле. Так, например, химик создает описание вещества в виде химической формулы. По этому описанию химик-практик может предсказать свойства вещества и сконструировать его из ингредиентов.
 
Формализация чем-то похожа на поэзию. Поэт, как ни странно, загоняя себя в рамки строгих правил построения стихотворной формы, может выразить больше и с большей убедительностью, чем писатель прозаик.
 
А в информатике правила еще строже. Требуется, чтобы описания понимал не только человек, но и механическое устройство.
 
== Архитектура компьютера. Вычислимость и вычисления ==
Строка 95:
=== Параллелизм ===
 
Параллелизм  — исполнение, при котором разные блоки программы исполняются одновременно.
Различают ''истинный параллелизм'', когда разные вычисления идут на разных исполнителях
действительно одновременно, и ''квазипараллелизм'', когда один и тот же исполнитель
Строка 105:
 
Параллелизм делится на И-параллелизм, когда для
успеха должны завершиться все подпроцессы, и
ИЛИ-параллелизм, когда достаточно успешно завершиться одному из них.
 
Строка 123:
=== Алгоритм ===
 
Алгоритм  — предписание, которое может быть формально исполнено и в результате
приводит к решению задачи.
 
Конкретных вариаций формального понятия алгоритма имеется множество
(машины Тьюринга, алгоритмы Колмогорова и как их частный случай алгоритмы
Маркова, рекурсивные схемы, RAM машины и  т. п.) Все эти понятия
математически эквивалентны, но сложностные характеристики при решении
разных классов задач могут различаться принципиально. Эти формализации
Строка 137:
 
Из [[Журнал «Потенциал»|«Потенциала»]]:
* [[Что такое алгоритм]]
* [[Слово «алгоритм»: происхождение и развитие]]
<!--
=== Стили (парадигмы) программирования ===
Строка 148:
=== Автоматное программирование ===
 
Автоматное программирование  — стиль
программирования, при котором вычисление ориентируется
на структуру конечного автомата: программа
Строка 162:
интенсивно использующая <code>go to</code>, система объектов, в
которой каждое конкретное состояние описано как наследник общего объекта
«состояние программы», и  т. п.) Оно требует, чтобы конкретные
локальные действия и описания были упрятаны в реализации процедур,
изменяющих состояние системы, поскольку автоматное программирование
Строка 185:
Но важно отметить, что термин «модель» в информатике обозначает уже некую самостоятельную сущность,
не привязанную ни к какому реальному объекту. Конечно, часто существует некоторый моделируемый реальный объект,
но его может и не быть. Реальный объект может быть физическим объектом во плоти (вычислительное устройство, сеть компьютеров, промышленный завод или его части, …), или опять же виртуальным, как и сама модель (программа, база даннных, информационная система, ...).
 
Важно отметить, что в практике разработки сложных систем создание модели всегда идёт перед созданием самого объекта.
Модели в информатике не моделируют существующее, а предшествуют разработке нового.
Например, создание модели хранимых данных и модели информационных потоков является важным моментом на этапе проектирования
Строка 193:
 
Итак:<br />
Модель  — это [[#Формализация|формализованное]] описание чего-либо, то есть чётко и однозначно определяющее и, (в идеальном случае) интерпретируемое компьютером, описание на некотором формальном (строго определённом) языке.
 
=== [[Метамоделирование]] ===
 
Метамоделирование  — это одновременно и процесс и некоторая методология (идеология),
провозглашающая, как нужно правильно моделировать.
Это методология формулируется достаточно просто: «прежде чем создавать модель, придумайте модель
описания моделей». Модель описания модели называется метамоделью.
В результате имеем трехуровневую систему: метамодель, модель, сам объект.
Наличие метамодели гарантирует некоторую гибкость системы  — возможность быстрой адаптации
системы в случае необходимости изменения модели.
Модель не заложена в самую основу системы, а может меняться пользователем системы в пределах, позволяемых метамоделью.
Строка 208:
=== Концептуальность ===
 
Концептуальность (или концептуальная целостность)  — один из главный критериев качества
модели (программного средства, программного модуля, системы, ...).
Определяется полнотой и целостностью математических принципов, заложенных в основу модели.
 
Строка 216:
 
Рассмотрим два полюса:
* Концептуальная целостность и чистота принципов, заложенных в основу (математической теории, стиля программирования, ...).
* Эклектичность, смешение различных принципов, необоснованность структуры.
Очевидно, что следует стремится к первому. Но при этом нужно не забывать о народной мудрости и принципах человека-прагматика:
Строка 224:
* «и так сойдет»
* «кто платит, тот и музыку заказывает»
* «лучшее - — враг хорошего»
Причиной забвения и непопулярности некоторых моделей (языков программирования, технологий, программ) является именно их излишняя концептуальная целостность.
Но это редкость. В основном же, программное обеспечения страдает отсутствием концептуальной целостности
Строка 247:
процессы одной физической природы моделировались процессами совершенно
другой (например, механическое движение электрическим током или миграция
людей  — потоками воды). В настоящее время мы вернулись к уровню
Птолемея, и основным инструментом имитационного моделирования служат
программы.
Строка 253:
=== Нормативное моделирование ===
 
Нормативное моделирование  — метод изучения систем, когда
система представляется идеей, а внешнее поведение системы комбинацией идеи
и корректив, вносимых конкретной ситуацией. Критерием качества
Строка 276:
=== Неформализуемое понятие ===
 
Неформализуемое понятие  — понятие, смысл которого
зависит от контекста и меняется таким образом, что противоречит любой его
[[#Формализация|формализации]]. В жизни это такие понятия, как любовь, добро, в
математике  — теория множеств (как её ни формализуй, обязательно найдется
необходимое для математических построений свойство, которое не выполнено).
 
Строка 291:
воспринимает как неформализуемые.
 
=== Концептуальное противоречие ===
 
Концептуальное противоречие  — термин теории неформализуемых понятий, обозначающий формально
непротиворечивые понятия либо концепции, мешающие друг другу при
совместном использовании. Первым явно осознанным примером концептуального
Строка 304:
== Разработка программного обеспечения ==
 
=== Характеристики программного средства ===
 
Характеристики программного средства делятся на группы.
Строка 315:
 
 
'''Функциональность'''  — это способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПС.
 
'''Надёжность'''  — это когда ПС поставили на военную технику, а его разработчик спит спокойно.
 
'''Легкость применения'''  — это характеристики ПС, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя.
 
'''Эффективность'''   это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов.
То есть, скорость и точность работы (или актуальность и полнота услуг, предоставляемых ПС), деленное на вычислительную мощь исполнителя.
 
'''Мобильность'''  — это способность ПС быть перенесенным с одной платформы на другую, то есть возможность использования ПС на разных устройствах с разными операционными системами. Сегодня это, в первую очередь, возможность использования на мобильных устройствах.
 
Функциональность и надежность являются самыми важными характеристиками ПС, причём
обеспечение [[#Правильность и надёжность|надежности]] красной нитью проходит по всем этапам разработки ПС.
Остальные критерии имеют меньший приоритет и ранжируются в зависимости от типа ПС и потребностей пользователей.
 
Но для разработчиков важна другая характеристика ПС:
* '''Сопровождаемость'''  — это совокупность свойств ПС, которая позволяют минимизировать усилия по внесению изменений для устранения в нем ошибок и по его модификации в соответствии с изменяющимися потребностями пользователей.
Эта характеристика касается не качества работы ПС, а качества архитектуры и качество исходного кода ПС:
* концептуальная продуманность архитектуры, которая делает систему простой, легко понимаемой и расширяемой
* [[#Самодокументированность (code self-documentation)|самодокументированность кода]]
* [[#Самопроверяемость (code self-verification)|самопроверяемость кода]]
Эта характеристика, часто не принимаемая во внимание пользователем (пользователь часто просто не имеет доступа к исходным кодам ПС), играет ключевую роль в жизнеспособности и используемости ПС на практике.
 
Строка 344:
=== Сложность ===
 
Суть. Неизбежность сложности. Методы борьбы со сложностью: модульность и reuse, обеспечения независимости модулей системы, использование иерархических структур.
<!--
=== Абстракция ===
-->
 
=== Подпорка ===
 
Подпорка  — объект, понятие или конструкция, вводимая лишь для того, чтобы уложить
алгоритм решения задачи в прокрустово ложе конкретной системы.
 
Например подпоркой может называться кусок кода, в котором осуществляется обработка
Строка 368 ⟶ 369 :
* несовершенность реального мира.
 
От первой причины избавиться очень сложно, от второй  — невозможно.
 
Подпорки  — это проявления несовершенной материи в программировании (которое «в принципе» не зависит от материального субстрата).
Материя  — это, в первую очередь, языки программирования, которые не могут быть универсальными.
Но ничего другого, кроме этой несовершенной материи у программистов нет.
 
Строка 381 ⟶ 382 :
=== Призрак ===
 
Призрак  — значение либо условие, которое не отображено в строках кода программы,
но необходимо для ее понимания. Это понятие дуально к понятию «подпорка».
 
Очень часто призраки  — это предусловия (условия на входные данные),
которые явно не следуют из предшествующих строк кода.
 
Другой пример призраков  — математические теоремы, на которых основывается код
и без которых сложно понять его логику и убедится в его верности.
(например, теоремы, на которых основано шифрование RSA).
 
Есть более прозаические примеры призраков: число шагов цикла <code>while</code>,
либо инварианты циклов, либо требование упорядоченности массива, явно не следующее из кода.
 
Призраки  — абстрактные сущности, на которых основан код, но которые в этот код не попали,
а так и остались в «голове у программиста» (подпорки же обладают обратным свойством  — они присутствуют в коде, но их назначение быстро забывается программистами).
 
Принцип [[#Самодокументированность (code self-documentation)|самодокументированности кода (code self-documentation)]]
провозглашенный в теории коллективной разработки программ гласит
«Призраков быть не должно!»
 
Но что же делать?  — Пишите коментарии!
 
=== [[Reuse: методология повторного использования]] ===
 
Переиспользование  — применение готовых программных модулей (уже использованных в другой программе либо кем-то другим) при создании нового программного обеспечения. Доля переиспользуемых программных решений выказывает качество организации работы программистской артели, но вовсе не обязательно  — качество самой работы. Различные средства модульности и объектности создавались прежде всего с целью облегчить переиспользование. Но обычно они этой цели не достигали.
 
Вспоминая историю науки и техники, можно заметить, что переиспользование всегда было основным орудием математиков: у них все доказывается на основе ранее доказанного. В технике его удалось достичь, лишь отойдя от индивидуальной подгонки каждой детали и введя строжайшие стандарты и допуски на размеры и характеристики деталей; но это возможно лишь при выпуске одинаковых деталей.
Строка 417 ⟶ 418 :
* Переиспользование отвлекает проектировщика от концептуальной целостности и может повлечь ошибки в архитектуре.
 
Серьёзное программирование  — это всегда не массовое производство, а производство уникальных изделий.
 
Чем больше программирование будет ориентироваться на материальное массовое производство, забывая об этой специфике, и чем дольше оно будет игнорировать опыт математики как чистую теорию (забывая о том, что математика точно так же, как программирование, занимается построением идеальных понятий, рождаемых конкретизацией наших идей силой нашей мысли под контролем нашей логики), тем дольше переиспользование будет оставаться коварной ловушкой, в которую попадались слишком многие.
Строка 424 ⟶ 425 :
 
=== [[Ортогональность]] ===
Термин "«ортогональность"» заимствован из геометрии. Две линии являются ортогональными, если они пересекаются под прямым углом, например, оси координат на графике. В терминах векторной алгебры две такие линии перемещения являются независимыми. Если двигаться параллельно оси X вдоль одной из линий, то проекция движущейся точки на другую линию не меняется.
 
Этот термин был введён в информатике для обозначения некой разновидности независимости или несвязанности. В грамотно спроектированной системе программа базы данных будет ортогональной к интерфейсу пользователя: вы можете менять интерфейс пользователя без воздействия на базу данных и менять местами базы данных, не меняя интерфейса.
Строка 430 ⟶ 431 :
=== Проектирование ===
 
Проектирование  — это поиск ответа на вопрос, ''как'' должна быть реализована система.
 
Это второй этап процесса разработки программного обеспечения (первый  — генерация концептуальной идеи).
 
Главные задачи проектирования  — подбор подходящего стиля и инструментария, а затем
разбиение задачи на подзадачи, естественно представимые в виде реализуемых
модулей или процедур и фиксация системы взаимосвязей между выделенными
блоками.
 
Область знаний «Системный анализ» претендует на описание
базовых принципов, позволяющих избежать ошибок во время проектирования:
* концептуальная целостность;
Строка 451 ⟶ 452 :
Основной же принцип всякого проектирования это:
* '''достижения баланса между дуальными концепциями''',
как то, «универсальность и расширяемость  — простота и достижение конкретной функциональности»,
«концептуальная целостность - — полнота и удобство функциональности»,
«многофункциональность  — внутренняя простота и поддерживаемость».
 
Для успешного проектирования необходимо просто знать
о существовании этого дуализма,
иметь представление о большом количестве различных принципов,
знать негативные и позитивные стороны каждого принципа,
видеть какая пара дуальных принципов является наиболее критической для
поставленной задачи и наиболее аккуратно проконтролировать баланс этой пары.
 
Самым ценным (но наиболее трудным) способом проектирования является известный в теории творческого мышления принцип: выделить критическое проблемное противоречие (это как раз предыдущий пункт) и снять его, перейдя к более высоким уровням.
Компромисс всегда паллиатив, но он достижим гораздо легче.
 
Это не так много, но и не так мало.
Проектировщик должен владеть системным подходом к решению задачи,
способностью выделять существенное, не отвлекаться на детали,
не увлекаться оттачиванием мелочей,
умением добиваться концептуальной целостности не забывая о реальной цели.
Лучшим рецептом обучения проектированию является комбинация
изучение оснований логики и участие в реальных проектах.
 
Строка 480 ⟶ 481 :
 
=== Тестирование ===
{{ССЫЛКАСсылка|Тестирование}}
 
=== Восходящее программирование ===
Характерная особенность Лиспа как вольно саморасширяемого языка: см. [[Лисп#Восходящее программирование]].
 
=== Прототипирование ===
 
Прототипирование  — это быстрая «черновая» реализация базовой функциональности для анализа работы системы в целом. Для прототипирования используют языки высокого уровня абстракции (Java, Python, Haskell, ...). После этапа прототипирования обязательно следуют этапы пересмотрения архитектуры системы, разработки, реализации и тестирования конечного продукта. На этапе разработки подготавливают систему тестов, по работе которых буду судить о качестве продукта. При реализации решения обычно используют другой, «более машинноориентированный» язык программирования (Си, Си++, ...), пишут более аккуратный документированный код, а на тестирование системы тратят сравнительно большое количество усилий для достижения качественного результата. На этапе прототипирования выявляются важные архитектурные ошибки, вносятся поправки в интерфейсы модулей (перераспределяется функциональность между кусочками системы). Прототипирование по мнению многих программистов является самым приятным этапом разработки, так как малыми усилиями создается нечто более-менее работающее. Кроме того, во время прототипирования на программистов обычно «снисходит понимание» и они начинают «видеть», как система должна быть устроена.
 
=== Несвязность и закон Деметра ===
{{ССЫЛКАСсылка|Несвязность и закон Деметра}}
 
=== «Волшебники», частично автоматизирующие разработку систем ===
[[макрокоманды]]
[[макропрограммирование]]
{{ССЫЛКАСсылка|Злые волшебники}}
 
=== Надёжность ===
 
Безусловно, программные средства (далее тут - — ПС) должны работать правильно и надёжно.
Но оба упомянутых термина допускают большую свободу интерпретации.
Например:
 
'''Работать правильно'''  — это
* так, как представляет себе это заказчик;
* так, как понял и сформулировал менеджер проекта;
Строка 512 ⟶ 513 :
 
Под надёжностью ПС можно понимать правильность работы для '''всех''' входных данных.
Для большинства сложных систем такая ''абсолютная надёжность''  — очень серьезное требование. Часто оно просто недостижимо. Какой бы полной не была спецификация логики работы ПС, она просто не может
включить (описать), каким должно быть поведение ПС в экстремальных условиях.
 
Строка 520 ⟶ 521 :
от ПС:
 
'''Надёжность ПС'''  — это высокая вероятность правильности работы ПС как при
нормальных так и при экстремальных условиях. Надёжность достигается за счет учёта
возможных сбоев в различных подсистемах, от которых зависит
работа ПС, и многоуровневой защиты от сбоев как внутренних, так и внешних подсистем.
 
В экстремальных ситуациях словосочетание «правильность работы» имеет смысл заменить на
«логичность поведения ПС». Даже в экстремальных ситуациях ПС должно делать
попытки «выжить» и обеспечить сохранность данных, а также
Строка 534 ⟶ 535 :
и внутренней логикой работы компонент.
 
[[#Самодокументированность (code self-documentation)|Самодокументированность]] и
[[#Cамопроверяемость (code self-verification)|самопроверяемость]] являются важными
общепринятыми методологиями достижения надёжности кода. Они позволяют без тестирования
продукта, малыми усилиями, обеспечить недопущение и устранение большого числа ошибок.
 
Кроме того, надёжность ПС гарантируется с помощью массового
и многопланового [[#Тестирование|тестирования]] ПС.
 
Строка 546 ⟶ 547 :
Эти условия указываются непосредственно в коде, и непосредственно
связаны с требованиями, предъявляемыми к ПС в спецификации логики работы.
Например, это могут быть post- и prerequisites conditions —
условие, которым должны удовлетворять данные в момент вызова некоторой функции,
и в момент завершения выполнения функции.
Строка 566 ⟶ 567 :
слишком медленному коду. Например, в коде в самых различных
местах можно вставлять кусочки, проверяющие корректность данных и состояний устройств,
с которыми будет связано следующее действие.
Здесь, как и везде и информационных технологиях, важно чувствовать баланс
и не доводить стремление к надёжности до паранойи.
Строка 581 ⟶ 582 :
 
=== Демон ===
Демон  — программная единица, которая активизируется не
путем прямого вызова, а при наступлении некоторого события в системе.
Демон отличается от обработчика события тем, что он программируется как
Строка 591 ⟶ 592 :
файловой системы, файрволлы).
 
[[Категория:Информатика]]
[[Категория:Философия и идеология программирования ЭВМ]]