Формальная спецификация - Formal specification

В Информатика, формальные спецификации представляют собой математически обоснованные методы, цель которых - помочь при реализации систем и программного обеспечения. Они используются для описания системы, анализа ее поведения и помощи в ее проектировании путем проверки ключевых свойств, представляющих интерес, с помощью строгих и эффективных инструментов рассуждения.[1][2] Эти спецификации формальный в том смысле, что у них есть синтаксис, их семантика укладывается в один домен, и они могут использоваться для вывода полезной информации.[3]

Мотивация

С каждым прошедшим десятилетием компьютерные системы становились все более мощными и, как следствие, оказывали большее влияние на общество. Из-за этого необходимы более совершенные методы для помощи в разработке и внедрении надежного программного обеспечения. Установленные инженерные дисциплины используют математический анализ как основу для создания и проверки дизайна продукта. Формальные спецификации - один из способов достижения этой надежности при разработке программного обеспечения, как это было предсказано ранее. Другие методы, такие как тестирование чаще используются для повышения качества кода.[1]

Использует

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

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

Хорошая спецификация должна иметь некоторые из следующих атрибутов: адекватная, внутренне непротиворечивая, однозначная, полная, удовлетворяющая, минимальная.[3]

Хорошая спецификация будет иметь:[3]

  • Конструктивность, управляемость и эволюционируемость
  • Удобство использования
  • Коммуникабельность
  • Мощный и эффективный анализ

Одна из основных причин интереса к формальным спецификациям заключается в том, что они предоставляют возможность проводить проверки программных реализаций.[2] Эти доказательства могут использоваться для проверки спецификации, проверки правильности проектирования или подтверждения того, что программа удовлетворяет спецификации.[2]

Ограничения

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

Формальные методы разработки программного обеспечения не получили широкого распространения в промышленности. Большинство компаний не считают рентабельным применять их в своих процессах разработки программного обеспечения.[4] Это может быть по разным причинам, некоторые из которых:

  • Время
    • Высокая начальная стоимость запуска при низкой измеримой прибыли
  • Гибкость
    • Многие софтверные компании используют гибкие методологии которые сосредоточены на гибкости. Формальная спецификация всей системы заранее часто воспринимается как противоположность гибкости. Тем не менее, есть некоторые исследования преимуществ использования формальных спецификаций при «гибкой» разработке.[5]
  • Сложность
    • Они требуют высокого уровня математических знаний и аналитических навыков, чтобы понимать и эффективно применять их.[5]
    • Решением этого может быть разработка инструментов и моделей, которые позволяют реализовать эти методы, но скрывают лежащую в основе математику.[2][5]
  • Ограниченный объем[3]
    • Они не охватывают свойства, представляющие интерес для всех заинтересованные стороны в проекте[3]
    • Они плохо справляются с указанием пользовательских интерфейсов и взаимодействия с пользователем.[4]
  • Не рентабельно
    • Это не совсем так, поскольку они ограничивают их использование только основными частями критических систем, которые они доказали как рентабельные.[4]

Прочие ограничения:[3]

  • Изоляция
  • Онтологии низкого уровня
  • Плохое руководство
  • Бедные разделение проблем
  • Плохая обратная связь с инструментом

Парадигмы

Формальные методы спецификации существовали в различных областях и в различных масштабах в течение довольно долгого времени.[6] Реализации формальных спецификаций будут различаться в зависимости от того, какую систему они пытаются смоделировать, как они применяются и на каком этапе жизненного цикла программного обеспечения они были введены.[2] Эти типы моделей можно разделить на следующие парадигмы спецификации:

  • Спецификация на основе истории[3]
    • поведение на основе системной истории
    • утверждения интерпретируются с течением времени
  • Спецификация на основе состояний[3]
    • поведение на основе состояний системы
    • серия последовательных шагов (например, финансовая транзакция)
    • языки, такие как Z, VDM или же B полагаться на эту парадигму[3]
  • Спецификация на основе переходов[3]
    • поведение на основе переходов из состояния в состояние системы
    • лучше всего использовать с реактивной системой
    • языки, такие как диаграммы состояний, PROMELA, STeP-SPL, RSML или SCR, полагаются на эту парадигму[3]
  • Функциональная спецификация[3]
    • определить систему как структуру математических функций
    • OBJ, ASL, PLUSS, LARCH, HOL или PVS полагаются на эту парадигму[3]
  • Операционная спецификация[3]
    • ранние языки, такие как Пейсли, GIST, сети Петри или алгебры процессов опираются на эту парадигму[3]

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

Программные инструменты

В Обозначение Z является примером ведущего официального язык спецификации. Другие включают язык спецификации (VDM-SL) Венский метод развития и Обозначение абстрактной машины (AMN) B-метод. в Веб-сервисы области, формальная спецификация часто используется для описания нефункциональных свойств[7] (Веб-сервисы Качество обслуживания ).

Вот некоторые инструменты:[4]

Примеры

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

Смотрите также

Рекомендации

  1. ^ а б Hierons, R.M .; Богданов, К .; Боуэн, Дж. П.; Cleaveland, R .; Деррик, Дж .; Дик, Дж .; Георге, М .; Харман, М.; Капур, К .; Krause, P .; Lüttgen, G .; Simons, A.JH .; Вилкомир, С.А.; Woodward, M. R .; Зедан, Х. (2009). «Использование формальных спецификаций для поддержки тестирования». Опросы ACM Computing. 41 (2): 1. CiteSeerX  10.1.1.144.3320. Дои:10.1145/1459352.1459354.
  2. ^ а б c d е Годель, М.-К. (1994). «Методы формальной спецификации». Материалы 16-й Международной конференции по программной инженерии. С. 223–227. Дои:10.1109 / ICSE.1994.296781. ISBN  978-0-8186-5855-6.
  3. ^ а б c d е ж грамм час я j k л м п о Ламсверде, А. В. (2000). «Формальная спецификация». Материалы конференции о будущем программной инженерии - ICSE '00. С. 147–159. Дои:10.1145/336512.336546. ISBN  978-1581132533.
  4. ^ а б c d Соммервилл, Ян (2009). «Формальная спецификация» (PDF). Программная инженерия. Получено 3 февраля 2013.
  5. ^ а б c Нумменмаа, Тимо; Тиэнсуу, Алекси; Берки, Элени; Микконен, Томми; Куиттинен, Юсси; Култима, Аннакайса (4 августа 2011 г.). «Поддержка гибкой разработки путем облегчения естественного взаимодействия пользователя с исполняемыми формальными спецификациями». Примечания по разработке программного обеспечения ACM SIGSOFT. 36 (4): 1–10. Дои:10.1145/1988997.2003643.
  6. ^ а б ван дер Полл, Джон А .; Паула Коце (2002). «Какие эвристики проектирования могут повысить полезность формальной спецификации?». Труды Ежегодной исследовательской конференции 2002 года Южноафриканского института компьютерных ученых и информационных технологов по обеспечению доступа с помощью технологий. SAICSIT '02: 179–194.
  7. ^ Модель знаний S-Cube: Формальная спецификация

внешняя ссылка