Формални спецификации

1. Формални спецификации

2. Цели • Да обясни защо формалната спецификация помага за откриването на проблемите в системните изисквания. • Да се обясни използването на алгебричните техники при спецификацията на интерфейса. • Да опише използването на основаните на модели техники при спецификацията на поведението на системата

3. Основни теми • Формалните спецификации в софтуерния процес • Спецификация на интерфейса на подсистемите • Спецификация на поведението

4. Формални методи • Формалните спецификации е част от множество техники, познати под името “формални методи”. • Всички се основават на математическо представяне и анализ на софтуера. • Формалните методи включват: • Формални спецификации • Анализ и доказателство на спецификациите • Трансформационна разработка • Верифициране на програмата

5. Приемливост на формалните методи • Формалните методи не са станали основна техника за разработка на софтуер, како се предполагаше по-рано • Други софтуерни техники се оказаха успешни при по-добро качество на с-мата. Оттук намалената нужда от формални методи • Промените в пазара направиха времето за излизане на пазара ключов фактор. Формалните методи не намаляват времето за разработка. • Обхватът на формалните методи е ограничен. Те не са подходящи за специфициране на потребителски интерфейс и взаимодействие с потребителя. • Формалните методи все още трудно се приспособяват към големи системи.

6. Употреба на формалните методи • Основната полза от формалните методи е намаляване на дефектите на системата • Следователно, главна област на приложение е разработката на критични с-ми. Съществуват няколко успешни проекта, при които са използвани формални методи • В тази област е много вероятно формалните методи да бъдат икономически ефективни, защото трябва да се избегнат скъпо струващи откази.

7. Спецификацията в софтуерния процес • Спецификацията и проектирането се припокриват и не могат да се разделят. • Архитектурният проект е съществен за структурирането на спецификацията и на процеса на специфициране. • Формалните спецификации се изразяват с математически обозначения с прецизно дефинирани речник, синтаксис и семантика.

8. Спецификация и проектиране

9. Спецификацията в софтуерния процес

10. Употреба на формалната спецификация • Формалната спецификация изисква по-големи усилия в по-ранните фази на разработката на софтуера • Намаляват се грешките в изискванията, тъй като изисква подробен анализ на изискванията. • Могат да открият и разрешат непълноти и противоречия. • Намаляват се преработките, дължащи се на проблеми в изискванията.

11. Профил на разходите • При използването на формални спецификации се променя профилът на разходите • Първоначалните разходи са по-високи, тъй като се изразходват повече време и усилия за разработката на спецификации • Обаче разходите за осъществяване и валидиране би трябвало да намалеят, тъй като процесът на спецификация намалява грешките и двусмислията в изискванията.

12. Разходи за разработка с формална спецификация

13. Техники на спецификация • Алгебрични спецификации • С-мата се специфицира в термините на собствените операции и отношения. • Спецификация основана на модел • С-мата се специфицира в термините на модел на състоянията, който е изграден с използването на математически понятия като множества и последователности. Операциите се дефинират чрез модификациите на състоянието на с-мата.

14. Езици за формални спецификации

15. Спецификация на интерфейса • Големи системи се декомпозират на подсистеми с добре дефинирани интерфейси м/у тези подс-ми. • Спецификацията на интерфейсите подпомагат независимата разработка на различните подсистеми. • Интерфейсите могат да бъдат дефинирани като множество абстрактни типове данни или класове от обекти • Алгебричният подход към формалните спецификации подхожда добре на спецификациите на интерфейсите и се фокусира в/у дефинирането на операциите в един обект.

16. Интерфейси на подсистеми

17. Структура на алгебрична спецификация <Име на спецификацията> (генерично име) sort <име> imports <СПИСЪК ОТ СПЕЦИФИКАЦИОННИ ИМЕНА> Неформално описание на типа и операциите Сигнатури на операциите, задаващи имената и типовете на параметрите на операциите, дефинирани върху типа Аксиоми дефиниращи операциите върху типа

18. Компоненти на спецификацията • Въведение • Дефинира името на типа и декларира други използваните спецификации • Описание • Неформално описва операциите на типа или класа от обекти • Сигнатура • Дефинира синтаксиса на операциите и параметрите им • Аксиоми • Дефинира семантиката на операциите чрез дефиниране на аксиомите, характеризиращи поведението.

19. Систематични алгебрични спецификации • Алгебричните спецификации на системата могат да бъдат разработени по систематичен начин • Структуриране на спецификациите • Избор на имената • Определяне на операциите • Неформална спецификация на операциите • Дефиниция на синтаксиса • Дефиниция на аксиомите

20. Спецификация на операциите • Операции конструктори – създават обекти от специфицирания тип • Инспектиращи операции – изчисляват атрибути на специфицирания тип • За да се специфицира поведение, да се дефинират инспектори за всеки конструктор

21. Операциите на ADT списък (List) • Конструктори, които създават сортиран списък • Create, Cons and Tail • Инспектори, които имат параметър от типа list и връщат резултат от друг тип • Head and Length. • Tail може да се дефинира чрез използването на по-простите конструктори Create и Cons. Не е нужно да се дефинира Head и Length за Tail

22. LIST ( Elem: [Undefined ® Elem] ) sort List imports INTEGER Дефинира списък, в който елементите се добавят в края и се махат от началото. Операциите са Create (създава празен списък), Cons (създава нов списък с добавен елемент), Length (изчислява дължината), Head(изчислява първия елемент) и Tail (създава нов списък като отстранява първия елемент от входния списък) Create ® List Cons (List, Elem) ® List T ail (List) ® List Head (List) ® Elem Length (List) ® Integer Head (Create) = Undefined -- Error to e v aluate an empty list Head (Cons (L, v)) = if L = Create then v else Head (L) Length (Create) = 0 Length (Cons (L, v)) = Length (L) + 1 T ail (Create ) = Create T ail (Cons (L, v)) = if L = Create then Create else Cons (T ail (L), v) Спецификация на List

23. Рекурсивни спецификации • Често операциите се дефинират рекурсивно • Tail (Cons (L, v)) = if L = Create then Create else Cons (Tail (L), v). • Cons ([5, 7], 9) = [5, 7, 9] • Tail ([5, 7, 9]) = Tail (Cons ( [5, 7], 9)) = • Cons (Tail ([5, 7]), 9) = Cons (Tail (Cons ([5], 7)), 9) = • Cons (Cons (Tail ([5]), 7), 9) = • Cons (Cons (Tail (Cons ([], 5)), 7), 9) = • Cons (Cons ([Create], 7), 9) = Cons ([7], 9) = [7, 9]

24. Спецификация на интерфейс в критични системи • Да разгледаме система за управление на въздушното движение, където самолетите летят през наблюдавани сектори на въздушното пространство • Всеки сектор може да съдържа няколко самолета, но от съображения за сигурност те трябва да бъдат разделени. • В този пример е предложено просто разделяне от 300 м по вертикала. • С-мата трябва да предупреди контрольора, ако самолетът е инструктиран да се движи така, че правилото за разделяне ще бъде нарушено.

25. Обект сектор • Критичните операции на един обект, представляващ контролиран сектор са: • Enter. Добавя самолет в контролираното пространство; • Leave. Премахва самолет от контролираното пространство; • Move. Премахва самолет от една височина на друга; • Lookup. При даден идентификатор на самолет, връща текущата му височина;

26. Примитивни операции • Понякога е необходимо да се въведат допълнителни операции, за да се опрости спецификацията • Тогава другите операции могат да се дефинират чрез тези по-примитивни конструктори • Примитивни операции • Create. Започва съществуването на екземпляр от сектор; • Put.Добавя самолет без проверка за опасност; • In-space. Определя дали даден самолет е в сектора; • Occupied. При дадена височина определя, дали един самолет се намира на по-малко от 300m от нея.

27. Спецификация на Sector(1)

28. Спецификация на Sector (2)

29. Коментари към спецификациите • Използват се базови конструктори Createи Put,за да се специфицират другите операции. • Дефинират се Occupiedи In-space, които използват CreateиPut, и се използват в дефинициите на други операции. • Всички операции, при които се извършват промени в сектора, трябва да проверяват, дали са изпълнени критериите за безопасност.

30. Спецификации на поведение • Алгебричните спецификации могат да бъдат тежки и неудобни, когато операциите на обекта зависят от състоянието му. • Спецификациите базирани на модел показват състоянието на системата и дефинират операциите в термините на промяна на това състояние. • Z обозначението е разработена техника за спецификация. Тя комбинира формално и неформално описание като използва графични допълнения за представяне на спецификациите.

31. Структура на Z схема Schema name Schema signature Schema predicate Container contents: capacity: contents <= capacity

32. Моделиране на помпа за инсулин • Z схемата за помпата за инсулин декларира няколко променливи за състояния: • Входни променливи като switch? (ключът на у-вото), InsulinReservoir? (текущото количество на инсулина) и Reading? (отчет от сензора); • Изходни променливи като alarm! (ситемна аларма), display1!, display2! (дисплеите на помпата) и dose! (дозата инсулин, която трябва да бъде бита).

33. Инвариант на схемата • Всяка Z схема има инвариантна част, която дефинира условията, които са винаги верни. • За схемата за инсулиновата помпа винаги е вярно, че: • For the insulin pump schema it is always true that • Дозата трябва да е по-малка или равна на капацитета на резервоара за инсулин; • Единичната доза не може да е по-голяма от 4 ед. инсулин и общата доза за един период не трябва да надхвърля 25 ед. инсулин. Това ограничение за безопасност. • display2! показва количеството инсулин, което трябва да бъде бито.

34. Схема на инсулинова помпа

35. Инвариантни състояния

36. Изчисление на дозировката • Инсулиновата помпа количеството инсулин като сравнява текущия отчет с предишните два. • Ако се види, че кръвната захар се покачва, се бие инсулин. • Информацията за общата бита доза се поддържа, за да позволи приложението на инварианта на проверката за безопасност. • Забележете, че този инвариант винаги се прилага – няма нужда да се повтаря в изчислението на дозата.

37. RUN схема (1)

38. RUN схема (2)

39. Sugar OK схема

40. Обобщение • Формалните спецификации на системата допълва другите методи • Те са точни и недвусмислени и отстраняват съмненията • Формалната спецификация предизвиква анализ на системните изисквания в ранен стадий на разработката. Изправянето на грешки в този стадий по-евтино от модифицирането на доставената с-ма • Техниките на формалните спецификации са най-приложими при разработката на критични системи и стандарти

41. Обобщение • Алгебричните техники са подходящи за спецификацията на интерфейс, където интерфейсът е дефиниран като множество от класове обекти • Техниките базирани на модели моделират системата използвайки множества и функции. Това опростява някои типове спецификация на поведението. • В спецификациите базирани на модели операциите са дефинирани чрез определяне на пре и постусловия на състоянията на системата