Словарик философствующего информатика: различия между версиями
Содержимое удалено Содержимое добавлено
Innv (обсуждение | вклад) викификация и замена названия шаблона |
|||
Строка 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:
=== Сложность ===
Суть. Неизбежность сложности.
<!--
=== Абстракция ===
-->
=== Подпорка ===
Подпорка
алгоритм решения задачи в прокрустово ложе конкретной системы.
Например подпоркой может называться кусок кода, в котором осуществляется обработка
Строка 368 ⟶ 369 :
* несовершенность реального мира.
От первой причины избавиться очень сложно, от второй
Подпорки
Материя
Но ничего другого, кроме этой несовершенной материи у программистов нет.
Строка 381 ⟶ 382 :
=== Призрак ===
Призрак
но необходимо для ее понимания. Это понятие дуально к понятию «подпорка».
Очень часто призраки
которые
Другой пример призраков
и без которых сложно понять его логику и убедится в его верности.
(например, теоремы, на которых основано шифрование RSA).
Есть более прозаические примеры призраков: число шагов цикла <code>while</code>,
либо инварианты циклов, либо требование упорядоченности массива, явно не следующее из кода.
Призраки
а так и остались в «голове у программиста» (подпорки же обладают обратным свойством
Принцип [[#Самодокументированность (code self-documentation)|самодокументированности кода (code self-documentation)]]
провозглашенный в теории коллективной разработки программ гласит
«Призраков быть не должно!»
Но что же делать?
=== [[Reuse: методология повторного использования]] ===
Переиспользование
Вспоминая историю науки и техники, можно заметить, что переиспользование всегда было основным орудием математиков: у них все доказывается на основе ранее доказанного. В технике его удалось достичь, лишь отойдя от индивидуальной подгонки каждой детали и введя строжайшие стандарты и допуски на размеры и характеристики деталей; но это возможно лишь при выпуске одинаковых деталей.
Строка 417 ⟶ 418 :
* Переиспользование отвлекает проектировщика от концептуальной целостности и может повлечь ошибки в архитектуре.
Серьёзное программирование
Чем больше программирование будет ориентироваться на материальное массовое производство, забывая об этой специфике, и чем дольше оно будет игнорировать опыт математики как чистую теорию (забывая о том, что математика точно так же, как программирование, занимается построением идеальных понятий, рождаемых конкретизацией наших идей силой нашей мысли под контролем нашей логики), тем дольше переиспользование будет оставаться коварной ловушкой, в которую попадались слишком многие.
Строка 424 ⟶ 425 :
=== [[Ортогональность]] ===
Термин
Этот термин был введён в информатике для обозначения некой разновидности независимости или несвязанности. В грамотно спроектированной системе программа базы данных будет ортогональной к интерфейсу пользователя: вы можете менять интерфейс пользователя без воздействия на базу данных и менять местами базы данных, не меняя интерфейса.
Строка 430 ⟶ 431 :
=== Проектирование ===
Проектирование
Это второй этап процесса разработки программного обеспечения (первый
Главные задачи проектирования
разбиение задачи на подзадачи, естественно представимые в виде реализуемых
модулей или процедур и фиксация системы взаимосвязей между выделенными
блоками.
Область знаний «Системный анализ» претендует на описание
базовых принципов, позволяющих избежать ошибок во время проектирования:
* концептуальная целостность;
Строка 451 ⟶ 452 :
Основной же принцип всякого проектирования это:
* '''достижения баланса между дуальными концепциями''',
как то, «универсальность и расширяемость
«концептуальная целостность
«многофункциональность
Для успешного проектирования необходимо просто знать
о существовании этого дуализма,
иметь представление о большом количестве различных принципов,
знать негативные и позитивные стороны каждого принципа,
видеть какая пара дуальных принципов является наиболее критической для
поставленной задачи и наиболее аккуратно проконтролировать баланс этой пары.
Самым ценным (но наиболее трудным) способом проектирования является известный в теории творческого мышления принцип: выделить критическое проблемное противоречие (это как раз предыдущий пункт) и снять его, перейдя к более высоким уровням.
Компромисс всегда паллиатив, но он достижим гораздо легче.
Это не так много, но и не так мало.
Проектировщик должен владеть системным подходом к решению задачи,
способностью выделять существенное, не отвлекаться на детали,
не увлекаться оттачиванием мелочей,
умением добиваться концептуальной целостности не забывая о реальной цели.
Лучшим рецептом обучения проектированию является комбинация
изучение оснований логики и участие в реальных проектах.
Строка 480 ⟶ 481 :
=== Тестирование ===
{{
=== Восходящее программирование ===
Характерная особенность Лиспа как вольно саморасширяемого языка: см. [[Лисп#Восходящее программирование]].
=== Прототипирование ===
Прототипирование
=== Несвязность и закон Деметра ===
{{
=== «Волшебники», частично автоматизирующие разработку систем ===
[[макрокоманды]]
[[макропрограммирование]]
{{
=== Надёжность ===
Безусловно, программные средства (далее тут
Но оба упомянутых термина допускают большую свободу интерпретации.
Например:
'''Работать правильно'''
* так, как представляет себе это заказчик;
* так, как понял и сформулировал менеджер проекта;
Строка 512 ⟶ 513 :
Под надёжностью ПС можно понимать правильность работы для '''всех''' входных данных.
Для большинства сложных систем такая ''абсолютная надёжность''
включить (описать), каким должно быть поведение ПС в экстремальных условиях.
Строка 520 ⟶ 521 :
от ПС:
'''Надёжность ПС'''
нормальных так и при экстремальных условиях. Надёжность достигается за счет учёта
возможных сбоев в различных подсистемах, от которых зависит
работа ПС, и многоуровневой защиты от сбоев как внутренних, так и внешних подсистем.
В экстремальных ситуациях словосочетание «правильность работы» имеет смысл заменить на
«логичность поведения ПС». Даже в экстремальных ситуациях ПС должно делать
попытки «выжить» и обеспечить сохранность данных, а также
Строка 534 ⟶ 535 :
и внутренней логикой работы компонент.
[[#Самодокументированность (code self-documentation)|Самодокументированность]] и
[[#Cамопроверяемость (code self-verification)|самопроверяемость]] являются важными
общепринятыми методологиями достижения надёжности кода. Они позволяют без тестирования
продукта, малыми усилиями, обеспечить недопущение и устранение большого числа ошибок.
Кроме того, надёжность ПС гарантируется с помощью массового
и многопланового [[#Тестирование|тестирования]] ПС.
Строка 546 ⟶ 547 :
Эти условия указываются непосредственно в коде, и непосредственно
связаны с требованиями, предъявляемыми к ПС в спецификации логики работы.
Например, это могут быть post- и
условие, которым должны удовлетворять данные в момент вызова некоторой функции,
и в момент завершения выполнения функции.
Строка 566 ⟶ 567 :
слишком медленному коду. Например, в коде в самых различных
местах можно вставлять кусочки, проверяющие корректность данных и состояний устройств,
с которыми будет связано следующее действие.
Здесь, как и везде и информационных технологиях, важно чувствовать баланс
и не доводить стремление к надёжности до паранойи.
Строка 581 ⟶ 582 :
=== Демон ===
Демон
путем прямого вызова, а при наступлении некоторого события в системе.
Демон отличается от обработчика события тем, что он программируется как
Строка 591 ⟶ 592 :
файловой системы, файрволлы).
[[Категория:Информатика]]
[[Категория:Философия и идеология программирования ЭВМ]] |