В программной инженерии и информатике абстракция — это процесс обобщения конкретных деталей, [1] таких как атрибуты , отвлекая внимание от изучения объектов и систем, чтобы сосредоточить внимание на деталях большей важности. [2] Абстракция — это фундаментальная концепция в информатике и программной инженерии , особенно в парадигме объектно-ориентированного программирования . [3] Вот некоторые примеры:
Суть абстракции заключается в сохранении информации, которая имеет значение в данном контексте, и забывании информации, которая не имеет значения в этом контексте.
– Джон В. Гуттаг [5]
Вычисления в основном работают независимо от конкретного мира. Аппаратное обеспечение реализует модель вычислений , которая взаимозаменяема с другими. [6] Программное обеспечение структурировано в архитектурах, позволяющих людям создавать огромные системы, концентрируясь на нескольких проблемах одновременно. Эти архитектуры сделаны из определенных выборов абстракций. Десятое правило Гринспена — это афоризм о том, как такая архитектура является одновременно неизбежной и сложной.
Абстракция языка является центральной формой абстракции в вычислениях: новые искусственные языки разрабатываются для выражения определенных аспектов системы. Языки моделирования помогают в планировании. Компьютерные языки могут обрабатываться с помощью компьютера. Примером этого процесса абстракции является поколенческая разработка языка программирования от машинного языка до языка ассемблера и языка высокого уровня . Каждый этап может использоваться как ступенька для следующего этапа. Абстракция языка продолжается, например, в языках сценариев и предметно-ориентированных языках программирования .
В языке программирования некоторые функции позволяют программисту создавать новые абстракции. К ним относятся подпрограммы , модули , полиморфизм и программные компоненты . Некоторые другие абстракции, такие как шаблоны проектирования программного обеспечения и архитектурные стили, остаются невидимыми для переводчика и работают только при проектировании системы.
Некоторые абстракции пытаются ограничить круг концепций, которые должен знать программист, полностью скрывая абстракции, на которых они построены. Инженер-программист и писатель Джоэл Спольски раскритиковал эти усилия, заявив, что все абстракции являются дырявыми — что они никогда не смогут полностью скрыть детали ниже; [7] однако это не отрицает полезности абстракции.
Некоторые абстракции предназначены для взаимодействия с другими абстракциями — например, язык программирования может содержать внешний интерфейс функций для выполнения вызовов к языку более низкого уровня.
Различные языки программирования предоставляют различные типы абстракции в зависимости от предполагаемых приложений языка. Например:
function(parameters) = 0; abstractinterfaceАналитики разработали различные методы формальной спецификации программных систем. Некоторые известные методы включают:
Языки спецификаций обычно полагаются на абстракции того или иного рода, поскольку спецификации обычно определяются раньше в проекте (и на более абстрактном уровне), чем конечная реализация. Например, язык спецификаций UML позволяет определять абстрактные классы, которые в каскадном проекте остаются абстрактными на этапе архитектуры и спецификации проекта.
Языки программирования предлагают абстракцию управления как одну из основных целей их использования. Компьютерные машины понимают операции на очень низком уровне, такие как перемещение некоторых битов из одного места памяти в другое и создание суммы двух последовательностей битов. Языки программирования позволяют делать это на более высоком уровне. Например, рассмотрим это утверждение, написанное в стиле Pascal :
a := (1 + 2) * 5Для человека это кажется довольно простым и очевидным вычислением ( «один плюс два равно трем, умножить на пять равно пятнадцати» ). Однако низкоуровневые шаги, необходимые для выполнения этой оценки и возврата значения «15», а затем присвоения этого значения переменной «a», на самом деле довольно тонкие и сложные. Значения необходимо преобразовать в двоичное представление (часто гораздо более сложная задача, чем можно было бы подумать), а вычисления разложить (компилятором или интерпретатором) на ассемблерные инструкции (опять же, которые гораздо менее интуитивны для программиста: такие операции, как сдвиг двоичного регистра влево или добавление двоичного дополнения содержимого одного регистра к другому, просто не являются тем, как люди думают об абстрактных арифметических операциях сложения или умножения). Наконец, присвоение результирующего значения «15» переменной с меткой «a» для того, чтобы «a» можно было использовать позже, включает в себя дополнительные «закулисные» шаги поиска метки переменной и результирующего местоположения в физической или виртуальной памяти, сохранения двоичного представления «15» в этом месте памяти и т. д.
Без абстракции управления программисту пришлось бы указывать все шаги регистрового/двоичного уровня каждый раз, когда он просто хотел бы сложить или умножить пару чисел и присвоить результат переменной. Такое дублирование усилий имеет два серьезных негативных последствия:
Структурное программирование подразумевает разделение сложных программных задач на более мелкие части с четким управлением потоком и интерфейсами между компонентами, а также снижением сложности, потенциальной возможности возникновения побочных эффектов.
В простой программе это может быть направлено на то, чтобы гарантировать, что циклы имеют единственные или очевидные точки выхода и (где это возможно) иметь единственные точки выхода из функций и процедур.
В более крупной системе это может включать разбиение сложных задач на множество различных модулей. Рассмотрим систему, которая обрабатывает расчет заработной платы на судах и в береговых офисах:
Эти слои создают эффект изоляции деталей реализации одного компонента и его различных внутренних методов от других. Объектно-ориентированное программирование охватывает и расширяет эту концепцию.
Абстракция данных обеспечивает четкое разделение между абстрактными свойствами типа данных и конкретными деталями его реализации. Абстрактные свойства — это те, которые видны клиентскому коду, использующему тип данных — интерфейс к типу данных — в то время как конкретная реализация остается полностью приватной и действительно может меняться, например, для включения улучшений эффективности с течением времени. Идея заключается в том, что такие изменения не должны оказывать никакого влияния на клиентский код, поскольку они не подразумевают никаких изменений в абстрактном поведении.
Например, можно определить абстрактный тип данных , называемый таблицей поиска , которая однозначно связывает ключи со значениями , и в которой значения могут быть извлечены путем указания соответствующих им ключей. Такая таблица поиска может быть реализована различными способами: как хэш-таблица , двоичное дерево поиска или даже простой линейный список пар (ключ:значение). Что касается клиентского кода, абстрактные свойства типа в каждом случае одинаковы.
Конечно, все это зависит от правильного понимания деталей интерфейса в первую очередь, поскольку любые изменения в нем могут иметь серьезные последствия для клиентского кода. Как один из способов взглянуть на это: интерфейс формирует контракт на согласованное поведение между типом данных и клиентским кодом; все, что не прописано в контракте, может быть изменено без уведомления.
Хотя большая часть абстракции данных происходит посредством компьютерной науки и автоматизации, бывают случаи, когда этот процесс выполняется вручную и без вмешательства программирования. Один из способов понять это — через абстракцию данных в процессе проведения систематического обзора литературы. В этой методологии данные абстрагируются одним или несколькими абстракторами при проведении метаанализа , при этом ошибки уменьшаются посредством двойной абстракции данных с последующей независимой проверкой, известной как вынесение суждения . [11]
В теории объектно-ориентированного программирования абстракция подразумевает возможность определять объекты, представляющие абстрактных «актеров», которые могут выполнять работу, сообщать о своем состоянии и изменять его, а также «общаться» с другими объектами в системе. Термин инкапсуляция относится к сокрытию деталей состояния , но расширение концепции типа данных из более ранних языков программирования для наиболее тесной связи поведения с данными и стандартизации способа взаимодействия различных типов данных является началом абстракции . Когда абстракция переходит в определенные операции, позволяя заменять объекты различных типов, это называется полиморфизмом . Когда она переходит в противоположном направлении, внутри типов или классов, структурируя их для упрощения сложного набора отношений, это называется делегированием или наследованием .
Различные объектно-ориентированные языки программирования предлагают схожие возможности для абстракции, все для поддержки общей стратегии полиморфизма в объектно-ориентированном программировании, которая включает замену одного типа на другой в той же или похожей роли. Хотя это и не поддерживается в целом, конфигурация, образ или пакет могут предопределять большое количество этих привязок во время компиляции , компоновки или загрузки . Это оставит только минимум таких привязок для изменения во время выполнения .
Например, Common Lisp Object System или Self , в меньшей степени различают класс-экземпляр и больше используют делегирование для полиморфизма . Отдельные объекты и функции абстрагируются более гибко, чтобы лучше соответствовать общему функциональному наследию Lisp .
C++ является примером другой крайности: он в значительной степени полагается на шаблоны , перегрузку и другие статические привязки во время компиляции, что, в свою очередь, имеет определенные проблемы с гибкостью.
Хотя эти примеры предлагают альтернативные стратегии для достижения той же абстракции, они принципиально не меняют необходимость поддержки абстрактных существительных в коде — все программирование основано на способности абстрагировать глаголы как функции, существительные как структуры данных и то и другое как процессы.
Рассмотрим, например, фрагмент Java- примера для представления некоторых распространенных фермерских "животных" на уровне абстракции, подходящем для моделирования простых аспектов их голода и кормления. Он определяет Animalкласс для представления как состояния животного, так и его функций:
public class Animal extends LivingThing { private Location loc ; private double energyReserves ; public boolean isHungry () { return energyReserves < 2.5 ; } public void eat ( Food food ) { // Потребление пищи energyReserves + = food.getCalories (); } public void moveTo ( Location location ) { // Перемещение в новое местоположение this.loc = location ; } } Используя приведенное выше определение, можно создать объекты типаЖивотноеи вызывать их методы следующим образом:
thePig = new Animal () ; theCow = new Animal ( ) ; if ( thePig.isHungry ( ) ) { thePig.eat ( tableScraps ) ; } if ( theCow.isHungry ( ) ) { theCow.eat ( grass ) ; } theCow.moveTo ( theBarn ) ; В приведенном выше примере класс Animalявляется абстракцией, используемой вместо реального животного, LivingThingявляется дальнейшей абстракцией (в данном случае обобщением) Animal.
Если требуется более дифференцированная иерархия животных — например, чтобы отделить тех, кто дает молоко, от тех, кто не дает ничего, кроме мяса в конце своей жизни, — то это промежуточный уровень абстракции, вероятно, DairyAnimal (коровы, козы), которые будут есть пищу, подходящую для получения хорошего молока, и MeatAnimal (свиньи, быки), которые будут есть пищу, обеспечивающую получение мяса наилучшего качества.
Такая абстракция могла бы устранить необходимость для кодировщика приложения указывать тип пищи, так что вместо этого они могли бы сосредоточиться на графике кормления. Два класса могли бы быть связаны с помощью наследования или быть автономными, и программист мог бы определять различные степени полиморфизма между двумя типами. Эти возможности, как правило, радикально различаются между языками, но в целом каждый может достичь всего, что возможно с любым из других. Большое количество перегрузок операций, тип данных за типом данных, могут иметь тот же эффект во время компиляции, что и любая степень наследования или другие средства достижения полиморфизма. Нотация класса — это просто удобство для кодировщика.
Решения относительно того, что абстрагировать, а что оставить под контролем кодировщика, становятся основной заботой объектно-ориентированного проектирования и анализа предметной области , а фактическое определение соответствующих взаимосвязей в реальном мире является заботой объектно-ориентированного анализа или анализа наследия.
В общем, чтобы определить подходящую абстракцию, нужно принять много небольших решений о сфере действия (анализ предметной области), определить, с какими другими системами нужно сотрудничать (анализ наследия), затем выполнить подробный объектно-ориентированный анализ, который выражается в рамках ограничений по времени и бюджету проекта как объектно-ориентированный дизайн. В нашем простом примере домен — это скотный двор, живые свиньи и коровы и их привычки в еде — это ограничения наследия, подробный анализ заключается в том, что кодеры должны иметь возможность кормить животных тем, что доступно, и поэтому нет причин кодировать тип пищи в самом классе, а дизайн — это один простой класс Animal, экземплярами которого являются свиньи и коровы с теми же функциями. Решение дифференцировать DairyAnimal изменит подробный анализ, но анализ предметной области и наследия останется неизменным — таким образом, он полностью находится под контролем программиста, и это называется абстракцией в объектно-ориентированном программировании в отличие от абстракции в анализе предметной области или наследия.
При обсуждении формальной семантики языков программирования , формальных методов или абстрактной интерпретации абстракция относится к акту рассмотрения менее подробного, но безопасного определения наблюдаемого поведения программы. Например, можно наблюдать только конечный результат выполнения программы вместо того, чтобы рассматривать все промежуточные этапы выполнения. Абстракция определяется как конкретная (более точная) модель выполнения.
Абстракция может быть точной или верной по отношению к свойству, если можно ответить на вопрос о свойстве одинаково хорошо на конкретной или абстрактной модели. Например, если кто-то хочет узнать, чему равен результат оценки математического выражения, включающего только целые числа +, -, ×, по модулю n , то нужно только выполнить все операции по модулю n (знакомая форма этой абстракции — выбрасывание девяток ).
Однако абстракции, хотя и не обязательно точные , должны быть обоснованными . То есть, должно быть возможно получить обоснованные ответы из них — даже если абстракция может просто привести к результату неразрешимости . Например, ученики в классе могут быть абстрагированы по их минимальному и максимальному возрасту; если кто-то спрашивает, принадлежит ли определенный человек к этому классу, можно просто сравнить возраст этого человека с минимальным и максимальным возрастом; если его возраст выходит за пределы диапазона, можно смело ответить, что человек не принадлежит к классу; если нет, можно только ответить «Я не знаю».
Уровень абстракции, включенный в язык программирования, может влиять на его общее удобство использования . Фреймворк когнитивных измерений включает концепцию градиента абстракции в формализме. Этот фреймворк позволяет разработчику языка программирования изучать компромиссы между абстракцией и другими характеристиками дизайна, а также то, как изменения в абстракции влияют на удобство использования языка.
Абстракции могут оказаться полезными при работе с компьютерными программами, поскольку нетривиальные свойства компьютерных программ по сути неразрешимы (см. теорему Райса ). Как следствие, автоматические методы получения информации о поведении компьютерных программ должны либо отказаться от завершения (в некоторых случаях они могут давать сбой, аварийно завершаться или вообще не выдавать результат), либо от обоснованности (они могут предоставлять ложную информацию), либо от точности (они могут отвечать «Я не знаю» на некоторые вопросы).
Абстракция — это основная концепция абстрактной интерпретации . Проверка модели обычно происходит на абстрактных версиях изучаемых систем.
Компьютерная наука обычно представляет уровни (или, реже, слои ) абстракции, где каждый уровень представляет другую модель той же информации и процессов, но с разным количеством деталей. Каждый уровень использует систему выражения, включающую уникальный набор объектов и композиций, которые применяются только к определенной области. [12] Каждый относительно абстрактный, «более высокий» уровень строится на относительно конкретном, «более низком» уровне, который имеет тенденцию обеспечивать все более «зернистое» представление. Например, вентили строятся на электронных схемах, двоичный код на вентилях, машинный язык на двоичном, язык программирования на машинном языке, приложения и операционные системы на языках программирования. Каждый уровень воплощен, но не определяется уровнем ниже него, что делает его языком описания, который является в некоторой степени самодостаточным.
Поскольку многие пользователи систем баз данных не имеют глубоких знаний о компьютерных структурах данных, разработчики баз данных часто скрывают сложность с помощью следующих уровней:
Физический уровень: Самый низкий уровень абстракции описывает, как система фактически хранит данные. Физический уровень подробно описывает сложные низкоуровневые структуры данных.
Логический уровень: Следующий более высокий уровень абстракции описывает, какие данные хранит база данных, и какие отношения существуют между этими данными. Таким образом, логический уровень описывает всю базу данных в терминах небольшого числа относительно простых структур. Хотя реализация простых структур на логическом уровне может включать сложные структуры физического уровня, пользователю логического уровня не нужно знать об этой сложности. Это называется физической независимостью данных . Администраторы баз данных , которые должны решать, какую информацию хранить в базе данных, используют логический уровень абстракции.
Уровень представления: наивысший уровень абстракции описывает только часть всей базы данных. Несмотря на то, что логический уровень использует более простые структуры, сложность сохраняется из-за разнообразия информации, хранящейся в большой базе данных. Многим пользователям системы базы данных не нужна вся эта информация; вместо этого им нужно получить доступ только к части базы данных. Уровень представления абстракции существует для упрощения их взаимодействия с системой. Система может предоставлять много представлений для одной и той же базы данных.
Возможность создания дизайна различных уровней абстракции может
Это могут использовать как системное проектирование , так и проектирование бизнес-процессов . Некоторые процессы проектирования специально генерируют проекты, содержащие различные уровни абстракции.
Многоуровневая архитектура разделяет задачи приложения на сложенные группы (слои). Это метод, используемый при проектировании компьютерного программного обеспечения, оборудования и коммуникаций, в котором системные или сетевые компоненты изолированы в слоях, так что изменения могут быть сделаны в одном слое, не затрагивая другие.