Редактирование: МФСП, 05 лекция (от 01 октября)
Материал из eSyr's wiki.
Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.
Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.
| Текущая версия | Ваш текст | ||
| Строка 17: | Строка 17: | ||
* Тема безопасности. Совсем неспецифицирована, поскольку сейчас все этой проблемой озабочены. Это серьёзная вещь и хочется рассмотреть разные стороны описания системы как независимые аспекты, в частности, хотелось бы безопасность отделить от функциональности, но это удаётся далеко не всегда. | * Тема безопасности. Совсем неспецифицирована, поскольку сейчас все этой проблемой озабочены. Это серьёзная вещь и хочется рассмотреть разные стороны описания системы как независимые аспекты, в частности, хотелось бы безопасность отделить от функциональности, но это удаётся далеко не всегда. | ||
| - | Есть некие | + | Есть некие свсем экз. темы, наз. |
| - | * Спецификация ответственности. В больших | + | * Спецификация ответственности. В больших системх всегд дост. высокая вер. тказа, а взаимотн. междлу потр. некоторых услуг и првайдерм ресурсом джлжны быть дост. ясны. Если клиент з чт-то заплтил и ему эт предост., т всё ъхрошо, если не предост, то кк эту коллизию рзреш. Првйдер, который выст. перед гентм, теор. мг бы взять тветственнсть за всё по, хз весь комп. парк, з сетевые возм. и тк длее. Н првйдер не хчет и не мжет сделть этого, олн хочет отв. только з то, что может твечать. Тут возн. субпдрядчик, кторый и длжен твечать. И взаимотн. этих бяз, если бы ни были описаны, и если бы был бы мехнизм разбра инцидентв, то это была бы неплохя прктика страхвых кмпаний. |
| - | Что можно было бы | + | Что можно было бы скзать по части упрощ. анализ? Указанное выше — тенденция к услож. языкв специф. |
* Функциональные языки | * Функциональные языки | ||
| - | * | + | * Упрощ. система типов |
| - | * | + | * Строгя семнтика |
| - | * | + | * Платфрмонез. спец. |
| - | Приняли | + | Приняли реш., что языкми спец. польз. не будем, берём хороший язык пргр. и дп. его эл-тми спец.: дбвляем пред, пст усл. и инвринты. |
Spec# | Spec# | ||
| - | * | + | * Рсширение C# |
| - | * | + | * Кмпилятор |
| - | * | + | * Верификтор — Boogie |
| - | * | + | * SpecEcxplorer |
| - | прект | + | прект бесплтный, но не ткрытый. Для пркт. пргрммиста это не совсем новый язык, а расширение известного. Выявляется дст. ширкий класс ошщибк за счёт исп. рзл. техник. |
| - | Пример | + | Пример тог, кк выгдл, предусловие: |
'''class''' ArrayList | '''class''' ArrayList | ||
{ | { | ||
| Строка 45: | Строка 45: | ||
} | } | ||
} | } | ||
| - | В этом | + | В этом случе, если пдётся неке число, выход. з рамки грницы, выдётся предопр. иск., никк не окрш: requuires violation exception. Пр исключения и пр трактовку предусл. стит сказать тдельно. Рзрб. след. трктвке искл., ктря был ещё их предш. предлжен, и трктовк искл. следующя: исключения трактуются как ткз. Эти откзы бывают двух видов: клиентские и провайдерские. Клиентские — клиент нер. обр. к метду, иил когд релиз. метода сделн не тк, плучился тказ. Провайдесркие тказы в свю очередь делятся ещё н два клсса: admissible — допустимые ткзы, и observed program error. Первый и псл. вид — unchecked исключения, второй, единственный — checked. Любя пргр. длжн ожидть ткие жидемые искл. и опис., чт при этом делть. Если взн. unchecked, т зн., что релиз. некорр. |
| - | Пример | + | Пример пис. admissible исключения: |
'''class''' ArrayList | '''class''' ArrayList | ||
{ | { | ||
| Строка 60: | Строка 60: | ||
} | } | ||
| - | + | Пстусловие: | |
'''ensures''' Count=='''old'''(Count) + 1; | '''ensures''' Count=='''old'''(Count) + 1; | ||
'''ensures''' value==this[index]; | '''ensures''' value==this[index]; | ||
| Строка 66: | Строка 66: | ||
'''ensures''' Forall{'''int''' i '''in''' index:'''old'''(Count): '''old'''(this[i])==this[i+1]} | '''ensures''' Forall{'''int''' i '''in''' index:'''old'''(Count): '''old'''(this[i])==this[i+1]} | ||
| - | Для | + | Для постусловаия важнй бывет ситуация,кгд выд. кке искл, нужно сказть, чт вып., что не вып. Чт релиз. должн грантирвать? Если я рбтю с нек. файлом |
'''throws''' EndOFileException '''ensure''' a.Count==old(a.Count); {...} | '''throws''' EndOFileException '''ensure''' a.Count==old(a.Count); {...} | ||
Минусы: | Минусы: | ||
| - | * Нет обратной | + | * Нет обратной свместимости |
| - | * | + | * Спец. с реализ. |
Плюсы: | Плюсы: | ||
* Библиотеки | * Библиотеки | ||
| - | * | + | * Единя система типв |
| - | * | + | * Пдхд deign by contract |
(тут история) | (тут история) | ||
| Строка 83: | Строка 83: | ||
* 99 - JML | * 99 - JML | ||
* 2003 --- Spec# | * 2003 --- Spec# | ||
| - | * Конец 90-х ( | + | * Конец 90-х (примерн 98; первые идеи в рйне 72 года) --- Extended Static Checker (ESC). Идея: когда мы гворили про пред и пст-усл, то считли, чт пракильное пвед. писн там. Есть другой пдхд: прграмма крректн, если в ней нет дурцких ошибок. Этот пдход — релизация этй идеи, и до посл. времени эти нлиз. и вериф., ктрые прверял корр. требваний и ... были дв незв. набор инстр. Сейчас две эти техники боъединены. |
| - | Те | + | Те техникивериф, с которыми в втрой ччсти сем. позн., это именн те техники, н к-рых ... бзир. |
{{МФСП}} | {{МФСП}} | ||
{{Lection-stub}} | {{Lection-stub}} | ||
