ПРОФЕСИОНАЛЕН МОДУЛ
„Разработка на софтуер
софтуерни модули
софтуер за компютър
системи"

MDK

Системно програмиране
Приложно програмиране

Цели и задачи на модула

зная:
основните етапи на разработка на софтуер
сигурност;
основни принципи на строителната технология
и обектно-ориентирани
програмиране;
основни принципи на отстраняване на грешки и тестване
софтуерни продукти;
методи и средства за разработване на технически
документация.

Цели и задачи на модула

да може да:
разработване на софтуерен код
модули на съвременни програмни езици;
създайте програма според разработения алгоритъм
като отделен модул;
отстраняване на грешки и тестване на програмата
модулно ниво;
изготвяне на софтуерна документация
съоръжения;
използвайте инструменти за
автоматизация на документооборота;

Цели и задачи на модула

имат практически опит:
разработване на алгоритъм за задачата и
изпълнение чрез средства
автоматизирано проектиране;
разработка на код на софтуерен продукт
въз основа на готовата спецификация на ниво
модул;
използване на инструменти на
етап на отстраняване на грешки на софтуерния продукт;
софтуерно тестване
модул по определен сценарий;

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

PC 1.1. Извършване на разработването на спецификации за индивидуални
компонент.
PC 1.2. Извършете разработването на код на софтуерен продукт
на базата на готови спецификации на ниво модул.
PC 1.3. Извършване на отстраняване на грешки на програмни модули с
с помощта на специализиран софтуер.
PC 1.4. Извършва тестване на софтуерни модули.
PC 1.5. Да се ​​оптимизира програмния код на модула.
PC 1.6. Разработване на дизайн и технически компоненти
документация, използваща графични езици
спецификации.

Междупредметни връзки

Информатика и ИКТ;
Информационни технологии;
Архитектура компютърни системи;
Основи на програмирането;
ОПЕРАЦИОННА СИСТЕМА.

Етапи на обучение

Аудиторни уроци
Практически уроци
Самостоятелна работа
курсов проект
Учебна практика
Стаж
Квалификационен изпит (защита
портфолио)

Приложно програмиране

Раздел 1. Основни принципи на разработване на приложения

Тема 1.1. Основни понятия
приложно програмиране

Въпроси

Класификация софтуер
Жизнен цикъл на софтуера
Етапи на развитие на програмата
Програмна документация

Какво е програмиране?

Програмиране – в широк смисъл
представлява всички технически
операции, необходими за създаване
програми, включително анализ на изискванията и
всички етапи на разработка и внедряване. IN
тесен смисъл е кодиране и
тестване на програмата в рамките на
някакъв конкретен проект.

Какво е софтуер?

Софтуер (софтуер) (софтуер)
- общ термин за
"нематериален" (за разлика от физическия)
компоненти на компютърна система.
В повечето случаи се отнася за
изпълняват се програми
компютърна система към
подчертават разликата им от хардуера
средства на същата система.

Какви класове софтуер
Ти знаеш?

система: операционни системи; драйвери
устройства; различни комунални услуги;
за разработчици: среди за програмиране;
писмени и устни преводачи; CASE инструменти;
програмни библиотеки;
за крайни потребители: текст
процесори; електронни таблици; графика
редактори; решаващи математически задачи;
системи за обучение и контрол;
компютърни игри; приложни програми.

Какво е приложен
програма?

приложна програма (приложение
програма) - всяка програма,
допринасяйки за задачата,
присвоен на компютъра в рамките на това
организация и пряк принос към
изпълнението на тази задача.

Какво може да се нарече софтуерна система?

Софтуерната система представлява
е множество от решения на множеството
различни, но свързани
задачи (ОС, СУБД).
По-тясно специализирани
програмите не се наричат ​​системи
(текстов редактор, компилатор и др.)

Жизнен цикъл на софтуера (жизнен цикъл на софтуера) целия период на съществуване
софтуерни системи,
започвайки от развитието на началния
концепция за тази система и нейното прекратяване
остаряване

ЖИЗНЕН ЦИКЪЛ НА СОФТУЕРА

ЕТАПИ НА СЪЗДАВАНЕ НА ПРОГРАМИ

Системен анализ.
Анализ на изискванията за
софтуерна система, базирана на
първично изследване на всички информационни потоци
по време на традиционна работа и се извършва
в следната последователност:
а) изясняване на видовете и последователността на цялата работа;
б) дефиниране на целите, които трябва да бъдат
постигнати от разработената програма;
в) идентифициране на аналози, които осигуряват постижението
подобни цели, техните предимства и недостатъци.

ЕТАПИ НА СЪЗДАВАНЕ НА ПРОГРАМИ

Външна спецификация
Състои се от дефиниране на външни спецификации, т.е.
описания на входната и изходната информация,
форми на тяхното представяне и начини за обработка на информацията.
Изпълнява се в следната последователност:
а) поставяне на задача за разработване на нова програма;
б) оценка на постигнатите цели на разработените
софтуерен продукт.
Освен това, ако е необходимо, стъпки 1-2 могат да се повтарят, докато
постигане на задоволителен външен вид на програмата
система с описание на функциите, които изпълнява и някои
яснота на изпълнение на неговото функциониране.

ЕТАПИ НА СЪЗДАВАНЕ НА ПРОГРАМИ

Дизайн на програмата
Извършва се набор от работи за формиране на описание на програмата.
Изходните данни за тази фаза са поставените изисквания
в спецификацията, разработена в предишната стъпка. приет
решения за това как да се изпълнят изискванията
спецификации. Тази фаза на разработване на програмата е разделена на два етапа:
а) архитектурен дизайн. Това е развитие
програмни описания в общ изглед. Това описание съдържа
информация за възможни варианти за конструктивно изграждане
софтуерен продукт (или под формата на няколко програми, или под формата на
няколко части от една програма), както и за основните
алгоритми и структури от данни. Резултатите от тази работа са
окончателната версия на архитектурата на софтуерната система,
изисквания към структурата на отделните софтуерни компоненти и
организация на файлове за междупрограмен обмен на данни;
б) работен проект. На този етап архитектурното описание
програмата е детайлизирана до ниво, което прави
възможна работа по внедряването му (кодиране и асемблиране). За
Това става чрез компилиране и проверка на спецификациите на модулите,
компилиране на описания на логиката на модулите, компилиране на финала
план за изпълнение на програмата.

ЕТАПИ НА СЪЗДАВАНЕ НА ПРОГРАМИ

Кодиране и тестване
Изпълнява се за отделни модули и
колекция от готови модули до
получаване на готовата програма.
Цялостно тестване
Развитие на оперативен
документация
Приемане и други видове
тестове

ЕТАПИ НА СЪЗДАВАНЕ НА ПРОГРАМИ

Корекция на програмата
Въз основа на резултатите
предишни тестове.
Доставка до клиента
Извършва се окончателна доставка
софтуерен продукт на клиента.
Репликация

ЕТАПИ НА СЪЗДАВАНЕ НА ПРОГРАМИ

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

Въпроси

1. Основни понятия на програмирането.
Софтуерни класове.
2. Жизнен цикъл на софтуера
осигурете
3. Етапи на създаване на програми

ПРОГРАМНА ДОКУМЕНТАЦИЯ

Всеки етап на проектиране
кулминира в изготвянето
съответните документи, т.н
важен елемент от дизайна
софтуерни приложения е
подготовка на софтуерна документация.

ПРОГРАМНА ДОКУМЕНТАЦИЯ

Спецификация на програмата (програма
спецификация) - точно описание на това
резултат, който трябва да се постигне
използване на програмата. Това описание
трябва да посочи точно какво
направете програма без да уточнявате как е
трябва да го направи.

ПРОГРАМНА ДОКУМЕНТАЦИЯ

За програми, които завършват работата си с някакъв резултат, обикновено се компилират
I/O спецификации, които описват
желано картографиране на входния набор
количества в набор от изходни количества.
За циклични програми (в които не
посочете крайната точка), развийте
спецификации, където е фокусът
се фокусира върху отделни функции,
изпълнявани от програмата по време на цикличен
операции.

ПРОГРАМНА ДОКУМЕНТАЦИЯ

Основната спецификация описва:
обекти, включени в задачата (какво прави програмата
и какво прави човекът, който работи с тази програма);
процеси и дейности (проектни процедури и дейности
човек, алгоритми за решаване на проблеми в машина,
ред на обработка на информацията, размерът на оперативните
необходима памет за работа на програмата);
входни и изходни данни, както и тяхната организация
(например диалогов скрипт с екранни форми,
организиране на файлове, определящи дължините на записните полета и
максимално количество информация във файлове);
инструкции за използване на бъдещата програма.

ПРОГРАМНА ДОКУМЕНТАЦИЯ

Правете разлика между външен софтуер
документация, която е в съответствие с
клиент и междинен
вътрешна проектна документация.
При компилиране на програма
първо се разработва документация
външни спецификации и след това -
вътрешни.

ПРОГРАМНА ДОКУМЕНТАЦИЯ

Външните спецификации включват
входни и изходни спецификации
данни, тяхната организация, реакции към
изключения, определение,
какво прави човек (по какви алгоритми
работи и откъде получава информация), и
тази машина.

ПРОГРАМНА ДОКУМЕНТАЦИЯ

Вътрешните спецификации включват
описание на вътрешните програмни данни
(променливи, особено структурирани) и
описания на алгоритмите на цялата програма и нейните
части.
Вътрешните спецификации са дадени в единство
с описание на софтуерната архитектура
сложна и вътрешна структура
изграждане на отделен софтуер
компонент.

Домашна работа

Направете списък с видовете документи за
осигуряване на жизнения цикъл на софтуера.

принцип на включване, който осигурява това
изисквания за създаване, функциониране и развитие
Софтуерът се определя от страна на по-сложни,
системата, която го включва;
принципът на системното единство, който е
че на всички етапи на създаване, експлоатация и
разработване на софтуер, неговата цялост ще бъде гарантирана
връзки между подсистемите и
функциониране на подсистемата за управление;
принцип на развитие, който предвижда софт
възможност за разширяване и подобряване
компоненти и връзки между тях;

ОБЩОСИСТЕМНИ ПРИНЦИПИ ЗА СЪЗДАВАНЕ НА ПРОГРАМИ

принципът на комплексността
е, че софтуерът предоставя
свързаност на обработката на информация
отделни елементи, така и за целия обем
данни като цяло на всички етапи на обработка;
принципът на информационното единство, т.е
във всички подсистеми, средства за поддръжка и
софтуерните компоненти използват общ
термини, символи, конвенции и
методи на представяне;

ОБЩОСИСТЕМНИ ПРИНЦИПИ ЗА СЪЗДАВАНЕ НА ПРОГРАМИ

Принципът на съвместимост е това
език, символи, кодове и софтуерни инструменти
осигуряване съгласувано, предоставяне
съвместно функциониране на всички
подсистеми и поддържат отворена структура
системи като цяло;
принципът на инвариантността определя
инвариантност на софтуерните подсистеми и компоненти
към обработваната информация, тоест те са универсални или типични.

Технологиите за програмиране са
доказани стратегии за създаване
програми, които са представени под формата на методи
с информационни фондове, описания
процедури за проектиране и операции по проектиране.
Има технология на структурно
програмиране, технологии
проектиране на програми с рационални
структура на данните, технология за обектно-ориентирано програмиране,
технология за визуално програмиране.

ТЕХНОЛОГИИ И ПАРАДИГМИ НА ПРОГРАМИРАНЕ

Парадигми на програмиране (концепции,
системи от вярвания) са различни
подходи за писане на програми.
Има четири основни парадигми
които описват повечето от днешните
методи на програмиране: императивни,
приложни, базирани на правила
и обектно-ориентирани.

ТЕХНОЛОГИИ И ПАРАДИГМИ НА ПРОГРАМИРАНЕ

императивна парадигма
Този модел произтича от характеристиките на хардуера
стандартен компютър, който изпълнява инструкции
(команди) последователно.
Основният тип абстракция, използвана в това
парадигма, са алгоритми. Въз основа на него разработен
много операторски ориентирани езици
програмиране.
Програма на такъв език се състои от последователността
оператори, изпълнението на всеки от които води до
промяна на стойността в една или повече клетки от паметта. IN
Най-общо синтаксисът на такъв език е:
Оператор_1:
Оператор_2:
...

ТЕХНОЛОГИИ И ПАРАДИГМИ НА ПРОГРАМИРАНЕ

Приложна парадигма
Тази парадигма се основава на разглеждането
функцията, която изпълнява програмата.
Въпросът е: каква функция е необходима
прилага към първоначалното състояние на машината (от
избор на първоначален набор от променливи и
съчетавайки ги по определен начин) до
получите желания резултат?
Езици, които подчертават този възглед
изчисленията се наричат ​​приложни, или
функционален. Синтаксисът на език като
правилото изглежда така:
Функция_n (... функция_2 (функция_1 (данни))...)

ТЕХНОЛОГИИ И ПАРАДИГМИ НА ПРОГРАМИРАНЕ

Парадигма, базирана на правила
Езици, базирани на тази проверка на парадигмата
наличието на необходимото разрешително условие, а в случай на негов
засичанията извършват подходящото действие.
Изпълнението на програма на подобен език е като
изпълнение на програма, написана на императивен език.
Изявленията обаче не се изпълняват в реда, в който са
които са определени в програмата. Ред за изпълнение
определяне на разрешителни условия. Синтаксисът на такива езици
както следва:
разрешително условие_1 -> действие_1 разрешително
условие_2 -> действие__2
разрешаване на условие_n -> действие _n
Понякога правилата се записват като „ако действие
разрешително условие“, когато действието, което трябва да се извърши
написано отляво.

ТЕХНОЛОГИИ И ПАРАДИГМИ НА ПРОГРАМИРАНЕ

Обектно ориентирана парадигма
Този модел изгражда сложни обекти от данни.
За операции по тях някои
ограничен набор от методи. Създаден
обектите могат да наследяват свойства на по-прости
обекти.
Поради тази способност обектно-ориентираните програми имат висока
ефективността на програмите
написани на императивни езици. Възможност
разработване на различни класове, които използват
ограничен набор от обекти с данни,
осигурява гъвкавост и надеждност, която
характеристика на приложния език.

Излъчване (компилация)
Това е метод за превод на програми, написани на
езици на високо ниво, до еквивалент
използвани програми на машинен език
компютър.
След това интерпретаторът, вграден в
микропроцесорен хардуер,
директно изпълнява преведеното в
програма за машинен код. Предимството на това
метод - много бързо изпълнение на програмата
след приключване на процеса на превод.

ИЗЛЪЧВАНЕ И ИНТЕРПРЕТАЦИЯ НА ПРОГРАМИ

Преводачът е езиков процесор, който
приема програми от някакъв източник
език като вход и като изход
произвежда еквивалентни по своята функционалност
програми, но вече на друга, т.нар
обектен език (който също може да бъде
произволно ниво).
Асемблерът е транслатор, чийто източник
езикът е символично представяне
машинен код (асемблер) и обектен език
е вид машинен език
всеки истински компютър.

ИЗЛЪЧВАНЕ И ИНТЕРПРЕТАЦИЯ НА ПРОГРАМИ

Компилаторът е преводач, за който източникът
е език от високо ниво и неговия обектен език
близо до машинния език на истински компютър. Това
или асемблерен език, или някакъв вариант
машинен език.
Линкерът (линкер) е преводач,
чийто изходен език се състои от програми в
машинен език в преместваема форма и таблици
данни, указващи точките, в които
кодът за преместване трябва да бъде модифициран,
да стане изпълним. Обектният език се състои от
готов за изпълнение на машинни инструкции. задача
линкерът е да създаде един изпълним файл
програма, която използва договорени
адреси, както е показано в таблицата.

ИЗЛЪЧВАНЕ И ИНТЕРПРЕТАЦИЯ НА ПРОГРАМИ

Препроцесорът (макропроцесорът) е
преводач, чийто изходен език
е разширена форма на
език от високо ниво (като Java или
C++), а обектният език - стандартът
версия на този език. обектна програма,
създаден от препроцесора, готов за
превод и изпълнение на обикн
процесори на оригиналния стандарт
език

ИЗЛЪЧВАНЕ И ИНТЕРПРЕТАЦИЯ НА ПРОГРАМИ

Тълкуване (софтуерна симулация)
Това е методът при използване на програмата
(преводач) изпълнен на
хардуерен компютър, създаден
виртуален компютър на машинен език
високо ниво. Интерпретаторът декодира и
изпълнява всеки оператор в програмата
език на високо ниво в съответния
последователности и произвеждат изход
получените данни, определени от това
програма.

ИЗЛЪЧВАНЕ И ИНТЕРПРЕТАЦИЯ НА ПРОГРАМИ

Смесени системи за изпълнение
Първо, програмата се превежда от нейния оригинал
оформя в по-удобна за изпълнение форма.
Това обикновено се прави чрез създаване на множество
самостоятелни части от програмата, т.нар
модули.
По време на фазата на зареждане тези независими части се комбинират
с набор от програми за изпълнение,
прилагане на софтуерна симулация
(тълкувани) операции. Това води до
създаване на изпълнима форма на програма, оператори
които се декодират и изпълняват посредством техните
интерпретация.

СРЕДА И РЕАЛИЗИРАНЕ НА ЕЗИЦИ ЗА ПРОГРАМИРАНЕ

Средата за програмиране е набор
инструменти, използвани в разработката
софтуер.
Този набор обикновено се състои от файл
система, текстов редактор, редактор
връзки и компилатор. Освен това той
може да включва голям брой
инструментални комплекси с
единен потребителски интерфейс

Упражнение

Избройте и опишете различните
среди за програмиране.

Процедурата за разработване на софтуерен модул.

• 1. проучване и проверка на спецификацията на модула, избор на език за програмиране; (т.е. разработчикът, изучавайки спецификацията, установява дали тя му е ясна или не, дали описва модула достатъчно; след това той избира езика за програмиране, на който ще бъде написан модулът, въпреки че езикът за програмиране може да бъде същият за целия PS)
• 2. избор на алгоритъм и структура на данните (тук се оказва дали са известни алгоритми за решаване на проблема и ако е така, използвайте го)
• 3. модулно програмиране (писане на програмен код)
• 4. полиране на текста на модула (редактиране на съществуващи коментари, добавяне на допълнителни коментари за осигуряване на необходимото качество)
• 5. проверка на модула (логиката на модула се проверява, работата му се отстранява)

Прилагат се следните методи за управление на програмния модул:

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

Структурно програмиране.

Най-популярната техника за програмиране днес е структурираното програмиране отгоре надолу.

Структурното програмиране е процесът на разделяне на алгоритъм стъпка по стъпка на все по-малки и по-малки части, за да се получат елементи, за които лесно могат да бъдат написани специфични предписания.

Два принципа на структурното програмиране:

• 1. последователно детайлизиране "отгоре надолу"
• 2. ограничен базов набор от структури за конструиране на алгоритми с всякаква степен на сложност

Изисквания за структурирано програмиране:

• 1. Програмата трябва да бъде изготвена на малки стъпки, така че сложната задача е разделена на доста прости, лесно възприемани части.
• 2. Логиката на програмата трябва да се основава на минимален брой достатъчно основни контролни структури (линейни, разклонени и циклични структури)

Основните свойства и предимства на структурното програмиране:

• 1. Намаляване на сложността на програмите
• 2. възможността за демонстриране на коректността на програмите на различни етапи от решаването на проблема
• 3. видимост на програмите
• 4. лекота на модификация (промяна) на програмите.

Съвременните инструменти за програмиране трябва да осигуряват максимална защита срещу възможни грешки на разработчиците.

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

Основната идея на структурираното програмиране: програмата трябва да бъде набор от блокове, комбинирани в йерархична дървовидна структура, всяка от които има един вход и един изход.

Всяка програма може да бъде изградена само с три основни типа блокове:

• 1. функционален блок - отделен линеен оператор или тяхната последователност;
• 2-ри разклонителен блок - Ако
• 3. обобщен цикъл - конструкция от тип While

От съществено значение е всяка от тези структури да има само един вход и един изход по отношение на контрола. По този начин обобщеният оператор също има само един вход и един изход.

Структурираното програмиране понякога се нарича "програмиране без GO TO". Въпросът тук обаче не е операторът GO TO, а безразборното му използване. Много често, когато се прилага структурно програмиране в някои езици за програмиране, операторът на преход (GO TO) се използва за реализиране на структурни конструкции, без да се намаляват основните предимства на структурното програмиране. Това са "неструктурните" оператори за прескачане, които объркват програмата, особено прескачането към оператор, разположен в текста на модула над (по-рано) оператора за скок, който се изпълнява. Въпреки това, опитът да се избегне операторът за прескачане в някои прости случаи може да доведе до структурирани програми, които са твърде тромави, което не подобрява тяхната яснота и крие опасност от допълнителни грешки в текста на модула. Следователно може да се препоръча да се избягва използването на оператора за прескачане, когато е възможно, но не за сметка на яснотата на програмата.

Полезни случаи на използване на оператора за преход включват излизане от цикъл или процедура при специално условие, което "ранно" прекратява работата на този цикъл или тази процедура, т.е. прекратяване на работата на някаква структурна единица (обобщен оператор) и по този начинсамо локално нарушаване на структурирането на програмата. Големи трудности (и усложняване на структурата) се причиняват от структурното изпълнение на отговора на изключителни (често погрешни) ситуации, тъй като това изисква не само ранно излизане от структурната единица, но и необходимата обработка на тази ситуация (например , издаване на подходяща диагностична информация). Манипулаторът на изключения може да бъде разположен на всяко ниво на програмната структура и може да бъде достъпен от различни по-ниски нива. Съвсем приемливо от технологична гледна точка е следната "неструктурна" реализация на реакцията при извънредни ситуации. Манипулаторите за изключения се поставят в края на една или друга структурна единица, като всеки такъв манипулатор е програмиран така, че след приключване на работата си да излиза от структурната единица, в края на която е поставен. Такъв манипулатор се извиква от оператора за прескачане от дадената структурна единица (включително всяка вложена структурна единица).

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

Дж. Хюз, Дж. Мичтом. Структурен подход към програмирането. - М.: Мир, 1980. - с. 29-71.

В. Турски. Методика на програмиране. - М.: Мир, 1981. - стр. 90-164.

Е.А. Жоголев. Технологични основи на модулното програмиране // Програмиране, 1980, № 2. - стр.44-49.

Р. С. Холт. Структура на компютърните програми: Проучване // Сборници на IEEE, 1975, 63 (6). - стр. 879-893.

Г. Майерс. Надеждност на софтуера. - М.: Мир, 1980. - с. 92-113.

И.Пайл. ADA е език за вградени системи. М .: Финанси и статистика, 1984. - стр. 67-75.

М. Желковец, А. Шоу, Дж. Ганън. Принципи на разработка на софтуер. - М.: Мир, 1982, с. 65-71.

А. Л. Фуксман. Технологични аспекти на създаване на софтуерни системи. М.: Статистика, 1979. - стр. 79-94.

2. Лекция 8. Разработка на софтуерен модул

3. Процедурата за разработване на софтуерен модул. Структурно програмиране и детайлизиране стъпка по стъпка. Концепцията за псевдокод. Управление на софтуерен модул.

5. 8.1. Процедурата за разработване на софтуерен модул.

6. При разработването на софтуерен модул е ​​препоръчително да се придържате към следния ред:

   проучване и проверка на спецификацията на модула, избор на език

   програмиране;

   избор на алгоритъм и структура на данните;

   модулно програмиране;

   полиране на текста на модула;

   проверка на модула;

   модулна компилация.

   Първата стъпка в разработването на софтуерен модул е ​​до голяма степен непрекъснат контрол на структурата на програмата отдолу: чрез изучаване на спецификацията на модула, разработчикът трябва да се увери, че тя е разбираема и достатъчна за него, за да разработи този модул. В края на тази стъпка се избира език за програмиране: въпреки че езикът за програмиране може вече да е предварително дефиниран за целия PS, в някои случаи (ако системата за програмиране го позволява) може да бъде избран друг език, който е по-подходящ за изпълнение на този модул (например асемблер).

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

   На третата стъпка се изгражда текстът на модула на избрания език за програмиране. Изобилието от всякакви детайли, които трябва да се вземат предвид при изпълнението на функциите, посочени в спецификацията на модула, лесно може да доведе до създаването на много объркващ текст, съдържащ много грешки и неточности. Откриването на грешки в такъв модул и извършването на необходимите промени в него може да отнеме много време. Ето защо е много важно да се използва технологично обоснована и практически доказана програмна дисциплина за изграждане на текста на модула. За първи път Дейкстра обърна внимание на това, формулирайки и обосновавайки основните принципи на структурното програмиране. Много от дисциплините по програмиране, които се използват широко в практиката, се основават на тези принципи. Най-често срещаната е дисциплината drill down, която е разгледана подробно в раздели 8.2 и 8.3.

   Следващата стъпка в разработването на модула е свързана с привеждане на текста на модула в окончателен вид в съответствие със спецификацията за качество на PS. При програмиране на модул разработчикът се фокусира върху правилното изпълнение на функциите на модула, оставяйки коментарите недовършени и допускайки някои нарушения на изискванията за стила на програмата. При изпипване на текста на модул, той трябва да редактира коментарите в текста и евентуално да включи допълнителни коментари, за да осигури необходимите качествени примитиви. Със същата цел текстът на програмата се редактира, за да отговаря на стилистичните изисквания.

   Стъпката за проверка на модула е ръчна проверка на вътрешната логика на модула преди неговото отстраняване на грешки (използвайки изпълнението му на компютър), прилага общия принцип, формулиран за обсъжданата технология за програмиране, за необходимостта да се контролират решенията, взети на всеки етап от Развитие на PS (виж лекция 3). Методите за валидиране на модула са обсъдени в раздел 8.4.

   И накрая, последната стъпка от разработването на модул означава завършване на валидирането на модула (с помощта на компилатора) и преминаване към процеса на отстраняване на грешки в модула.

8. 8.2. Структурно програмиране.

9. Когато програмирате модул, трябва да се има предвид, че програмата трябва да бъде разбираема не само за компютър, но и за човек: както разработчика на модула, така и лицата, които проверяват модула, и текстописците, подготвящи тестове за отстраняване на грешки в модул и поддържащите PS, които правят необходимите промени в модула, ще трябва многократно да анализират логиката на модула. В съвременните езици за програмиране има достатъчно инструменти, за да объркате тази логика колкото искате, като по този начин направите модула труден за разбиране от човек и в резултат на това го направите ненадежден или труден за поддръжка. Следователно трябва да се внимава да се изберат подходящи езикови инструменти и да се спазва определена програмна дисциплина. За първи път Дейкстра обърна внимание на това и предложи да се изгради програма като композиция от няколко типа контролни структури (структури), което може значително да увеличи разбираемостта на логиката на програмата. Програмирането, използващо само такива конструкции, се нарича структурно програмиране.

   Основните конструкции на структурираното програмиране са: следване, разклоняване и повторение (виж Фигура 8.1). Компонентите на тези конструкции са обобщени оператори (обработващи възли) S, S1, S2 и условие (предикат) P. Като обобщен оператор може да има или прост оператор на използвания език за програмиране (присвояване, вход, изход, процедура повиквания), или програмен фрагмент, който е композиция от основните управляващи структури на структурираното програмиране. От съществено значение е всяка от тези структури да има само един вход и един изход по отношение на контрола. По този начин обобщеният оператор също има само един вход и един изход.

   Също така е много важно, че тези конструкции вече са математически обекти (което по същество обяснява причината за успеха на структурното програмиране). Доказано е, че за всяка неструктурирана програма е възможно да се конструира функционално еквивалентна (т.е. решаваща същата задача) структурирана програма. За структурираните програми някои свойства могат да бъдат доказани математически, което прави възможно откриването на някои грешки в програмата. На този въпрос ще бъде посветена отделна лекция.

   Структурираното програмиране понякога се нарича "програмиране без GO TO". Въпросът тук обаче не е операторът GO TO, а безразборното му използване. Много често при прилагане на структурно програмиране в някои езици за програмиране (например във FORTRAN) операторът на прехода (GO TO) се използва за внедряване на структурни структури, без да се намаляват основните предимства на структурираното програмиране. Това са "неструктурните" оператори за прескачане, които объркват програмата, особено прескачането към оператор, разположен в текста на модула над (по-рано) оператора за скок, който се изпълнява. Въпреки това, опитът да се избегне операторът за прескачане в някои прости случаи може да доведе до структурирани програми, които са твърде тромави, което не подобрява тяхната яснота и крие опасност от допълнителни грешки в текста на модула. Следователно може да се препоръча да се избягва използването на оператора за прескачане, когато е възможно, но не за сметка на яснотата на програмата.

   Полезни случаи на използване на оператора за преход включват излизане от цикъл или процедура при специално условие, което "ранно" прекратява работата на този цикъл или тази процедура, т.е. прекратяване на работата на някаква структурна единица (обобщен оператор) и по този начин само локално нарушаване на структурността на програмата. Големи трудности (и усложняване на структурата) са причинени от структурното изпълнение на отговора на изключителни (често погрешни) ситуации, тъй като това изисква не само ранно излизане от структурната единица, но и необходимата обработка (изключване) на тази ситуация (например издаване на подходяща диагностична информация). Манипулаторът на изключения може да бъде разположен на всяко ниво на програмната структура и може да бъде достъпен от различни по-ниски нива. Съвсем приемливо от технологична гледна точка е следната "неструктурна" реализация на реакцията при извънредни ситуации. Манипулаторите за изключения се поставят в края на една или друга структурна единица, като всеки такъв манипулатор е програмиран така, че след приключване на работата си да излиза от структурната единица, в края на която е поставен. Такъв манипулатор се извиква от оператора за прескачане от дадената структурна единица (включително всяка вложена структурна единица).

11. 8.3. Стъпка по стъпка детайлизация и концепцията за псевдокод.

12. Структурираното програмиране дава препоръки за това какъв трябва да бъде текстът на модула. Възниква въпросът как трябва да действа програмистът, за да конструира такъв текст. Понякога програмирането на един модул започва с изграждането на неговата блокова схема, която описва в общи линии логиката на неговата работа. Съвременните технологии за програмиране обаче не препоръчват това. Въпреки че блок-схемите предоставят много визуално представяне на логиката на модул, когато са кодирани на език за програмиране, възниква много специфичен източник на грешки: картографирането на по същество двуизмерни структури, като блок-схеми, върху линеен текст, представящ модул, съдържа опасността от изкривяване на логиката на модула, освен това е психологически доста трудно да се поддържа високо ниво на внимание при повторния му преглед. Изключение може да бъде случаят, когато се използва графичен редактор за изграждане на блок-схеми и те са формализирани така, че от тях автоматично да се генерира текст на език за програмиране (както например това може да се направи в P-технологията).

    Като основен метод за конструиране на модулен текст, съвременната технология за програмиране препоръчва детайлизиране стъпка по стъпка. Същността на този метод е да се раздели процесът на разработване на текста на модула на няколко стъпки. Първата стъпка описва обща схемаработата на модула във видима линейна текстова форма (т.е. използвайки много големи понятия), като това описание не е напълно формализирано и е фокусирано върху човешкото възприятие. На всяка следваща стъпка една от концепциите (ще я наречем усъвършенствана) се усъвършенства и детайлизира, която се използва (като правило не е формализирана) във всяко описание, разработено на една от предходните стъпки. В резултат на тази стъпка се създава описание на избраната концепция, която се усъвършенства, или по отношение на основния език за програмиране (т.е. модулът, избран за представяне), или в същата форма, както в първата стъпка, като се използват нови концепции, които се усъвършенстват . Този процес приключва, когато всички концепции, които се усъвършенстват, в крайна сметка се изразят на основния език за програмиране. Последната стъпка е да се получи текстът на модула на основния език за програмиране чрез замяна на всички появявания на усъвършенстваните концепции с техните специфицирани описания и изразяване на всички появявания на структурни програмни конструкции, използващи този език за програмиране.

    Стъпка по стъпка разработката включва използването на частично формализиран език за представяне на споменатите описания, който се нарича псевдокод. Този език позволява използването на всички структурирани програмни конструкции, които са формализирани, заедно с неформални естествени езикови фрагменти за представяне на общи изрази и условия. Съответстващите фрагменти в основния език за програмиране също могат да бъдат зададени като обобщени оператори и условия.

    Описанието на главата в псевдокод може да се счита за външен дизайн на модула в основния език за програмиране, който

    началото на модула на основния език, т.е. първото изречение или заглавие (спецификация) на този модул;

    раздел (набор) от описания на базовия език, а вместо описания на процедури и функции - само техния външен дизайн;

    неформално обозначаване на последователността от изрази на тялото на модула като един обобщен израз (вижте по-долу), както и неформално обозначаване на последователността от изрази на тялото на всяка процедура или описание на функция като един обобщен израз;

    последното изречение (край) на модула на основния език.

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

    Неформалното обозначение на обобщен оператор в псевдокод се прави на естествен език чрез произволно изречение, което разкрива съдържанието му в общи линии. Единственото формално изискване за дизайна на такова обозначение е следното: това изречение трябва да заема изцяло един или повече графични (печатни) реда и да завършва с точка.

    За всеки неформален обобщен оператор трябва да се създаде отделно описание, което изразява логиката на неговата работа (подробно съдържанието му), като се използва съставът на основните структури на структурното програмиране и други обобщени оператори. Заглавието на такова описание трябва да бъде неофициалното обозначение на обобщения оператор, който се прецизира. Основните конструкции на структурираното програмиране могат да бъдат представени по следния начин (виж Фигура 8.2). Тук условието може или да бъде изрично указано в основния език за програмиране като булев израз, или неофициално представено на естествен език чрез някакъв фрагмент, който очертава значението на това условие. В последния случай трябва да се създаде отделно описание, в което да се описва подробно това условие, като се посочва обозначението на това условие (фрагмент на естествен език) като заглавие.

13. Ориз. 8.2. Основни конструкции на структурното програмиране в псевдокод.

14. Ориз. 8.3. Частни случаи на оператора на прехода като обобщен оператор.

    Като обобщен оператор в псевдокод можете да използвате горните специални случаи на оператора за преход (вижте фиг. 8.3). Последователността от манипулатори на изключения (изключения) е посочена в края на описанието на модул или процедура (функция). Всеки такъв манипулатор изглежда така:

    EXCEPTION име_на изключение

    общ_оператор

    ВСИЧКИ ИЗКЛЮЧЕНИЯ

    Разликата между манипулатор на изключения и процедура без параметри е следната: след като процедурата бъде изпълнена, контролът се връща към оператора, следващ извикването към него, а след като изключението бъде изпълнено, контролът се връща към оператора, следващ извикването на модула или процедура (функция), в края на която (който) се поставя това изключение.

    Препоръчително е на всяка стъпка от детайлизирането да се създаде достатъчно смислено описание, но лесно видимо (визуално), така че да бъде поставено на една страница текст. По правило това означава, че такова описание трябва да бъде композиция от пет или шест структурирани програмни конструкции. Също така се препоръчва да се поставят вложени структури с изместване надясно с няколко позиции (виж Фиг. 8.4). В резултат на това можете да получите описание на логиката на работа по отношение на видимостта, която е доста конкурентна на блок-схемите, но има значително предимство - линейността на описанието се запазва.

15. ИЗТРИЙ ВЪВ ФАЙЛОВИТЕ ЗАПИСИ ПРЕДИ ПЪРВОТО, ПОДХОДЯЩИ ЗА КОМПЛЕКТА ФИЛТЪР: ЗАДАВА НАЧАЛОТО НА ФАЙЛА. АКО ДРУГ ЗАПИС ГО УДОВОЛЯВА ФИЛТРИРАНЕ КЪМ ИЗТРИЙТЕ ДРУГ ЗАПИС ОТ ФАЙЛА. ВСИЧКИ АКО ЧАО АКО ВХОДЪТ НЕ Е ИЗТРИТ ТОГАВА НАПИШЕТЕ „ЗАПИСИТЕ НЕ ИЗТРИТИ“. ОТПЕЧАТАЙТЕ „ПРЕМАХНАТО n ЗАПИСА“. ВСИЧКИ АКО

Ориз. 8.4. Пример за една стъпка на детайлизиране в псевдокод.

16. Идеята за детайлизиране стъпка по стъпка понякога се приписва на Дейкстра. Дейкстра обаче предлага принципно различен метод за конструиране на модулния текст, който ни се струва по-задълбочен и по-обещаващ. Първо, заедно с усъвършенстването на операторите, той предложи постепенно (стъпка по стъпка) да се прецизират (подробят) използваните структури от данни. Второ, на всяка стъпка той предложи да се създаде определена виртуална машина за детайлизиране и, в нейните условия, подробно описване на всички усъвършенствани концепции, за които тази машина позволява да се направи това. По този начин, Dijkstra предложи по същество детайлизиране чрез хоризонтални слоеве, което е прехвърлянето на неговата идея за слоести системи (вижте Лекция 6) на нивото на модулно развитие. Този метод на разработване на модули в момента се поддържа от езикови пакети ADA и инструменти за обектно-ориентирано програмиране.

18. 8.4. Управление на софтуерен модул.

19. Прилагат се следните методи за управление на програмния модул:

    статична проверка на текст на модула;

    проследяване от край до край;

    доказателство за свойствата на софтуерния модул.

    При статична проверка на текста на модул, този текст се чете от началото до края, за да се открият грешки в модула. Обикновено, в допълнение към разработчика на модула, за такава проверка участват още един или дори няколко програмисти. Препоръчва се грешките, открити по време на такава проверка, да бъдат коригирани не веднага, а след завършване на четенето на текста на модула.

    Проследяването от край до край е един от видовете динамично управление на модула. Той също така включва няколко програмисти, които ръчно преминават през изпълнението на модула (изявление по изявление в последователността, която следва от логиката на модула) на определен набор от тестове.

    Следващата лекция е посветена на доказването на свойствата на програмите. Тук трябва само да се отбележи, че този метод все още се използва много рядко.

21. Литература към лекция 8.

22. 8.2. Е. Дейкстра. Бележки за структурираното програмиране// W. Dahl, E. Dijkstra, K. Hoor. Структурно програмиране. - М.: Мир, 1975. - С. 24-97.

    8.3. Н. Вирт. Систематично програмиране. - М.: Мир, 1977. - С. 94-164.

24. Лекция 9

25. Концепцията за програмна обосновка. Формализация на свойствата на програмата, триада на Хоор. Правила за задаване на свойствата на оператор за присвояване, условен оператор и съставен оператор. Правила за установяване на свойствата на оператор на цикъл, концепцията за инвариант на цикъл. Прекратяване на изпълнението на програмата.

27. 9.1. Програмни обосновки. Формализация на свойствата на програмата.

28. За да подобрите надеждността на софтуера, е много полезно да предоставите на програмите допълнителна информация, с помощта на която можете значително да повишите нивото на контрол на софтуера. Такава информация може да бъде дадена под формата на неофициални или формализирани изявления, които са свързани с различни програмни фрагменти. Такива твърдения ще наричаме програмни оправдания. Неформализираните обосновки на програмите могат например да обяснят мотивите за вземане на определени решения, което може значително да улесни търсенето и коригирането на грешки, както и изучаването на програмите по време на тяхната поддръжка. Формализираните обосновки позволяват да се докажат някои свойства на програмите както ръчно, така и да се управляват (задават) автоматично.

    Една от използваните в момента концепции за формални обосновки за програми е използването на така наречените триади на Хор. Нека S е някакъв обобщен оператор над информационната среда IS, P и Q - някои предикати (изявления) над тази среда. Тогава нотацията (P)S(Q) се нарича триада на Хоор, в която предикатът P се нарича предусловие, а предикатът Q се нарича постусловие по отношение на оператора S. Операторът (по-специално програмата) Твърди се, че S има свойството (P)S(Q) , ако всеки път, когато предикатът P е верен преди S да бъде изпълнен, предикатът Q е верен след S да бъде изпълнен.

    Прости примери за свойства на програмата:

    (9.1) (n=0) n:=n+1 (n=1),

    (9.2) (н

    (9.3) (н

    (9.4) (n>0) p:=1; m:=1;

    WHILE m /= n НАПРАВЕТЕ

29. ЧАО

    За да докажем свойството на програмата S, използваме свойствата на простите оператори на езика за програмиране (тук се ограничаваме до празния оператор и оператора за присвояване) и свойствата на управляващите структури (композиции), с които програмата е изградена от прости оператори (тук се ограничаваме до трите основни състава на структурното програмиране, вижте Лекция 8). Тези свойства обикновено се наричат ​​правила за проверка на програмата.

31. 9.2. Свойства на простите оператори.

32. За празен оператор,

    Теорема 9.1. Нека P е предикат над информационната среда. Тогава свойство (P)(P) е в сила.

    Доказателството на тази теорема е очевидно: празният оператор не променя състоянието на информационната среда (в съответствие с нейната семантика), така че неговото предварително условие остава вярно след изпълнението му.

    За оператора за присвояване,

    Теорема 9.2. Нека информационната среда IS се състои от променливата X и останалата част от информационната среда RIS:

33. След това собствеността

    (Q(F(X, RIS), RIS)) X:= F(X, RIS) (Q(X, RIS)) ,

    където F(X, RIS) е някаква еднозначна функция, Q е предикат.

    Доказателство. Нека предикатът Q(F(X0, RIS0), RIS0) е верен преди изпълнението на оператора за присвояване, където (X0, RIS0) е произволно състояние на информационната среда IS, тогава след изпълнението на оператора за присвояване предикатът Q(X, RIS) ще бъде вярно, така че как X ще получи стойността F(X0, RIS0) и състоянието на RIS не се променя от дадения оператор за присвояване и следователно след изпълнението на този оператор за присвояване в този случай

    Q(X, RIS)=Q(F(X0, RIS0), RIS0).

    По силата на произволността на избора на състоянието на информационната среда теоремата е доказана.

    Пример за свойство на оператор за присвояване е Пример 9.1.

35. 9.3. Свойства на основните структури на структурното програмиране.

36. Помислете сега за свойствата на основните структури на структурираното програмиране: следване, разклоняване и повторение.

    Свойствата на сукцесията се изразяват в следното

    Теорема 9.3. Нека P, Q и R са предикати над информационната среда, а S1 и S2 са обобщени оператори, имащи съответно свойствата

    (P)S(Q) и (Q)S2(R).

    След това за съставния оператор

    S1; S2<.blockquote>

    има имот

    (P) S1; S2(R).

    Доказателство. Нека за дадено състояние на информационната среда преди изпълнението на оператора S1 е верен предикатът P. Тогава, по силата на свойството на оператора S1, след изпълнението му, предикатът Q ще бъде верен. чрез изпълнение на оператора S2. Следователно, след изпълнението на оператора S2, по силата на своето свойство, предикатът R ще бъде верен и тъй като операторът S2 завършва изпълнението на съставния оператор (в съответствие с неговата семантика), предикатът R ще бъде верен след изпълнението на това съставно твърдение, което трябваше да бъде доказано.

    Например, ако свойствата (9.2) и (9.3) са валидни, тогава

    място и имущество

    (н

    Свойството на разклоняване се изразява в следното

    Теорема 9.4. Нека P, Q и R са предикати над информационната среда, а S1 и S2 са обобщени оператори, имащи съответно свойствата

    (P,Q)S1(R) и (`P,Q)S2(R).

    След това за условния оператор

    IF P THEN S1 ELSE S2 ALL IF

    има имот

    (Q) IF P THEN S1 ELSE S2 ALL IF (R) .

    Доказателство. Нека предикатът Q е верен за някакво състояние на информационната среда преди изпълнението на условния оператор.Ако предикатът P също е верен, тогава изпълнението на условния оператор в съответствие с неговата семантика се свежда до изпълнението на оператора S1 . По силата на свойството на оператора S1, след неговото изпълнение (и в този случай след изпълнението на условния оператор), предикатът R ще бъде верен.Ако обаче преди изпълнението на условния оператор, предикатът P е невярно (и Q все още е вярно), тогава изпълнението на условния оператор в съответствие с неговата семантика се свежда до изпълнението на оператора S2. По силата на свойството на оператора S2, след изпълнението му (и в този случай след изпълнението на условния оператор) ще бъде верен предикатът R. Така теоремата е напълно доказана.

    Преди да преминете към свойството на конструкцията на повторение, трябва да се отбележи, че е полезно за по-нататъшно

    Теорема 9.5. Нека P, Q, P1 и Q1 са предикати над информационната среда, за която се отнасят последиците

    P1=>P и Q=>Q1,

    и нека свойство (P)S(Q) е валидно за оператора S. Тогава свойство (P1)S(Q1) е валидно.

    Тази теорема се нарича още теорема за отслабване.

    Доказателство. Нека предикатът P1 е верен за някакво състояние на информационната среда преди изпълнението на оператора S. Тогава предикатът P също ще бъде верен (поради импликацията P1=>P). Следователно, по силата на свойството на оператора S, след неговото изпълнение, предикатът Q ще бъде верен, а оттам и предикатът Q1 (по силата на импликацията Q=>Q1). Така теоремата е доказана.

    Свойството на повторение се изразява със следното

    Теорема 9.6. Нека I, P, Q и R са предикати над информационната среда, за която са последиците

    P=>I и (I,`Q)=>R ,

    и нека S е обобщен оператор със свойството (I)S(I).

    След това за оператора на цикъла

    BYE Q DO S ALL BYE

    има имот

    (P) BYE Q DO S ALL BYE (R) .

    Предикатът I се нарича инвариант на оператора за цикъл.

    Доказателство. За да се докаже тази теорема, е достатъчно да се докаже свойството

    (I) BYE Q DO S ALL BYE (I,`Q)

    (по теорема 9.5 въз основа на импликациите в условията на тази теорема). Нека предикатът I е верен за някакво състояние на информационната среда преди изпълнението на оператора на цикъла.Ако в този случай предикатът Q е фалшив, тогава операторът на цикъла ще бъде еквивалентен на празен оператор (в съответствие с неговата семантика) и, по силата на теорема 9.1, след изпълнението на оператора на цикъла, твърдението (I ,`Q). Ако предикатът Q е верен преди изпълнението на оператора за цикъл, тогава операторът за цикъл, в съответствие с неговата семантика, може да бъде представен като съставен оператор S; BYE Q DO S ALL BYE

    По силата на свойството на оператора S след неговото изпълнение предикатът I ще бъде верен и възниква началната ситуация за доказване на свойството на оператора на цикъла: предикатът I е верен преди изпълнението на оператора на цикъла, но за различно (променено) състояние на информационната среда (за което предикатът Q може да бъде или true, или false). Ако изпълнението на оператора за цикъл приключи, тогава чрез прилагане на метода на математическата индукция, в краен брой стъпки, ще стигнем до ситуация, в която операторът (I,`Q) ще бъде верен преди неговото изпълнение. И в този случай, както беше доказано по-горе, това твърдение ще бъде вярно дори след изпълнението на оператора на цикъла. Теоремата е доказана.

    Например, за оператора на цикъл от пример (9.4), има място свойството

    m:= m+1; p:= p*m

    ВСИЧКИ ОЩЕ (p= n.!}

    Това следва от теорема 9.6, тъй като инвариантът на този оператор на цикъл е предикатът p=m! и импликациите (n>0, p=1, m=1) => p=m! и (p=m!, m=n) => p=n!

38. 9.4. Прекратяване на изпълнението на програмата.

39. Едно от свойствата на програмата, което може да ни интересува, за да избегнем евентуални грешки в PS, е нейното прекратяване, т.е. липсата на цикличност в него за определени първоначални данни. В структурираните програми, които разгледахме, само конструкцията за повторение може да бъде източник на зацикляне. Следователно, за да се докаже прекратяването на програма, е достатъчно да можете да докажете прекратяването на оператор за цикъл. Следното е полезно за това.

    Теорема 9.7. Нека F е целочислена функция, която зависи от състоянието на информационната среда и отговаря на следните условия:

    (1) ако предикатът Q е верен за дадено състояние на информационната среда, то неговата стойност е положителна;

    (2) намалява, когато състоянието на информационната среда се промени в резултат на изпълнението на оператора S.

    След това изпълнението на оператора за цикъл

    WHILE Q ПРАВИ ВСИЧКО WHILE завършва.

    Доказателство. Нека е състоянието на информационната среда преди изпълнението на командата за цикъл и нека F(is)=k. Ако предикатът Q(is) е фалшив, тогава изпълнението на оператора за цикъл приключва. Ако Q(is) е вярно, тогава по предположението на теоремата k>0. В този случай операторът S ще бъде изпълнен един или повече пъти. След всяко изпълнение на оператора S, според условието на теоремата, стойността на функцията F намалява и тъй като преди изпълнението на оператора S, предикатът Q трябва да е верен (според семантиката на оператора на цикъла) , стойността на функцията F в този момент трябва да е положителна (според условието на теоремата). Следователно, поради интегралността на функцията F, операторът S в този цикъл може да бъде изпълнен повече от k пъти. Теоремата е доказана.

    Например, за примера на оператора на цикъла, разгледан по-горе, условията на теорема 9.7 са изпълнени от функцията f(n, m)= n-m. Тъй като преди изпълнението на оператора за цикъл m=1, тялото на този цикъл ще бъде изпълнено (n-1) пъти, т.е. този оператор за цикъл завършва.

41. 9.5. Пример за доказателство за свойство на програма.

42. Въз основа на доказаните правила за проверка на програмата е възможно да се докажат свойствата на програми, състоящи се от оператори за присвояване и празни оператори и използвайки три основни композиции на структурно програмиране. За да направите това, анализирайки структурата на програмата и използвайки нейните пред- и пост-условия, е необходимо да приложите подходящо правило за проверка на всяка стъпка от анализа. В случай на повтаряща се композиция ще е необходимо да се избере подходящ инвариант на цикъла.

    Като пример нека докажем свойството (9.4). Това доказателство ще се състои от следните стъпки.

    (Етап 1). n>0 => (n>0, p - произволен, m - произволен).

    (Стъпка 2). Възниква

    (n>0, p - произволен, m - произволен) p:=1 (n>0, p=1, m - произволен).

    По теорема 9.2.

    (Стъпка 3). Възниква

    (n>0, p=1, m - всякакви) m:=1 (n>0, p=1, m=1).

    По теорема 9.2.

    (Стъпка 4). Възниква

    (n>0, p - произволен, m - произволен) p:=1; m:=1 (n>0, p=1, m=1).

    По теорема 9.3, поради резултатите от стъпки 2 и 3.

    Нека докажем, че предикатът p=m! е цикъл инвариант, т.е. (p=m m:=m+1; p:=p*m {p=m!}.!}

    (Стъпка 5). Провежда се (p=m m:=m+1 {p=(m-1)!}.!}

    По теорема 9.2, ако представим предварителното условие във формата (p=((m+1)-1).!}

    (Стъпка 6). Провежда се (p=(m-1) p:=p*m {p=m!}.!}

    По теорема 9.2, ако представим предварителното условие във формата (p*m=m.!}

    (Стъпка 7). Има инвариантен цикъл

    (p=m m:=m+1; p:=p*m {p=m!}.!}

    По теорема 9.3, поради резултатите от стъпки 5 и 6.

    (Стъпка 8). Възниква

    (n>0, p=1, m=1) WHILE m /= n DO

    m:= m+1; p:= p*m

    ВСИЧКИ ОЩЕ (p= n.!}

    По теорема 9.6, по силата на резултата от стъпка 7 и като се има предвид, че (n>0, p=1, m= 1)=>p=m!; (p=m!, m=n)=>p=n!.

    (Стъпка 9). Възниква

    (n>0, p - произволен, m - произволен) p:=1; m:=1;

    WHILE m /= n НАПРАВЕТЕ

    m:= m+1; p:= p*m

    ВСИЧКИ ОЩЕ (p= n.!}

    По теорема 9.3, поради резултатите от стъпки 3 и 8.

    (Стъпка 10). Свойството (9.4) е в сила от теорема 9.5 поради резултатите от стъпки 1 и 9.

44. Литература към лекция 9.

45. 9.1. S.A. Абрамов. Елементи на програмирането. - М.: Наука, 1982. С. 85-94.

    9.2. М. Желковец, А. Шоу, Дж. Ганън. Принципи на разработка на софтуер. - М.: Мир, 1982. С. 98-105.

47. Лекция 10

48. Основни понятия. Стратегия за проектиране на тестове. Заповеди за отстраняване на грешки. Офлайн отстраняване на грешки и тестване на софтуерен модул. Цялостно отстраняване на грешки и тестване на софтуер.

50. 10.1. Основни понятия.

51. Отстраняването на грешки в PS е дейност, насочена към откриване и коригиране на грешки в PS, използвайки процесите на изпълнение на неговите програми. PS тестването е процесът на изпълнение на неговите програми върху определен набор от данни, за които резултатът от приложението е известен предварително или са известни правилата за поведение на тези програми. Посоченият набор от данни се нарича тест или само тест. По този начин отстраняването на грешки може да бъде представено като многократно повторение на три процеса: тестване, в резултат на което може да се установи наличието на грешка в PS, търсене на мястото на грешка в програмите и документацията на PS и редактиране на програми и документация с цел отстраняване на откритата грешка. С други думи:

    Отстраняване на грешки = тестване + намиране на грешки + редактиране.

    В чуждестранната литература отстраняването на грешки често се разбира само като процес на намиране и коригиране на грешки (без тестване), чието наличие се установява по време на тестване. Понякога тестването и отстраняването на грешки се считат за синоними. У нас понятието отстраняване на грешки обикновено включва тестване, така че ще следваме установената традиция. Съвместното разглеждане на тези процеси в тази лекция обаче прави посоченото несъответствие не толкова съществено. Все пак трябва да се отбележи, че тестването се използва и като част от процеса на сертифициране на PS (вижте лекция 14).

52. 10.2. Принципи и видове отстраняване на грешки.

53. Успехът на отстраняването на грешки до голяма степен се определя от рационалната организация на тестването. По време на отстраняването на грешки се откриват и отстраняват главно онези грешки, чието наличие в PS се установява по време на тестването. Както вече беше отбелязано, тестването не може да докаже правилността на PS, в най-добрия случай може да демонстрира наличието на грешка в него. С други думи, не може да се гарантира, че чрез тестване на софтуера с практически осъществим набор от тестове е възможно да се установи наличието на всяка грешка, присъстваща в софтуера. Следователно възникват два проблема. Първо, подгответе такъв набор от тестове и приложете PS към тях, за да откриете възможно най-много грешки в него. Въпреки това, колкото по-дълго продължава процесът на тестване (и отстраняването на грешки като цяло), толкова по-висока става цената на софтуера. Оттук и втората задача: да се определи моментът, в който отстраняването на грешки на PS (или отделните му компоненти) е завършено. Знак за възможността за край на отстраняването на грешки е пълнотата на покритието от тестовете, преминали през PS (т.е. тестовете, към които се прилага PS) на много различни ситуации, които възникват по време на изпълнението на PS програмите, и относително рядка проява на грешки в PS в последния сегмент от процеса на тестване. Последната се определя в съответствие с необходимата степен на надеждност на ПС, посочена в спецификацията на нейното качество.

    За да оптимизирате тестовия пакет, т.е. за да се подготви такъв набор от тестове, който да позволи за даден брой от тях (или за даден интервал от време, отделен за тестване) да се открият по-голям брой грешки, е необходимо, първо, този набор да се планира предварително и, второ , за използване на рационална стратегия за планиране (дизайн) тестове. Проектирането на теста може да започне веднага след завършване на етапа външно описание PS. Съществуват различни подходи за разработване на стратегия за проектиране на тестове, които условно могат да бъдат поставени графично (виж Фигура 9.1) между следните два крайни подхода. Крайният ляв подход е, че тестовете са проектирани само въз основа на изучаване на спецификациите на PS (външно описание, описание на архитектурата и спецификация на модула). По никакъв начин не се отчита структурата на модулите, т.е. те се третират като черни кутии. Всъщност този подход изисква пълно изброяване на всички набори от входни данни, тъй като при използване само на част от тези набори като тестове, някои раздели на PS програмите може да не работят на нито един тест и следователно грешките, съдържащи се в тях, няма да се появи. Тестването на PS с пълен набор от набори от входни данни обаче е практически невъзможно. Правилният екстремен подход е, че тестовете са проектирани въз основа на изучаване на програмни текстове, за да се тестват всички начини, по които се изпълнява всяка PS програма. Ако вземем предвид наличието на цикли с променлив брой повторения в програмите, тогава може да има и изключително голям брой различни начини за изпълнение на PS програми, така че тестването им също ще бъде практически невъзможно.

    Оптималната стратегия за дизайн на теста се намира в интервала между тези крайни подходи, но по-близо до ляво. Това включва проектиране на значителна част от тестовете според спецификациите, базирани на принципите: за всяка използвана функция или характеристика - поне един тест, за всяка област и за всяка граница на промяна във всяка входна променлива - поне един тест, за всяка специален случай или за всяко изключение, посочено в спецификациите - поне един тест. Но също така изисква дизайн на някои тестове и текстове на програми, базирани на принципа (най-малко): всяка команда на всяка PS програма трябва да работи върху поне един тест.

    Оптималната стратегия за дизайн на теста може да бъде определена въз основа на следния принцип: за всеки програмен документ (включително програмни текстове), който е част от PS, трябва да проектират свои собствени тестове, за да идентифицират грешките в него. Във всеки случай този принцип трябва да се спазва в съответствие с дефиницията на софтуера и съдържанието на понятието технология за програмиране като технология за разработване на надежден софтуер (виж лекция 1). В тази връзка Майерс дори дефинира различни видове тестване, в зависимост от вида на програмния документ, на базата на който се изграждат тестовете. В нашата страна има два основни вида отстраняване на грешки (включително тестване): самостоятелно и комплексно отстраняване на грешки. Офлайн отстраняването на грешки означава тестване само на част от програмата, включена в PS, с търсене и коригиране на грешки, записани по време на тестването. Това всъщност включва отстраняване на грешки на всеки модул и отстраняване на грешки при сдвояване на модули. Цялостното отстраняване на грешки означава тестване на PS като цяло с търсене и коригиране на грешки, записани по време на тестването във всички документи (включително текстове на PS програми), свързани с PS като цяло. Такива документи включват дефинирането на изискванията за PS, спецификацията на качеството на PS, функционалната спецификация на PS, описанието на архитектурата на PS и текстовете на програмите за PS.

55. 10.3. Заповеди за отстраняване на грешки.

56. Този раздел предоставя общи насоки за организиране на отстраняване на грешки. Но първо трябва да се отбележи един феномен, който потвърждава важността на предотвратяването на грешки в предишни етапи на разработка: с нарастването на броя на откритите и коригирани грешки в софтуера, относителната вероятност за съществуване на неоткрити грешки в него също се увеличава. Това се обяснява с факта, че с увеличаването на броя на грешките, открити в PS, нашето разбиране за общия брой грешки, направени в него, и следователно, до известна степен, броят на грешките, които все още не са открити, също се усъвършенства. Това явление потвърждава важността на ранното откриване на грешки и необходимостта от внимателен контрол на решенията, взети на всеки етап от разработката на софтуера.

    Заповед 1. Считайте тестването за ключова задача на разработката на софтуер, поверете го на най-квалифицираните и надарени програмисти; не е желателно да тествате собствената си програма.

    Заповед 2. Добър тест е този, който има голяма вероятност да открие грешка, а не този, който демонстрира правилната работа на програмата.

    Заповед 3. Подгответе тестове както за верни, така и за неверни данни.

    Заповед 4. Избягвайте невъзпроизводими тестове, документирайте преминаването им през компютъра; проучете подробно резултатите от всеки тест.

    Заповед 5. Свържете всеки модул към програмата само веднъж; никога не променяйте програма, за да улесните тестването.

    Заповед 6. Пропуснете отново всички тестове, свързани с проверка на работата на която и да е PS програма или нейното взаимодействие с други програми, ако са направени промени в нея (например в резултат на коригиране на грешка).

58. 10.4. Офлайн отстраняване на грешки в модула.

59. При офлайн отстраняване на грешки всеки модул всъщност се тества в някаква програмна среда, освен ако програмата, която се отстранява, се състои само от един модул. Тази среда се състои от други модули, някои от които са модули на дебъгваната програма, които вече са дебъгвани, а някои от които са модули, които контролират отстраняването на грешки (модули за отстраняване на грешки, вижте по-долу). По този начин, по време на офлайн отстраняване на грешки, винаги се тества някаква програма, създадена специално за тестване на модула, който се отстранява. Тази програма само частично съвпада с програмата, в която се отстраняват грешки, освен когато последният модул на програмата, в която се отстраняват грешки, се отстранява. С напредването на отстраняването на грешки в програмата все по-голяма част от средата на следващия модул, който се отстранява, ще бъде вече отстранени модули на тази програма, а при отстраняване на грешки в последния модул на тази програма, средата на модула, който се отстранява, ще се състои изцяло от всички други (вече дебъгвани) модули на програмата, която се дебъгва (без никакви) модули за дебъгване.модули, т.е. в този случай ще бъде тествана самата дебъгвана програма. Този процес на изграждане на дебъгвана програма с дебъгвани и дебъгвани модули се нарича програмна интеграция.

    Модулите за отстраняване на грешки, включени в средата на модула, който се отстранява, зависят от реда, в който се отстраняват грешки в модулите на тази програма, кой модул се отстранява и евентуално кой тест ще бъде пропуснат.

    При тестване отдолу нагоре (вижте Глава 7), тази среда винаги ще съдържа само един модул за отстраняване на грешки (освен когато последният модул на програмата, която се отстранява, се отстранява), който ще бъде главата на програмата, която се тества, и който се нарича капитанът (или шофьорът). Водещият модул за отстраняване на грешки подготвя информационната среда за тестване на модула, който се отстранява (т.е. формира своето състояние, необходимо за тестване на този модул, по-специално може да въведе някои тестови данни), извиква модула, който се отстранява, и след работата му е завършен, издава необходимите съобщения. При отстраняване на грешки на един модул могат да бъдат компилирани различни главни модули за отстраняване на грешки за различни тестове.

    При низходящо тестване (вижте Глава 7), средата на модула, който се отстранява, съдържа, като модули за отстраняване на грешки, симулатори на всички модули, които могат да бъдат достъпни от модула, който се отстранява, както и симулатори на тези модули, които могат да бъдат достъпни от отстранения модули на програмата, които се отстраняват (включени в тази среда), но които все още не са отстранени. Някои от тези симулатори може да се променят за различни тестове при отстраняване на грешки в един модул.

    Всъщност средата на модула, който се отстранява, може в много случаи да съдържа и двата вида модули за отстраняване на грешки поради следните причини. Както възходящото, така и низходящото тестване имат своите предимства и недостатъци.

    Ползите от тестването отдолу нагоре включват

    лекота на подготовка на тестове и

    способността за пълно изпълнение на плана за тестване на модула.

    Това се дължи на факта, че тестовото състояние на информационната среда се подготвя непосредствено преди извикването на модула, който се отстранява (водещ модул за отстраняване на грешки). Недостатъците на тестването отдолу нагоре са следните характеристики:

    тестовите данни се подготвят по правило не във формата, предназначена за потребителя (освен когато последният, главен, модул на програмата, която се отстранява, е отстранена от грешки);

    голямо количество програмиране за отстраняване на грешки (когато дебъгвате един модул, често трябва да композирате много водещи модули за отстраняване на грешки за различни тестове);

    необходимостта от специално тестване на интерфейсните модули.

    Предимствата на тестването отгоре надолу включват следните характеристики:

    повечето тестове се изготвят във форма, предназначена за потребителя;

    в много случаи относително малко количество програмиране за отстраняване на грешки (симулаторите на модули, като правило, са много прости и всеки е подходящ за голям брой, често за всички тестове);

    няма нужда да тествате сдвояването на модулите.

    Недостатъкът на тестването отгоре надолу е, че тестовото състояние на информационната среда преди достъп до модула, който се дебъгва, се подготвя косвено - това е резултат от прилагане на вече дебъгвани модули за тестови данни или данни, издадени от симулатори. Това, първо, затруднява подготовката на тестове, изисква висококвалифициран изпълнител на тестове, и второ, затруднява или дори невъзможно прилагането на пълен тестов план за дебъгвания модул. Този недостатък понякога принуждава разработчиците да използват тестване отдолу нагоре дори в случай на разработка отгоре надолу. По-често обаче се използва някаква модификация на тестване отгоре надолу или някаква комбинация от тестване отгоре надолу и отдолу нагоре.

    Въз основа на факта, че тестването отгоре надолу е по принцип за предпочитане, нека се спрем на техники, които ни позволяват да преодолеем тези трудности до известна степен. На първо място, необходимо е да се организира отстраняването на грешки на програмата по такъв начин, че модулите, които извършват въвеждане на данни, да бъдат отстранени грешки възможно най-скоро - тогава тестовите данни могат да бъдат подготвени във форма, предназначена за потребителя, което значително ще опростете подготовката на следващите тестове. Този вход по никакъв начин не винаги се извършва в главния модул, така че първо трябва да отстраните грешките на веригите от модули, водещи до модулите, които изпълняват посочения вход (срв. с метода на целенасочено конструктивно внедряване в Лекция 7). Докато входните модули не бъдат отстранени, тестовите данни се предоставят от някои симулатори: те или се включват в симулатора като част от него, или се въвеждат от този симулатор.

    При тестване отгоре надолу някои състояния на информационната среда, при които се изисква да се тества модулът, който се отстранява, може да не се появят по време на изпълнението на програмата, в която се отстраняват грешки, за който и да е вход. В тези случаи би било възможно изобщо да не се тества модулът, който се отстранява, тъй като грешките, открити в този случай, няма да се появят, когато програмата, която се отстранява, се изпълни под каквито и да е входни данни. Не се препоръчва обаче да се прави това, тъй като когато програмата, която се отстранява, се променя (например при поддържане на PS), вече могат да възникнат състоянията на информационната среда, които не са били използвани за тестване на модула, който се отстранява, което изисква допълнителни тестване на този модул (и това, с рационална организация на отстраняването на грешки, не може да се направи, ако самият модул не се е променил). За да се тества модулът, който се отстранява в тези ситуации, понякога се използват подходящи симулатори за създаване на желаното състояние на информационната среда. По-често се използва модифицирана версия на тестване отгоре надолу, при която модулите, които се отстраняват грешки, се тестват предварително отделно, преди да бъдат интегрирани (в този случай водещ модул за отстраняване на грешки се появява в средата на модула, който се отстранява, заедно с модула симулатори, които могат да бъдат достъпни от модула, който се отстранява). Въпреки това, друга модификация на тестването отгоре надолу изглежда по-подходяща: след като тестването отгоре надолу на модула, който се дебъгва, за достижими тестови състояния на информационната среда е завършено, той трябва да бъде тестван отделно за останалите необходими състояния на информацията заобикаляща среда.

    Често се използва и комбинация от тестване отдолу нагоре и отдолу нагоре, което се нарича метод на сандвич. Същността на този метод се крие в едновременното прилагане както на възходящо, така и на низходящо тестване, докато тези два процеса на тестване се срещнат в някакъв модул някъде в средата на структурата на програмата, която се отстранява. Този метод позволява при разумен подход да се възползват от предимствата както на тестването отдолу нагоре, така и на тестването отгоре надолу и до голяма степен да неутрализират недостатъците им. Този ефект е проява на по-общ принцип: най-големият технологичен ефект може да бъде постигнат чрез комбиниране на методите отгоре надолу и отдолу нагоре на програмиране на COP. Архитектурният подход към разработването на софтуер е предназначен да поддържа този метод (виж Лекция 7): слой от добре проектирани и внимателно тествани модули значително улеснява внедряването на фамилия от програми в съответната тематична област и последващата им модернизация.

    Много важно при офлайн отстраняване на грешки е тестването на сдвояването на модули. Факт е, че спецификацията на всеки програмен модул, с изключение на главния, се използва в тази програма в две ситуации: първо, когато се разработва текстът (понякога казват: тялото) на този модул и, второ, когато се пише обжалване на този модул в други програмни модули. И в двата случая в резултат на грешка може да бъде нарушено необходимото съответствие с дадена спецификация на модула. Такива грешки трябва да бъдат открити и коригирани. Това е целта на тестването на сдвояването на модулите. При тестване отгоре надолу, тестването на двойки се извършва по пътя с всеки пропуснат тест, което се счита за най-силното предимство на тестването отгоре надолу. По време на тестване отдолу нагоре достъпът до дебъгвания модул се осъществява не от модулите на програмата, която се дебъгва, а от водещия модул за дебъгване. В тази връзка съществува опасност последният модул да се адаптира към някои "погрешни схващания" на модула, който се отстранява. Следователно, когато се стартира (в процеса на програмна интеграция) дебъгване на нов модул, е необходимо да се тества всяко извикване на предварително дебъгван модул, за да се открият несъответствия между това извикване и тялото на съответния модул (и е възможно, че за това е виновен модулът с предварително отстраняване на грешки). По този начин е необходимо частично да се повтори тестването на предварително дебъгван модул при нови условия и възникват същите трудности, както в случай на тестване отгоре надолу.

    Автономното тестване на модула трябва да се извърши в четири последователни стъпки.

    Стъпка 1: Въз основа на спецификацията на модула, който отстранявате грешки, подгответе тест за всяка възможност и ситуация, за всяка граница на диапазоните на всички входове, за всеки диапазон от промени в данните, за всеки невалиден диапазон на всички входове и всеки невалидно условие.

    Стъпка 2. Проверете текста на модула, за да сте сигурни, че всяко направление на който и да е клон ще премине поне един тест. Добавяне на липсващи тестове.

    Стъпка 3. Проверете от текста на модула, че за всеки цикъл има тест, за който тялото на цикъла не се изпълнява, тест, за който тялото на цикъла се изпълнява веднъж, и тест, за което тялото на цикъла се изпълнява максималния брой пъти. Добавяне на липсващи тестове.

    Стъпка 4. Проверете текста на модула за неговата чувствителност към отделни специални стойности на входните данни - всички такива стойности трябва да бъдат включени в тестовете. Добавяне на липсващи тестове.

61. 10.5. Комплексно отстраняване на грешки на софтуера.

62. Както бе споменато по-горе, при сложно отстраняване на грешки PS се тества като цяло и се подготвят тестове за всеки от PS документите. Тестването на тези документи обикновено се извършва в обратния ред на тяхното разработване (единственото изключение е тестването на документацията на приложението, която се разработва според външното описание успоредно с разработването на програмните текстове; това тестване е най-добре да се направи след тестване на външното описание е завършено). Тестването при сложно отстраняване на грешки е прилагането на PS към конкретни данни, които по принцип могат да възникнат от потребителя (по-специално, всички тестове се подготвят във форма, предназначена за потребителя), но вероятно в симулирана (а не реална) заобикаляща среда. Например, някои входни и изходни устройства, които са недостъпни по време на сложно отстраняване на грешки, могат да бъдат заменени от техните софтуерни симулатори.

    Тестване на PS архитектура. Целта на тестването е да се намери несъответствие между описанието на архитектурата и набора от програми на PS. Докато започне тестването на PS архитектурата, автономното отстраняване на грешки на всяка подсистема вече трябва да е завършено. Грешките в изпълнението на архитектурата могат да бъдат свързани предимно с взаимодействието на тези подсистеми, по-специално с изпълнението на архитектурни функции (ако има такива). Затова бих искал да проверя всички начини на взаимодействие между подсистемите на PS. Но тъй като може да има твърде много от тях, би било желателно да се тестват поне всички вериги за изпълнение на подсистеми без повторно влизане на последната. Ако дадената архитектура представя PS като малка система от избрани подсистеми, тогава броят на тези вериги ще бъде доста видим.

    Тестване на външни функции. Целта на тестването е да се открият несъответствия между функционалната спецификация и набора от софтуерни програми на PS. Въпреки факта, че всички тези програми вече са били независимо отстранени, тези несъответствия може да се дължат например на несъответствие между вътрешните спецификации на програмите и техните модули (въз основа на които е извършено автономното тестване) и външната функционална спецификация на МС. По правило тестването на външни функции се извършва по същия начин, както тестването на модули в първата стъпка, т.е. като черна кутия.

    Тестване на качеството на PS. Целта на тестването е да се търсят нарушения на изискванията за качество, формулирани в спецификацията за качество на PS. Това е най-трудният и най-слабо изучаван вид тестване. Ясно е само, че не всеки примитив за качество на PS може да бъде тестван чрез тестване (вижте следващата лекция за оценка на качеството на PS). Пълнотата на PS се проверява вече при тестване на външни функции. На този етаптестването на този примитив за качество може да продължи, ако е необходимо да се получи някаква вероятностна оценка на степента на надеждност на PS. Въпреки това, методологията за такова тестване все още трябва да бъде разработена. Могат да бъдат тествани точност, устойчивост, сигурност, времева ефективност, ефективност на паметта до известна степен, ефективност на устройството, разширяемост и отчасти независимост на устройството. Всеки от тези видове тестове има своите специфики и заслужава отделно разглеждане. Тук ще се ограничим до изброяването им. Лекотата на използване на PS (критерий за качество, който включва няколко примитиви за качество, вижте Лекция 4) се оценява при тестване на документацията за използването на PS.

    Документация за изпитване на приложението на PS. Целта на тестването е да се търсят несъответствия между документацията на приложението и набора от софтуерни програми, както и неудобството при използване на софтуера. Този етап непосредствено предшества връзката на потребителя със завършването на разработката на PS (тестване на изискванията за PS и сертифициране на PS), така че е много важно разработчиците първо да използват самите PS по начина, по който потребителят ще го направи то. Всички тестове на този етап се изготвят единствено въз основа на документацията за прилагане на PS. На първо място, трябва да се тестват възможностите на софтуера, както беше направено при тестване на външни функции, но само на базата на документацията на приложението. Всички неясни места в документацията, както и всички примери, използвани в документацията, трябва да бъдат тествани. След това се тестват най-трудните случаи на прилагане на PS, за да се открие нарушение на изискванията за относителността на лекотата на използване на PS.

    Тестване на дефиницията на изискванията за PS. Целта на тестването е да се установи до каква степен софтуерът не отговаря на представената дефиниция на изискванията към него. Особеността на този тип тестване е, че се извършва от организацията купувач или организацията потребител на PS като един от начините за преодоляване на бариерата между разработчика и потребителя (вижте лекция 3). Обикновено това тестване се извършва с помощта на контролни задачи - типични задачи, за които резултатът от решението е известен. В случаите, когато разработеният PS трябва да замени друга версия на PS, която решава поне част от задачите на разработения PS, тестването се извършва чрез решаване на общи проблеми, използвайки както стария, така и новия PS, последвано от сравнение на резултатите получено. Понякога като форма на такова тестване се използва пробна експлоатация на PS - ограничено приложение на нова PS с анализ на използването на резултатите в практиката. По същество този вид тестване има много общо с тестването на ПС по време на неговото сертифициране (виж лекция 14), но се извършва преди сертифициране, а понякога и вместо сертифициране.

64. Литература към лекция 10.

65. 10.1. Г. Майерс. Надеждност на софтуера. - М.: Мир, 1980. - С. 171-262.

    10.2. Д. Ван Тасел. Стил, разработка, ефективност, отстраняване на грешки и програми за тестване. - М.: Мир, 1985. - С. 179-295.

    10.3. Дж. Хюз, Дж. Мичтом. Структурен подход към програмирането. - М.: Мир, 1980. - С. 254-268.

    10.4. Дж. Фокс. Софтуер и неговото развитие. - М.: Мир, 1985. - С. 227-241.

    10.5. М. Зелковиц, А. Шоу, Дж. Ганън. Принципи на разработка на софтуер. - М.: Мир, 1982. - С. 105-116.

    10.6. Ю.М. Безбородов. Индивидуално отстраняване на грешки на програми. - М.: Наука, 1982. - С. 9-79.

    10.7. В.В. Липаев. Тестване на програмата. - М.: Радио и комуникация, 1986. - С. 15-47.

    10.8. Е.А. Жоголев. Въведение в технологията на програмиране (записки от лекции). - М.: "ДИАЛОГ-МГУ", 1994 г.

    10.9. Е. Дейкстра. Бележки за структурното програмиране. //U. Дал, Е. Дейкстра, К. Хор. Структурно програмиране. - М.: Мир, 1975. - С. 7-13.

67. Лекция 11

69. 11.1. Функционалност и надеждност като задължителни критерии за качество на софтуера.

70. В предишните лекции разгледахме всички етапи от разработването на PS, с изключение на нейното сертифициране. В същото време не засегнахме въпросите за осигуряване на качеството на PS в съответствие с неговата спецификация за качество (вижте лекция 4). Вярно е, че при прилагането на функционалната спецификация на PS, ние обсъдихме основните въпроси за осигуряване на критерия за функционалност. След като обявихме надеждността на софтуера като негов основен атрибут (вижте лекция 1), ние избрахме предотвратяването на грешки като основен подход за осигуряване на надеждност на софтуера (вижте лекция 3) и обсъдихме прилагането му на различни етапи от разработката на софтуера. Така се проявява тезата за задължителната функционалност и надеждност на ПС като критерии за нейното качество.

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

    Осигуряването на примитиви за качество на MS, които изразяват критериите за функционалност и надеждност на MS, са обсъдени по-долу.

72. 11.2. Осигуряване на пълнота на софтуера.

73. Пълнотата на PS е общ примитив за качество на PS за изразяване както на функционалността, така и на надеждността на PS, а за функционалността е единственият примитив (виж Лекция 4).

    Функционалността на PS се определя от неговата функционална спецификация. Пълнотата на PS като примитив на неговото качество е мярка за това как тази спецификация е приложена в дадена PS. Предоставянето на този примитив в пълна степен означава прилагане на всяка от функциите, дефинирани във функционалната спецификация, с всички подробности и характеристики, посочени там. Всички разгледани по-горе технологични процеси показват как може да се направи това.

    Въпреки това, в спецификацията за качество на PS могат да бъдат дефинирани няколко нива на изпълнение на функционалността на PS: може да се дефинира някаква опростена (първоначална или начална) версия, която трябва да бъде внедрена първо, както и няколко междинни версии. В този случай възниква допълнителен технологичен проблем: организацията за увеличаване на функционалността на PS. Тук е важно да се отбележи, че разработването на опростена версия на PS не е разработване на неговия прототип. Прототипът се разработва, за да се разберат по-добре условията за използване на бъдещата ПС, да се изясни външното му описание. Той е предназначен за избрани потребители и следователно може да се различава значително от необходимия PS не само в изпълняваните функции, но и в характеристиките на потребителския интерфейс. Опростена версия на изискваната PS трябва да бъде проектирана за практическа употреба от всички потребители, за които е предназначена. Следователно основният принцип за осигуряване на функционалността на такава ОС е да се разработи ОС от самото начало по такъв начин, сякаш е необходима цялата ОС, докато разработчиците се справят с тези части или детайли на ОС, внедряването на което може да бъде отложено в съответствие с неговата спецификация за качество. По този начин както външното описание, така и описанието на архитектурата на PS трябва да бъдат разработени изцяло. Възможно е да се отложи само внедряването на онези софтуерни подсистеми, дефинирани в архитектурата на разработения PS, чието функциониране не се изисква в първоначалната версия на този PS. Внедряването на самите софтуерни подсистеми се извършва най-добре чрез метода на целенасоченото конструктивно внедряване, оставяйки в първоначалната версия на PS подходящи симулатори на тези софтуерни модули, които не се изискват в тази версия. Допустимо е и опростено изпълнение на някои софтуерни модули, като се пропускат изпълнението на някои детайли на съответните функции. От технологична гледна точка обаче е по-добре да се разглеждат такива модули като техни оригинални имитатори (макар и далеч напреднали).

    Поради грешките в разработения PS, постигнатата пълнота при осигуряване на неговата функционалност (в съответствие със спецификацията на качеството му) всъщност може да не е според очакванията. Можем само да кажем, че тази пълнота е постигната с известна вероятност, обусловена от обема и качеството на тестването. За да се увеличи тази вероятност, е необходимо да се продължи тестването и отстраняването на грешки в PS. Въпреки това, оценката на такава вероятност е много специфична задача (като се има предвид фактът, че проявлението на грешката в PS е функция на първоначалните данни), която все още чака подходящи теоретични изследвания.

75. 11.3. Гарантиране на точността на софтуерния инструмент.

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

    относно грешката на използвания метод на изчисление (в който включваме неточността на използвания модел),

    от грешката в представянето на използваните данни (от така наречената фатална грешка),

    от грешката при закръгляване (неточност при изпълнението на използваните в метода операции).

78. 11.4. Осигуряване на автономност на софтуера.

79. Този примитив за качество се предоставя на етапа на спецификация на качеството чрез вземане на решение дали да се използва някакъв подходящ базов софтуер в разработения PS или да не се използва никакъв базов софтуер в него. В същото време е необходимо да се вземе предвид както неговата надеждност, така и ресурсите, необходими за използването му. При повишени изисквания към надеждността на разработения PS, надеждността на основния софтуер, достъпен за разработчиците, може да се окаже незадоволителен, поради което използването му трябва да бъде изоставено и изпълнението на неговите функции в необходимия обем трябва да бъде включено в ПС. Подобни решения трябва да се вземат при строги ограничения на използваните ресурси (според критерия за ефективност на PS).

81. 11.5. Осигуряване на устойчивост на софтуера.

82. Този качествен примитив се осигурява с помощта на така нареченото защитно програмиране. Най-общо казано, защитното програмиране се използва за подобряване на надеждността на MS при програмиране на модула в по-широк смисъл. Както заявява Майърс, „Отбранителното програмиране се основава на важна предпоставка: Най-лошото нещо, което един модул може да направи, е да приеме лош вход и след това да върне неправилен, но правдоподобен резултат.“ За да се избегне това, текстът на модула включва проверки на неговите входни и изходни данни за тяхната коректност в съответствие със спецификацията на този модул, по-специално изпълнението на ограниченията върху входните и изходните данни и връзките между тях посочени в спецификацията на модула трябва да бъдат проверени. В случай на отрицателен резултат от проверката се повдига съответното изключение. В тази връзка в края на този модул са включени фрагменти от втория вид - манипулатори на съответните извънредни ситуации, които освен да издават необходимата диагностична информация, могат да предприемат мерки или за отстраняване на грешки в данните (напр. изискват повторното им въвеждане) или за смекчаване на въздействието на грешката (например, плавно спиране на устройства, управлявани от PS, за да се избегне повредата им в случай на аварийно прекратяване на изпълнението на програмата).

    Използването на защитно програмиране на модулите води до намаляване на ефективността на PS както във времето, така и в паметта. Следователно е необходимо разумно да се регулира степента на прилагане на защитното програмиране в зависимост от изискванията за надеждност и ефективност на PS, формулирани в спецификацията за качество на разработената PS. Входните данни на разработения модул могат да идват директно от потребителя или от други модули. Най-честият случай на използване на защитно програмиране е използването му за първата група данни, което означава реализиране на стабилност на PS. Това трябва да се прави винаги, когато спецификацията за качество на PS съдържа изискване за гарантиране на стабилността на PS. Използването на защитно програмиране за втората група входни данни означава опит за откриване на грешка в други модули по време на изпълнение на разработения модул, а за изходните данни на разработения модул - опит за откриване на грешка в самия модул по време на неговото изпълнение. По същество това означава частично прилагане на подхода за самооткриване на грешки за гарантиране на надеждността на софтуера, който беше разгледан в Лекция 3. Този случай на защитно програмиране се използва изключително рядко - само когато изискванията за надеждност на софтуера са изпълнени. са изключително високи.

84. 11.6. Гарантиране на сигурността на софтуера.

85. Разграничете следните видовезащита на PS от изкривяване на информацията:

    защита срещу хардуерни повреди;

    защита от влиянието на "чужда" програма;

    защита срещу повреди на "собствена" програма;

    защита срещу грешки на оператора (потребителя);

    защита срещу неоторизиран достъп;

    защита срещу защита.

    Защитата срещу хардуерни повреди в момента не е много спешна задача (като се има предвид постигнатото ниво на надеждност на компютъра). Но все пак е полезно да знаете нейното решение. Това се осигурява от организирането на така наречените "двойно-тройни грешки". За да направите това, целият процес на обработка на данни, определен от PS, се разделя във времето на интервали от така наречените "референтни точки". Продължителността на този интервал не трябва да надвишава половината от средното време на работа на компютъра. Копие от състоянието на паметта, променено в този процес за всяка референтна точка, се записва във вторичната памет с някаква контролна сума (число, изчислено като функция на това състояние) в случай, когато се счита, че обработката на данни от предишната референтна точка към тази (т.е. едно "грешно изчисление") е направена правилно (без компютърни повреди). За да се установи, се правят две такива "грешни изчисления". След първото "изчисление" зададената контролна сума се изчислява и съхранява, след което се възстановява състоянието на паметта за предишната референтна точка и се прави второто "изчисление". След второто "грешно изчисляване" посочената контролна сума се изчислява отново, която след това се сравнява с контролната сума на първото "грешно изчисляване". Ако тези две контролни суми съвпадат, второто изчисление се счита за правилно, в противен случай контролната сума на второто "изчисление" също се съхранява и се извършва третото "изчисление" (с предварително възстановяване на състоянието на паметта за предишната референтна точка). Ако контролната сума на третото "грешно изчисление" съвпада с контролната сума на едно от първите две "грешни изчисления", тогава третото погрешно изчисление се счита за правилно, в противен случай е необходима инженерна проверка на компютъра.

    Защитата от влиянието на "чужда" програма се отнася предимно за операционни системи или програми, които частично изпълняват своите функции. Има два вида тази защита:

    защита при повреда,

    защита срещу злонамерено влияние на "чужда" програма.

    Когато се появи мултипрограмен режим на работа на компютър, няколко програми могат да се изпълняват едновременно в неговата памет, последователно получавайки управление в резултат на прекъсвания (така нареченото квазипаралелно изпълнение на програми). Една от тези програми (обикновено: операционната система) обработва прекъсвания и управлява мултипрограмиране. Във всяка от тези програми могат да възникнат повреди (появят се грешки), които могат да повлияят на изпълнението на функции от други програми. Следователно управляващата програма (операционната система) трябва да защити себе си и другите програми от подобно влияние. За да направите това, компютърният хардуер трябва да реализира следните функции:

    защита на паметта,

    два режима на работа на компютъра: привилегирован и работен (потребител),

    два вида транзакции: привилегировани и обикновени,

    правилно прилагане на прекъсвания и първоначално стартиране на компютъра,

    временно прекъсване.

    Защитата на паметта означава възможност за програмно задаване за всяка програма на области от паметта, които са недостъпни за нея. В привилегирован режим могат да се извършват всякакви операции (обикновени и привилегировани), а в режим на изпълнение - само обикновени. Опит за извършване на привилегирована операция, както и достъп до защитена памет в работен режим, предизвиква съответното прекъсване. Освен това привилегированите операции включват операции за промяна на защитата на паметта и режима на работа, както и достъп до външната информационна среда. Първоначалното включване на компютъра и всяко прекъсване трябва автоматично да активират привилегирован режим и да отменят защитата на паметта. В този случай управляващата програма (операционната система) може напълно да се защити от влиянието на други програми, ако всички точки за прехвърляне на управление при първоначално включване и прекъсвания принадлежат на тази програма, ако не позволява на друга програма да работи в привилегирован режим (когато управлението се прехвърли на който и да е друг, програмата ще включи само работния режим) и ако напълно защитава своята памет (съдържаща, по-специално, цялата си управляваща информация, включително така наречените вектори на прекъсване) от други програми. Тогава никой няма да му попречи да изпълнява каквито и да е защитни функции, внедрени в него за други програми (включително достъп до външната информационна среда). За да се улесни решаването на този проблем, част от такава програма се поставя в постоянна памет, т.е. неотделима от самия компютър. Наличието на временно прекъсване позволява на управляващата програма да се защити от зацикляне в други програми (без такова прекъсване тя просто може да загуби способността си да управлява).

    Защитата срещу повреди на "собствената" програма се осигурява от надеждността на тази програма, която е фокусът на цялата технология на програмиране, разгледана в този курс от лекции.

    Защитата срещу потребителски грешки (в допълнение към грешки при въвеждане на данни, вижте осигуряване на стабилност на PS) се осигурява чрез издаване на предупредителни съобщения за опити за промяна на състоянието на външната информационна среда с изискване за потвърждаване на тези действия, както и възможност за възстановяване на състояние на отделни компоненти на външната информационна среда. Последното се основава на внедряването на архивни промени в състоянието на външната информационна среда.

    Защитата срещу неоторизиран достъп се осигурява чрез използването на тайни думи (пароли). В този случай на всеки потребител се предоставят определени информационни и процедурни ресурси (услуги), чието използване изисква представяне на парола към PS, предварително регистрирана в PS от този потребител. С други думи, потребителят, така да се каже, "заключва" ресурсите, които са му разпределени, "ключът", към който има само този потребител. Възможно е обаче да се правят постоянни опити за нарушаване на такава защита в отделни случаи, ако защитените ресурси са от изключителна стойност за някого. В такъв случай трябва да се вземат допълнителни мерки за защита срещу пробиви в сигурността.

    Защитата срещу пробиви в сигурността е свързана с използването на специални техники за програмиране в PS, които затрудняват преодоляването на защитата срещу неоторизиран достъп. Използването на обикновени пароли не е достатъчно, когато става въпрос за изключително упорито желание (например от престъпен характер) да се получи достъп до ценна информация. Първо, защото информацията за паролите, които PS използва за защита срещу неоторизиран достъп, може да бъде получена относително лесно от "кракер" на тази защита, ако той има достъп до самия този PS. На второ място, с помощта на компютър е възможно да се извърши достатъчно голямо изброяване на възможни пароли, за да се намери подходяща за достъп до информацията, която представлява интерес. Можете да се предпазите от такъв хак по следния начин. Тайната дума (парола) или само секретното цяло число X е известно само на собственика на защитената информация, а за проверка на правата за достъп в компютъра се съхранява друго число Y=F(X), което се изчислява еднозначно от PS всеки път, когато се прави опит за достъп до тази информация при представяне на тайната дума. В същото време функцията F може да бъде добре позната на всички потребители на PS, но има такова свойство, че възстановяването на думата X от Y е практически невъзможно: с достатъчно голяма дължина на думата X (например няколкостотин знака ), това изисква астрономическо време. Такъв номер Y ще се нарича електронен (компютърен) подпис на собственика на тайната дума X (а оттам и на защитената информация).

    Друг вид такава защита е свързана със защитата на съобщения, изпратени през компютърни мрежи, умишлено (или злонамерено) изкривяване. Такова съобщение може да бъде прихванато в "претоварни" точки на компютърната мрежа и заменено с друго съобщение от автора на прихванатото съобщение. Тази ситуация възниква преди всичко при извършването на банкови операции с помощта на компютърна мрежа. Чрез замяна на такова съобщение, което е нареждане от собственика на банкова сметка за извършване на банкова операция, парите от неговата сметка могат да бъдат прехвърлени към сметката на "хакерска" защита (вид компютърен банков обир). Защитата срещу такъв пробив в сигурността може да бъде направена по следния начин. Наред с функцията F, която определя компютърния подпис на притежателя на секретната дума X, която е известна на адресата на защитеното съобщение (ако само нейният собственик е клиент на този адресат), друга функция Stamp е дефинирана в PS, от което изпращачът на съобщението трябва да изчисли числото S=Stamp(X,R), използвайки тайната дума X и текста на предаденото съобщение R. Функцията Stamp също се счита за добре позната на всички потребители на MS и има такива свойство, че е практически невъзможно да се възстанови числото X от S или да се избере друго съобщение R със съответния компютърен подпис. Самото предавано съобщение (заедно със защитата му) трябва да изглежда така:

    освен това Y (компютърен подпис) позволява на адресата да установи истинността на клиента, а S, така да се каже, свързва защитеното съобщение R с компютърен подпис Y. В тази връзка ще наречем числото S електронен (компютър ) тюлен. PS дефинира още една нотариална функция, според която получателят на защитеното съобщение проверява истинността на предаденото съобщение:

86. Това ви позволява недвусмислено да установите, че съобщението R принадлежи на собственика на тайната дума X.

    Защитата от защита е необходима в случай, че потребителят е забравил (или изгубил) паролата си. За такъв случай трябва да е възможно специален потребител (PS администратор), отговорен за функционирането на системата за защита, да премахне временно защитата от неоторизиран достъп за собственика на забравената парола, за да му позволи да коригира нова парола.

88. Литература към лекция 11.

89. 11.1. И.С. Березин, Н.П. Жидков. Изчислителни методи, кн. 1 и 2. - М.: Физматгиз, 1959.

    11.2. Н.С. Бахвалов, Н.П. Жидков, Г. М. Кобелков. Числени методи. - М.: Наука, 1987.

    11.3. Г. Майерс. Надеждност на софтуера. - М.: Мир, 1980. С. 127-154.

    11.4. А.Н. Лебедев. Защита на банковата информация и съвременна криптография//Въпроси на информационната сигурност, 2(29), 1995.

91. Лекция 12. Осигуряване на качеството на софтуера

93. 12.1. Обща характеристика на процеса за осигуряване на качеството на софтуера.

94. Както вече беше отбелязано в лекция 4, спецификацията на качеството определя основните насоки (цели), които на всички етапи от разработването на PS по един или друг начин влияят върху избора на подходящ вариант при вземане на различни решения. Въпреки това, всеки примитив на качеството има свои собствени характеристики на такова влияние, така че осигуряването на неговото присъствие в PS може да изисква собствени подходи и методи за разработване на PS или отделни негови части. Освен това беше отбелязано несъответствието на критериите за качество на PS и примитивите за качество, които ги изразяват: доброто осигуряване на един от примитивите за качество на PS може значително да усложни или направи невъзможно предоставянето на някои от другите от тези примитиви. Следователно съществена част от процеса на осигуряване на качеството на PS се състои в намирането на приемливи компромиси. Тези компромиси трябва да бъдат частично дефинирани още в спецификацията на качеството на PS: моделът на качеството на PS трябва да уточни необходимата степен на присъствие в PS на всеки от неговите примитиви за качество и да определи приоритетите за постигане на тези степени.

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

    първо е необходимо да се осигури необходимата функционалност и надеждност на PS и след това да се доведат останалите критерии за качество до приемливо ниво на тяхното присъствие в PS;

    няма нужда и дори може да е вредно да се търси по-високо ниво на присъствие в PS на какъвто и да е примитив за качество от определеното в спецификацията за качество на PS.

    Осигуряването на функционалността и надеждността на PS беше разгледано в предишната лекция. Предоставянето на други критерии за качество на ОС е обсъдено по-долу.

    12.2.. Осигуряване на лекота на използване на софтуерния инструмент

    P-документацията на PS определя състава на потребителската документация

    В предишната лекция вече беше разгледано осигуряването на два от петте примитиви за качество (стабилност и сигурност), които определят лекотата на използване на PS.

    P-документацията и информативността определят състава и качеството на потребителската документация (вижте следващата лекция).

    Комуникацията се осигурява чрез създаване на подходящ потребителски интерфейси съответната обработка на изключения. Какъв е проблемът тук?

96. 12.3. Гарантиране на ефективността на софтуера.

97. Ефективността на ПС се осигурява чрез вземане на подходящи решения на различни етапи от нейното развитие, като се започне от развитието на нейната архитектура. Изборът на структура и представяне на данните влияе особено силно на ефективността на PS (особено по отношение на паметта). Но изборът на алгоритми, използвани в определени софтуерни модули, както и характеристиките на тяхното изпълнение (включително изборът на език за програмиране) могат значително да повлияят на ефективността на PS. В същото време човек постоянно трябва да разрешава противоречието между времевата ефективност и ефективността от паметта. Следователно е много важно спецификацията за качество изрично да посочва количествената връзка между показателите на тези примитиви за качество или поне да определя количествени граници за един от тези показатели. И все пак различните софтуерни модули имат различен ефект върху ефективността на PS като цяло: както по отношение на техния принос към общите разходи на PS по отношение на време и памет, така и по отношение на въздействието върху различни примитиви за качество (някои модули могат силно да повлияят на постигането на времева ефективност и практически да не повлияят на ефективността на паметта, докато други могат значително да повлияят на общото потребление на памет, без да повлияят значително на времето за работа на PS). Освен това това въздействие (предимно по отношение на времевата ефективност) предварително (преди завършването на изпълнението на ПС) не винаги може да бъде правилно оценено.

    първо трябва да разработите надежден PS и едва след това да постигнете необходимата му ефективност в съответствие със спецификацията за качество на този PS;

    за да подобрите ефективността на PS, на първо място, използвайте оптимизиращ компилатор - това може да осигури необходимата ефективност;

    ако постигнатата ефективност на PS не отговаря на спецификацията за неговото качество, тогава намерете най-критичните модули по отношение на необходимата ефективност на PS (в случай на времева ефективност, това ще изисква получаване на разпределението по модули на PS време на работа чрез подходящи измервания по време на внедряването на ПС); тези модули и опитайте първо да ги оптимизирате, като ги модифицирате ръчно;

    не оптимизирайте модула, ако това не е необходимо за постигане на необходимата ефективност на PS.

    12.4. Осигуряване на ремонтопригодност.

    C-документацията, информационното съдържание и разбираемостта определят състава и качеството на документацията за поддръжка (вижте следващата лекция). Освен това могат да се направят следните препоръки по отношение на текстовете на програмите (модулите).

    използвайте коментари в текста на модула, които изясняват и обясняват особеностите на вземаните решения; ако е възможно, включете коментари (поне в кратка форма) на най-ранния етап от разработването на текста на модула;

    използвайте смислени (мнемонични) и устойчиво различими имена (оптималната дължина на името е 4-12 букви, цифрите са в края), не използвайте подобни имена и ключови думи;

    внимавайте, когато използвате константи (уникална константа трябва да има еднократно срещане в текста на модула: когато е декларирана или в последна инстанция, при инициализиране на променлива като константа);

    не се страхувайте да използвате незадължителни скоби (скобите са по-евтини от грешките;

    поставяйте не повече от едно твърдение на ред; за изясняване на структурата на модула използвайте допълнителни интервали (отстъпи) в началото на всеки ред;

    избягвайте трикове, т.е. такива техники за програмиране, когато се създават фрагменти от модул, чийто основен ефект не е очевиден или скрит (завоалиран), например странични ефекти на функции.

    Разширяемостта се осигурява чрез създаване на подходящ инсталатор.

    Структурираността и модулността опростяват както разбирането на програмните текстове, така и тяхната модификация.

    12.5. Осигуряване на мобилност.

99. Литература към лекция 12.

100. 12.1. Иън Съмървил. Софтуерно инженерство. - Addison-Wesley Publishing Company, 1992. P.

     12.3. Д. Ван Тасел. Стил, разработка, ефективност, отстраняване на грешки и програми за тестване. - М.: Мир, 1985. С. 8-44, 117-178.

     12.4. Софтуерна потребителска документация/ANSI/IEEE стандарт 1063-1987.

102. Лекция 13

104. 13.1. Документация, създадена по време на процеса на разработка на софтуер.

105. При разработването на PS се създава голямо количество разнообразна документация. Той е необходим като средство за прехвърляне на информация между разработчиците на PS, като средство за управление на развитието на PS и като средство за предаване на потребителите на информацията, необходима за прилагането и поддръжката на PS. Създаването на тази документация представлява голяма част от разходите за PS.

     Тази документация може да бъде разделена на две групи:

     Документи за управление на развитието на ПС.

     Документи, включени в ПС.

     Документи за управление на разработката на PS (документация на процеса) записват процесите на разработване и поддържане на PS, осигурявайки комуникация в рамките на екипа за разработка и между екипа за разработка и мениджърите (мениджърите) - лица, управляващи разработката. Тези документи могат да бъдат от следните видове:

     Планове, разчети, графици. Тези документи се създават от мениджърите, за да предвидят и управляват процесите на разработка и поддръжка.

     Доклади за използването на ресурси по време на разработката. Създадени от мениджъри.

     Стандарти. Тези документи предписват на разработчиците какви принципи, правила, споразумения трябва да следват в процеса на разработване на PS. Тези стандарти могат да бъдат международни или национални, или специално създадени за организацията, в която се разработва този PS.

     Работни документи. Това са основните технически документи, които осигуряват комуникация между разработчиците. Те съдържат фиксиране на идеи и проблеми, които възникват в процеса на разработка, описание на използваните стратегии и подходи, както и работни (временни) версии на документи, които трябва да бъдат включени в PS.

     Бележки и кореспонденция. Тези документи улавят различни детайли от взаимодействието между мениджъри и разработчици.

     Документите, включени в PS (документация на продукта), описват PS програмите както от гледна точка на използването им от потребителите, така и от гледна точка на техните разработчици и поддържащи (в съответствие с предназначението на PS). Тук трябва да се отбележи, че тези документи ще се използват не само на етапа на експлоатация на PS (във фазите на неговото прилагане и поддръжка), но и на етапа на разработка за управление на процеса на разработка (заедно с работни документи) - във всеки случай, те трябва да бъдат проверени (тествани) за съответствие с PS програмите. Тези документи образуват два комплекта с различни цели:

     PS потребителска документация (P-документация).

     Документация за поддръжка на PS (C-документация).

107. 13.2. Софтуерна потребителска документация.

108. Потребителската документация на PS (потребителска документация) обяснява на потребителите как трябва да процедират, за да приложат този PS. Необходимо е, ако PS включва взаимодействие с потребителите. Тази документация включва документи, които насочват потребителя при инсталиране на PS (когато инсталира PS с подходяща настройка за средата за използване на PS), когато използва PS за решаване на проблемите си и когато управлява PS (например, когато този PS взаимодейства с други системи). Тези документи покриват частично проблемите на поддръжката на софтуера, но не се занимават с въпроси, свързани с модификацията на програмите.

     В тази връзка трябва да се разграничат две категории потребители на PS: обикновени потребители на PS и администратори на PS. Един обикновен потребител на PS (краен потребител) използва PS за решаване на проблемите си (в своята предметна област). Това може да е инженер, който проектира техническо устройство, или касиер, продаващ билети за влак с помощта на PS. Той може да не знае много подробности за работата на компютъра или принципите на програмиране. Администраторът на PS (системен администратор) управлява използването на PS от обикновените потребители и осигурява поддръжка за PS, която не е свързана с модификация на програми. Например, може да регулира правата за достъп до ОС между обикновените потребители, да комуникира с доставчиците на ОС или да извършва определени действия, за да поддържа ОС в работно състояние, ако е включена като част от друга система.

     Съставът на потребителската документация зависи от аудиториите на потребителите, към които е насочен този PS, и от начина на използване на документите. Под публика тук се разбира контингентът от потребители на PS, който има нужда от определена потребителска документация на PS. Един успешен потребителски документ по същество зависи от точното определение на аудиторията, за която е предназначен. Потребителската документация трябва да съдържа необходимата информация за всяка аудитория. Начинът на използване на документ се отнася до начина, по който се използва документът. Обикновено потребителят на достатъчно големи софтуерни системи изисква или документи, за да проучи PS (използване в инструкции), или за изясняване на информация (използвайте като справка).

     В съответствие с произведенията, следният състав на потребителската документация за достатъчно голям PS може да се счита за типичен:

     Общо функционално описание на ПС. Дава кратко описание на функционалността на PS. Предназначен е за потребители, които трябва да решат колко им е необходим този PS.

     Ръководство за инсталиране на PS. Предназначен за системни администратори. Той трябва да предписва подробно как да се инсталират системи в определена среда. То трябва да съдържа описание на машинночетимия носител, на който се доставя MS, файловете, представляващи MS, и изискванията за минималната хардуерна конфигурация.

     Инструкции за използване на PS. Предназначен за обикновени потребители. Съдържа необходимата информация по приложението на ПС, организирана в удобен за изучаването й вид.

     Справочник по приложението на PS. Предназначен за обикновени потребители. Съдържа необходимата информация за приложението на ПС, организирана във вид, удобен за избирателно търсене на отделни детайли.

     Ръководство за управление на PS. Предназначен за системни администратори. Той трябва да описва съобщенията, генерирани, когато MS взаимодейства с други системи, и как да се отговори на тези съобщения. Освен това, ако MS използва системен хардуер, този документ може да обясни как да поддържате този хардуер.

     Както бе споменато по-рано (вижте Лекция 4), разработването на потребителска документация започва веднага след създаването на външно описание. Качеството на тази документация може значително да определи успеха на PS. Трябва да е доста просто и удобно за потребителя (в противен случай този PS като цяло не си струваше да се създава). Следователно, въпреки че чернови версии (чернови) на потребителски документи се създават от главните разработчици на PS, професионалните технически автори често участват в създаването на окончателните им версии. Освен това, за да се гарантира качеството на потребителската документация, са разработени редица стандарти (вижте например), които предписват процедурата за разработване на тази документация, формулират изисквания за всеки тип потребителски документи и определят тяхната структура и съдържание .

     13.3. Документация за поддръжка на софтуер.

     Документация за поддръжка на PS (системна документация) описва PS от гледна точка на неговото развитие. Тази документация е необходима, ако PS включва проучване на това как е подреден (проектиран) и модернизиране на неговите програми. Както беше отбелязано, поддръжката е непрекъснато развитие. Следователно, ако е необходимо да се надстрои PS, в тази работа участва специален екип от придружаващи разработчици. Този екип ще трябва да се справи със същата документация, която определя дейностите на екипа от първоначални (основни) разработчици на PS, с единствената разлика, че тази документация по правило ще бъде на някой друг за екипа за разработка на поддържащия ( създадено е от друг екип). Екипът по поддръжката ще трябва да проучи тази документация, за да разбере структурата и процеса на разработка на обновения PS и да направи необходимите промени в тази документация, повтаряйки до голяма степен технологичните процеси, чрез които е създаден оригиналният PS.

     Документацията за поддръжка на PS може да бъде разделена на две групи:

     (1) документация, която определя структурата на програмите и структурите от данни на PS и технологията за тяхното разработване;

     (2) документация за подпомагане на промените в PS.

     Документацията от първа група съдържа окончателните документи на всеки технологичен етап от развитието на ПС. Той включва следните документи:

     Външно описание на PS (документ с изисквания).

     Описание на системната архитектура на PS, включително външната спецификация на всяка от неговите програми.

     За всяка PS програма, описание на нейната модулна структура, включително външна спецификация за всеки модул, включен в нея.

     За всеки модул - неговата спецификация и описание на структурата му (design description).

     Модулни текстове на избрания език за програмиране (списъци с изходния код на програмата).

     Документи за валидиране на ОС, описващи как е установена валидността на всяка програма за ОС и как информацията за валидиране е свързана с изискванията за ОС.

     Документите за проверка на софтуера включват предимно документация за тестване (дизайн на теста и описание на тестовия пакет), но може да включват и резултатите от други видове валидиране на софтуера, като например доказателства за свойствата на програмата.

     Документацията на втората група съдържа

     Ръководството за поддръжка на системата, което описва известни проблеми заедно със софтуера, описва кои части от системата са зависими от хардуера и софтуера и как развитието на софтуера се взема предвид в неговата структура (дизайн).

     Често срещан проблем при поддръжката на PS е да се гарантира, че всички негови представяния поддържат темпото (остават последователни), когато PS се промени. За да се подпомогне това, връзките и зависимостите между документите и техните части трябва да бъдат записани в базата данни за управление на конфигурацията.

110. Литература към лекция 13.

111. 13.1. Иън Съмървил. Софтуерно инженерство. - Addison-Wesley Publishing Company, 1992. P.

     13.2. ANSI/IEEE Std 1063-1988, IEEE стандарт за софтуерна потребителска документация.

     13.3. ANSI/IEEE Std 830-1984, Ръководство на IEEE за спецификация на софтуерните изисквания.

     13.4. ANSI/IEEE Std 1016-1987, IEEE Препоръчителна практика за описание на дизайна на софтуера.

     13.5. ANSI/IEEE Std 1008-1987, IEEE стандарт за тестване на софтуерни модули.

     13.6. ANSI/IEEE Std 1012-1986, IEEE стандарт за планове за проверка и валидиране на софтуер.

     13.7. ANSI/IEEE Std 983-1986, Ръководство на IEEE за планиране на осигуряване на качеството на софтуера.

     13.8. ANSI/IEEE Std 829-1983, IEEE стандарт за документация за тестване на софтуер.

113. Лекция 14

114. Назначаване на сертификация на софтуер. Тестване и оценка на качеството на софтуера. Видове тестове и методи за оценка на качеството на софтуера.

116. 14.1. Назначаване на сертификация на софтуер.

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

     Въз основа на информацията, получена по време на тестването на PS, на първо място трябва да се установи, че PS изпълнява декларираните функции, а също така трябва да се установи до каква степен PS притежава декларираните примитиви и критерии за качество. По този начин оценката на качеството на PS е основното съдържание на процеса на сертифициране. Оценката на качеството на ПС се записва в съответното решение на атестационната комисия.

119. 14.2. Видове тестване на софтуер.

120. Известни са следните видове тестове на PS, провеждани с цел сертифициране на PS:

     тестване на PS компоненти;

     системни тестове;

     приемни тестове;

     полеви изпитания;

     индустриални тестове.

     Тестването на компонентите на PS е проверка (тестване) на работоспособността на отделните подсистеми на PS. Те се провеждат само в изключителни случаи със специално решение на атестационната комисия.

     Системното тестване на PS е проверка (тестване) на работоспособността на PS като цяло. Може да включва същите видове тестове, както при комплексното отстраняване на грешки на PS (вижте лекция 10). Извършва се с решение на атестационната комисия, ако има съмнения относно качеството на отстраняване на грешки от разработчиците на PS.

     Приемните изпитвания са основният вид изпитвания за сертифициране на ПС. Именно с тези тестове започва работата на сертификационната комисия. Тези тестове започват с проучване на предоставената документация, включително документация за тестване и отстраняване на грешки в PS. Ако документацията не съдържа достатъчно пълни резултати от тестването на софтуера, сертификационната комисия може да реши да проведе системно тестване на софтуера или да прекрати процеса на сертифициране с препоръка към разработчика да извърши допълнително (по-пълно) тестване на софтуера. В допълнение, по време на тези тестове тестовете за разработчици могат да бъдат избирателно пропуснати, както и задачите за потребителски контрол (вижте лекция 10) и допълнителни тестове, изготвени от комисията за оценка на качеството на сертифицирания PS.

     Полевото тестване на PS е демонстрация на PS заедно с техническата система, управлявана от тази PS, на тесен кръг клиенти в реални условия, като поведението на PS се следи внимателно. На клиентите трябва да се даде възможност да задават свои собствени тестови случаи, по-специално от изходи до критични режими на работа на техническата система, както и с повикване на аварийни ситуации в нея. Това са допълнителни изпитвания, извършвани с решение на атестационната комисия само за някои ПС, които контролират определени технически системи.

     Промишленото тестване на PS е процесът на прехвърляне на PS в постоянна експлоатация на потребителите. Това е период на пробна експлоатация на PS (вижте лекция 10) от потребители със събиране на информация за поведението на PS и неговите експлоатационни характеристики. Това са окончателните тестове на PS, които се извършват с решение на атестационната комисия, ако по време на предишните тестове е получена недостатъчно пълна или надеждна информация за оценка на качеството на сертифицирания PS.

122. 14.3. Методи за оценка на качеството на софтуера.

123. Оценката на качеството на PS за всеки от критериите се свежда до оценка на всеки от примитивите, свързани с този критерий за качество на PS, в съответствие с тяхната спецификация, направена в спецификацията за качество на този PS. Методите за оценка на примитивите за качество на PS могат да бъдат разделени на четири групи:

     директно измерване на качествени примитивни показатели;

     програми за обработка и документация на ПС със специални програмни средства (процесори);

     тестване на PS програми;

     експертна оценка въз основа на проучване на програми и документация на ПС.

     Директното измерване на качествените примитивни показатели се извършва чрез преброяване на броя на появяванията в определен програмен документ на характерни единици, обекти, структури и т.н., както и чрез измерване на времето на работа на различни устройства и обем използвана паметкомпютър при изпълнение на тестови случаи. Например, някаква мярка за ефективност на паметта може да бъде броят редове на програма на език за програмиране, а известна мярка за времева ефективност може да бъде времето за отговор на заявка. Използването на всякакви индикатори за качествени примитиви може да бъде определено в спецификацията на качеството на MS. Методът за директно измерване на качествени примитивни показатели може да се комбинира с използването на програмно тестване.

     Някои софтуерни инструменти могат да се използват, за да се определи дали MS има определени примитиви за качество. Такива софтуерни инструменти обработват програмни текстове или софтуерна документация, за да контролират всякакви качествени примитиви или да получат някои индикатори за тези качествени примитиви. За да се оцени структурността на PS програмите, ако те са програмирани на подходящ структурен диалект на основния език за програмиране, би било достатъчно да бъдат прекарани през структуриран програмен конвертор, който извършва синтактичен и известен семантичен контрол на този диалект и превежда текстовете на тези програми във входния език на основния преводач. Понастоящем обаче само малък брой качествени примитиви могат да бъдат контролирани по този начин и дори тогава в редки случаи. В някои случаи, вместо софтуерни инструменти, които контролират качеството на софтуера, е по-полезно да се използват инструменти, които трансформират представянето на програмите или програмната документация. Такъв, например, е програма за форматиране, която привежда програмните текстове в четима форма - обработката на текстове на PS програми с такъв инструмент може автоматично да гарантира, че PS има подходящ примитив за качество.

     Тестването се използва за оценка на някои примитиви на качеството на PS. Такива примитиви включват основно пълнотата на PS, както и неговата точност, стабилност, сигурност и други примитиви за качество. В някои случаи тестването се използва в комбинация с други методи за оценка на отделните примитиви за качество на PS. Така че, за да се оцени качеството на документацията за използването на PS (P-документация), тестването се използва в комбинация с експертна оценка на тази документация. Ако по време на комплексното отстраняване на грешки на PS е извършено достатъчно пълно тестване, тогава същите тестове могат да се използват по време на сертифицирането на PS. В този случай сертификационната комисия може да използва протоколите за тестване, извършени по време на сложно отстраняване на грешки. Въпреки това, дори и в този случай е необходимо да се извършат нови тестове или поне да се изпълнят отново някои от старите. Ако тестването по време на сложното отстраняване на грешки се окаже недостатъчно пълно, тогава е необходимо да се проведе по-пълно тестване. В този случай може да се вземе решение за провеждане на компонентни тестове или системни тестове на PS, както и за връщане на PS на разработчиците за ревизия. Много е важно, за да се оцени PS по критерия за лекота на използване (по време на отстраняване на грешки и сертифициране на PS), да се извърши пълно тестване на тестове, изготвени на базата на документацията за приложението, и съгл. по критерия ремонтопригодност - по изготвени тестове за всеки от документите, предложени за поддръжка.PS.

     За да се оцени по-голямата част от примитивите за качество на PS, в момента може да се използва само методът на експертните оценки. Този метод се състои в следното: назначава се група експерти, като всеки от тези експерти, в резултат на проучване на представената документация, прави мнението си за притежанието на PS с необходимото качество примитивно, след което оценката на изискваното качество качественият примитив на PS се установява чрез гласуване на членовете на тази група. Тази оценка може да бъде направена както по двуточкова система ("притежава" - "няма"), така и да вземе предвид степента на притежание на PS от този примитив за качество (например може да се направи на пет -точкова система). В същото време експертната група трябва да се ръководи от спецификацията на този примитив и указание за метода за оценката му, формулиран в спецификацията за качество на сертифицирания ПС.

     Литература към лекция 14.

     14.2. В. В. Липаев. Тестване на програмата. - М.: Радио и комуникация, 1986. - С. 231-245.

     14.3. Д. Ван Тасел. Стил, разработка, ефективност, отстраняване на грешки и програми за тестване. - М.: Мир, 1985. - С. 281-283.

     14.4. Б. Шнайдерман. Психология на програмирането. - М.: Радио и комуникация, 1984. - С. 99-127.

125. Лекция 15. Обектен подход при разработката на софтуер

127. 15.1. Обекти и релации в програмирането. Същността на обектния подход към разработката на софтуер.

128. Светът около нас се състои от обекти и отношения между тях. Един обект въплъщава някакъв обект и има някакво състояние, което може да се промени с течение на времето в резултат на влиянието на други обекти, които по някакъв начин са с данните. Може да има вътрешна структура: може да се състои от други обекти, които също са в някаква връзка помежду си. Въз основа на това можете да изградите йерархична структура на света от обекти. Въпреки това, за всяко конкретно разглеждане на света около нас, някои обекти се считат за неделими ("точкови") и в зависимост от целите на разглеждане могат да бъдат приети такива (неделими) обекти от различни нива на йерархия. Отношението свързва някои обекти: можем да считаме, че обединението на тези обекти има някакво свойство. Ако една връзка свързва n обекта, тогава такава връзка се нарича n-местна (n-ary). На всяко място на асоцииране на обекти, които могат да бъдат свързани с някаква конкретна връзка, могат да има различни обекти, но съвсем определени (в този случай те казват: обекти от определен клас). Едноместна релация се нарича свойство на обект (съответния клас). Състоянието на даден обект може да се изследва чрез стойността на свойствата на този обект или имплицитно чрез стойността на свойствата на обединенията на обекти, свързани помежду си с дадено едно или друго отношение.

     В процеса на опознаване или промяна на света около нас, ние винаги вземаме предвид един или друг опростен модел на света (model world), в който включваме някои от обектите и някои от отношенията на света около нас и, като правило, едно ниво на йерархия. Всеки обект, който има вътрешна структура, може да представлява свой собствен моделен свят, включително обектите на тази структура и връзките, които ги свързват. Така светът около нас може да се разглежда (в известно приближение) като йерархична структура от моделни светове.

     В момента, в процеса на изучаване или промяна на света около нас, компютърните технологии се използват широко за обработка на различни видове информация. В тази връзка се използва компютърно (информационно) представяне на обекти и отношения. Всеки обект може да бъде информационно представен от някаква структура от данни, която показва неговото състояние. Свойствата на този обект могат да бъдат зададени директно като отделни компоненти на тази структура или чрез специални функции върху тази структура от данни. N-арните отношения за N>1 могат да бъдат представени в активна или в пасивна форма. В своята активна форма N-местна релация е представена от някакъв програмен фрагмент, който изпълнява или N-местна функция (определяща стойността на свойството на съответния съюз от обекти), или процедура, която променя състоянията на някои от тях въз основа върху състоянието на репрезентации на обекти, свързани с репрезентираното отношение. В пасивна форма такава релация може да бъде представена от определена структура от данни (която може да включва представяния на обекти, свързани с тази релация), интерпретирана въз основа на приети споразумения относно общи процедури, които са независими от специфични релации (например релационна база данни). И в двата случая представянето на връзката определя някои дейности по обработка на данни.

     Когато изследва моделния свят, потребителят може да получи (или да иска) информация от компютъра по различни начини. При един подход той може да се интересува от получаване на информация за индивидуалните свойства на обектите, които го интересуват, или резултатите от всяко взаимодействие между някои обекти. За да направи това, той поръчва разработването на един или друг PS, който изпълнява функциите, които го интересуват, или някаква информационна система, способна да издава информация за отношенията, които го интересуват, като използва съответната база данни. В началния период на развитие на компютърните технологии (с недостатъчно висока мощност на компютрите) такъв подход към използването на компютри беше съвсем естествен. Именно той провокира функционалния (релационния) подход към развитието на ПС, който беше разгледан подробно в предишни лекции. Същността на този подход е системното използване на декомпозицията на функции (отношения) за изграждане на структурата на ПС и програмните текстове, включени в него. В същото време самите обекти, към които са приложени поръчаните и изпълнявани функции, са представени фрагментарно (доколкото е необходимо за изпълнение на тези функции) и във вид, удобен за изпълнение на тези функции. По този начин не беше осигурено пълно и адекватно компютърно представяне на моделния свят, който представлява интерес за потребителя: показването му на използвания PS може да се окаже доста трудоемка задача за потребителя, опит за леко разширяване на обема и естеството на информация за моделния свят, който представлява интерес за потребителя. получени от такава подстанция може да доведе до тяхната сериозна модернизация. Този подход към разработването на PS се подкрепя от повечето използвани програмни езици, вариращи от асемблерни езици и процедурни езици (FORTRAN, Pascal) до функционални езици (LISP) и езици за логическо програмиране (PROLOGUE).

     С друг подход към изучаването на моделния свят с помощта на компютър, потребителят може да се интересува от наблюдение на промяната в състоянията на обектите в резултат на техните взаимодействия. Това изисква доста солидно представяне в компютъра на обекта, който представлява интерес за потребителя, и софтуерните компоненти, които реализират връзките, в които този обект участва, са изрично свързани с него. За да се приложи този подход, беше необходимо да се изградят софтуерни инструменти, които симулират процесите на взаимодействие между обектите (модел свят). С помощта на традиционните инструменти за разработка това се оказа доста трудоемка задача. Вярно е, че се появиха езици за програмиране, които са специално фокусирани върху такова моделиране, но това само частично опрости задачата за разработване на необходимия PS. Най-пълното решение на този проблем е обектният подход към разработването на PS. Същността му се състои в системното използване на декомпозицията на обекти при изграждането на структурата на PS и включените в нея текстове на програми. В същото време функциите (отношенията), изпълнявани от такъв PS, бяха изразени чрез отношенията на обекти от различни нива, т.е. тяхното разлагане значително зависи от разлагането на обектите.

     Говорейки за обектния подход, човек също трябва ясно да разбере какъв вид обекти въпросният: обекти от моделния свят на потребителя, за тяхното информационно представяне, за програмните обекти, с помощта на които е изграден PS. Освен това трябва да се прави разлика между действителните обекти („пасивни“ обекти) и субекти („активни“ обекти).

130. 15.2. Обекти и субекти в програмирането.

132. 15.3. Обективни и субективни подходи към разработката на софтуер.

133. Декарт отбелязва, че хората обикновено имат обектно-ориентиран възглед за света (c).

     Те вярват, че обектно-ориентираният дизайн се основава на принципите на:

     подчертаване на абстракции,

     Ограничение на достъпа,

     модулност,

     йерархия,

     писане,

     паралелизъм,

     устойчивост.

     Но всичко това може да се приложи във функционален подход.

     Необходимо е да се прави разлика между предимствата и недостатъците на общия обектен подход и неговия частен случай - субектно-ориентирания подход.

     Предимства на общия обективен подход:

     Естествено картографиране на реалния свят върху структурата на PS (естествено човешко възприемане на възможностите на PS, няма нужда да се „измисля“ структурата на PS, а се използват естествени аналогии).

     Използването на достатъчно значими структурни единици на PS (обект като цялост на неизлишни асоциации, информационно силни модули).

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

135. 15.4. Обектен подход към разработването на външно описание и софтуерна архитектура.

136. Обектно-ориентираният дизайн е метод, който използва декомпозиция на обекти; обектно-ориентираният подход има своя собствена система символии предлага богат набор от логически и физически модели за проектиране на много сложни системи. .

     Обектно-ориентираният анализ (OOA) преобразува обектния подход. OOA има за цел да създаде модели, които са по-близки до реалността, използвайки обектно-ориентиран подход; това е методология, при която изискванията се формират въз основа на концепциите за класове и обекти, които съставляват речника на предметната област. .

     Характеристики на обектно-ориентираното програмиране.

     Обекти, класове, поведение на обекти, свойства, събития.

138. Литература към лекция 15.

139. 15.1. К. Фути, Н. Сузуки. Езици за програмиране и VLSI схеми. - М.: Мир, 1988. С. 85-98.

     15.2. Иън Съмървил. Софтуерно инженерство. - Addison-Wesley Publishing Company, 1992. P. ?-?

     15.3. Г. Буч. Обектно-ориентиран дизайн с примери за приложение: per. от английски. - М.: Конкорд, 1992.

     15.4. В.Ш.Кауфман. Програмни езици. Понятия и принципи. Москва: Радио и комуникация, 1993 г.

МИНИСТЕРСТВО НА ОБРАЗОВАНИЕТО И НАУКАТА

ДОНЕЦКА НАРОДНА РЕПУБЛИКА

ДЪРЖАВЕН ПРОФЕСИОНАЛЕН

ОБРАЗОВАТЕЛНА ИНСТИТУЦИЯ

"ДОНЕЦК ИНДУСТРИАЛЕН И ИКОНОМИЧЕСКИ КОЛЕЖ"

РАБОТЕЩА ПРОГРАМА

Учебна практика УП.01

професионален модул PM.01 Разработка на софтуерни модули за компютърни системи

специалност 09.02.03 "Програмиране в компютърни системи"

съставен от:

Волков Владимир Александрович, учител по компютърни дисциплини от квалификационна категория "специалист от най-висока категория", Държавна образователна институция "Донецк индустриален и икономически колеж"

Програмата е одобрена от: Вовк Павел Андреевич, директор на Smart IT Service

1. ПАСПОРТ НА ПРОГРАМАТА ЗА ПРАКТИКА
2. РЕЗУЛТАТИ ОТ ПРАКТИКАТА
3. СТРУКТУРА И СЪДЪРЖАНИЕ НА ПРАКТИКАТА
4. УСЛОВИЯ ЗА ОРГАНИЗИРАНЕ И ПРОВЕЖДАНЕ НА ПРАКТИКАТА
5. МОНИТОРИНГ И ОЦЕНКА НА РЕЗУЛТАТИТЕ ОТ ПРАКТИКАТА

1 ПАСПОРТ НА ПРОГРАМАТА ЗА УЧЕБНА ПРАКТИКА НАГОРЕ. 01

1.1 Място на учебна практика УП.01

Програмата за учебна практика UP.01 на професионален модул PM.01 „Разработване на програмни софтуерни модули за компютърни системи” специалност 09.02.03 „Програмиране в компютърни системи” » разширена група 09.00.00 "Информатика и компютърни технологии", по отношение на овладяването на основния вид професионална дейност (ВПД):

Разработване на софтуерни софтуерни модули за компютърни системи и свързаните с тях професионални компетенции (PC):

	Извършва разработване на спецификации за отделни компоненти.
	Извършване на разработване на код на софтуерен продукт на базата на готови спецификации на ниво модул.
	Извършване на отстраняване на грешки на програмни модули с помощта на специализирани софтуерни инструменти.
	Извършва тестване на софтуерни модули.
	Да се ​​оптимизира програмния код на модула.
	Разработване на компоненти за проектиране и техническа документация с помощта на езици за графични спецификации.

Програмата за учебна практика UP.01 на професионален модул PM.01 "Разработване на софтуерни софтуерни модули за компютърни системи" може да се използва в допълнителното професионално образование и професионално обучение на служители за специалности 09.02.03 Програмиране в компютърни системи със средно ( пълно) общо образование. Трудов опит не се изисква.

1.2 Цели и задачиучебна практика УП.01

За да овладее посочения вид професионална дейност и съответните професионални компетенции, студентът в хода на учебната практика UP.01 трябва:

имат практически опит:

разработване на алгоритъма на задачата и нейното изпълнение чрез компютърно проектиране;

разработване на код на софтуерен продукт по готова спецификация на ниво модул;

използване на инструменти на етапа на отстраняване на грешки в софтуерен продукт;

тестване на софтуерен модул по определен сценарий;

да може да:

извършват разработването на кода на програмния модул на съвременни езици за програмиране;

създаване на програма по разработения алгоритъм като отделен модул;

отстраняване на грешки и тестване на програмата на ниво модул;

съставяне на софтуерна документация;

използват инструменти за автоматизиране на подготовката на документация;

зная:

основни етапи на разработка на софтуер;

основни принципи на технологията за структурно и обектно-ориентирано програмиране;

основни принципи на отстраняване на грешки и тестване на софтуерни продукти;

методи и средства за разработване на техническа документация.

1.3 Брой седмици(часа) за развитието на програматаучебна практика УП.01

Само 1,5 седмици, 54 часа.

2 РЕЗУЛТАТИ ОТ ПРАКТИКАТА

Резултатът от учебната практика UP.01 на професионален модул PM.01 „Разработване на програмни софтуерни модули за компютърни системи” е развитието на общи компетентности (ОК):

	Име на резултата от практиката
	-
OK 2. Организират собствените си дейности, избират стандартни методи и методи за изпълнение на професионални задачи, оценяват тяхната ефективност и качество.
OK 3. Вземайте решения в стандартни и нестандартни ситуации и носете отговорност за тях.
OK 4. Търси и използва информацията, необходима за ефективно изпълнение на професионални задачи, професионално и личностно развитие.
OK 5. Използване на информационни и комуникационни технологии в професионалните дейности.
OK 6. Работете в екип и в екип, общувайте ефективно с колеги, ръководство, потребители.
OK 7. Поемете отговорност за работата на членовете на екипа (подчинените), за резултата от изпълнението на задачите.	-
	квалификации
OK 9. Ориентирайте се в условията на честа смяна на технологиите в професионалната дейност.

професионални компетенции (PC):

Вид професионална дейност		Име на резултатите от практиката
Овладяване на основния вид професионална дейност		използване на ресурси на локални и глобални компютърни мрежи; Управление на файлове с данни на локални, сменяеми устройства за съхранение, както и на дискове на локална компютърна мрежа и в Интернет; печат, тиражиране и копиране на документи на принтер и друга офис техника. текущ контрол под формата на отчет за всяка практическа работа. модулен квалификационен изпит.
		грамотност и точност на работа в приложни програми: текстови и графични редактори, бази данни, редактор на презентации; скоростта на търсене на информация в съдържанието на базите данни.
		точност и грамотност на настройките на електронната поща, сървърния и клиентския софтуер: скоростта на търсене на информация с помощта на технологии и услуги на Интернет; точност и грамотност при въвеждане и предаване на информация чрез интернет технологии и услуги.
		грамотност при използване на методи и средства за защита на информацията от неоторизиран достъп; коректност и точност Резервно копиеи възстановяване на данни;
		грамотност и точност при работа с файлови системи, различни файлови формати, програми за управление на файлове;
		поддържане на отчети и техническа документация.

3 СТРУКТУРА И СЪДЪРЖАНИЕ НА ПРОГРАМАТАУЧЕБНА ПРАКТИКА ДО.01

3.1 Тематичен план

Кодове на генерирани компетенции	Име на професионалния модул	Обхват на времето, назначен на практика (след седмици, часа)	Дати
PC 1.1 - PC 1.6	PM.01 "Разработване на софтуерни модули за компютърни системи"	1,5 седмици 54 часа

3.2 Практическо съдържание

дейности	Видове работни места		Наименование на учебните дисциплини, интердисциплинарни курсове, посочващи теми, осигуряване на изпълнението на видовете работа	Брой часове (седмици)
„Овладяване на основния вид професионална дейност »	Тема 1.Въведение. Алгоритми за решаване на задачи. Структура линеен алгоритъм. Структура цикличен алгоритъм. Алгоритъм на подпрограма (функция).	Формирани знания за основите на създаване на специални обекти
	Предмет2 . Околна среда Skratch (Scratch).	Формирани знания за основите на инструментите за автоматизация на процесите Формирани знания за основите на анимационните ефекти към обекти; използване на хипервръзки и бутони; демо настройка; презентации, записани в различни формати.	MDK.01.01 "Системно програмиране"
	Предмет 3 . Създаване на програма за обучение (урок по предмета).	Формирани знания за основите на анализа на данни с помощта на процесорни функции	MDK.01.02 "Приложно програмиране"
	Тема 4.Разработка на игрална програма.	Формирани знания за основите на изчисляване на крайните характеристики	MDK.01.01 "Системно програмиране"
	Тема 5.Графичен език за програмиране LabVIEW.	Формирани знания за основите на създаване на процесорен тест.	MDK.01.02 "Приложно програмиране"
	Предмет 6. Изграждане на приложение с помощта на LabVIEW.	Формирани знания за основите на диалога на потребителя със системата	MDK.01.02 "Приложно програмиране"
	Предмет 7 Повторно използване на фрагмент от програмата.	Формирани знания за операторите и функциите на системата.	MDK.01.02 "Приложно програмиране"
	Предмет 8 Семинар по LabVIEW. Охрана на труда при работа с компютър на работното място на потребителя.	Формирани знания за изчисляване на елементарни функции. Формирани знания по охрана на труда.	МДК.01.02 "Приложно програмиране". OP.18 "Охрана на труда"
	Предмет 9 Изводи. Съставяне на доклад от практиката.	Формират се умения за анализ на компютърни технологии, решаване на проблеми Формират се умения.	MDK.01.01 "Системно програмиране" MDK.01.02 "Приложно програмиране" MDK.04.01 "Офис софтуер"

4 УСЛОВИЯ ЗА ОРГАНИЗАЦИЯ И ПРОВЕЖДАНЕ

УЧЕБНА ПРАКТИКА НАГОРЕ. 01

4.1 Изисквания към документацията, необходими за практиката:

Работна програма на учебната практика УП.01 на професионален модул ПМ.01. „Разработване на софтуерни модули за компютърни системи“ е част от програмата за обучение на специалисти от средно ниво от Държавната професионална образователна институция „Донецки индустриално-икономически колеж“ в съответствие с държавния образователен стандарт за средно професионално образование по специалността 09.02.03 "Програмиране в компютърни системи", базиран на учебния план на специалността, работна програмапо дисциплините MDK.01.01 "Системно програмиране", MDK01.02 "Приложно програмиране", методически препоръки за образователна и методическа подкрепа на практиката на студенти, усвояващи образователни програми на средното професионално образование.

4.2 Изисквания за учебно-методическо осигуряване на практиката:

списък с одобрени задачи по вид работа, насоки за студентите за изпълнение на работата, препоръки за изпълнение на доклади от практиката.

4.3 Логистични изисквания:

организацията на производствената практика изисква наличието на класни стаи и лаборатории.

Офис оборудване и работни места:

места според броя на учениците (маса, компютър, стол);

работно място на учителя (маса, компютър, стол);

шкаф за съхранение на учебни помагала и носители на информация;

задачи за индивидуален подход към обучението, организация на самостоятелна работа и упражнения, ученик на компютър;

справочна и методическа литература;

набор от системни, приложни и обучителни програми за компютър на оптичен и електронен носител;

дневник за инструктаж на учениците по защита на труда;

набор от учебни помагала.

Технически средства за обучение:

табло за класната стая;

персонален компютър с лицензиран софтуер;

лазерен принтер;

• образователни компютри;

  комплект интерактивно оборудване (проектор, екран, високоговорители);

  средства за гасене на пожар (пожарогасител).

Оборудване на кабинета и работните станции на инструменти за разработка: персонални компютри (монитор, системен блок, клавиатура, мишка), набор от учебна и методическа документация, софтуер в съответствие със съдържанието на дисциплината (черупки на езици за програмиране).

Всички компютри в класа са свързани в локална мрежа, имат достъп до мрежово съхранение на информация и имат достъп до Интернет.

Комуникационно оборудване:

мрежови адаптери;

мрежови кабели;

WiFi безжично оборудване.

Компоненти за монтаж на мрежи, оборудване за монтаж.

4.4 Списък на учебни издания, Интернет ресурси, допълнителна литература

Основни източници:

Олифер В.Г. Мрежови операционни системи: учебник за университети / V.G. Olifer, N.A. Olifer. - 2-ро изд. - Санкт Петербург: Питър, 2009,2008. - 668 стр.:

Е. Таненбаум. ОПЕРАЦИОННА СИСТЕМА. Разработка и внедряване. Санкт Петербург: Питер, 2006. - 568 с.

Пупков К.А. Овладяване на операционната система Unix / К. А. Пупков, А. С. Черников, Н. М. Якушева. - Москва: Радио и комуникация, 1994. - 112 с.

Л. Бек Въведение в системното програмиране - М.: Мир, 1988г.

Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектиране на информационни системи / Москва: Бином, 2008. - 304 с.

Липаев, В. В. Софтуерно инженерство. Методически основи [Текст]: учеб. / В. В. Липаев; състояние. ун-т - Висше училище по икономика. - М.: TEIS, 2006. - 608 с.

Лаврищева Е. М., Петрухин В. А. Методи и средства за софтуерно инженерство. – Учебник

Иън Съмървил. Софтуерно инженерство, 6-то издание: Пер. от английски. — М. : Williams Publishing House, 2002.―624 p.

Excel 2010: професионално програмиране във VBA.: Пер. от английски. - М.: LLC “I.D. Уилямс”, 2012. - 944 с. : аз ще. - Парал. синигер. Английски

Фаулър М. Рефакторинг: Подобряване на съществуващ код. От англ.—Санкт Петербург: Символ Плюс, 2003.—432 с.

Допълнителни източници:

Волков В.А. МЕТОДИЧЕСКИ УКАЗАНИЯ за изпълнение на практическа работа по дисциплината "Системно програмиране", Донецк: DONPEK, 2015 г.

Волков В.А. Насокикъм изпълнението на курсов проект, Донецк: DONPEC, 2015.

Интернет- ресурси:

Системно програмиране [електронен ресурс] / Режим на достъп: http://www.umk3.utmn.ru.

Софтуер и интернет ресурси: http://www.intuit.ru

Литература по дисциплини - http://www.internet-technologies.ru/books/

Електронен учебник "Въведение в софтуерното инженерство" - http://www.intuit.ru/studies/professional_skill_improvements/1419/info

Електронен учебник "Технология на програмирането" - http://bourabai.kz/alg/pro.htm

4.5 Изисквания към ръководители на практика от учебно заведение и организация

Изисквания към ръководители на практика от учебно заведение:

инженерно-преподавателски състав: дипломирани преподаватели по интердисциплинарни курсове и общопрофесионални дисциплини. Опитът в организации от съответната професионална област е задължителен.

майстор индустриално обучение: наличие на 5–6 квалификационна категория със задължителен стаж в специализирани организации поне веднъж на 3 години. Опитът в организации от съответната професионална област е задължителен.

5 МОНИТОРИНГ И ОЦЕНКА НА РЕЗУЛТАТИТЕ

УЧЕБНА ПРАКТИКА НАГОРЕ. 01

Форма за отчитане на образователната практика UP.01 - доклад за практиката, изготвен в съответствие с изискванията на методическите препоръки.

резултати (овладени професионални компетенции)	Основни показатели резултат от подготовката	Форми и методи контрол
PC 1.1. Извършва разработването на спецификации за отделни компоненти	Разработване на алгоритъм за изпълнение на задачата и неговата реализация чрез компютърно проектиране	Експертно наблюдение и оценка на дейността на студентите в процеса на усвояване на учебната програма в практическите занятия, при извършване на работа по учебна и производствена практика.
PC 1.2. Извършване на разработване на код на софтуерен продукт на базата на готови спецификации на ниво модул.	Да познава основните принципи на технологията за структурно и обектно-ориентирано програмиране. Да се ​​извърши разработването на кода на програмния модул на съвременни езици за програмиране.
PC 1.3. Извършване на отстраняване на грешки на програмни модули с помощта на специализирани софтуерни инструменти	Извършване на отстраняване на грешки и тестване на програмата на ниво модул.
PC 1.4. Извършва тестване на софтуерни модули.	Създайте програма по разработения алгоритъм като отделен модул.
PC 1.5. Извършете оптимизация на кода на модула	Разработване на код на софтуерен продукт по готова спецификация на ниво модул.
PC 1.6. Разработване на компоненти за дизайн и техническа документация с помощта на езици за графични спецификации	Да познава методите и средствата за разработване на техническа документация. Подгответе софтуерна документация. Използвайте инструменти за автоматизиране на документацията.

Формите и методите за наблюдение и оценка на резултатите от обучението трябва да позволяват на учениците да проверяват не само формирането на професионални компетентности, но и развитието на общите компетентности и уменията, които ги осигуряват.

резултати (овладени общи компетенции)	Основни показатели за оценка на резултата	Форми и методи за контрол и оценяване
ОК 1. Разберете същността и социалната значимост на вашите бъдеща професияпроявяват постоянен интерес към него.	Демонстрация на постоянен интерес към бъдещата професия; - валидността на прилагането на овладени професионални компетенции;	Експертно наблюдение и оценка в практическите занятия при извършване на работа по производствена практика;
OK 2. Организират собствените си дейности, определят методите и средствата за изпълнение на професионалните задачи, оценяват тяхната ефективност и качество.	Обосновка на целеполагане, избор и прилагане на методи и методи за решаване на професионални проблеми; Извършване на самоанализ и корекция на резултатите от собствената работа	Оценяване в практическите занятия при изпълнение на работата; Наблюдение по време на практиката; Самоанализ
OK 3. Решавайте проблеми, оценявайте рисковете и вземайте решения в нестандартни ситуации.	Ефективността на вземането на решения за стандартни и нестандартни професионални задачи в определено време; Ефективността на плана за оптимизиране на качеството на извършената работа	Интерпретация на резултатите от наблюдението на дейностите на ученика в процеса на изпълнение на задачите
OK 4. Търси, анализира и оценява необходимата информация за поставяне и решаване на професионални проблеми, професионално и личностно развитие.	Подбор и анализ на необходимата информация за ясна и бързо изпълнениепрофесионални задачи, професионално и личностно развитие	Експертна оценка в процеса на работа; Самоконтрол в хода на поставяне и решаване на проблеми
OK 5. Използвайте информационни и комуникационни технологии за подобряване на професионалните дейности.	способност за използване на информационни и комуникационни технологии за решаване на професионални проблеми	оценка на заданията
OK 6. Работете в екип и екип, осигурете неговата сплотеност, общувайте ефективно с колеги, ръководство, потребители.	Способност за взаимодействие с група, учители, майстор на индустриално обучение
OK 7. Поставяйте цели, мотивирайте дейността на подчинените, организирайте и контролирайте работата им с поемане на отговорност за резултата от задачите.	- самоанализ и корекция на резултатите от собствената работа и работата на екипа	Наблюдение на хода на работата в групата в процеса на производствената практика
ОК 8. Самостоятелно определяйте задачите за професионално и личностно развитие, участвайте в самообразование, съзнателно планирайте напреднало обучение.	Организиране на самостоятелна работа по формирането на творчески и професионален образ; Организация на работата по самообразование и усъвършенстване квалификации	Наблюдение и оценка в процеса на производствена практика; Рефлексивен анализ (алгоритъм на ученическите действия); Дневник на практиката; Анализ на студентското портфолио
OK 9. Бъдете готови да промените технологиите в професионалните дейности.	Анализ на иновациите в областта на технологичните процеси за разработване и производство на облекла	Оценка на решенията на ситуационни проблеми; Делови и организационно-образователни игри; Наблюдение и оценка в практическите занятия, в процеса на производствената практика