2) Строки ввода, кроме первых трех, игнорируются.
3) Если какая-либо из первых трех строк содержит более одного целого числа, то программа завершает работу и выдает сообщение.
ОШИБКА ВВОДА – допускается только одно целое число на строке.
ПРИМЕР:
ввод ® – 3
2
+ 17
вывод ® – 3 2 + 17
Этот шаг программирования является наиболее трудным. На данной стадии постановка задачи должна быть превращена в алгоритм. Поэтому алгоритмист должен обладать достаточным опытом программирования и подходить к каждой новой задаче, опираясь на твердо установленную методику проектирования. К сожалению, в настоящее время все большие программы содержат ошибки, что приводит к скверным проектам. Плохие проекты в свою очередь являются следствием сложности задач и использования неадекватных методов проектирования. Чтобы избежать ошибок в программах, алгоритмисты должны использовать тщательно разработанные процедуры конструирования, основанные на правилах логического вывода.
Существуют две основные модели вывода:
Первая модель известна как дедуктивный вывод. Эту форму логического мышления обессмертил знаменитый сыщик Шерлок Холмс. Дедуктивная логика применяет общие правила к конкретным случаям. Например, Холмс мог вывести конкретное утверждение «Дворецкий является убийцей» из более общих сведений «Убийца-блондин», а «Дворецкий является единственным блондином, которого можно подозревать».
Вторая модель – это индуктивный вывод, который является противоположностью дедуктивному выводу. Индуктивная логика извлекает общие заключения из отдельных случаев. Например, индуктивный вывод может быть использован, чтобы обосновать общее заключение «солнце поднимается на востоке» на основании многих отдельных наблюдений того, что солнце всегда поднималось на востоке.
Эти два процесса вывода умозаключений – дедукция (от общего к частному) и индукция (от частного к общему) – тесно связаны с двумя наиболее широко распространенными методами проектирования: «сверху вниз» и «снизу вверх». Подобно дедукции, проектирование «сверху вниз» начинается с большой задачи, которая разбивается на подзадачи. Например, проектировщик нового холодильника-морозильника на основании исходного множества спецификаций агрегата (т.е. постановки задачи) должен дать детальные схемы и спецификации окончательного продукта (т.е. проект).
Если при этом он использует метод проектирования «сверху вниз», то единственная задача проектирования может быть разбита на две меньшие подзадачи: (1) проектирование холодильного агрегата и (2) проектирование морозильника.
Однако можно воспользоваться методом проектирования «снизу вверх» и начать с проектирования холодильного компрессора, а затем охлаждающих труб, агрегата или холодильной камеры. В таком случае этот выбор будет налагать определенные ограничения на весь проект.
Задача проектировщика – создание алгоритма, выполняющего функции связующего звена между постановкой задачи и готовой для исполнения программой. Проверку созданного алгоритма, т. е. насколько последний отражает постановку задачи, осуществляет системный аналитик. В силу этого и системный аналитик, и проектировщик должны уметь читать и понимать алгоритм. Каждый алгоритм записывается на некотором псевдоязыке. Алгоритмы, называемые также псевдокодами, не могут быть выполнены ни на каком компьютере.
Работа кодировщика заключается в переводе алгоритма в программу. Для создания полной, точной и понятной программы необходимы соответствующие методы записи программ. Например, кулинарные рецепты обычно записываются на естественных языках, таких, как английский, французский, русский или японский. Программы же пишутся на языках программирования. В настоящее время ни один из естественных языков нельзя использовать в качестве языка программирования, так как они чересчур сложны, чтобы их могли «понимать» машины. В отличие от естественных, языки программирования созданы специально для такого представления решения задачи, которое может быть выполнено компьютером.
Прежде чем завершить работу, кодировщик должен убедиться, что программа соответствует псевдокоду. Затем системный аналитик, алгоритмист и, что самое главное, пользователь должны протестировать и подтвердить, что она работает правильно. После этого можно считать, что программа готова для передачи пользователю в комплекте со всей необходимой документацией.
Однако на этом программирование не заканчивается; далее следует шаг сопровождения. Дело в том, что в программе могут быть ошибки, обусловленные либо неадекватной постановкой задачи, либо тем, что проект не удовлетворяет постановке задачи или программа не соответствует проекту. Какова бы ни была причина, пользователь вправе потребовать корректировки программы, поскольку он не представлял, что программа будет работать таким образом. Исправление ошибок является одной из главных задач сопровождения программ. Другой не менее важной задачей сопровождения программ является ее модификация, т. е. добавление в программу новых возможностей или изменение существующих. Пользователь может изменить требования к работе программы, что, в свою очередь, приведет к необходимости ее переписать. Сложность операций по сопровождению программы зависит от типа изменений, которые должны быть сделаны: в худшем случае может потребоваться полная переработка программы от постановки до кодирования. Обычно на сопровождение программы затрачивается большее время, чем на ее создание.
1.1.5 Программная документация
Последней составляющей процесса программирования является документирование. Оно включает широкий спектр описаний, облегчающих процесс программирования и обогащающих результирующую программу. Постоянное документирование должно составлять неотъемлемую часть каждого шага программирования. Постановка задачи, проектные документы, алгоритмы и программы – все это документы. Внутренняя документация, включенная непосредственно в программу, облегчает чтение кода. Назначение учебного пособия (еще одной формы документации) – научить пользователя применять новую программу; справочное руководство позволяет ознакомиться с описанием команд программного обеспечения.
Вывод к п.1.1.
Согласно модели, представленной в данной главе, программирование можно разделить на четыре шага: постановку задачи, проектирование решений, кодирование программы, сопровождение программы. Дополнительно модель включает документирование программы как действия, которые необходимо выполнять в течение всего процесса программирования.
Модель программирования построена специально для решения больших проблем, так как именно они представляют интерес для специалистов в области информатики. Тем не менее, на практике важно использовать тщательно выбранные инженерные методики проектирования программ независимо от размера задач: навыки, приобретенные в процессе решения более мелких задач, могут быть закреплены и успешно реализованы при решении больших задач.
Следует помнить, что хорошее программирование – это не кодирование быстро найденного решения с помощью любой подходящей методики, а тщательно инструментированная инженерная процедура, позволяющая создать полное, точное и легко понимаемое (ясное) программное обеспечение.
1.2 Определение ЖЦПО по Леману
В самом общем случае можно считать, что жизненный цикл программной системы состоит из трех фаз:
определения;
реализации;
обслуживания.
1.2.1 Определение системы
Процесс создания ПО начинается с практических изысканий, ведущих к системному анализу, задача которого состоит в определении общих требований к системе и программам. Такой анализ должен, прежде всего, установить реальные потребности и цели и по возможности выявить имеющиеся методы, позволяющие достичь поставленной цели. При необходимости анализ может основываться на математических или иных формальных схемах. Считается, что при любом подходе указанный анализ должен иметь определенную структуру и проводиться в соответствии с некоторой теорией. Анализ и внесение уточнений, осуществляемые совместно с аналитиками и потенциальными пользователями, должны привести к выработке окончательной спецификации требований.
Процесс составления такой спецификации имеет целью получение правильного технического задания, полного в смысле отражения требований и согласованного с определением реализации. За составлением спецификаций следует фаза проектирования, смысл которой состоит в идентификации и структуризации данных, их преобразовании и организации их передачи. Кроме того, на этой фазе необходимо добиться в определенном смысле оптимального распределения функции системы, выбрать алгоритм и процедуры, а также обозначить системные компоненты и связь между ними.
Завершив проектирование можно начинать реализацию системы. Однако на практике фаза проектирования и реализации перекрываются. Таким образом, по мере осуществления иерархического процесса разбиения анализ некоторых элементов системы может быть признан достаточно полным для перехода к реализации, в то время как другие элементы требуют дальнейшего уточнения.