МФСП, 01 лекция (от 03 сентября)
Материал из eSyr's wiki.
Строка 1: | Строка 1: | ||
* '''Аудиозапись:''' http://esyr.org/lections/audio/mfsp_2008_winter/MFSP_08_09_03.ogg | * '''Аудиозапись:''' http://esyr.org/lections/audio/mfsp_2008_winter/MFSP_08_09_03.ogg | ||
- | Пргрммня | + | Пргрммня инженерия |
* ОО анализ и проектирование | * ОО анализ и проектирование | ||
* Верификация и м. | * Верификация и м. | ||
* ФСВП | * ФСВП | ||
* Тестирование | * Тестирование | ||
- | * | + | * Внедрение |
** Интеграция с окружением | ** Интеграция с окружением | ||
- | * | + | * Сопровождение |
* Требование | * Требование | ||
- | + | Внедрение, Интеграция с окружением, Сопровождение, Требование --- обычно называют технологиями программирования | |
На английском языке programming == coding. На русском оно имеет ещё один смысл. | На английском языке programming == coding. На русском оно имеет ещё один смысл. | ||
Строка 17: | Строка 17: | ||
Вообще, все 5 курсов есть, но не все из них уложены в сетку ВМК. | Вообще, все 5 курсов есть, но не все из них уложены в сетку ВМК. | ||
- | Тестирование на | + | Тестирование на моделях не читается нигде. |
- | Ещё одно | + | Ещё одно замечание методического плана. Цель преподавания --- передать знания. И чтобы мы в этом курсе научились, потребуется достаточно много энергии, лектор этому мешать не будет. В чём это будет выражаться: в лекционном материале почти ничего не будет про язык спецификации, его необходимо изучить самим. |
- | + | Необходимо самостоятельно пострить кластеры двух понятий. (Кластер --- такя картинка, в середине которой рисуется овальчик и то понятие, которе нужно рассмотреть, например кластер "медицина", и от этого кружочка строите ассоциации, если косвенные, строить косвенные ассоциации, перекрёстные связи тоже желательны). Необходимо нарисовать два кластера --- "спецификация" и "верификация". | |
* Спецификация | * Спецификация | ||
Строка 29: | Строка 29: | ||
... | ... | ||
- | В конце занятия | + | В конце занятия лектор постарается выделить 4 минуты, чтобы мы эти кластеры пополнили. Это инструмент, который в конце некоего сеанса разговора позволяет разложить по полочкам те знания, которые в этот период получили. Выписывание такого рода кластеров до и после, и получение дельты очень помогает усвоению материала. А кто этим не пользуется, лишает себя этой возможности. |
- | Для того, чтобы всё это понимать, | + | Для того, чтобы всё это понимать, усваивать и использовать в жизни, хорошо иметь представление, зачем это нужно. Многие классические курсы (матан, урматы) этой части уделяют мало внимания, хотя в реальной жизни многими подвергается сомнению, стоит ли учить подобным наукам студентов-программистов в таком объёме, и идут активные дискуссии. |
- | Аналогично здесь, это | + | Аналогично здесь, это академическая дисциплина или нет? Лектор сказал бы так: сфера применения этих методов вполне обширна и востербована: |
* Ответственные системы --- те, в которых риски ненадёжнсти, отказов очень высоки. Эти высокие риски бывают двух видов: | * Ответственные системы --- те, в которых риски ненадёжнсти, отказов очень высоки. Эти высокие риски бывают двух видов: | ||
** Либо в экономических категориях (сумм ущерба) | ** Либо в экономических категориях (сумм ущерба) | ||
** Либо в неколичественных характеристиках, определяющих безопасность | ** Либо в неколичественных характеристиках, определяющих безопасность | ||
- | Заметьте, что здесь лектор | + | Заметьте, что здесь лектор намеренно не написал "программные системы", нас интересуют системы управления, а это не только программы, и забывать ни один из факторов нельзя --- машины, линии связи, протоколы, системное ПО, прикладное ПО --- всё это должно быть высокого качества в ответственной системе. |
- | Системы подобного качества --- достаточный аргумент для | + | Системы подобного качества --- достаточный аргумент для использования методов спецификации и верификации? Если достаточно, то есть некий нонсенс: количество людей, которые понимают, что такое спецификация/верификация можно оценить как количество людей, которые это прослушали --- сотни тысяч. Реально работают порядка 10 тысяч преподавателей и 10 тысяч в продакшене. А программистов миллионы. |
- | Оценка процента | + | Оценка процента верифицируемого аппаратного и программного обеспечения: |
* АО ~90-95 | * АО ~90-95 | ||
* ПО ~1-5 | * ПО ~1-5 | ||
- | Важно отметить, что | + | Важно отметить, что верификация точно отвечает на вопрос, тестирование приблизительно. |
На самом деле: | На самом деле: | ||
- | * HW --- IBM, Intel --- отдельные блоки, при этом самое большое достижение ---- блок работы с | + | * HW --- IBM, Intel --- отдельные блоки, при этом самое большое достижение ---- блок работы с плавающей точкой, умножение и деление |
- | * SW --- некоторые | + | * SW --- некоторые компьютерные верификации --- например, системы управления шлюзами, которые охраняют Голландию от навднения. |
- | + | Верифицированное ПО будет стоить минимум в 20 раз дороже. В самой верификации высоки риски, что результат верификации не даст 100-процентной гарантии, поскольку там делаются математически точные вычисления на основании неких предположений, и всё зависит от них. Кроме того, это социальный и человеческий фактор. Область молодая, и в случае, когда мало специалистов, риски велики. | |
- | Если есть | + | Если есть достаточно денег и есть достаточно признаков, то мы займёмся верификацией Этого достаточно? |
Вопрос: всегда ли можно верифицировать. Вопрос очень правильный. Верифицировать можно всегда, когда есть спецификация. Но часты ситуации, когда проект начинается, а спецификации нет. | Вопрос: всегда ли можно верифицировать. Вопрос очень правильный. Верифицировать можно всегда, когда есть спецификация. Но часты ситуации, когда проект начинается, а спецификации нет. | ||
- | + | Верификация — на самом деле это очень просто. Но для этого нужна спецификация, а она есть не всегда. | |
- | Сейчас самый ходовой | + | Сейчас самый ходовой продукт --- порталы. Для заказчиков этих порталов сказать, что они там хотят видеть, абсолютно невозможно. А когда разработчик делает по крайней мере прототип, то уже можно сказать, что нравится, что нет. |
- | Поэтому | + | Поэтому верификация всегда идёт бок о бок с валидацией. |
- | У заказчик есть требования и ожидания, | + | У заказчик есть требования и ожидания, неформальные. На основании требований можно строить спецификацию. Кроме того в реальной жизни на основе разговора с заказчиком можно делать и реализацию. Мы должны проверить соответствие между спецификациями требований (по анг. specification --- просто описание) и реализации. Эта проверка называется верификацией. А проверка между требования и ожиданиями заказчика и реализацией называется валидацией. Проверка соответствия спецификации требованиям и ожиданиям это тоже валидация, но это совершенно разные валидации. Целью первой является реализация. Вторя же должна рассматривать гораздо больше аспектов --- ... . |
... | ... | ||
Строка 70: | Строка 70: | ||
Примеры: | Примеры: | ||
* abs(MIN_INT) --- ? | * abs(MIN_INT) --- ? | ||
- | * Динамическя аллокация --- как описать, если | + | * Динамическя аллокация --- как описать, если внутреняя структура меняется? |
Очень коротко о тех подходах, которые будут рассматриваться. | Очень коротко о тех подходах, которые будут рассматриваться. | ||
- | Почти всегда при решении сложных задач челвечество | + | Почти всегда при решении сложных задач челвечество пользуется методом "разделять и властвовать". Например, нужно разработать крупную, хорошую программную систему. Для того, чтобы дну проблему решить, нужно разбить её на две части: спецификация и верификация. В реальной жизни, в результате того, что спецификации сделаны качественно, для разработчика нет тёмных пятен, он представляет как что делать, и верификация не нужна. Процесс спецификации мжет быть существенно более трудоёмким чем разработка, и общее количество ошибок вылавливается на этом этапе. Этот процесс это не просто написание бумаг, это процесс, связанный с анализом. Верификация --- задача тн. простая, поскольку мы задаёмся вопросом "как проверить соответствие". В спецификации есть два аспекта, связанных между собой, и как их решать, надо придумывать каждый раз: что специфицировать и как специфицировать. Причём момент что тоже разделяется на две части: как неоформленные требования, потр., знания предметной области передать разработчикам спецификации и реализации. Понятно, что надо писать не всё. Документ должен быть компактным. Знания предметной области должны быть, но какие знания --- вопрос. Имеется три основных подхода, ответа на вопрос, как писать спецификацию: |
* Use cases | * Use cases | ||
* Sequence diagram | * Sequence diagram | ||
Строка 81: | Строка 81: | ||
... | ... | ||
- | --- написание | + | --- написание посредника между спецификацией и прототипом. Это не всегда возможно, но это работает. |
- | В | + | В любом случае между спецификацией и реализацией есть прослойка. |
- | + | ||
- | + | ||
- | + | ||
+ | Для оценки нужно иметь зачёт по практикуму, суммарная оценка на экзамене складывается из оценки на коллоквиуме, на экзамене и, возможно, за практикум. | ||
{{МФСП}} | {{МФСП}} | ||
{{Lection-stub}} | {{Lection-stub}} |
Версия 20:22, 29 сентября 2010
Пргрммня инженерия
- ОО анализ и проектирование
- Верификация и м.
- ФСВП
- Тестирование
- Внедрение
- Интеграция с окружением
- Сопровождение
- Требование
Внедрение, Интеграция с окружением, Сопровождение, Требование --- обычно называют технологиями программирования
На английском языке 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
...
--- написание посредника между спецификацией и прототипом. Это не всегда возможно, но это работает.
В любом случае между спецификацией и реализацией есть прослойка.
Для оценки нужно иметь зачёт по практикуму, суммарная оценка на экзамене складывается из оценки на коллоквиуме, на экзамене и, возможно, за практикум.
Формальная спецификация и верификация программ
|
|