Разработка спецификации программы это

Все мы прекрасно знаем о том, как разрабатывается ПО. Подумали 10 минут и сразу пошли кодить. Цикл создания программного обеспечения состоит из многих ключевых моментов. Это такие моменты как планирование, создания архитектуры, создание SRS, создание дизайна и тд и тп.

Что такое SRS ?

SRS — Software Requirement Specification — специальная документация для ПО которая содержит в себе информацию о том, как должна себя вести система, какие функции должна выполнять, какую нагрузку должна выдерживать и тд.

Зачем оно надо ?

Все предельно просто. Вы используете ТЗ (велосипед), я использую SRS (машину). Надеюсь аналогия получилась ясная? 🙂

Структура SRS

Ниже приведена структура на англ языке в raw виде. Чуть ниже в статье мы рассмотрим каждый пункт более подробно

• Introduction

• Purpose
• Document conventions
• Intended Audience and Reading Suggestions
• Project scope
• References

• Product perspective
• Product features
• User classes and characteristics
• Operating environment
• Design and implementation constraints
• User documentation
• Assumptions and dependencies

• System feature X (таких блоков может быть несколько)

Создание спецификации — 1С

• Description and priority
• Stimulus/Response sequences
• Functional requirements

• User interfaces
• Software interfaces
• Hardware interfaces
• Communication interfaces

• Performance requirements
• Safety requirements
• Software quality attributes
• Security requirements

И так со структурой разобрались, теперь перейдем к разделам и тому, что в них надо писать.

Базовые требования ко всем разделам SRS

• Кратко, четко. Описывает все предельно кратко и четко. Насколько это возможно.
• Без двусмысленных описаний. Человек читающий SRS должен понимать именно то, что написано, а не что-то другое. Закон Мерфи: Если Вас могут понять неправильно, Вас поймут неправильно. Избегайте этого
• Простота и «читабельность». Не используйте каких либо слишком заумных оборотов. Красота в простоте 🙂
• DFD-диаграммы. Спецификация не может быть полной если мы не знаем что на входе в описываемый софт, а что на выходе. Все должно быть четко нарисовано.
• Степень детализации. Это эвристический параметр. Его можно определить так: если я могу свободно изложить информацию о функционале и написанное не вызывает у меня смущения, если требования однозначны и не подлежат никакому двоякому пониманию, если требования в достаточной для меня мере описывают поведение функционала, то проработку SRS можно считать завершенной

Пояснение каждого пункта структуры SRS

Introduction Purpose
В данной секции описываем приложение или продукт, функционал которого будет описываться в SRS.

Формирование спецификаций требований. Обучение проектированию ПО. Часть 7 Тренинг 1

Introduction Document conventions
Здесь мы описываем все непонятные технические слова или термины которые встречаются в SRS. Заметьте, что описание непонятного слова не может содержать другое непонятное слово. Старайтесь расписать как можно подробнее термин который Вы используете простым и понятным всем языком. Не экономьте на этой секции потому, что чем больше вы распишете непонятных вещей, тем проще будет потом проектировать.

Introduction References
В данной секции мы пишем ссылки на литературу в которой можно найти основания использованных технологий и фактов. Допустим можно вставлять RFC если вы пишете приложение работающее с TCP/IP, вставлять ссылки на документы на которые вы ссылаетесь и тд. Ссылки и их описание должны быть максимально полными, чтобы в случае чего (линк умер просто) можно было нагуглить этот материал.

Overall Description Product features
В данном разделе мы описываем части функционала на высоком уровне. Более детально каждая часть функционала будет описана в своем разделе ниже. Тут желательно разместить DFD-диаграмму которая покажет общее взаимодействие системы.

Overall Description Operating environment
Как понятно из названия раздела тут мы описываем окружение в котором будет работать продукт. ОС, версии компиляторов, базы данных, сервера, софт, железо и другие вещи которые необходимы для работы вашего продукта.

• Язык программирования, база данных
• Стандарты кодирования
• Стандарты обмена данными
• Ограничения накладываемые Operational Enviroment, допустим совместимость только с ФФ
• Ограничения которые могут быть наложены бизнес-логикой проекта

Overall Description User documentation
Описываем какая документация нужна для пользователей данного продукта. Возможно это книга по HTML если это HTML редактор.

System features System feature X
Называем фичу проекту и даем ей уникальный идентификатор. Например, server.html.editor. Уникальный идентификатор дается для того, чтобы потом где то в тикетах ваших не писать — «а вот та хреновина, которая позволяет редактировать хтмл»

System features System feature X Description and priority
Описываем детально фичу продукта. Для чего она? Что должна делать? Какой у нее приоритет выполнения. Из этого раздела читающему срс человеку должно сразу стать понятно зачем этот функционал присутствует в системе.

System features System feature X Stimulus/Response sequences
Триггер запуска фичи. Когда она запускается и как себя ведет при запуске? Например, HTML редактор показывается при нажатии пользователя на ссылку меню Открыть HTML редактор

System features System feature X Functional requirements
Подробное и детальное описание фичи. Описываем все: как работает, как реагирует на ошибки, что должно проверять, как отображать данные, как и куда что сохраняет и тд

External interface requirements
Описание того как система будет взаимодействовать с внешним миров. Если будет конечно. Какие API, как получить те или иные данные и тп. Подразделы служат для детализации требований. Какие софт интерфейсы, «железячные» интерфейсы, комуникационные интерфейсы и прочее.

Non functional requirements
Не функциональные требования. Есть требования которые невозможно описать как какую то фичу, например, требования к безопасности.

Non functional requirements Performance requirements
Требования к производительности. Это не фича, однако налагает определенные ограничения. Допустим база данных проекта должна выдерживать 1000 запросов в секунду и тп. Эти требования приводят к колоссальной работе по оптимизации проекта.

Non functional requirements Software quality attributes
Тут мы описываем требования к качеству кода. Какие тесты использовать? Какие метрики использовать для определения качества кода? Сколько кода должно быть покрыто тестами?

Non functional requirements Security requirements
Требования по безопасности. Если это HTML редактор, через которые можно изменять что-то на сайте, то это может быть нечто вроде: через HTML редактор не должно быть возможности поставить shell на сервер и тп

Appendix A: Glossary
Приложение. Иногда в SRS пытаются вставлять описание протоколов и тд и тп. Этого делать не нужно. Однако иногда нужно таки прояснить какую то концепцию. Для этого существует этот раздел.

Вставляем ссылочки на такие пояснения. Такой себе словарик.

Appendix B: Analysis Models
Раздел определяет какие диаграммы нужно использовать при написании SRS. Например, DFD, какие то общие диаграммы взаимодействия и работы

Appendix C: Issues list
Данный раздел используется для очень формальных SRS. Описывает пункты TBD(To Be Done) — что в будущем надо еще сделать, но тут не описано.

Заключение

SRS не является обязательным для использования, однако может помочь в средних и больших проектах. Использование SRS показывает Ваш профессиональный уровень как разработчика.

P.S. прошу сильно не винить — первая статья более или менее среднего масштаба на хабре. Исправления в синтаксисе приветствуются (стараюсь писать грамотно, однако 7-ми классное образование по русскому языку накладывает свой отпечаток.)

• srs
• software requirements specification
• rules

Источник: habr.com

Спецификация программы

Специфика́ция програ́ммы, точное и, по возможности, полное описание назначения программы (программной системы), её функций, требований на входные данные, её результатов, особенностей функционирования и нефункциональных свойств таких как надёжность , отказоустойчивость , требований к ресурсам, и описание состава, структуры программы и её интерфейсов . То есть спецификация программы охватывает различные аспекты программы и её свойств, при этом разные аспекты часто описываются с разной полнотой. В этом случае говорят о частичных спецификациях или об абстрактных спецификациях, в которых нет всех деталей готовой программы (т. н. «реализации программы», англ. implementation). Высокоуровневая спецификация программы является одной из составных частей технического задания на разработку (см. ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению» ).

В силу того, что спецификация программы или части спецификации программы абстрагируются от несущественных деталей реализации, их часто рассматривают как модели программной системы или модели некоторых требований к программной системе или её свойств. Такой подход используется, например, в UML (см. CASE-технологии ). Сами модели программ иногда называются спецификациями, например в Z, B-Method и Event-B.

Основными аспектами спецификации программы являются:

• назначение (для решения каких задач можно или следует использовать);
• состав (набор подпрограмм, функций, глобальных или локальных переменных, формальных параметров и др.);
• структура (набор элементов и связей между ними), например, граф связей модулей по вызовам функций/подпрограмм;
• поведение программной системы видимое извне (например, как результат функции, подпрограммы, через каналы ввода-вывода) или поведение, включая изменение внутреннего состояния программной системы (например, последовательность прохождения вершин на графе управления, значения локальных переменных);
• способ использования (функциональные требования, которые должны быть выполнены перед началом использования и по завершении использования, ограничения по входным данным, ограничения по ресурсам и др.);
• способ сборки (конфигурационные файлы, параметры конфигурирования, утилиты типа make) или способ её установки.

Помимо спецификации собственно программы рассматриваются спецификации характеристик внешнего по отношению к программе окружения, связанного с разработкой и эксплуатацией программных систем, например:

• спецификация нефункциональных требований к программе (требований к ресурсам и аппаратной части, требований информационной безопасности, требований по переносимости, по отказоустойчивости и др.);
• спецификация набора тестов или тестовой системы для данной программы.

Различные виды спецификаций отвечают различным целям их использования и различным ролям пользователя спецификации (программист-разработчик, тестировщик-верификатор, интегратор программного комплекса и др.), например:

• для разработчика функциональная спецификация должна раскрывать интерфейсы разрабатываемой программы (каналы ввода-вывода данных), функцию программной системы (что должно быть получено в результате выполнения программы, какое поведение программы должно быть при получении тех или иных входных данных или других воздействий); кроме того, спецификация должна описывать ограничения, в которые разработчик должен уложиться (объём памяти, скорость вычислений или скорость реакции на входные воздействия);
• для верификатора или разработчика тестов спецификация должна описывать условия корректного использования интерфейсов программы (например, ограничения на входные параметры, на аргументы функций, требования инициации глобальных данных перед обращением к интерфейсам) и критерии корректности результатов выполнения программы (например, требования к выходным данным, включая глобальные переменные, в зависимости от аргументов и состояния глобальных переменных перед вызовом программы).

Спецификации, которые описывают одну и ту же программу в одном и том же наборе аспектов, могут представлять собой иерархическую структуру, где верхние уровни описывают свойства программы в обобщённом (абстрактном) виде, а нижние в более детальном, уточнённом (англ. refined) виде. Переход от абстрактных спецификаций к уточнённым сам по себе называется уточнением (англ. refinement). Разбиение спецификации на слои уточнений позволяет разработчику сначала сконцентрироваться на общих требованиях к программе, а потом постепенно наращивать уровень подробностей в конструкции программы. Для верификатора разбиение спецификации на слои уточнений позволяет разбить задачу верификации большой системы на существенно более простые подзадачи верификации, сводящиеся к проверке правильности каждого перехода от более абстрактного слоя к его уточнению. Это же обстоятельство ослабляет требования к инструментам верификации и позволяет обходить ограничения таких инструментов.

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

Если речь идёт о формальных спецификациях, то понятия и средства построения математических объектов, используемые в спецификациях, выходят далеко за рамки того, что характерно для типичных языков программирования . Это – равенства, системы подстановок и формулы исчисления предикатов , таблицы, графы (сети, диаграммы), операции над сложными объектами, средства описания взаимодействия процессов и процедурные средства высокого уровня, алгебраические системы. Набор парадигм программирования , в рамках которых строятся функциональные спецификации, мало отличается от парадигм в разработке программ, но при этом там, где возможно, используется декларативная, непроцедурная форма спецификации программы.

Известными языками формальной спецификации являются VDM (его развитие: VDM-SL и VDM++), Z (его развитие: B-Method, Event-B), Alloy, LOTOS (его развитие: E-LOTOS), TLA+, ACL2. Многие средства верификации спецификаций используют собственные нотации для представления спецификаций. Наряду с языками формальной спецификации постепенно в практику входят спецификационные расширения обычных языков программирования. Как правило, эти расширения позволяют описывать программные контракты (англ. software contract), предусловия на входные данные и постусловия на результаты. Например, такие средства спецификации уже вошли в современные версии стандартов языков программирования Ada (Ada-2012) и Spark-2014, Dafny, Whiley. Обсуждается введение средств спецификации в новых версиях стандарта C++ .

Имеются спецификационные расширения языков программирования, например: JML для Java , ACSL (ANSI/ISO C Specification Language) для С , Spec# и Sing# для C# . Роль языков спецификации также выполняют языки моделирования. Часто они совмещают в себе возможности моделирования разных аспектов, например, архитектуры системы и функционального описания интерфейсов. Наиболее известным является язык моделирования UML и расширение его подмножества для спецификации архитектуры программно-аппаратных комплексов SysML и его альтернатива AADL. Для телекоммуникационных программно-аппаратных систем широкое распространение получили SDL и MSC, LOTOS и др.

Нередко спецификация программы создаётся на основе уже написанной реализации с встроенными в неё комментариями специального вида. Такие инструменты как Doxygen, Javadoc и их аналоги позволяют генерировать спецификации программ автоматически. При этом состав, структура программной системы, состав интерфейсов функций будут описаны полно и точно, а семантические характеристики (например, для формальных параметров и результатов функций) будут описаны лишь так, как они были описаны в соответствующих комментариях. Задачей генерации более точных спецификаций программ активно занимаются, например, в области статического анализа и верификации программ, но применимость таких спецификаций является ограниченной.

Источник: bigenc.ru

Лекция 7: Формальные спецификации, доказательство и верификация программ

Разработка спецификации проводится по следующей схеме:

1. Определение терминов, которыми будет специфицироваться программа.
2. Описание понятий и объектов, для обозначения которых используется денотат , идентифицируемый с помощью некоторого имени (или фразы).
3. Описание инвариантных свойств программы.
4. Определение операций над структурами программы (например, ввести объект, удалить и др.), изменяющие ее состояние и сохранение инвариантных свойств.

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

При реальном выполнении спецификация исполняется итерационно. На первом уровне проверяется только свойства модели программы при заданных ограничениях независимо от среды. Затем используется уточненная и расширенная спецификация с набором формальных утверждений. И так до тех пор, пока окончательно не будет завершен процесс пошагового доказательства спецификации.

Для демонстрации возможностей VDM языка рассмотрим задачу поиска («Поиск») в каталоге ( ) репозитария компонентов имени компонента и сравнения его с заданным в запросе пользователя. В случае совпадения имен проверяются параметры, и при их совпадении из каталога извлекается код компонента и передается пользователю.

Спецификация переменных программы «Поиск»

репозитария при совпадении имен в каталоге и запросе; — переменная, в которой хранится текущий элемент из репозитария, найденный по фасете компонента с номером для ; — имя разработчика компонента; — переменная, которая используется для задания признака — компонент не найден или к нему никто не обращался.

Описание инвариантных свойств программы

Операторы программы проверяют список имен компонентов в каталоге, который содержит элементов типа . Если они совпадают с именем в запросе, результат сохраняется в .

Доказательство инвариантных свойств программ должно проводиться автоматизированным способом с помощью специально созданных инструментальных средств поддержки VDM языка.

6.1.2. Спецификация программ средствами RAISE

RAISE-метод и RSL -спецификация (RAISE Specification Language) [6.9, 6.10] были разработаны в 80-х годах как результат предварительного исследования формальных методов и их пополнения новыми возможностями. Метод содержит нотации, техники и инструменты для конструирования программ и доказательстве их правильности.

Он имеет программную поддержку в виде набора инструментов и методик, которые постоянно развиваются и используются при доказательстве правильности программ, описанных в RSL и ЯП (С++ и Паскаль). Язык RSL содержит абстрактные параметрические типы данных (алгебраические спецификации) и конкретные типы данных (модельноориентированные), подтипы, операции для задания последовательных и параллельных программ. Он предоставляет аппликативный и императивный стиль спецификации абстрактных программ, а также формальное конструирование программ в других ЯП и доказательство их правильности. Синтаксис этого языка близок к синтаксису языков С++ и Паскаль.

В RSL -языке имеются предопределенные абстрактные типы данных и конструкторы сложных типов данных , такие как произведение ( ), множества ( ), списки ( ), отображения ( ), записи ( ) и т.п. Далее рассмотрим некоторые конструкторы сложных типов данных .

Произведение типов — это упорядоченная конечная последовательность типов произведения ( ) . Представитель типа имеет вид ( ), где каждое -это значение типа . Компонент произведения можно получить операцией и переслать , т.е.

Количество компонентов произведения d находится таким образом:

Конструктор произведения и строит произведение вида:

можно построить конструктор значения этого типа из отдельных компонентов произведения таким образом:

где каждое значение имеет тип , а результирующее значение — тип произведения

Списки типов — это последовательность значений одного типа , могут быть конечным списком типов и неконечными списком типов . В качестве структур данных типа списка может быть бинарное дерево, в котором есть голова ( ) и сын ( ), который следует за ним в списке, и хвост. К операциям списка относится операция — взятия первого элемента списка, т.е. головы, и операция — хвоста остальных элементов (аналогично как в VDM ).

Функция выбирает из списка -элемент. Индекс элемента помогает выбрать нужный элемент списка:

Для определения количества элементов в списке выполняется функция:

Элемент списка находится так:

Аналогично можно представить функции конкатенации, преобразование типов данных, добавления элемента в голову и хвост списка и др.

Отображение — это структура ( ), которая ставит в соответствие значениям одного типа значение другого типа. Вместе с тем отображение — это бинарное отношение декартова произведения двух множеств как совокупности двухкомпонентных пар, в которых первый компонент — содержит элементы аргументов отображения, а второй компонент — соответствующие элементы значений этого отображения.

В языке имеются разные допустимые операции над отображениями: наложение, объединение, композиция, срез и др. Среди этих видов отношений рассмотрим, например, композицию отображений ( , ):

При этом используются функции:

Запись — это совокупность именованных полей. Этот тип соответствует типу в языке Паскаль и в языке С++. В языке RAISE для записи определено два конструктора — , , описание которых имеет вид

Идентификатор — это конструктор типа , для которого задается деструктор как функции получения значения компонентов записи.

Объединение — это конструктор для объединения типов , при котором тип получает одно из значений в списке элементов.

Конструктор типа имеет вид

Операции над самим типом не определены в языке RAISE.

Рассмотренные формальные структуры данных языков VDM и RAISE предназначены для математического описания программ с помощью утверждений и конструирования новых структур данных, необходимых для проектируемых программ. Средства этих языков фактически — элементы спецификации программ , по которым проще проверять правильность программ методами верификации или доказательства, составляя при этом, как и в случае VDM , пред, постусловия и утверждения для проведения доказательства программы по ее спецификациям.

Источник: intuit.ru