Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Основы разработки программного обеспечения на примере языка С. Учебное пособие для СПО
.pdf
MAXNUMBER(1, 1, 1) ответ ?
Они дают значения, указывающие на 3-й, 2-й и 1-й параметры
соответственно. Совсем не очевиден результат для случая, когда все три
параметра имеют одинаковые значения.
Это как раз тот случай, когда следует вернуться к этапу постановки
требований и добавить в функциональные требования еще один пункт:
3.2. При одинаковых значениях параметров программа должна
выводить порядковый номер с наименьшим значением.
Тогда становится очевидным, что на входную тройку (1, 1, 1) ответ
должен быть 1. На тестовый пример (1, 2, 2) - ответ 2. Получение такого
решения потребует модификации первичной программной реализации.
Строгие отношения неравенства > потребуется сменить на , что
приведет к схеме, представленной на рис. 2.4(б)
.
Рис. 2.4(б). Модифицированная схема решения задачи
MAXNUMBER(A, B, C)
MAXNUMBER(1, 2, 3) ответ 3
MAXNUMBER(1, 3, 2) ответ 2
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
41
MAXNUMBER(3, 1, 2) ответ 1
MAXNUMBER(1, 1, 1) ответ 1
MAXNUMBER(1, 2, 2) ответ 2
Дополнительный тест на покрытие:
MAXNUMBER(1, 2, 2) ответ 3
Результат выполнения тест-модуля - отчет о прогоне теста тоже
является частью спецификации программы. Тесты, которые нельзя
провести в автоматическом режиме, проводятся вручную, и их
результаты добавляются в отчет о прогоне теста. Желательно по
завершении тестирования проверить не только то, что все требования к
программе были выполнены, но и то, что проверен весь программный
код и все ветви программы.
На рис. 2.4(б)
выделена ветвь, которая не была пройдена (покрыта)
первыми пятью тест-примерами (1, 2, 3), (1, 3, 2), (3, 1, 2), (1, 1, 1), (1, 2,
2). Поэтому специально для покрытия этой части кода добавлен еще
один набор входных значений (2, 1, 3), также выдающий номер третьего
параметра, но при вычислении которого была задействована не
пройденная ранее ветвь программы. Более детально вопросы
тестирования и покрытия кода будут рассмотрены позже.
2.3. пример оформления задачи
Задание
Напишите программу, выполняющую кодирование входной строки
перестановкой символов по правилу 2-3-1.
Первый этап работы
Соображения
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
42
Необходимо представить себе поведение программы в целом. Хотим ли
мы получить программу кодирования одной единственной строки, или
желателен диалоговый режим управления кодированием группы строк,
каждая из которых вводится после некоторого приглашающего
сообщения? Из общих соображений простоты общения и проверки
работоспособности второй вариант (циклический ввод) представляется
более предпочтительным.
Выводы
Первый раздел требований (спецификации) может быть сформулирован
так:
1. Общее описание задачи.
Необходимо разработать программу, выполняющую ввод и
преобразование строки символов путем их перестановки по правилу 23-1. Программа должна обрабатывать строки последовательно, каждый
раз предупреждая пользователя о необходимости очередного ввода.
Соображения
Теперь необходимо принять решения по основным позициям внешнего
проекта программы.
Что такое входная строка (последовательность символов,
ограничения на входной алфавит)?
Существенно ли деление строки на слова (пробел как спецсимвол
алфавита, разделитель/ограничитель слов)?
Может ли в строку (в слово) быть включен символ, не имеющий
адекватного представления на клавиатуре, или символразделитель как часть слова?
Существует ли ограничение на длину строки?
Как вводится входная строка (ограничитель строки и признак
конца ввода)?
Как выходная (преобразованная) строка сопоставляется с входной
(формат вывода)?
Как производится преобразование при длине входной строки, не
кратной трем?
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
43
Каждый автор может принять собственное решение по этим пунктам. В
любом случае свои решения в рамках лабораторного практикума
необходимо согласовать с преподавателем.
Выводы
В данном варианте предлагается несколько усложненный вариант
требований, предполагающий разбивку строки на слова и выполнение
заданных правил перестановки только в пределах отдельного слова. В
нем не накладывается сложных ограничений на разделитель слов. Им
может быть многоточие или произвольная последовательность точек,
запятых и пробелов.
2. Внешний проект.
2.1. Вход.
2.1.1. Входная строка должна вводиться с клавиатуры после вывода на
экран приглашающего сообщения.
2.1.2. Входная строка представляет собой последовательность слов,
разделенных (ограниченных) символами-разделителями ","; "."; " "
(запятая, точка, пробел). Признаком конца ввода строки с клавиатуры
является нажатие клавиши "Enter". Длина строки не должна превышать
длины строки экрана (80 символов).
2.1.3. Слово входной строки может состоять из букв (русского и
латинского алфавита) и/или цифр.
2.1.4. Первому слову в строке может предшествовать
последовательность пробелов.
2.1.5. Признаком конца слова является любой символ-ограничитель (см.
2.1.2). Последнее слово строки может не иметь за собой ограничителя.
2.1.6. Ввод пустой строки является указанием пользователя на
необходимость закончить работу программы.
2.2. Вывод.
2.2.1. Сообщения программы. Сообщения программы выводятся с
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
44
новой строки. Курсор после вывода устанавливается на новую строку.
2.2.1.1. "Введите строку для кодирования" - приглашающее сообщение
программы. Указывает на необходимость ввода с клавиатуры входной
строки.
2.2.1.2. "Работа закончена" - завершающее сообщение программы.
Выводится после ввода пустой строки. Работа программы
заканчивается.
2.2.1.3. "Ошибка во входной строке" - информационное сообщение
программы. Выводится после ввода входной строки, не
соответствующей пункту 2.1. Работа программы продолжается с ввода
новой строки.
2.2.2. Результат.
2.2.2.1. Выходная строка представляет собой последовательность
преобразованных слов, организованную (в смысле разделителей и
ограничителей) идентично входной строке.
2.2.2.2. Преобразованные слова выходной строки получаются из
соответствующих слов входной строки применением к ним процедуры
кодирования.
2.2.2.3. При выводе на экран выходная строка располагается строго под
входной (разделитель под разделителем, слово под словом).
3. Функция преобразования.
3.1. Преобразование входной строки. Преобразованию подвергаются
только правильные строки.
3.1.1. Преобразование слов входной строки производится путем
перестановки каждой тройки символов слова в порядке 2-3-1.
3.1.2. Если в слове количество символов не кратно трем, то
преобразование последних символов слова должно производиться по
сокращенной схеме.
3.1.2.1. Последние два символа переставляются в порядке 2-1.
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
45
3.1.2.1. Единственный последний символ слова остается на своем
месте.
3.1.3. Символы-разделители (ограничители) слов остаются в выходной
строке на тех же местах, которые они занимали во входной строке.
3.2. Контроль входной строки.
3.2.1. Входная строка считается правильной, если она соответствует
требованиям, описанным в пункте 2.1.
3.2.2. Если обнаружено, что входная строка не соответствует пункту 2.1,
то на экран (в стандартный поток вывода) должно выдаваться
сообщение пункта 2.2.1.3 и снова должен запрашиваться ввод входной
строки.
3.3. Вывод результата.
3.3.1. Перед ожиданием ввода строки программа должна вывести на
экран (в стандартный поток вывода) сообщение пункта 2.2.1.1 и
перевести курсор на новую строку для ввода строки.
3.3.2. Выходная строка должна выводиться строго под входной строкой.
3.3.3. После ввода пустой входной строки программа должна вывести
на экран (в стандартный поток вывода) сообщение пункта 2.2.1.2 и
завершить свою работу.
4. Требования по проверке функций программной реализации.
4.1. Проверить, что при правильном вводе строки производится ее
преобразование в соответствии с п.п. 3.1.
4.1.1. В том числе проверить, что правильно обрабатывается строка,
начинающаяся с пробелов.
4.1.2. В том числе проверить, что правильно обрабатывается строка,
содержащая слова, длина которых не кратна трем.
4.1.3. В том числе проверить, что правильно обрабатывается (остается
без изменения) строка, состоящая из одних разделителей.
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
46
4.2. Проверить, что при вводе пустой строки производится вывод
сообщения п.п. 2.3.2 и выполнение программы заканчивается.
4.3. Проверить, что выводится сообщение п.п. 2.3.3 и повторяется
приглашение к вводу как реакция программы на неправильный ввод
строки.
4.3.1. Строка содержит символы, отличные от пробелов, перед первым
словом.
4.3.2. В строке встретился недопустимый символ алфавита
(недопустимый разделитель слов или недопустимый символ в слове).
4.3.3. Длина строки превышает 80 символов (не считая признака конца
строки).
4.4. Проверить, что выходная строка располагается с начала строки
экрана и строго под значением входной строки, в том числе при длине
строки, строго равной 80 символам.
Замечания
В данном варианте требования по проверке функций программной
реализации сгруппированы в соответствии с описанием интерфейса
(раздел спецификации 2). В некоторых случаях удобнее разрабатывать и
структурировать требования по проверке в соответствии с описанием
функций проектируемой системы (раздел спецификации 3).
Второй этап работы
Соображения
Работа над программной реализацией должна начинаться с
проектирования основной последовательности действий и/или
основных информационных объектов, подлежащих обработке.
Последнее предпочтительней, так как дает хорошее основание к
модульной декомпозиции программы. Если проще представить себе
процедурную форму описания, то, записав последовательность
проектируемых действий в виде предложений естественного языка,
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
47
можно затем проанализировать глагольные группы и существительные.
Существительные, особенно подлежащее, часто являются хорошими
кандидатами для информационных объектов. Глаголы - кандидаты в
процедуры (операции над объектами). Например, в нашем случае:
(1) ввести входную строку;
(2) если строка пустая, то закончить работу;
(3) преобразовать входную строку;
(4) вывести преобразованную строку;
(5) ввести очередную входную строку и вернуться к действию (2).
Даже самый простой предварительный анализ подобного описания
позволяет нам выделить основной объект "входную строку" и список
действий: "ввести", "преобразовать", а также операцию "проверка
состояния - строка пустая". Если продолжать декомпозицию дальше, то
легко можно выделить объект "сообщение" и соответствующую ему
операцию "вывести". Конечно, многие проектные решения
определяются программистом на основании его собственного опыта,
интуиции, но во всех случаях рекомендуется рассматривать и оценивать
несколько вариантов. Например, форма представления строки - список
в связном представлении или массив; параметр процедуры "вывести
сообщение" - текст сообщения или его номер и т.п.
Выводы
Конечно, все сказанное выше применимо только при разработке
достаточно простых задач, объем документации которых не превышает
нескольких десятков страниц. В случае выполнения коллективной
работы над большим программным комплексом (десятки и сотни тысяч
строк программного кода) должны применяться более сложные
процедуры и приемы организации и хранения документации,
взаимодействия разработчиков.
2.4. ГОСТ Р 51904-2002
Созданный специально для встроенных систем, ГОСТ Р 51904-2002
"Программное обеспечение встроенных систем. Общие требования к
разработке и документированию" регламентирует общие требования к
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
48
разработке и документированию программного обеспечения. Во многом
этот ГОСТ повторяет общеизвестные международные стандарты типа
DO-178B, принятые при сертификации авиационного встроенного
программного обеспечения.
Одним из принципиальных моментов является использование не
водопадной модели жизненного цикла проекта, выделяющей его
отдельные стадии (этапы), а процессной модели. Таким образом, в
рамках ГОСТ Р 51904-2002 и DO-178B программный проект и
производство программного продукта рассматриваются как
совокупность параллельно текущих и взаимодействующих процессов.
В документе определяются шесть основных процессов программного
проекта (рис. 2.5
), из которых три можно отнести к производственным:
планирование, разработка и верификация, а три - к поддерживающим:
обеспечение качества, взаимодействие с сертифицирующим органом и
управление конфигурациями. При этом разработка рассматривается как
совокупность процессов определения требований, проектирования,
кодирования и интеграции ПО. А одним из принципиальных свойств
документации декларируется трассируемость.
Рис. 2.5. Основные и поддерживающие процессы разработки
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
49
Трассируемость должна обеспечивать прослеживаемость того:
как требования отражены в архитектуре ПО;
каким образом те или иные функции реализованы в коде;
какие тесты проверяют работоспособность указанных функций.
Как правило, трассируемость реализуется в виде указателей (опорных
точек, якорей) и ссылок. Например, каждому требованию присваивается
свой уникальный номер - его указатель, а в тесте, проверяющем
реализацию этого требования, ставится ссылка на этот номер.
Прослеживание трассируемости должно обеспечивать проверку того,
что:
все требования отображаются на архитектуру ПО и отражены в
требованиях более низкого уровня;
все требования реализованы в программном коде;
все требования проверены в процессе верификации ПО;
все элементы программного кода соотнесены с требованиями
высокого или низкого уровня, т.е. отсутствуют
недокументированные функции и т.п.
Одним из ключевых вопросов, определяющих требования к
документированию проекта в рамках данного стандарта, является
понятие критичности отказов системы, которые предлагается
классифицировать по следующим категориям.
Категория A - катастрофическая: отказная ситуация, препятствующая
безопасному функционированию объекта управления.
Категория B - опасная/критическая: отказная ситуация, приводящая к
уменьшению возможностей объекта управления или способности
персонала справиться с неблагоприятными эксплуатационными
режимами, при которых возникают:
большое снижение гарантийных резервов или функциональных
возможностей;
крайне тяжелое положение или перегрузки, которые могут
вызвать неточное или неполное выполнение задачи;
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
50
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]