WikiDer > TLA +
Парадигма | Действие |
---|---|
Разработано | Лесли Лэмпорт |
Впервые появился | 23 апреля 1999 г.[1] |
Стабильный выпуск | TLA+2 / 15 января 2014 г.[2] |
Язык реализации | Ява |
Операционные системы | Кроссплатформенность (мультиплатформенность) |
Лицензия | Лицензия MIT[3] |
Расширения имени файла | .tla |
Интернет сайт | исследование |
TLA+ это формальная спецификация язык, разработанный Лесли Лэмпорт. Он используется для разработки, моделирования, документирования и проверки программ, особенно параллельные системы и распределенные системы. TLA+ описан как поддающийся исчерпывающей проверке псевдокод,[4] и его использование сравнивается с рисование чертежей для программных комплексов;[5] TLA является акроним за Временная логика действий.
По проектированию и документации TLA+ выполняет ту же цель, что и неформальный технические характеристики. Однако TLA+ спецификации написаны на формальном языке логика и математика, а точность спецификаций, написанных на этом языке, предназначена для выявления недостатков дизайна до начала реализации системы.[6]
Поскольку TLA+ спецификации написаны на формальном языке, они поддаются конечному проверка модели. Средство проверки моделей находит все возможные варианты поведения системы вплоть до некоторого количества этапов выполнения и проверяет их на предмет нарушений желаемого инвариантность свойства, такие как безопасность и живость. TLA+ спецификации используют базовые теория множеств определить безопасность (плохого не случится) и темпоральная логика чтобы определить жизнеспособность (хорошие вещи в конце концов случаются).
TLA+ также используется для записи проверенные машиной доказательства правильности как для алгоритмы и математические теоремы. Доказательства написаны в декларативном, иерархическом стиле, независимом от какой-либо отдельной бэкэнда средства доказательства теорем. Как формальные, так и неформальные структурированные математические доказательства могут быть написаны в TLA.+; язык похож на Латекс, и существуют инструменты для перевода TLA+ спецификации к документам LaTeX.[7]
TLA+ был представлен в 1999 году после нескольких десятилетий исследований метода проверки для параллельных систем. С тех пор была разработана цепочка инструментов, включая IDE и средство проверки распределенных моделей. Псевдокодоподобный язык PlusCal создан в 2009 году; Это транспилес в TLA+ и полезен для определения последовательных алгоритмов. TLA+2 был объявлен в 2014 году, расширяя языковую поддержку для конструкций доказательства. Текущий TLA+ ссылка TLA+ Гиперкнига пользователя Лесли Лэмпорт.
История
Современное темпоральная логика был разработан Артур Прайор в 1957 году тогда называли напряженной логикой. Несмотря на то что Амир Пнуели был первым, кто серьезно изучил приложения темпоральной логики к ИнформатикаПрайор размышлял о его использовании десятью годами ранее, в 1967 году:
Полезность систем такого типа [от дискретного времени] не зависит от какого-либо серьезного метафизического предположения о дискретности времени; они применимы в ограниченных областях дискурса, в которых нас интересует только то, что происходит дальше в последовательности дискретных состояний, например в работе цифрового компьютера.
Пнуэли исследовал использование темпоральной логики в определении и рассуждении о компьютерных программах, представив линейная темпоральная логика в 1977 году. LTL стал важным инструментом для анализа параллельных программ, легко выражая такие свойства, как взаимное исключение и свобода от тупик.[8]
Параллельно с работой Пнуэли над LTL ученые работали над обобщением Логика Хоара для проверки многопроцессорных программ. Лесли Лэмпорт заинтересовался проблемой после экспертная оценка обнаружил ошибку в представленной им статье о взаимном исключении. Эд Эшкрофт представил инвариантность в своей статье 1975 года «Доказательство утверждений о параллельных программах», которую Лэмпорт использовал для обобщения Флойдв своей статье 1977 г. «Доказательство правильности многопроцессорных программ». В статье Лампорта также представлены безопасность и живость как обобщение частичная правильность и прекращение, соответственно.[9] Этот метод использовался для проверки первого параллельного вывоз мусора алгоритм в статье 1978 года с Эдсгер Дейкстра.[10]
Лампорт впервые столкнулся с LTL Пнуэли во время семинара 1978 г. Стэнфорд организованный Сьюзан Овики. По словам Лэмпорта, «я был уверен, что темпоральная логика - это какая-то абстрактная чушь, у которой никогда не будет практического применения, но это показалось забавным, поэтому я присутствовал». В 1980 году он опубликовал статью «Иногда бывает, а иногда и не никогда» », которая стала одной из самых цитируемых статей в литературе по темпоральной логике.[11] Лэмпорт работал над написанием спецификаций временной логики во время своего пребывания в НИИ, но сочли такой подход непрактичным:
Однако я разочаровался во временной логике, когда увидел, как Шварц, Меллиар-Смит и Фриц Фогт целыми днями пытались определить простой Очередь FIFO - спорить о достаточности перечисленных объектов. Я понял, что, несмотря на его эстетическую привлекательность, написание спецификации как совокупности временных свойств просто не работает на практике.
Его поиски практического метода спецификации привели к статье 1983 г. «Specifying Concurrent Programming Modules», в которой была введена идея описания переходов между состояниями как булевозначных функций переменных со штрихом и без штриха.[12] Работа продолжалась в течение 1980-х годов, и Лэмпорт начал публиковать статьи о временная логика действий в 1990 г .; однако официально он не был представлен до тех пор, пока в 1994 году не была опубликована «Временная логика действий». TLA позволила использовать действия в темпоральных формулах, что, по словам Лэмпорта, «обеспечивает элегантный способ формализовать и систематизировать все рассуждения, используемые при параллельной проверке системы».[13]
Спецификации TLA в основном состояли из обычной вневременной математики, которую Лэмпорт нашел менее громоздкой, чем чисто временная спецификация. TLA предоставила математическую основу для языка спецификаций TLA+, представленный в статье "Определение параллельных систем с помощью TLA+" в 1999 году.[1] Позже в том же году Юань Ю написал TLC. модель проверки для TLA+ технические характеристики; ТСХ использовалась для поиска ошибок в согласованность кеша протокол для Compaq мультипроцессор.[14]
Лампорт опубликовал полный учебник по TLA+ в 2002 году под названием «Определение систем: TLA+ Язык и инструменты для инженеров-программистов ».[15] PlusCal был представлен в 2009 году,[16] и TLA+ система доказательств (TLAPS) в 2012 году.[17] TLA+2 была анонсирована в 2014 году, добавив некоторые дополнительные языковые конструкции, а также значительно увеличив поддержку на языке системы доказательства.[2] Lamport занимается созданием обновленного TLA+ ссылка, "TLA+ Гиперкнига ». Незавершенная работа имеется в наличии со своего официального сайта. Лампорт также создает Видеокурс TLA +, описанный в нем как «незавершенная работа, которая состоит из начала серии видеолекций, чтобы научить программистов и разработчиков программного обеспечения, как писать свои собственные спецификации TLA +».
Язык
TLA+ спецификации организованы в модули. Модули могут расширять (импортировать) другие модули для использования их функций. Хотя TLA+ стандарт указывается в наборных математических символах, существующих TLA+ инструменты использовать Латекс-подобные определения символов в ASCII. TLA+ использует несколько терминов, требующих определения:
- Состояние - присвоение значений переменным
- Поведение - последовательность состояний
- Шаг - пара последовательных состояний в поведении
- Шаг заикания - шаг, во время которого переменные не меняются
- Отношение следующего состояния - отношение, описывающее, как переменные могут изменяться на любом этапе
- Государственная функция - выражение, содержащее переменные и константы, которое не является отношением следующего состояния
- Предикат состояния - булевозначная функция состояния
- Инвариантный - предикат состояния истинен во всех достижимых состояниях
- Временная формула - выражение, содержащее утверждения во временной логике
Безопасность
TLA+ занимается определением набора всех правильных поведений системы. Например, однобитовые часы, бесконечно тикающие между 0 и 1, можно указать следующим образом:
VARIABLE clockInit == clock in {0, 1} Tick == IF clock = 0 THEN clock '= 1 ELSE clock' = 0Spec == Init / [] [Tick] _ <>
Отношение следующего состояния Поставить галочку наборы Часы' (значение Часы в следующем состоянии) до 1, если Часы равно 0, и 0, если Часы равно 1. Предикат состояния В этом верно, если значение Часы либо 0, либо 1. Спецификация - это временная формула, утверждающая, что все поведения однобитовых часов должны изначально удовлетворять В этом и все шаги совпадают Поставить галочку или запинающимся шагом. Два таких поведения:
0 -> 1 -> 0 -> 1 -> 0 -> ...1 -> 0 -> 1 -> 0 -> 1 -> ...
Свойства безопасности однобитовых часов - набора доступных состояний системы - адекватно описаны в спецификации.
Живучесть
Вышеупомянутая спецификация запрещает странные состояния для однобитовых часов, но не говорит, что часы когда-либо будут тикать. Например, допустимы следующие варианты поведения, связанные с постоянным заиканием:
0 -> 0 -> 0 -> 0 -> 0 -> ...1 -> 1 -> 1 -> 1 -> 1 -> ...
Часы, которые не тикают, бесполезны, поэтому следует запретить такое поведение. Одно из решений - отключить заикание, но TLA+ требует, чтобы заикание всегда было включено; шаг заикания представляет собой изменение некоторой части системы, не описанной в спецификации, и полезен для уточнение. Чтобы часы со временем тикали, слабый справедливость утверждается для Поставить галочку:
Spec == Init / [] [Tick] _ <> / WF_ <> (Tick)
Слабая справедливость по отношению к действию означает, что если это действие постоянно разрешено, в конечном итоге оно должно быть выполнено. Со слабой справедливостью Поставить галочку между отметками разрешено только конечное число шагов заикания. Это темпоральное логическое утверждение о Поставить галочку называется утверждением живучести. В общем, утверждение живучести должно быть закрытый машиной: он не должен ограничивать набор достижимых состояний, только набор возможных поведений.[18]
Большинство спецификаций не требуют утверждения свойств живучести. Свойства безопасности достаточны как для проверки модели, так и для руководства по внедрению системы.[19]
Операторы
TLA+ основан на ZF, поэтому операции с переменными включают манипулирование множеством. Язык включает набор членство, союз, пересечение, разница, powerset, и подмножество операторы. Логика первого порядка операторы, такие как ∨, ∧, ¬, ⇒, ↔, ≡ также включены, а также универсальный и экзистенциальный кванторы ∀ и ∃. Гильберта ε предоставляется как оператор CHOOSE, который однозначно выбирает произвольный элемент набора. Арифметические операторы над реалы, целые числа, и натуральные числа доступны из стандартных модулей.
Операторы временной логики встроены в TLA+. Использование темпоральных формул значить п всегда правда, и значить п в конце концов правда. Операторы объединены в значить п верно бесконечно часто, или иметь в виду в конце концов п всегда будет правдой. Другие временные операторы включают слабую и сильную справедливость. Слабая справедливость WFе(А) означает, что действие А включен непрерывно (т.е. без перерывов), в конце концов его нужно принять. Сильная справедливость SFе(А) означает, что действие А включен постоянно (неоднократно, с перерывами или без), в конечном итоге его необходимо принять.
Временная экзистенциальная и универсальная количественная оценка включены в TLA+, хотя и без поддержки со стороны инструментов.
Пользовательские операторы похожи на макросы. Операторы отличаются от функций тем, что их домен не обязательно должен быть набором: например, установить членство оператор имеет категория наборов как его домен, который не действительный набор в ZFC (поскольку его существование приводит к Парадокс Рассела). В TLA добавлены рекурсивные и анонимные пользовательские операторы+2.
Структуры данных
Базовая структура данных TLA+ это набор. Наборы либо перечисляются явно, либо создаются из других наборов с помощью операторов или с помощью {Икс в S: p}
куда п какое-то условие на Икс, или же {бывший в S}
куда е какая-то функция Икс. Уникальный пустой набор представлен как {}
.
Функции в TLA+ присвоить значение каждому элементу в своем домене, набору. [S -> T]
- множество всех функций с f [Икс] в Т, для каждого Икс в домен набор S. Например, TLA+ функция Двойной [x in Nat] == x * 2
является элементом множества [Нат -> Нат]
так Двойной in [Нат -> Нат]
истинное утверждение в TLA+. Функции также определяются с помощью [х в S | -> е]
для некоторого выражения е, или путем изменения существующей функции [f ИСКЛЮЧЕНИЕ! [v1] = v2]
.
Записи тип функции в TLA+. Запись [имя | -> "Джон", возраст | -> 35]
это запись с именем поля и возрастом, доступ к которой осуществляется с помощью r.name
и ярость
, и принадлежащий набору записей [имя: String, возраст: Nat]
.
Кортежи включены в TLA+. Они явно определены с помощью << e1, е2, е3>>
или построены с помощью операторов из стандартного модуля Sequences. Наборы кортежей определяются Декартово произведение; например, определяется набор всех пар натуральных чисел Nat X Nat
.
Стандартные модули
TLA+ имеет набор стандартных модулей, содержащих общие операторы. Распространяются вместе с синтаксическим анализатором. Средство проверки моделей TLC использует реализации Java для повышения производительности.
- FiniteSets: Модуль для работы с конечные множества. Обеспечивает IsFiniteSet (S) и Мощность (S) операторы.
- Последовательности: Определяет операторы на кортежи Такие как Лен (S), Голова (S), Хвост (S), Добавить (S, E), конкатенация, и фильтр.
- Сумки: Модуль для работы с мультимножества. Обеспечивает аналог операции с примитивным множеством и дублирование подсчета.
- Naturals: Определяет Натуральные числа наряду с неравенством и арифметическими операторами.
- Целые числа: Определяет Целые числа.
- Реалы: Определяет Действительные числа вместе с разделением и бесконечность.
- В реальном времени: Дает определения, полезные в система реального времени технические характеристики.
- TLC: Предоставляет служебные функции для проверенных моделью спецификаций, таких как ведение журнала и утверждения.
Стандартные модули импортируются с РАСШИРЕНИЯ
или же ПРИМЕР
заявления.
Инструменты
IDE
TLA+ Среда IDE при типичном использовании: обозреватель спецификаций слева, редактор в середине и ошибки анализа справа. | |
Оригинальный автор (ы) | Саймон Замбровски, Маркус Куппе, Дэниел Рикеттс |
---|---|
Разработчики) | Hewlett Packard, Microsoft |
изначальный выпуск | 4 февраля 2010 г. |
Стабильный выпуск | 1.7.0 / 25 апреля 2020 г. |
Предварительный выпуск | 1.7.1 / 1 мая 2020 г. |
Репозиторий | github |
Написано в | Ява |
Доступно в | английский |
Тип | Интегрированная среда развития |
Лицензия | Лицензия MIT |
Интернет сайт | исследование |
An интегрированная среда развития реализуется поверх Затмение. Он включает редактор с ошибкой и подсветка синтаксиса, плюс GUI интерфейс для нескольких других TLA+ инструменты:
- Синтаксический анализатор SANY, который анализирует и проверяет спецификацию на наличие синтаксических ошибок.
- В Латекс переводчик, чтобы произвести красиво напечатанный спецификации.
- Переводчик PlusCal.
- Средство проверки моделей TLC.
- Система доказательств TLAPS.
IDE распространяется в Панель инструментов TLA.
Проверка модели
TLC модель проверки строит конечное состояние модель TLA+ спецификации для проверки свойства инвариантности. TLC генерирует набор начальных состояний, удовлетворяющих спецификации, затем выполняет поиск в ширину по всем определенным переходам между состояниями. Выполнение прекращается, когда все переходы между состояниями приводят к состояниям, которые уже были обнаружены. Если TLC обнаруживает состояние, которое нарушает системный инвариант, он останавливается и обеспечивает путь трассировки состояния к состоянию нарушения. TLC предоставляет метод объявления симметрии модели для защиты от комбинаторный взрыв.[14] Это также распараллеливает этап исследования состояния и может выполняться в распределенном режиме для распределения рабочей нагрузки по большому количеству компьютеров.[20]
В качестве альтернативы исчерпывающему поиску в ширину TLC может использовать поиск в глубину или генерировать случайное поведение. TLC работает на подмножестве TLA+; модель должна быть конечной и перечислимой, а некоторые временные операторы не поддерживаются. В распределенном режиме TLC не может проверять свойства живучести, а также случайное поведение или поведение в глубину. TLC - это имеется в наличии как инструмент командной строки или в комплекте с инструментарием TLA.
Система доказательств
TLA+ Система доказательства или TLAPS, механически проверяет доказательства написаны в TLA+. Он был разработан в Microsoft Research-INRIA Объединенный центр доказательства правильности параллельных и распределенных алгоритмов. Язык доказательства разработан так, чтобы быть независимым от какого-либо конкретного средства доказательства теорем; Доказательства написаны в декларативном стиле и преобразованы в индивидуальные обязательства, которые отправляются внутренним доказывающим сторонам. Основными сторонними доказывающими устройствами являются Изабель и Зенон, с откатом на SMT решатели CVC3, Yices, и Z3. Доказательства TLAPS иерархически структурированы, что упрощает рефакторинг и делает возможной нелинейную разработку: работа может начинаться на более поздних этапах до того, как будут проверены все предыдущие этапы, а сложные этапы разбиты на более мелкие подэтапы. TLAPS хорошо работает с TLC, так как средство проверки моделей быстро находит мелкие ошибки до начала проверки. В свою очередь, TLAPS может подтвердить свойства системы, которые выходят за рамки возможностей проверки конечных моделей.[17]
TLAPS в настоящее время не поддерживает рассуждения с использованием реальных чисел или большинства временных операторов. Изабель и Зенон, как правило, не могут доказать обязательства арифметического доказательства, требующие использования решающих программ SMT.[21] TLAPS был использован для доказательства правильности Византийский Паксос, архитектура безопасности Memoir и компоненты Распределенная хеш-таблица кондитерских изделий.[17] Он распространяется отдельно от остальной части TLA.+ инструменты и бесплатное программное обеспечение, распространяемое под Лицензия BSD.[22] TLA+2 значительно расширена языковая поддержка конструкций доказательства.
Промышленное использование
В Microsoft, критическая ошибка была обнаружена в Xbox 360 модуль памяти в процессе написания спецификации в TLA+.[23] TLA+ был использован для написания формальных доказательств правильности для Византийский Паксос и компоненты Распределенная хеш-таблица кондитерских изделий.[17]
Веб-сервисы Amazon использовал TLA+ с 2011 года. TLA+ модель проверяет обнаруженные ошибки в DynamoDB, S3, EBS, и внутренний распределенный менеджер блокировок; некоторые ошибки требовали трассировки состояний из 35 шагов. Проверка модели также использовалась для проверки агрессивных оптимизаций. Кроме того, TLA+ Было обнаружено, что спецификации имеют ценность как документация и вспомогательные средства проектирования.[4][24]
Microsoft Azure использовал TLA+ разрабатывать Cosmos DB, глобально распределенная база данных с пятью различными модели согласованности.[25][26]
Примеры
--------------------------- МОДУЛЬ KeyValueStore --------------------- ------КОНСТАНТЫ Ключ, \* В набор из все ключи. Вал, \* В набор из все значения. TxId \* В набор из все сделка ID.ПЕРЕМЕННЫЕ хранить, \* А данные хранить отображение ключи к значения. tx, \* В набор из открыто снимок сделки. snapshotStore, \* Снимки из то хранить за каждый сделка. написано, \* А бревно из пишет выполнила в каждый сделка. пропущенный \* В набор из пишет невидимый к каждый сделка.----------------------------------------------------------------------------NoVal == \* выбирать что нибудь к представлять то отсутствие из а ценить. ВЫБЕРИТЕ v : v \не в ВалМагазин == \* В набор из все ключ-ценить магазины. [Ключ -> Вал \чашка {NoVal}]В этом == \* В исходный предикат. /\ хранить = [k \в Ключ |-> NoVal] \* Все хранить значения находятся первоначально NoVal. /\ tx = {} \* В набор из открыто сделки является первоначально пустой. /\ snapshotStore = \* Все snapshotStore значения находятся первоначально NoVal. [т \в TxId |-> [k \в Ключ |-> NoVal]] /\ написано = [т \в TxId |-> {}] \* Все записывать журналы находятся первоначально пустой. /\ пропущенный = [т \в TxId |-> {}] \* Все пропущенный пишет находятся первоначально пустой. ТипИнвариантный == \* В тип инвариантный. /\ хранить \в Магазин /\ tx \подгруппа TxId /\ snapshotStore \в [TxId -> Магазин] /\ написано \в [TxId -> ПОДМНОЖЕСТВО Ключ] /\ пропущенный \в [TxId -> ПОДМНОЖЕСТВО Ключ] TxLifecycle == /\ \А т \в tx : \* Если хранить != снимок & мы нет написано Это, мы должен имеют пропущенный а записывать. \А k \в Ключ : (хранить[k] /= snapshotStore[т][k] /\ k \не в написано[т]) => k \в пропущенный[т] /\ \А т \в TxId \ tx : \* Проверяет сделки находятся очищенный вверх после утилизация. /\ \А k \в Ключ : snapshotStore[т][k] = NoVal /\ написано[т] = {} /\ пропущенный[т] = {}OpenTx(т) == \* Открыть а новый сделка. /\ т \не в tx /\ tx ' = tx \чашка {т} /\ snapshotStore ' = [snapshotStore КРОМЕ ![т] = хранить] /\ НЕИЗМЕНЕННЫЙ <<написано, пропущенный, хранить>>Добавлять(т, k, v) == \* С помощью сделка т, Добавить ценить v к то хранить под ключ k. /\ т \в tx /\ snapshotStore[т][k] = NoVal /\ snapshotStore ' = [snapshotStore КРОМЕ ![т][k] = v] /\ написано ' = [написано КРОМЕ ![т] = @ \чашка {k}] /\ НЕИЗМЕНЕННЫЙ <<tx, пропущенный, хранить>> Обновлять(т, k, v) == \* С помощью сделка т, Обновить то ценить связанный с ключ k к v. /\ т \в tx /\ snapshotStore[т][k] \не в {NoVal, v} /\ snapshotStore ' = [snapshotStore КРОМЕ ![т][k] = v] /\ написано ' = [написано КРОМЕ ![т] = @ \чашка {k}] /\ НЕИЗМЕНЕННЫЙ <<tx, пропущенный, хранить>> Удалять(т, k) == \* С помощью сделка т, удалять ключ k из то хранить. /\ т \в tx /\ snapshotStore[т][k] /= NoVal /\ snapshotStore ' = [snapshotStore КРОМЕ ![т][k] = NoVal] /\ написано ' = [написано КРОМЕ ![т] = @ \чашка {k}] /\ НЕИЗМЕНЕННЫЙ <<tx, пропущенный, хранить>> RollbackTx(т) == \* Закрывать то сделка без слияние пишет в хранить. /\ т \в tx /\ tx ' = tx \ {т} /\ snapshotStore ' = [snapshotStore КРОМЕ ![т] = [k \в Ключ |-> NoVal]] /\ написано ' = [написано КРОМЕ ![т] = {}] /\ пропущенный' = [пропущенный КРОМЕ ![т] = {}] /\ НЕИЗМЕНЕННЫЙ хранитьCloseTx(т) == \* Закрывать сделка т, слияние пишет в хранить. /\ т \в tx /\ пропущенный[т] \колпачок написано[т] = {} \* Обнаружение из записывать-записывать конфликты. /\ хранить' = \* Объединить snapshotStore пишет в хранить. [k \в Ключ |-> ЕСЛИ k \в написано[т] ТОГДА snapshotStore[т][k] ЕЩЕ хранить[k]] /\ tx ' = tx \ {т} /\ пропущенный' = \* Обновлять то пропущенный пишет за Другой открыто сделки. [otherTx \в TxId |-> ЕСЛИ otherTx \в tx ' ТОГДА пропущенный[otherTx] \чашка написано[т] ЕЩЕ {}] /\ snapshotStore ' = [snapshotStore КРОМЕ ![т] = [k \в Ключ |-> NoVal]] /\ написано ' = [написано КРОМЕ ![т] = {}]Следующий == \* В следующий-государственный связь. \/ \E т \в TxId : OpenTx(т) \/ \E т \в tx : \E k \в Ключ : \E v \в Вал : Добавлять(т, k, v) \/ \E т \в tx : \E k \в Ключ : \E v \в Вал : Обновлять(т, k, v) \/ \E т \в tx : \E k \в Ключ : Удалять(т, k) \/ \E т \в tx : RollbackTx(т) \/ \E т \в tx : CloseTx(т) Спецификация == \* Инициализировать государственный с В этом и переход с Следующий. В этом /\ [][Следующий]_<<хранить, tx, snapshotStore, написано, пропущенный>>----------------------------------------------------------------------------ТЕОРЕМА Спецификация => [](ТипИнвариантный /\ TxLifecycle)=============================================================================
------------------------------ МОДУЛЬ Межсетевой экран ------------------ ------------РАСШИРЕНИЯ Целые числаКОНСТАНТЫ Адрес, \* В набор из все адреса Порт, \* В набор из все порты Протокол \* В набор из все протоколыAddressRange == \* В набор из все адрес диапазоны {р \в Адрес \Икс Адрес : р[1] <= р[2]}InAddressRange[р \в AddressRange, а \в Адрес] == /\ р[1] <= а /\ а <= р[2]PortRange == \* В набор из все порт диапазоны {р \в Порт \Икс Порт : р[1] <= р[2]}InPortRange[р \в PortRange, п \в Порт] == /\ р[1] <= п /\ п <= р[2]Пакет == \* В набор из все пакеты [адрес источника : Адрес, sourcePort : Порт, destAddress : Адрес, destPort : Порт, протокол : Протокол]Брандмауэр == \* В набор из все брандмауэры [Пакет -> BOOLEAN]Правило == \* В набор из все брандмауэр правила [remoteAddress : AddressRange, удаленный порт : PortRange, localAddress : AddressRange, localPort : PortRange, протокол : ПОДМНОЖЕСТВО Протокол, позволять : BOOLEAN]Набор правил == \* В набор из все брандмауэр наборы правил ПОДМНОЖЕСТВО ПравилоДопустимый[rset \в Набор правил, п \в Пакет] == \* Ли то набор правил позволяет то пакет ПОЗВОЛЯТЬ совпадения == {правило \в rset : /\ InAddressRange[правило.remoteAddress, п.адрес источника] /\ InPortRange[правило.удаленный порт, п.sourcePort] /\ InAddressRange[правило.localAddress, п.destAddress] /\ InPortRange[правило.localPort, п.destPort] /\ п.протокол \в правило.протокол} В /\ совпадения /= {} /\ \А правило \в совпадения : правило.позволять=============================================================================
------------------------------ МОДУЛЬ Лифт ------------------ ------------(***************************************************************************)(* Этот спецификация описывает а просто мульти-машина лифт система. В действия в *)(* это спецификация находятся неудивительно и общий к все такой системы Кроме за *)(* ОтправкаЛифт, который содержит то логика к определять который лифт *)(* должен к служба который вызов. В алгоритм использовал является очень просто и делает *)(* нет оптимизировать за Глобальный пропускная способность или же средний ждать время. В *)(* TemporalInvariant определение обеспечивает это Технические характеристики обеспечивает *)(* возможности ожидал из любой лифт система, такой в качестве люди в итоге *)(* достижение их пункт назначения этаж. *)(***************************************************************************)РАСШИРЕНИЯ Целые числаКОНСТАНТЫ Человек, \* В набор из все люди с помощью то лифт система Лифт, \* В набор из все лифты FloorCount \* В номер из этажи обслуживается к то лифт системаПЕРЕМЕННЫЕ PersonState, \* В государственный из каждый человек АктивныйЛифтЗвонки, \* В набор из все активный лифт звонки Лифт \* В государственный из каждый лифтВарс == \* Кортеж из все Технические характеристики переменные <<PersonState, АктивныйЛифтЗвонки, Лифт>>Этаж == \* В набор из все этажи 1 .. FloorCountНаправление == \* Направления имеется в наличии к это лифт система {"Вверх", "Вниз"}ЛифтЗвонок == \* В набор из все лифт звонки [этаж : Этаж, направление : Направление]ЛифтНаправлениеСостояние == \* Лифт движение государственный; Это является либо движущийся в а направление или же стационарный Направление \чашка {«Стационарный»}GetDistance[f1, f2 \в Этаж] == \* В расстояние между два этажи ЕСЛИ f1 > f2 ТОГДА f1 - f2 ЕЩЕ f2 - f1 Получить направление[Текущий, пункт назначения \в Этаж] == \* Направление из путешествовать требуется к двигаться между Текущий и пункт назначения этажи ЕСЛИ пункт назначения > Текущий ТОГДА "Вверх" ЕЩЕ "Вниз"CanServiceCall[е \в Лифт, c \в ЛифтЗвонок] == \* Ли лифт является в позиция к немедленно служба вызов ПОЗВОЛЯТЬ имущество == Лифт[е] В /\ c.этаж = имущество.этаж /\ c.направление = имущество.направлениеЛюди ждут[ж \в Этаж, d \в Направление] == \* В набор из все люди ожидающий на ан лифт вызов {п \в Человек : /\ PersonState[п].место расположения = ж /\ PersonState[п].ожидающий /\ Получить направление[PersonState[п].место расположения, PersonState[п].пункт назначения] = d}ТипИнвариантный == \* Заявления о то переменные который мы ожидать к держать в каждый система государственный /\ PersonState \в [Человек -> [место расположения : Этаж \чашка Лифт, пункт назначения : Этаж, ожидающий : BOOLEAN]] /\ АктивныйЛифтЗвонки \подгруппа ЛифтЗвонок /\ Лифт \в [Лифт -> [этаж : Этаж, направление : ЛифтНаправлениеСостояние, двери открыты : BOOLEAN, кнопки : ПОДМНОЖЕСТВО Этаж]]БезопасностьИнвариант == \* Немного более всесторонний чеки вне то тип инвариантный /\ \А е \в Лифт : \* An лифт имеет а этаж кнопка прижатый Только если а человек в который лифт является собирается к который этаж /\ \А ж \в Лифт[е].кнопки : /\ \E п \в Человек : /\ PersonState[п].место расположения = е /\ PersonState[п].пункт назначения = ж /\ \А п \в Человек : \* А человек является в ан лифт Только если то лифт является движущийся к их пункт назначения этаж /\ \А е \в Лифт : /\ (PersonState[п].место расположения = е /\ Лифт[е].этаж /= PersonState[п].пункт назначения) => /\ Лифт[е].направление = Получить направление[Лифт[е].этаж, PersonState[п].пункт назначения] /\ \А c \в АктивныйЛифтЗвонки : Люди ждут[c.этаж, c.направление] /= {} \* Нет призрак звонкиTemporalInvariant == \* Ожидания о лифт система возможности /\ \А c \в ЛифтЗвонок : \* Каждый вызов является в итоге обслуживается к ан лифт /\ c \в АктивныйЛифтЗвонки ~> \E е \в Лифт : CanServiceCall[е, c] /\ \А п \в Человек : \* Если а человек ждет за их лифт, они будут в итоге прибыть в их этаж /\ PersonState[п].ожидающий ~> PersonState[п].место расположения = PersonState[п].пункт назначенияPickNewDestination(п) == \* Человек решает Oни необходимость к идти к а разные этаж ПОЗВОЛЯТЬ pState == PersonState[п] В /\ ~pState.ожидающий /\ pState.место расположения \в Этаж /\ \E ж \в Этаж : /\ ж /= pState.место расположения /\ PersonState ' = [PersonState КРОМЕ ![п] = [@ КРОМЕ !.пункт назначения = ж]] /\ НЕИЗМЕНЕННЫЙ <<АктивныйЛифтЗвонки, Лифт>>Звонок(п) == \* Человек звонки то лифт к идти в а определенный направление из их этаж ПОЗВОЛЯТЬ pState == PersonState[п] В ПОЗВОЛЯТЬ вызов == [этаж |-> pState.место расположения, направление |-> Получить направление[pState.место расположения, pState.пункт назначения]] В /\ ~pState.ожидающий /\ pState.место расположения /= pState.пункт назначения /\ ActiveElevatorCalls ' = ЕСЛИ \E е \в Лифт : /\ CanServiceCall[е, вызов] /\ Лифт[е].двери открыты ТОГДА АктивныйЛифтЗвонки ЕЩЕ АктивныйЛифтЗвонки \чашка {вызов} /\ PersonState ' = [PersonState КРОМЕ ![п] = [@ КРОМЕ !.ожидающий = ИСТИННЫЙ]] /\ НЕИЗМЕНЕННЫЙ <<Лифт>>ОткрытьЛифтДвери(е) == \* Открыть то лифт двери если там является а вызов на это этаж или же то кнопка за это этаж был прижатый. ПОЗВОЛЯТЬ имущество == Лифт[е] В /\ ~имущество.двери открыты /\ \/ \E вызов \в АктивныйЛифтЗвонки : CanServiceCall[е, вызов] \/ имущество.этаж \в имущество.кнопки /\ ElevatorState ' = [Лифт КРОМЕ ![е] = [@ КРОМЕ !.двери открыты = ИСТИННЫЙ, !.кнопки = @ \ {имущество.этаж}]] /\ ActiveElevatorCalls ' = АктивныйЛифтЗвонки \ {[этаж |-> имущество.этаж, направление |-> имущество.направление]} /\ НЕИЗМЕНЕННЫЙ <<PersonState>> ВойтиЛифт(е) == \* Все люди на это этаж ВОЗ находятся ожидающий за то лифт и путешествие то одно и тоже направление войти то лифт. ПОЗВОЛЯТЬ имущество == Лифт[е] В ПОЗВОЛЯТЬ getOn == Люди ждут[имущество.этаж, имущество.направление] В ПОЗВОЛЯТЬ направления == {PersonState[п].пункт назначения : п \в getOn} В /\ имущество.двери открыты /\ имущество.направление /= «Стационарный» /\ getOn /= {} /\ PersonState ' = [п \в Человек |-> ЕСЛИ п \в getOn ТОГДА [PersonState[п] КРОМЕ !.место расположения = е] ЕЩЕ PersonState[п]] /\ ElevatorState ' = [Лифт КРОМЕ ![е] = [@ КРОМЕ !.кнопки = @ \чашка направления]] /\ НЕИЗМЕНЕННЫЙ <<АктивныйЛифтЗвонки>>ВыходЛифт(е) == \* Все люди чей пункт назначения является это этаж выход то лифт. ПОЗВОЛЯТЬ имущество == Лифт[е] В ПОЗВОЛЯТЬ getOff == {п \в Человек : PersonState[п].место расположения = е /\ PersonState[п].пункт назначения = имущество.этаж} В /\ имущество.двери открыты /\ getOff /= {} /\ PersonState ' = [п \в Человек |-> ЕСЛИ п \в getOff ТОГДА [PersonState[п] КРОМЕ !.место расположения = имущество.этаж, !.ожидающий = ЛОЖНЫЙ] ЕЩЕ PersonState[п]] /\ НЕИЗМЕНЕННЫЙ <<АктивныйЛифтЗвонки, Лифт>>ЗакрытьЛифтДвери(е) == \* Закрывать то лифт двери однажды все люди имеют вошел и вышел то лифт на это этаж. ПОЗВОЛЯТЬ имущество == Лифт[е] В /\ ~ВКЛЮЧЕНО ВойтиЛифт(е) /\ ~ВКЛЮЧЕНО ВыходЛифт(е) /\ имущество.двери открыты /\ ElevatorState ' = [Лифт КРОМЕ ![е] = [@ КРОМЕ !.двери открыты = ЛОЖНЫЙ]] /\ НЕИЗМЕНЕННЫЙ <<PersonState, АктивныйЛифтЗвонки>>MoveElevator(е) == \* Двигаться то лифт к то следующий этаж пока не мы имеют к открыто то двери здесь. ПОЗВОЛЯТЬ имущество == Лифт[е] В ПОЗВОЛЯТЬ nextFloor == ЕСЛИ имущество.направление = "Вверх" ТОГДА имущество.этаж + 1 ЕЩЕ имущество.этаж - 1 В /\ имущество.направление /= «Стационарный» /\ ~имущество.двери открыты /\ имущество.этаж \не в имущество.кнопки /\ \А вызов \в АктивныйЛифтЗвонки : \* Может двигаться Только если Другой лифт обслуживание вызов /\ CanServiceCall[е, вызов] => /\ \E e2 \в Лифт : /\ е /= e2 /\ CanServiceCall[e2, вызов] /\ nextFloor \в Этаж /\ ElevatorState ' = [Лифт КРОМЕ ![е] = [@ КРОМЕ !.этаж = nextFloor]] /\ НЕИЗМЕНЕННЫЙ <<PersonState, АктивныйЛифтЗвонки>>StopElevator(е) == \* Остановки то лифт если это взолнованный в качестве далеко в качестве Это может в один направление ПОЗВОЛЯТЬ имущество == Лифт[е] В ПОЗВОЛЯТЬ nextFloor == ЕСЛИ имущество.направление = "Вверх" ТОГДА имущество.этаж + 1 ЕЩЕ имущество.этаж - 1 В /\ ~ВКЛЮЧЕНО ОткрытьЛифтДвери(е) /\ ~имущество.двери открыты /\ nextFloor \не в Этаж /\ ElevatorState ' = [Лифт КРОМЕ ![е] = [@ КРОМЕ !.направление = «Стационарный»]] /\ НЕИЗМЕНЕННЫЙ <<PersonState, АктивныйЛифтЗвонки>>(***************************************************************************)(* Этот действие выбирает ан лифт к служба то вызов. В просто *)(* алгоритм выбирает то ближайший лифт который является либо стационарный или же *)(* уже движущийся к то вызов этаж в то одно и тоже направление в качестве то вызов. *)(* В система держит нет записывать из назначение ан лифт к служба а вызов. *)(* Это является возможный нет лифт является способный к служба а вызов, но мы находятся *)(* гарантированный ан лифт буду в итоге становиться имеется в наличии. *)(***************************************************************************)ОтправкаЛифт(c) == ПОЗВОЛЯТЬ стационарный == {е \в Лифт : Лифт[е].направление = «Стационарный»} В ПОЗВОЛЯТЬ приближающийся == {е \в Лифт : /\ Лифт[е].направление = c.направление /\ \/ Лифт[е].этаж = c.этаж \/ Получить направление[Лифт[е].этаж, c.этаж] = c.направление } В /\ c \в АктивныйЛифтЗвонки /\ стационарный \чашка приближающийся /= {} /\ ElevatorState ' = ПОЗВОЛЯТЬ ближайший == ВЫБЕРИТЕ е \в стационарный \чашка приближающийся : /\ \А e2 \в стационарный \чашка приближающийся : /\ GetDistance[Лифт[е].этаж, c.этаж] <= GetDistance[Лифт[e2].этаж, c.этаж] В ЕСЛИ ближайший \в стационарный ТОГДА [Лифт КРОМЕ ![ближайший] = [@ КРОМЕ !.этаж = c.этаж, !.направление = c.направление]] ЕЩЕ Лифт /\ НЕИЗМЕНЕННЫЙ <<PersonState, АктивныйЛифтЗвонки>>В этом == \* Инициализирует люди и лифты к произвольный этажи /\ PersonState \в [Человек -> [место расположения : Этаж, пункт назначения : Этаж, ожидающий : {ЛОЖНЫЙ}]] /\ АктивныйЛифтЗвонки = {} /\ Лифт \в [Лифт -> [этаж : Этаж, направление : {«Стационарный»}, двери открыты : {ЛОЖНЫЙ}, кнопки : {{}}]]Следующий == \* В следующий-государственный связь \/ \E п \в Человек : PickNewDestination(п) \/ \E п \в Человек : Звонок(п) \/ \E е \в Лифт : ОткрытьЛифтДвери(е) \/ \E е \в Лифт : ВойтиЛифт(е) \/ \E е \в Лифт : ВыходЛифт(е) \/ \E е \в Лифт : ЗакрытьЛифтДвери(е) \/ \E е \в Лифт : MoveElevator(е) \/ \E е \в Лифт : StopElevator(е) \/ \E c \в ЛифтЗвонок : ОтправкаЛифт(c)Временные предположения == \* Предположения о как лифты и люди буду вести себя /\ \А п \в Человек : WF_Vars(Звонок(п)) /\ \А е \в Лифт : WF_Vars(ОткрытьЛифтДвери(е)) /\ \А е \в Лифт : WF_Vars(ВойтиЛифт(е)) /\ \А е \в Лифт : WF_Vars(ВыходЛифт(е)) /\ \А е \в Лифт : SF_Vars(ЗакрытьЛифтДвери(е)) /\ \А е \в Лифт : SF_Vars(MoveElevator(е)) /\ \А е \в Лифт : WF_Vars(StopElevator(е)) /\ \А c \в ЛифтЗвонок : SF_Vars(ОтправкаЛифт(c))Спецификация == \* Инициализировать государственный с В этом и переход с Следующий, предмет к Временные предположения /\ В этом /\ [][Следующий]_Vars /\ Временные предположенияТЕОРЕМА Спецификация => [](ТипИнвариантный /\ БезопасностьИнвариант /\ TemporalInvariant)=============================================================================
Смотрите также
- Сплав (язык спецификации)
- B-метод
- Логика дерева вычислений
- PlusCal
- Временная логика
- Временная логика действий
- Обозначение Z
Рекомендации
- ^ а б Лэмпорт, Лесли (Январь 2000 г.). Указание параллельных систем с помощью TLA+ (PDF). Научная серия НАТО, III: Компьютерные и системные науки. 173. IOS Press, Амстердам. С. 183–247. ISBN 978-90-5199-459-9. Получено 22 мая 2015.
- ^ а б Лэмпорт, Лесли (15 января 2014 г.). «TLA+2: Предварительное руководство " (PDF). Получено 2 мая 2015.
- ^ «Tlaplus Tools - Лицензия». CodePlex. Microsoft, Compaq. 8 апреля 2013 г.. Получено 10 мая 2015.https://tlaplus.codeplex.com/license
- ^ а б Ньюкомб, Крис; Рат, Тим; Чжан, Фань; Мунтяну, Богдан; Брукер, Марк; Дорогой, Майкл (29 сентября 2014 г.). «Использование формальных методов в Amazon Web Services» (PDF). Amazon. Получено 8 мая 2015.
- ^ Лэмпорт, Лесли (25 января 2013 г.). «Почему мы должны создавать программное обеспечение, как мы строим дома». Проводной. Проводной. Получено 7 мая 2015.
- ^ Лэмпорт, Лесли (18 июня 2002 г.). «7.1 Зачем указывать». Определение систем: TLA+ Язык и инструменты для инженеров по аппаратному и программному обеспечению. Эддисон-Уэсли. п. 75. ISBN 978-0-321-14306-8.
Необходимость точного описания дизайна часто выявляет проблемы - тонкие взаимодействия и «угловые случаи», которые легко упустить из виду.
- ^ Лэмпорт, Лесли (2012). «Как написать доказательство 21 века» (PDF). Журнал теории фиксированной точки и приложений. 11: 43–63. Дои:10.1007 / s11784-012-0071-6. ISSN 1661-7738. Получено 23 мая 2015.
- ^ Эрстрём, Питер; Хасл, Пер (1995). «3.7 Темпоральная логика и информатика». Временная логика: от древних идей до искусственного интеллекта. Исследования в области лингвистики и философии. 57. Springer Нидерланды. С. 344–365. Дои:10.1007/978-0-585-37463-5. ISBN 978-0-7923-3586-3.
- ^ Лэмпорт, Лесли. "Сочинения Лесли Лэмпорта: доказательство правильности многопроцессорных программ". Получено 22 мая 2015.
- ^ Лэмпорт, Лесли. "Сочинения Лесли Лэмпорта: Сборка мусора на лету: упражнение в сотрудничестве". Получено 22 мая 2015.
- ^ Лэмпорт, Лесли. "Сочинения Лесли Лэмпорта:" Когда-нибудь "иногда" не никогда "'". Получено 22 мая 2015.
- ^ Лэмпорт, Лесли. "Сочинения Лесли Лэмпорта: определение модулей параллельного программирования". Получено 22 мая 2015.
- ^ Лэмпорт, Лесли. "Сочинения Лесли Лэмпорта: временная логика действий". Получено 22 мая 2015.
- ^ а б Юй Юань; Манолиос, Панайотис; Лэмпорт, Лесли (1999). Проверка модели TLA+ технические характеристики (PDF). Правильный дизайн оборудования и методы проверки. Конспект лекций по информатике. 1703. Springer-Verlag. С. 54–66. Дои:10.1007/3-540-48153-2_6. ISBN 978-3-540-66559-5. Получено 14 мая 2015.
- ^ Лэмпорт, Лесли (18 июня 2002 г.). Определение систем: TLA+ Язык и инструменты для инженеров по аппаратному и программному обеспечению. Эддисон-Уэсли. ISBN 978-0-321-14306-8.
- ^ Лэмпорт, Лесли (2 января 2009 г.). Язык алгоритмов PlusCal (PDF). Конспект лекций по информатике. 5684. Springer Berlin Heidelberg. С. 36–60. Дои:10.1007/978-3-642-03466-4_2. ISBN 978-3-642-03465-7. Получено 10 мая 2015.
- ^ а б c d Кузино, Дени; Долигез, Дэмиен; Лэмпорт, Лесли; Мерц, Стефан; Рикеттс, Дэниел; Ванцетто, Эрнан (1 января 2012 г.). TLA+ Доказательства (PDF). FM 2012: Формальные методы. Конспект лекций по информатике. 7436. Springer Berlin Heidelberg. С. 147–154. Дои:10.1007/978-3-642-32759-9_14. ISBN 978-3-642-32758-2. Получено 14 мая 2015.
- ^ Лэмпорт, Лесли (18 июня 2002 г.). «8.9.2 Закрытие машины». Определение систем: TLA+ Язык и инструменты для инженеров по аппаратному и программному обеспечению. Эддисон-Уэсли. п. 112. ISBN 978-0-321-14306-8.
Мы редко хотим написать спецификацию, которая не закрыта машиной. Если мы и пишем, то обычно по ошибке.
- ^ Лэмпорт, Лесли (18 июня 2002 г.). «8.9.6. Временная логика вызывает недоумение». Определение систем: TLA+ Язык и инструменты для инженеров по аппаратному и программному обеспечению. Эддисон-Уэсли. п. 116. ISBN 978-0-321-14306-8.
Действительно, [большинство инженеров] вполне могут уживаться со спецификациями формы (8.38), которые выражают только свойства безопасности и не скрывают никаких переменных.
- ^ Маркус А. Куппе (3 июня 2014 г.). Распределенный TLC (Запись технического разговора). TLA+ Общественное мероприятие 2014 г., Тулуза, Франция.CS1 maint: location (связь)
- ^ «Неподдерживаемые функции TLAPS». TLA+ Система доказательств. Microsoft Research - INRIA Объединенный центр. Получено 14 мая 2015.
- ^ Система проверки TLA +
- ^ Лесли Лэмпорт (3 апреля 2014 г.). Мышление для программистов (21:46) (Запись технического разговора). Сан-Франциско: Microsoft. Получено 14 мая 2015.
- ^ Крис, Ньюкомб (2014). Почему Amazon выбрала TLA+. Конспект лекций по информатике. 8477. Springer Berlin Heidelberg. С. 25–39. Дои:10.1007/978-3-662-43652-3_3. ISBN 978-3-662-43651-6.
- ^ Лардинуа, Фредерик (10 мая 2017 г.). «С Cosmos DB Microsoft хочет создать одну базу данных, чтобы управлять ими всеми». TechCrunch. Получено 10 мая 2017.
- ^ Лесли Лэмпорт (10 мая 2017 г.). Основы Azure Cosmos DB с доктором Лесли Лэмпорт (Запись интервью). Microsoft Azure. Получено 10 мая 2017.
внешняя ссылка
- Домашняя страница TLA, Веб-страница Лесли Лэмпорта со ссылкой на TLA+ инструменты и ресурсы
- TLA+ Гиперкнига, TLA+ учебник Лесли Лэмпорта
- Как Amazon Web Services использует формальные методы, статья в апрельском номере 2015 г. Коммуникации ACM
- Мышление для программистов, выступление Лесли Лэмпорта на Сборка 2014
- Мыслить выше кода, выступление Лесли Лэмпорта на 2014 Microsoft Research саммит факультетов
- Кто строит небоскреб без чертежей?, выступление Лесли Лэмпорта на Реагировать Сан-Франциско 2014
- Программирование должно быть больше, чем кодирование, разговор 2015 г. Стэнфорд Лесли Лэмпорт
- Евклид пишет алгоритм: сказка, TLA+ введение Лесли Лэмпорта включено в фестивальный сбор за Манфред Брой
- TLA+ Группа Google