Лекция Виды формальных спецификаций. Практические задачи курса

Лекция
Виды формальных
спецификаций.
Практические задачи курса
Виды использования моделей
жизненном цикле ПО
Фазы жизненного
цикла
Цель фазы
 Уточнение в понимании задачи
 Согласование с заказчиком
Прототипирование
 Оценка реализуемости
Проектирование
(поиск подходящих
решений)
Реверс-инженерия
ВМиК МГУ.
Сентябрь-декабрь 2006
 Получить программную систему
 Понимание организации (legacy)
системы
 Фиксация полученного знания
для хранения и передачи
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
2
Пример: Разработка спецификации
для целей прототипирования
Фазы жизненного
цикла
Прототипирование
Цель фазы
Уточнение в понимании задачи
Согласование с заказчиком
Оценка реализуемости
В примере не
будет
рассматриваться
задача «оценки
реализуемости».
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
3
«Очередь» - Неформальное
описание системы


Требуется спроектировать систему,
реализующую операции для работы с
«очередями»
Система будет предоставлять
программный интерфейс (ПИ, или
Application Program Interface - API)
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
4
Первый шаг формализации.
Выбор терминов (денотатов)

Типы данных



Операции




Очередь - Queue
Элемент очереди - Element
Поставить в очередь - append
Кого обслуживать следующим? - first
Кто останется после этого? - rest
Константа

Пустая очередь - empty
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
5
Сигнатура (структура) интерфейса
- простейший вид спецификации
QUEUE =
class
type
value
end
ВМиК МГУ.
Сентябрь-декабрь 2006
Element,
Queue
empty : Queue,
append : Element >< Queue -> Queue,
first : Queue -~-> Element,
rest : Queue -~-> Queue
Мы описали структуру, то есть набор
элементов и связи между элементами.
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
6
Упражнение: Как бы я написал(а)
спецификацию очереди
Знаю
Оцениваю сам
Оцениваю по
отношению к
сформулированным
требованиям
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
7
Требования к спецификации.
Спецификация должна:

быть простой/естественной для





реализитора/пользователя/
дизайнера тестов/тестировщика/
менеджера требований и инженера по качеству
позволять проверять внутреннюю
согласованность/консистентность
быть недвусмысленной для объективности анализа
быть полной (определена область допустимых значений для
всех функций, поведение определено при всех допустимых
сценариях использования)
не содержать лишних ограничений на реализацию
Вопрос: какие из этих требований могут быть
ослаблены?
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
8
Известные виды
спецификаций



Алгебраические/аксиоматические
Явные/исполнимые/алгоритмические
Неявные/неисполнимые/ограничения
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
9
Очередь. Алгебраическая
спецификация
QUEUE = class
type
Element,
Queue
value
empty: Queue,
append : Element >< Queue -> Queue,
first : Queue -~-> Element,
rest : Queue -~-> Queue
axiom forall e : Element, q : Queue :empty ~= append (e,q),
first(append(e, empty)) is e,
rest(append(e,empty)) is empty,
first(append(e, q)) is if q=empty then e
else first(q) end,
rest(append(e,q)) is if q=empty then empty
else append(rest(q)) end
end
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
10
Пример трансформаций типа
re-writing
…
axiom forall e : Element, q : Queue :empty ~= append (e,q),
first(append(e, empty)) is e,
rest(append(e,empty)) is empty,
first(append(e, q)) is if q=empty then e
else first(q) end,
rest(append(e,q)) is if q=empty then empty
else append(e, rest(q)) end
end
rest(append(a, append (b, empty))) 
append(a, rest(append (b, empty))) 
append(a, empty)
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
11
Очередь.
Явная спецификация
QUEUE = class
type
Element,
Queue = Element-list
value
empty: Queue,
append : Element >< Queue -> Queue,
first : Queue -~-> Element,
rest : Queue -~-> Queue
axiom forall e : Element, q : Queue :empty is <..>,
append(e,q) is q ^ <.e.>,
first(q) is hd q pre q~=<..>,
rest(q) is tl q pre q~=<..>
end
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
12
Очередь.
Явная спецификация (зеркало)
...
axiom forall e : Element, q : Queue :empty is <..>,
append(e,q) is <.e.> ^ q,
first(q) is q(len q)
pre q~=<..> ,
rest(q) is
variable x: Queue = <. .>
for i = <.2..len q.> do
x:=x ^ q(i) end
pre q~=<..>
end
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
13
Очередь.
Неявная спецификация
QUEUE = class
type
Element,
Queue = Element-list
value
empty: Queue,
append : Element >< Queue -> Queue,
first : Queue -~-> Element,
rest : Queue -~-> Queue
axiom forall e : Element, q : Queue :empty is <..>,
append(e,q1) as post q1 ^ <.e.> = q2,
first(q) as e
post hd q= e pre q~=<..>,
rest(q1) as q2
post exists e : Element :- <.e.> ^ q2 = q1
pre q~=<..>,
end
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
14
Очередь. Неявная
спецификация (зеркало)
QUEUE = class
type
Element,
Queue = Element-list
value
empty: Queue,
append : Element >< Queue -> Queue,
first : Queue -~-> Element,
rest : Queue -~-> Queue
axiom forall e : Element, q : Queue :empty is <..>,
append(e,q1) as q2 post <.e.> ^ q1 = q2,
first(q1) as e
post exists q2 : Queue :- q2 ^ <.e.> = q1
pre q1~=<..>,
rest(q1) as q2
post tl q1= q2 pre q1~=<..>
end
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
15
Определение функции
1. Определить имя функции
2. Определить тип (сигнатуру)

тип аргументов

тип результата

всюду вычислимая (total) или частично вычислимая (partial)
3. Определить стиль описания

явное определение (explicit) – если можем предложить
формулу

неявное определени (implicit) – если можем описать input-output
отношение

аксиоматическое (алгебраическое) – всегда возможно
типичное использование в случае, когда приходится
использовать специфический вид аргументов (аргумент –
вызов функции), например, f(g(x),x) - h(f,x)
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
16
Практические цели курса.
Научиться:

Строить модели




сопоставлять модели с неформальными требованиями
Изменять уровень абстракции (повышать и
понижать уровень)
Анализировать модели (проверять их
консистентность)
Анализировать согласованность моделей, при
помощи:


Уточнения (refinement)
Тестирования
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
17
Аналоги курса
SE313 Формальные методы
программной инженерии
 Подходы к проектированию и построению
программного обеспечения, использующие
математический аппарат для достижения
высоких уровней качества.
Математические основы формальных
методов; формальное моделирование;
аттестация формальных моделей;
формальный анализ проектирования;
преобразование программ.
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
18
Аналоги курса
SE221 Тестирование программного
обеспечения
 Подробный курс по всем аспектам
тестирования, а также по другим
аспектам верификации и аттестации,
включая определение тестируемых
требований, рецензий и обеспечение
качества продукта.
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
19
Рекомендации
Важнейшей задачей проектов по разработке
программного обеспечения {software
projects} является разрешение проблем
заказчика как явных, так и неявных.
К сожалению, наиболее частой ошибкой
является фокусирование исключительно на
технических проблемах, что в дальнейшем
приводит к созданию непригодных для
использования систем.
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
20
Рекомендации
Реккурентно.

Измерение {measurement}, количественный анализ {quantification} и
формальные {formal} математические подходы.

Моделирование, представление {representation} и абстракция {abstraction}.

Человеческие факторы и удобство использования{usability}. Необходимо
снова и снова обращать внимание студентов на то, что программная
инженерия {Software engineering} - это больше, чем просто технология {not
just about technology} .

Важность масштабирования {importance of scale}: студенты могут
практиковаться на решении относительно небольших проблем, однако они
должны понимать, что возможности множества методов наиболее полно
проявляются в больших системах. Они должны быть готовы решать задачи,
как если бы они работали над очень большими системами, они также
должны учиться читать и понимать код больших систем.
Рекомендация 5. Изучение некоторых тем программной инженерии {software
engineering} подразумевает определенный уровень зрелости {maturity} .

ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
21
Языки и методологии
спецификаций
Abstract State
Machines
B-Method
Estelle
Esterel
Lotos
Overture
Modeling
Language
Petri Nets
Promela
RAISE
SDL
VDM
Z
ВМиК МГУ.
Сентябрь-декабрь 2006
Языки
Методологии
RSL
VDM-SL
RAISE
VDM
VDM++
Development
process for realtime systems
(IFAD)
Z, B, ASML
Eiffel
Design-by-contract
ADL/ADL2, JML,
Design-by-contract
А.К.Петренко. Формальные спецификации
22
Jatva,
Spec#
программ
- I. Лекция 2

Спецкурс В.В.Кулямина. Технология
программирования. Компонентный
подход.
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
23
Ключевые слова
аксиоматические
алгебраические
денотат
жизненный цикл ПО
исполнимые спецификации
консистентность
методология разработки
неявные спецификации
ограничения
программный интерфейс
сигнатура
тестирование
уточнение
формальные спецификации
программ
явные спецификации
языки спецификаций
ВМиК МГУ.
Сентябрь-декабрь 2006
axiomatic
algebraic
denotate
software life-cycle
executable specification
consistency
development method
implicit specification
constraints
Application Program Interface
- API
signature
testing
refinement
formal specification of
software
explicit specification
specification languages
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
24
Дополнительная литература



Б.Мейер. Программная инженерия как
предмет обучения.- Открытые системы,
Июль-Август 2001, стр.80-86.
http://www.fmeurope.org
Бертран Мейер. Объектноориентированное конструирование
программных систем (+ CD-ROM)// Русская
редакция, 2005.
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
25
Приложение
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
26
Пример алгебраических
спецификаций. База данных
DATABASE = class
type
Database, Key, Data
value
/* generators */
empty: Database,
insert : Key >< Data >< Database -> Database,
remove : Key >< Database -> Database,
/* observers */
defined : Key >< Database -> Bool,
lookup : Key >< Database -~-> Data
axiom
[defined-empty]
 k : Key • defined(k,empty) = false,
[ defined-insert ]
 k,k1 : Key, d : Data, db : Database • defined(k,insert(k1,d,db)) is (k = k1) \/ defined(k,db),
[defined-remove]
 k,k1 : Key, db : Database • defined(k,remove(k1)db)) is k ~= k1 /\ defined(k,db),
[lookup-insert]
 k,k1 : Key, d : Data, db : Database • lookup(k,insert(k1,d,db)) =
if k = k1 then d else lookup(k,db) end
pre k = k1 V defined(k,db),
[lookup-remove]
k,k1 : Key, db : Database • lookup(k,remove(k1,db))  lookup(k,db)
pre k~=k1/\ defined(k,db)
end
ВМиК МГУ.
Сентябрь-декабрь 2006
А.К.Петренко. Формальные спецификации
программ - I. Лекция 2
27