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

* объектно-ориентированный анализ и проектирование

* Верификация и моделирование

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

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

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

* Ответственные системы — те, в которых риски ненадёжности, отказов очень высоки. Эти высокие риски бывают двух видов:

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

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

* HW — IBM, Intel — отдельные блоки, при этом самое большое достижение — блок работы с плавающей точкой, умножение и деление

* SW — некоторые компьютерные верификации --- например, системы управления шлюзами, которые охраняют Голландию от наводнения.

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

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

* abs(MIN_INT) — ?

* Динамическя аллокация — как описать, если внутреняя структура меняется?

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

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