МФСП, 01 лекция (от 03 сентября)

Материал из eSyr's wiki.

(Различия между версиями)
Перейти к: навигация, поиск
(Новая: Пргрммня инрженерия * ОО анализ и проектирование * Верификация и м. * ФСВП * Тестирование * Внедерние ** И...)
Строка 88: Строка 88:
{{МФСП}}
{{МФСП}}
 +
{{Lection-stub}}

Версия 15:45, 12 сентября 2008

Пргрммня инрженерия

  • ОО анализ и проектирование
  • Верификация и м.
  • ФСВП
  • Тестирование
  • Внедерние
    • Интеграция с окружением
  • Сопровождление
  • Требование

Внедерние, Интеграция с окружением, Сопровождление, Требование --- бычно называют технологиями программирования

На английском языке programming == coding. На русском оно имеет ещё один смысл.

Вообще, все 5 курсов есть, но не все из них уложены в сетку ВМК.

Тестирование на мделях нечитется нигде.

Ещё одно замечние методического плана. Цель преподавания --- передать знания. И чтобы мы в этом курсе научились, потребуется дстаточно много энергии, лектор этому мешать не будет. В чём это будет выржаться: в лекционном материале почти ничего не будет про язык спецификации, его небх. изучить самим.

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

  • Спецификация

...

  • Верификация

...

В конце занятия лектр постарается выделить 4 минуты, чтбы мы эти кластеры пполнили. Это интсрумент, который в конце некоего сеанс разговор позв. рзлжить по полочкам те знания, которые в этот период получили. Выписывание такого рода клстеров до и псле, и получение дельты очень помогает усвоению материала. А кт этим не пользуется, лишает себя этой возможности.

Для того, чтобы всё это понимать, усвивать и исп. в жизни, хорошо иметь представление, зачем это нужно. Многие классмяеские курсы (матан, урматы) этой части уделяют мало внимания, хотя в реальной жизни многими подвергается сомнению, стоит ли учить подобным нукам студентв-программиств в таком объёме, и идут активные дискуссии.

Аналогично здесь, это академическя дисциплина или нет? Лектор сказал бы так: сфера применения этих методов вплне обширна и востербована:

  • Ответственные системы --- те, в которых риски ненадёжнсти, отказов очень высоки. Эти высокие риски бывают двух видов:
    • Либо в экономических категориях (сумм ущерба)
    • Либо в неколичественных характеристиках, определяющих безопасность

Заметьте, что здесь лектор нмеренно не написал "программные системы", нас интересуют системы упрвления, а это не только программы, и забывать ни один из факторов нельзя --- машины, линии связи, протоколы, системное ПО, прикладное ПО --- всё это должно быть высокого качества в отв. системе.

Системы подобного качества --- достаточный аргумент для исп. методов спецификации и верификации? Если достаточно, то есть некий нонсенс: количество людей, которые понимют, что таке спец./вериф. можно оценить как количество людей, которые это прослушали --- сотни тысяч. Реально рботают порядка 10 тысяч преподавателей и 10 тысяч в продакшне. А программистов миллионы.

Оценка процента верифицируемоно апп. и прогр. обесп.:

  • АО ~90-95
  • ПО ~1-5

Важно отметить, что верификция точно отвечает на вопрос, тестирование приблизительно.

На самом деле:

  • HW --- IBM, Intel --- отдельные блоки, при этом самое большое достижение ---- блок работы с пл. точкой, умножение и деление
  • SW --- некоторые комп. вериф. --- напр., системы упр. шлюзами, которые охр. Голландию от навднения.

Верифицирванное ПО будет стоить минимум в 20 рз дороже. В самой вериф. высоки риски, что рез. вериф. не даст 100-прцентной гарантии, поск. там делуются мат. точные выч. н осн. неких предп., и всё зависит от них. Кроме того, это соц. и человеч. фактор. Обл. молодая, и в случе, когда мало специалиств, риски велики.

Если есть дост. денег и есть дост. признаков, то мы займёмся вериф. Этого достаточно?

Вопрос: всегда ли можно верифицировать. Вопрос очень правильный. Верифицировать можно всегда, когда есть спецификация. Но часты ситуации, когда проект начинается, а спецификации нет.

Верификция на самом деле это очень просто. Но для этого нужна спецификация, а она есть не всегда.

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

Поэтому вериф. всегда идёт бок о бок с влидацией.

У заказчик есть требования и ожидания, нефромальные. На основании требований можно строить специфкацию. Кроме того в реальной жизни на основе разг. с заказчиком можно делать и реализцию. Мы должны проверить соответствие между спецификациями требований (по анг. specification --- просто описание) и реализц. Эта проверка называется верификацией. А прверка между треб. и ожид. заказчика и реализацией наз. валидацией. Проверка соотв. спец. треб. и ожид. это тоже валидация, но это соверш. разные вали дации. Целью первой является реализация. Вторя же должна рассм. гораздо больше аспектов --- ... .

...

Примеры:

  • abs(MIN_INT) --- ?
  • Динамическя аллокация --- как описать, если внутр. структура меняется?

Очень коротко о тех подходах, которые будут рассматриваться.

Почти всегда при решении сложных задач челвечество польз. методом "разделять и властвовать". Например, нужно разработать крупную, хорошую прогр. систему. Для того, чтобы дну проблему решить, нужно разбить её на две чсти: спецификация и верификация. В реальной жизни, в резуьлтате того, что спец. сделаны качественно, для разработчика нет тёмных пятен, он предст. как что делать, и вериф. не нужна. Процесс спец. мжет быть сущ. более трудёмким чем разработка, и общее количество ошибок вылавливается на этом этапе. Этот процесс это не просто написание бумаг, это процесс, связанный с анализом. Вериф --- задача тн. прстая, поск. мы задаёмся вопросом "как проверить соотв.". В спец. есть два асп., связанных между собой, и как их решать, надо придумываь каждый раз: что специфицировать и как специфицирвать. Причём момент что тоже разд. на две части: как неоформленные требования, потр., знания предм. бласти передать разработчикам спец. и реализац.. Понятно, что надо пистаь не всё. Документ должен быть компактным. Знания предм. области должны быть, но какие знания --- вопрос. Имеется три осн. подхода, ответа на вопрс, как писать спецификацию:

  • Use cases
  • Sequence diagram
  • SDL

...

--- написание поср. между спец. и прототипм. Это не всегда возм., но это работает.

В любм случае между спепц. и релзи. есть прслойка.


Для оценки нужно иметь зачёт по практикуму, суммарная ценка н экза. склад. из оценки на колке, н экз. и возм. за практикум.



Формальная спецификация и верификация программ


Лекции

01 02 03 04 05 06 07 08 09 10 11 12 13 14


Календарь

Сентябрь
03 10 17 24
Октябрь
01 08 15 22 29
Ноябрь
12 19 26
Декабрь
03 17
Семинары

01 02 03 04 05 06


Календарь

Сентябрь
01 08 15 22 29
Октябрь
06

Оформление задач|Проведение экзамена


Эта статья является конспектом лекции.

Эта статья ещё не вычитана. Пожалуйста, вычитайте её и исправьте ошибки, если они есть.
Личные инструменты
Разделы