Этапы рождения задач

1. Введение.
Внедрение электронно-вычислительных машин, современных средств переработки и передачи информации послужило началом нового процесса, называемым информатизацией общества. Широкое распространение получил научно-технический прогресс. В настоящее время одним из направлений научно-технического прогресса является компьютеризация практически всех сфер человеческой деятельности.
Сейчас компьютер является неотъемлемой частью работы людей. Компьютеры ис-пользуются в школах и университетах. Они помогают систематизации полученные данных как в рабочих целях, так и в учебных.
Данном курсовом работе рассмотрен рассмотрено моделирование программных продуктов, а также этапы решения задач по созданию программ.
Проектирование алгоритмов и программ — наиболее ответственный этап жизненного цикла программных продуктов, определяющий, насколько создаваемая программа соответ-ствует спецификациям и требованиям со стороны конечных пользователей. Затраты на соз-дание, сопровождение и эксплуатацию программных продуктов, научно-технический уро-вень раз¬работки, время морального устаревания и многое другое — все это также зависит от про¬ектных решений.
2. Классификация методов проектирования программных продуктов
Методы проектирования алгоритмов и программ очень разнообразны, их можно клас¬сифицировать по различным признакам, важнейшими из которых являются:
■       степень автоматизации проектных работ;
■       принятая методология процесса разработки.
По степени автоматизации проектирования алгоритмов и программ можно выделить:
■       методы традиционного (неавтоматизированного) проектирования;
■ методы автоматизированного проектирования (CASE-технология и ее элемен-ты). Неавтоматизированное проектирование алгоритмов и программ преимущественно ис-пользуется при разработке небольших по трудоемкости и структурной сложности про¬граммных продуктов, не требующих участия большого числа разработчиков. Трудоемкость разрабатываемых программных продуктов, как правило, небольшая, а сами программные продукты имеют преимущественно прикладной характер.
При нарушении этих ограничений заметно снижается производительность труда раз¬работчиков, падает качество разработки, и, как ни парадоксально, увеличиваются трудозат¬раты и стоимость программного продукта в целом.
Автоматизированное проектирование алгоритмов и программ возникло с необходи¬мостью уменьшить затраты на проектные работы, сократить сроки их выполнения, Создать типовые "заготовки" алгоритмов и программ, многократно тиражируемых для различных разработок, координации работ большого коллектива разработчиков, стандартизации алго¬ритмов и программ.
Автоматизация проектирования может охватывать все или отдельные этапы жизнен¬ного цикла программного продукта, при этом работы этапов могут быть изолированы друг от дру-га либо составлять единый комплекс, выполняемый последовательно во времени. Как прави-ло, автоматизированный подход требует технического и программного "перевооруже¬ния" труда самих разработчиков (мощных компьютеров, дорогостоящего программного ин¬струментария, а также повышения квалификации разработчиков и т.п.).
Автоматизированное проектирование алгоритмов и программ под силу лишь крупным фирмам, специализирующимся на разработке определенного класса программных продук¬тов, занимающих устойчивое положение на рынке программных средств.
Проектирование алгоритмов и программ может основываться на различных подходах, среди которых наиболее распространены:
■       структурное проектирование программных продуктов;
■       информационное моделирование предметной области и связанных с ней прило-жений;
■ объектно-ориентированное проектирование программных продуктов.
В основе структурного проектирования лежит последовательная деком¬позиция, целе-направленное структурирование на отдельные составляющие. Начало разви¬тия структурного проектирования алгоритмов и программ падает на 60-е гг. Методы структурного проектиро-вания представляют собой комплекс технических и организацион¬ных принципов системного проектирования.
Типичными методами структурного проектирования являются:
■ нисходящее проектирование, кодирование и тестирование программ;
■       модульное программирование;
■       структурное проектирование (программирование) и др. В зависимости от объек-та структурирования различают:
■       функционально-ориентированные методы — последовательное разложение за-дачи или целостной проблемы на отдельные, достаточно простые составляющие, обладаю¬щие функциональной определенностью;
■       методы структурирования данных.
Для функционально-ориентированных методов в первую очередь учитываются задан¬ные функции обработки данных, в соответствии с которыми определяется состав и логика работы (алгоритмы) отдельных компонентов программного продукта. С изменением содер¬жания функций обработки, их состава, соответствующего им информационного входа и вы¬хода требуется перепроектирование программного продукта. Основной упор в структурном подходе делается на моделирование процессов обработки данных.
Для методов структурирования данных осуществляется анализ, структурирование и создание моделей данных, применительно к которым устанавливается необходимый состав функций и процедур обработки. Программные продукты тесно связаны со структурой обра¬батываемых данных, изменение которой отражается на логике обработки (алгоритмах) и обязательно требует перепроектирования программного продукта.
Структурный подход использует:
■       диаграммы потоков данных (информационно-технологические схемы) — пока-зывают процессы и информационные потоки между ними с учетом "событий", инициирую-щих процессы обработки;
■ интегрированную структуру данных предметной области (инфологическая мо-дель, ER-диаграммы);
■ диаграммы декомпозиции — структура и декомпозиция целей, функций управ-ления, приложений;
■ структурные схемы — архитектура программного продукта в виде иерархии взаимо¬связанных программных модулей с идентификацией связей между ними, детальная логика обработки данных программных модулей (блок-схемы).
Для полного представления о программном продукте необходима также текстовая ин¬формация описательного характера.
Еще большую значимость информационные модели и структуры данных имеют для информационного моделирования предметной области, в основе которого положение об оп-ределяющей роли данных при проектировании алгоритмов и программ. Подход появился в условиях развития программных средств организации хранения и обработки данных.
Один из основоположников информационной инженерии — Дж.Мартин — выделяет следующие составляющие данного подхода:
■       информационный анализ предметных областей (бизнес-областей);
■       информационное моделирование — построение комплекса взаимосвязанных моделей данных;
■       системное проектирование функций обработки данных;
■       детальное конструирование процедур обработки данных.
Первоначально строятся информационные модели различных уровней представления:
■       информационно-логическая модель, не зависящая от средств программной реа-лизации хранения и обработки данных, отражающая интегрированные структуры данных пред¬метной области;
■       даталогические модели, ориентированные на среду хранения и обработки дан-ных. Даталогические модели имеют логический и физический уровни представления. Физи¬ческий уровень соответствует организации хранения данных в памяти компьютера. Логичес¬кий уровень данных применительно к СУБД реализован в виде:
■       концептуальной модели базы данных — интегрированные структуры данных под уп¬равлением СУБД;
■       внешних моделей данных — подмножество структур данных для реализации прило¬жений.
Средствами структур данных моделируются функции предметной области, прослежи¬вается взаимосвязь функций обработки, уточняется состав входной и выходной информа¬ции, логика преобразования входных структур данных в выходные. Алгоритм обработки данных можно представить как совокупность процедур преобразований структур данных в соответ-ствии с внешними моделями данных.
Выбор средств реализации базы данных определяет вид даталогических моделей и, следовательно, алгоритмы преобразования данных. В большинстве случаев используется ре-ляционное представление данных базы данных и соответствующие реляционные языки для программирования (манипулирования) обработки данных СУБД и реализации алгорит¬мов обработки. Данный подход использован во многих CASE-технологиях.
Объектно-ориентированный подход к проектированию программных продуктов осно¬ван на:
■       выделении классов объектов;
■       установлении характерных свойств объектов и методов их обработки;
■       создании иерархии классов, наследовании свойств объектов и методов их об-работки. Каждый объект объединяет как данные, так и программу обработки этих данных и от¬носится к определенному классу. С помощью класса один и тот же программный код мож-но использовать для относящихся к нему различных объектов.
Объектный подход при разработке алгоритмов и программ предполагает:
■       объектно-ориентированный анализ предметной области;
- анализ предметной области и вы¬деление объектов, определение свойств и методов обра-ботки объектов, ус¬тановление их взаимосвязей.
■ бъектно-ориентированное проектирование;
- соединие процесса объект¬ной декомпозиции и представления с использованием моделей данных про¬ектируемой системы на логическом и физическом уровнях, в статике и динамике.
Для проектирования программных продуктов разработаны объектно-ориентированные
технологии , которые включают в себя специализированные языки программирования и ин-струментальные средства разработки пользовательского интерфейса.
Традиционные подходы к разработке профаммных продуктов всегда подчеркивали различия между данными и процессами их обработки. Так, технологии, ориентированные на информационное моделирование, сначала специфицируют данные, а затем описывают про-цессы, использующие эти данные. Технологии структурного подхода ориентированы, в пер-вую очередь, на процессы обработки данных с последующим установлением необходи¬мых для этого данных и организации информационных потоков между связанными процес¬сами.
Объектно-ориентированная технология разработки профаммных продуктов объеди¬няет данные и процессы в логические сущности — объекты, которые имеют способность на-следовать характеристики (методы и данные) одного или более объектов, обеспечивая тем самым повторное использование профаммного кода. Это приводит к значительному умень-шению затрат на создание профаммных продуктов, повышает эффективность жиз¬ненного цикла профаммных продуктов (сокращается длительность фазы разработки).При выполне-нии программы объекту посылается сообщение, которое инициирует обработку данных объ-екта.
3. Этапы решения задачи
При традиционной неавтоматизированной разработке программ независимо от принятого метода проектирования и используемого инструментария выполняют следующие работы.
3.1. Составление технического задания на программирование
Данная работа соответствует этапу анализа и спецификации программ жизненного цикла программных продуктов.
При составлении технического задания требуется:
■       определить платформу разрабатываемой программы — тип операционной системы (например, для IBM PC-совместимых машин делается выбор операционной среды: MS DOS, Windows, Windows NT либо Unix, OS/2);
■       оценить необходимость сетевого варианта работы программы (определяется про¬граммное обеспечение (ПО) вычислительной сети — Windows NT, допустимая номен¬клатура программного обеспечения сетевой обработки);
■       определить необходимость разработки программы, которую можно переносить на раз¬личные платформы;
■       обосновать целесообразность работы с базами данных под управлением СУБД.
На этом же этапе выбирают методы решения задачи; разрабатывают обобщенный ал¬горитм решения комплекса задач, функциональную структуру алгоритма или состав объек¬тов, определяют требования к комплексу технических средств системы обработки информа-ции, интерфейсу конечного пользователя.
3.2. Технический проект
На данном этапе выполняется комплекс наиболее важных работ, а именно:
■       с учетом принятого подхода к проектированию программного продукта разраба-тыва¬ется детальный алгоритм обработки данных или уточняется состав объектов я их свойств, методов обработки, событий, запускающих методы обработки;
■       определяется состав общесистемного программного обеспечения, включающий базо¬вые средства (операционную систему, модель СУБД электронные таблицы, методо-ориентированные и функциональные ППП промышленного назначения и т.п.);
■       разрабатывается внутренняя структура программного продукта, образованная отдель¬ными программными модулями;
■       осуществляется выбор инструментальных средств разработки программных мо-дулей. Работы данного этапа в существенной степени зависят от принятых решений по тех¬нической части системы обработки данных и операционной среде, от выбранных инстру¬ментальных средств проектирования алгоритмов и программ, технологии работ.
Например: Для создания MS DOS-приложений может быть использован язык про¬граммирования Visual Basic for DOS Standard, Fortran 5.1, Visual C++ for Windows. Если не-обходима переносимость программ на другие ЭВМ или другие операционные платформы, выбирается среда Windows NT.
При разработке программ, работающих в среде Windows, возможно применение тех¬нологии OLE 2.0 для создания приложений, включающих объекты других приложе¬ний. Определяется способ использования объектов: внедрение (embedding) или связывание (linking).
Приложение может работать с базами данных различных СУБД, для этого служит стандарт-ная технология интерфейса Open Database Connectivity (ODBC). Работа в ре¬жиме телекомму-никаций обеспечивается стандартной технологией Messaging Applica¬tion Program Interface (MAPI).
3.3.  Рабочая документация (рабочий проект)
На данном этапе осуществляется адаптация базовых средств программного обеспече-ния (операционной системы, СУБД, методо-ориентированных ППП, инструментальных сред конечного пользователя — текстовых редакторов, электронных таблиц и т.п.). Выполняется разработка программных модулей или методов обработки объектов — собственно програм¬мирование или создание программного кода. Проводятся автономная и комплексная отлад¬ка программного продукта, испытание работоспособности программных модулей и базовых программных средств. Доя комплексной отладки готовится контрольный пример, который позволяет проверить соответствие возможностей программного продукта задан¬ным специ-фикациям.
Основной результат работ этого этапа — также создание эксплуатационной докумен¬тации на программный продукт:
■       описание применения — дает общую характеристику программного изделия с указани¬ем сферы его применения, требований к базовому программному обеспечению, ком¬плексу технических средств;
■      руководство пользователя — включает детальное описание функциональных возмож¬ностей и технологии работы с программным продуктом. Данный вид документации ориентирован на конечного пользователя и содержит необходимую информацию для само-стоятех. чего освоения и нормальной работы пользователя (с учетом требуемой квалифика-ции пользователя);
■      руководство программиста (оператора) — указывает особенности установки (ин¬сталляции) программного продукта и его внутренней структуры — состав и назначе¬ние мо-дулей, правила эксплуатации и обеспечения надежной и качественной работы программного продукта.
В ряде случаев на данном этапе для программных продуктов массового применения создаются обучающие системы, демоверсии, гипертекстовые системы помощи.
3.4. Ввод в действие
Готовый программный продукт сначала проходит опытную эксплуатацию (пробный рынок продаж), а затем сдается в промышленную эксплуатацию (тиражирование и распро-стране¬ние программного продукта).
4. Структурное проектирование и программирование
 Нисходящее проектирование
Метод нисходящего проектирования предполагает последовательное разло¬жение общей функции обработки данных на простые функциональные элементы ("сверху-вниз").
В результате строится иерархическая схема, отражающая состав и взаимоподчинен¬ность от-дельных функций, которая носит название функциональная структура алгоритма (ФСА) при-ложения.
Последовательность действий по разработке функциональной структуры алгоритма приложения:
■       определяются цели автоматизации предметной области и их иерархия (цель-подцель);
■       устанавливается состав приложений (задач обработки), обеспечивающих реали-зацию поставленных целей;
■       уточняется характер взаимосвязи приложений и их основные характеристики (инфор¬мация для решения задач, время и периодичность решения, условия выполнения и
др);
■       определяются необходимые для решения задач функции обработки данных;
■       выполняется декомпозиция функций обработки до необходимой структурной слож¬ности, реализуемой предполагаемым инструментарием.
Подобная структура приложения отражает наиболее важное — состав и взаимосвязь функций обработки информации для реализации приложений, хотя и не рас¬крывает логику выполнения каждой отдельной функции, условия или периодичность их вы¬зовов.
Разложение должно носить строго функциональный характер, т.е. отдельный элемент ФСА описывает законченную содержательную функцию обработки информации, которая предполагает определенный способ реализации на программном уровне.
Функции ввода-вывода информации рекомендуется отделять от функций вычисли¬тельной или логической обработки данных.
По частоте использования функции делятся на:
■       однократно выполняемые;
■       повторяющиеся.
Степень детализации функций может быть различной, но иерархическая схема долж-на давать представление о составе и структуре взаимосвязанных функций и общем алгорит-ме обработки данных. Широко используемые функции приобретают ранг стандартных (встро¬енных) функций при проектировании внутренней структуры программного продукта.
Например: Некоторые функции, например, далее неразложимы на составляю¬щие: они предполагают непосредственную программную реализацию. Другие функции, могут быть представлены в виде структурного объединения более простых функций.. Для всех функций-компонентов осуществляется самостоятельная программная реализация; составные функции реализуются как программные модули, управляющие функ¬циями-компонентами, например, в виде программ-меню.
 Модульное программирование
Свойства модуля
Модульное программирование основано на понятии модуля — логически взаи¬мосвязанной совокупности функциональных элементов, оформленных в виде отдельных программных модулей.
Модуль характеризуют:
■       один вход и один выход — на входе программный модуль получает определенный на-бор исходных данных, выполняет содержательную обработку и возвращает один набор ре-зультатных данных, т.е. реализуется стандартный принцип IPO (Input — Process — Output) — вход-процесс-выход;
■       функциональная завершенность — модуль выполняет перечень регламентиро-ванных операций для реализации каждой отдельной функции в полном составе, достаточных для завершения начатой обработки;
■       логическая независимость — результат работы программного модуля зависит только от исходных данных, но не зависит от работы других модулей;
■       слабые информационные связи с другими программными модулями — обмен инфор¬мацией между модулями должен быть по возможности минимизирован;
■       обозримый по размеру и сложности программный элемент.
Таким образом, модули содержат определение доступных для обработки данных, опе¬рации обработки данных, схемы взаимосвязи с другими модулями.
Каждый модуль состоит из спецификации и тела. Спецификации определяют правила ис-пользования модуля, а тело — способ реализации процесса обработки.
4.3. Модульная структура программных продуктов
Принципы модульного программирования программных продуктов во многом сходны с принципами нисходящего проектирования. Сначала определяются состав и подчиненность функций, а затем — набор программных модулей, реализующих эти функции.
Однотипные функции реализуются одними и теми же модулями. Функция верхнего уровня обеспечивается главным модулем; он управляет выполнением нижестоящих функ¬ций, кото-рым соответствуют подчиненные модули.
При определении набора модулей, реализующих функции конкретного алгоритма, не¬обходимо учитывать следующее:
■       каждый модуль вызывается на выполнение вышестоящим модулем и, закончив рабо¬ту, возвращает управление вызвавшему его модулю;
■       принятие основных решений в алгоритме выносится на максимально "высокий" по иерархии уровень;
■       для использования одной и той же функции в разных местах алгоритма создает-ся один модуль, который вызывается на выполнение по мере необходимости.
В результате дальнейшей детализации алгоритма создается функционально-модульная схема (ФМС) алгоритма приложения, которая является основой для программи-рования
Состав и вид программных модулей, их назначение и характер использования в про¬грамме в значительной степени определяются инструментальными средствами. Например, применительно к средствам СУБД отдельными модулями могут быть:
■ экранные формы ввода и/или редактирования информации базы данных;
■       отчеты генератора отчетов;
■       макросы;
■       стандартные процедуры обработки информации;
■       меню, обеспечивающее выбор функции обработки и др.
Алгоритмы большой сложности обычно представляются с помощью схем двух видов:
■       обобщенной схемы алгоритма — раскрывает общий принцип функционирования алго¬ритма и основные логические связи между отдельными модулями на уровне обработ¬ки информации (ввод и редактирование данных, вычисления, печать результатов и т.п.);
■       детальной схемы алгоритма — представляет содержание каждого элемента обобщен¬ной схемы с использованием управляющих структур в блок-схемах алгоритма, псев¬докода либо алгоритмических языков высокого уровня.
Наиболее часто детально проработанные алгоритмы изображаются в виде блок-схем согласно требованиям структурного программирования; при их разработке используются ус-ловные обозначения согласно ГОСТ 19.003-80 ЕСПД (Единая система программной доку-ментации). Обозначения условные графические, ГОСТ 19.002-80 ЕСПД. Схемы алго¬ритмов и программ. Правила обозначения.
 Структурное программирование
Структурное программирование основано на модульной структуре программ¬ного продукта и типовых управляющих структурах алгоритмов обработки данных различ¬ных про-граммных модулей.
Алгоритм применительно к вычислительной машине: – точное предписание, т.е. на-бор операций и правил их чередования, при помощи которого, начиная с некоторых исход-ных данных, можно решить любую задачу фиксированного типа.
Виды алгоритмов как логико-математических средств отражают указанные  компоненты человеческой деятельности и тенденции, а сами алгоритмы в зависимости от цели, началь-ных условий задачи, путей ее решения, определения действий исполнителя подразделяются следующим образом:
• Механические алгоритмы, или иначе детерминированные, жесткие (например алгоритм работы машины, двигателя и т.п.);
• Гибкие алгоритмы, например стохастические, т.е. вероятностные и эвристические.
Механический алгоритм задает определенные действия, обозначая их в единственной и достоверной последовательности, обеспечивая тем самым однозначный требуемый или ис-комый результат, если выполняются те условия процесса, задачи, для которых разработан алгоритм.
• Вероятностный (стохастический) алгоритм дает программу решения задачи несколькими путями или способами, приводящими к вероятному достижению результата.
• Эвристический алгоритм  (от греческого слова “эврика”) – это такой алгоритм, в котором достижение конечного результата программы действий однозначно не предопределено, так же как не обозначена вся последовательность действий, не выявлены все действия исполнителя. К эвристическим алгоритмам относят, например, инструкции и предписа-ния. В этих алгоритмах используются универсальные логические процедуры и способы принятия решений, основанные на аналогиях, ассоцияциях и прошлом опыте решения схожих задач.
• Линейный алгоритм – набор команд (указаний), выполняемых последовательно во вре-мени друг за другом.
• Разветвляющийся алгоритм – алгоритм, содержащий хотя бы одно условие, в результате проверки которого ЭВМ обеспечивает переход на один из двух возможных шагов.
• Циклический алгоритм – алгоритм, предусматривающий многократное повторение одно-го и того же действия (одних и тех же операций) над новыми исходными данными. К ци-клическим алгоритмам сводится большинство методов вычислений, перебора вариантов.
Цикл программы – последовательность команд (серия, тело цикла), которая может выпо-лняться многократно (для новых исходных данных) до удовлетворения некоторого условия.
На рисунке продемонстрированы в условных обозначениях схемы основных конструкций алгоритмов:
а). линейного алгоритма;
б,в,г). разветвляющихся алгоритмов (б-ответвление, в-раздвоение, г-переключение);
д,е,ж). циклических алгоритмов (д,ж-проверка в начале цикла, е-проверка в конце цикла).
Вспомогательный (подчиненный) алгоритм (процедура) – алгоритм, ранее разрабо-танный и целиком используемый при алгоритмизации конкретной задачи. В некоторых слу-чаях при наличии одинаковых последовательностей указаний (команд) для различных дан-ных с целью сокращения записи также выделяют вспомогательный алгоритм.
На всех этапах подготовки к алгоритмизации задачи широко используется структур-ное представление алгоритма.
Структурная (блок-, граф-) схема алгоритма – графическое изображение алгоритма в виде схемы связанных между собой с помощью стрелок (линий перехода) блоков – графиче-ских символов, каждый из которых соответствует одному шагу алгоритма. Внутри блока да-ется описание соответствующего действия.
Графическое изображение алгоритма широко используется перед программированием задачи вследствие его наглядности, т.к. зрительное восприятие обычно облегчает процесс написания программы, ее корректировки при возможных ошибках, осмысливание процесса обработки информации.
Можно встретить даже такое утверждение: “Внешне алгоритм представляет собой схему – набор прямоугольников и других символов, внутри которых записывается, что вы-числяется, что вводится в машину и что выдается на печать и другие средства отображения информации “. Здесь форма представления алгоритма смешивается с самим алгоритмом.
Принцип программирования “сверху вниз” требует, чтобы блок-схема поэтапно конк-ретизировалась и каждый блок “расписывался” до элементарных операций. Но такой подход можно осуществить при решении несложных задач. При решении сколько-нибудь серьезной задачи блок-схема “расползется” до такой степени, что ее невозможно будет охватить одним взглядом.
Блок-схемы алгоритмов удобно использовать для объяснения работы уже готового алгоритма, при этом в качестве блоков берутся действительно блоки алгоритма, работа кото-рых не требует пояснений. Блок-схема алгоритма должна служить для упрощения изображе-ния алгоритма, а не для усложнения.
При решении задач на компьютере необходимо не столько умение составлять алгори-тмы, сколько знание методов решения задач ( как и вообще в математике ) . Поэтому изучать нужно не программирование как таковое ( и не алгоритмизацию ), а методы решения мате-матических задач на компьютере. Задачи следует классифицировать не по типам данных, как это обычно делается (задачи на массивы, на символьные переменные и т. д. ), а по разделу “Требуется”.
В информатике процесс решения задачи распределяется между двумя субъектами : программистом и компьютером. Программист составляет алгоритм ( программу ), компью-тер его исполняет. В традиционной математике такого разделения нет , задачу решает один человек, который составляет алгоритм решения задачи и сам выполняет его. Сущность алго-ритмизации не в том, что решение задачи представляется в виде набора элементарных опе-раций, а в том, что процесс решения задачи разбивается на два этапа : творческий ( програм-мирование ) и не творческий ( выполнение программы ). И выполняют эти этапы разные субъекты – программист и исполнитель
В учебниках по информатике обычно пишут, что исполнителем алгоритма может быть и че-ловек. На самом деле алгоритмы для людей никто не составляет ( не будем забывать, что не всякий набор дискретных операций является алгоритмом ). Человек в принципе не может действовать по алгоритму. Выполнение алгоритма – это автоматическое, бездумное выпол-нение операций. Человек всегда действует осмысленно. Для того, чтобы человек мог выпол-нять какой-то набор операций, ему нужно объяснить, как это делается. Любую работу чело-век сможет выполнять только тогда, когда он понимает, как она выполняется.
5. Литература
1.  Нестеренко А. В. ЭВМ и профессия программиста.
М., Просвещение, 1990.
2. Немнюгин С.А. Программирование – М.: Питер, 2000.
3.  Программирование под ред. В.В.Старлова – М: Питер, 1999