Файл: Алгоритмизация как обязательный этап разработки программы (Моделирование как средство поддержки принятия решений в профессиональной области.).pdf
Добавлен: 19.06.2023
Просмотров: 63
Скачиваний: 2
7.Документирование программы
Последней составляющей процесса программирования является документирование. Оно включает широкий спектр описаний, облегчающих процесс программирования и обогащающих результирующую программу. Постоянное документирование должно составлять неотъемлемую часть каждого шага программирования. Постановка задачи, проектные документы, алгоритмы и программы – все это документы. Внутренняя документация, включенная непосредственно в программу, облегчает чтение кода. Назначение учебного пособия (еще одной формы документации) – научить пользователя применять новую программу; справочное руководство позволяет ознакомиться с описанием команд программного обеспечения.
При разработке программы создается большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками программы, как средство управления разработкой программы и как средство передачи пользователям информации, необходимой для применения и сопровождения программы.
8. Запуск готовой программы и анализ полученных результатов.
После полученного нами файла с *.exe (обычно) разрешением мы можем запустить его и ещё раз проверить (проанализировать) верно, ли работает программа. На этом этапы создания программы закончены.
4. Алгоритмы
Алгоритм должен обладать следующими четырьмя свойствами:
• дискретностью;
• определенностью;
• результативностью;
• массовостью.
Дискретность. Задача должна быть разбита на конечное число действий
(шагов, тактов). Причем каждое последующее действие должно базироваться на
результатах, полученных в предыдущих действиях.
Определенность (детерминированность). Каждое действие должно быть
описано четко и однозначно (только так и никак по-другому). Необходимо исключить произвольность толкования как самих действий, так и порядка их следования.
Результативность (конечность). Алгоритм должен обязательно приводить к решению задачи (к получению результата), причем за конечное число шагов, или сообщить через определенное число шагов о невозможности дальнейшего решения задачи.
Массовость. Алгоритм разрабатывается в общем виде, чтобы его можно
было применить для различных исходных данных (область применимости алгоритма).
1. Алгоритмизация и программирование
Понятие алгоритма так же фундаментально для информатики, как и понятие информации. Существует много различных определений алгоритма, так как это понятие достаточно широкое и используется в различных областях науки, техники и повседневной жизни.
Алгоритм – понятная и точная последовательность действий, описывающая процесс преобразования объекта из начального состояния в конечное.
Исполнителем алгоритма может быть как человек (кулинарные рецепты, различные инструкции, алгоритмы математических вычислений), так и техническое устройство. Различные машины (компьютеры, промышленные роботы, современная бытовая техника) являются формальными исполнителями алгоритмов. От формального исполнителя не требуется понимание сущности решаемой задачи, но требуется точное выполнение последовательности команд.
2. Понятие алгоритма и способы его описания
Выше отмечалось, что один и тот же алгоритм может быть записан по-разному. Можно записывать алгоритм естественным языком. В таком виде мы используем рецепты, инструкции и т.п. Для записи алгоритмов, предназначенных формальным исполнителям, разработаны специальные языки программирования. Любой алгоритм можно описать графически в виде блок-схемы. Для этого разработана специальная система обозначений: |Действие |В вычислительных алгоритмах так обозначают присваивание|
|[pic] |Развилка |Развилка - компонент, необходимый для реализации |
| | |ветвлений и циклов |
|[pic] |Начало цикла с параметром | |
|[pic] |Типовой процесс |В программировании - процедуры или подпрограммы |
|[pic] |Переходы между блоками | |
5. Инструментарии решения функциональных задач
Пакеты прикладных программ (ППП) - служат программным инструментарием решения функциональных задач и являются самым многочисленным классом программных продуктов. В данный класс входят программные продукты, выполняющие обработку информации различных предметных областей.
Установка программных продуктов на компьютер выполняется квалифицированными пользователями, а непосредственную их эксплуатацию осуществляют, как правило, конечные пользователи - потребители информации, во многих случаях деятельность которых весьма далека от компьютерной области. Данный класс программных продуктов может быть весьма специфичным для отдельных предметных областей.
Прикладные программы предназначены для того, чтобы обеспечить применение вычислительной техники в различных сферах деятельности человека. Помимо создания новых программных продуктов разработчики прикладных программ большие усилия тратят на совершенствование и модернизацию популярных систем, создание их новых версий.
Существуют различные издательские системы, среди которых можно выделить следующие:
1. Adobe InDesign - пакет фирмы Adobe, оптимизированный под верстку документов самого широкого профиля, от одностраничных буклетов до толстых книг, обогащенный набором специфических визуальных инструментов.
2. Adobe PageMarker - еще один пакет
фирмы Adobe, с довольно сложным интерфейсом и системой команд, но в то же время с высокой производительностью и богатыми возможностями, особенно при работе с цветом.
3. Corel Ventura Publisher - альтернативный пакет фирмы Corel, несколько утративший в последнее время свои позиции, но вследствие своей универсальности (имеет широкие функции обычных текстовых и графических редакторов, интеграция с Web, поддержка различных платформ) не потерявший актуальности.
4. QuarkXPress - достаточно легкая в освоении и гибкая издательская система, которая традиционно используется многими издательствами газет, журналов, рекламными агентствами.
6. Архитектура программных систем
Архитектура программного обеспечения (англ. software architecture) — это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними. Этот термин также относится к документированию архитектуры программного обеспечения. Документирование архитектуры ПО упрощает процесс коммуникации между заинтересованными лицами (англ. stakeholders), позволяет зафиксировать принятые на ранних этапах проектирования решения о высокоуровневом дизайне системы и позволяет использовать компоненты этого дизайна и шаблоны повторно в других проектах.
1. История возникновения архитектуры ПО
Начало архитектуре программного обеспечения как концепции было положено в научно-исследовательской работе Эдсгера Дейкстры в 1968 году и Дэвида Парнаса в начале 1970-х. Эти ученые подчеркнули, что структура системы ПО имеет важное значение, и что построение правильной структуры — критически важно. Популярность изучения этой области возросла с начала 1990-х годов вместе с научно-исследовательской работой по исследованию архитектурных стилей (шаблонов), языков описания архитектуры, документирования архитектуры, и формальных методов.
В развитии архитектуры программного обеспечения как дисциплины играют важную роль научно-исследовательские учреждения. Мэри Шоу и Дэвид Гэрлан из университета Carnegie Mellon написали книгу под названием «Архитектура программного обеспечения: перспективы новой дисциплины в 1996 году», в которой выдвинули концепции архитектуры программного обеспечения, такие как компоненты, соединители (connectors), стили и так далее. В калифорнийском университете институт Ирвайна по исследованию ПО в первую очередь исследует архитектурные стили, языки описания архитектуры и динамические архитектуры.
Первым стандартом программной архитектуры является стандарт IEEE 1471: ANSI / IEEE 1471—2000: Рекомендации по описанию преимущественно программных систем. Он был принят в 2007 году, под названием ISO ISO / IEC 42010:2007.
7. Программное обеспечение и технологии программирования
Технология программирования - это совокупность методов и средств разработки (написания) программ и порядок применения этих методов и средств.
На ранних этапах развития программирования, когда программы писались в виде последовательностей машинных команд, какая-либо технология программирования отсутствовала. Первые шаги в разработке технологии состояли в представлении программы в виде последовательности операторов. Написанию последовательности машинных команд предшествовало составление операторной схемы, отражающей последовательность операторов и переходы между ними. Операторный подход позволил разработать первые программы для автоматизации составления программ - так называемые составляющие программы.
С увеличением размеров программ стали выделять их обособленные части и оформлять их как подпрограммы. Часть таких подпрограмм объединялась в библиотеки, из которых подпрошраммы можно было включать в рабочие программы и затем вызывать из рабочих программ. Это положило начало процедурному программированию - большая программа представлялась совокупностью процедур-подпрограмм. Одна из подпрограмм являлась главной и с нее начиналось выполнение программы.
В 1958 году были разработаны первые языки программирования, Фортран и Алгол-58. Программа на Фортране состояла из главной программы и некоторого количества процедур - подпрограмм и функций. Программа на Алголе-58 и его последующей версии Алголе-60 представляла собой единое целое, но имела блочную структуру, включающую главный блок и вложенные блоки подпрограмм и функций. Компиляторы для Фортрана обеспечивали раздельную трансляцию процедур и последующее их объединение в рабочую программу, первые компиляторы для Алгола предполагали, что транслируется сразу вся программа, раздельная трансляция процедур не обеспечивалась.
Процедурный подход потребовал структурирования будущей программы, разделения ее на отдельные процедуры. При разработке отдельной процедуры о других процедурах требовалось знать только их назначение и способ вызова. Появилась возможность перерабатывать отдельные процедуры, не затрагивая остальной части программы, сокращая при этом затраты труда и машинного времени на разработку и модернизацию программ.
Следующим шагом в углублении структурирования программ стало так называемое структурное программирование, при котором программа в целом и отдельные процедуры рассматривались как последовательности канонических структур: линейных участков, циклов и разветвлений. Появилась возможность читать и проверять программу как последовательный текст, что повысило производительность труда программистов при разработке и отладке программ. С целью повышения структурности программы были выдвинуты требования к большей независимости подпрограмм, подпрограммы должны связываться с вызывающими их программами только путем передачи им аргументов, использование в подпрограммах переменных, принадлежащих другим процедурам или главной программе, стало считаться нежелательным.
Процедурное и структурное программирование затронули прежде всего процесс описания алгоритма как последовательности шагов, ведущих от варьируемых исходных данных к искомому результату. Для решения специальных задач стали разрабатываться языки программирования, ориентированные на конкретный класс задач: на системы управления базами данных, имитационное моделирование и т.д.
При разработке трансляторов все больше внимания стало уделяться обнаружению ошибок в исходных текстах программ, обеспечивая этим сокращение затрат времени на отладку программ.
Объектно-ориентированный подход в программировании
Основные идеи объектно-ориентированного подхода опираются на следующие положения:
• Программа представляет собой модель некоторого реального процесса, части реального мира.
• Модель реального мира или его части может быть описана как совокупность взаимодействующих между собой объектов.
• Объект описывается набором параметров, значения которых определяют состояние объекта, и набором операций (действий), которые может выполнять объект.
• Взаимодействие между объектами осуществляется посылкой специальных сообщений от одного объекта к другому. Сообщение, полученное объектом, может потребовать выполнения определенных действий, например, изменения состояния объекта.
• Объекты, описанные одним и тем же набором параметров и способные выполнять один и тот же набор действий представляют собой класс однотипных объектов.
С точки зрения языка программирования класс объектов можно рассматривать как тип данного, а отдельный объект - как данное этого типа. Определение программистом собственных классов объектов для конкретного набора задач должно позволить описывать отдельные задачи в терминах самого класса задач (при соответствующем выборе имен типов и имен объектов, их параметров и выполняемых действий).
Таким образом, объектно-ориентированный подход предполагает, что при разработке программы должны быть определены классы используемых в программе объектов и построены их описания, затем созданы экземпляры необходимых объектов и определено взаимодействие между ними.
Классы объектов часто удобно строить так, чтобы они образовывали иерархическую структуру. Например, класс “Студент”, описывающий абстрактного студента, может служить основой для построения классов “Студент 1 курса”, “Студент 2 курса” и т.д., которые обладают всеми свойствами студента вообще и некоторыми дополнительными свойствами, характеризующими студента конкретного курса. При разработке интерфейса с пользователем программы могут использовать объекты общего класса “Окно” и объекты классов специальных окон, например, окон информационных сообщений, окон ввода данных и т.п. В таких иерархических структурах один класс может рассматриваться как базовый для других, производных от него классов. Объект производного класса обладает всеми свойствами базового класса и некоторыми собственными свойствами, он может реагировать на те же типы сообщений от других объектов, что и объект базового класса и на сообщения, имеющие смысл только для производного класса. Обычно говорят, что объект производного
класса наследует все свойства своего базового класса.
8. Основы создания программного продукта
Известно, что технологический цикл конструирования программной системы (ПС) включает три процесса – анализ, синтез и сопровождение. В ходе анализа определяется ответ на вопрос: «Что должна делать будущая система?». Именно на этой стадии закладывается фундамент успеха всего проекта. Известно множество неудачных реализаций из-за неполноты и неточностей в определении требований к системе. В процессе синтеза формируется ответ на вопрос: «Каким образом система будет реализовывать предъявляемые к ней требования?». Выделяют три этапа синтеза: проектирование ПС, кодирование ПС, тестирование ПС. Рассмотрим информационные потоки процесса синтеза.
Этапы проектирования опираются на требования к ПС, представленные информационной, функциональной и поведенческой моделями анализа. Иными словами, модели анализа поставляют этапу проектирования исходные сведения для работы.
Функциональная модель определяет перечень функций обработки. Поведенческая модель фиксирует желаемую динамику системы (режимы её работы). На выходе этапа проектирования – разработка данных, разработка архитектуры и процедурная разработка ПС.
Разработка данных – это результат преобразования информационной
модели анализа в структуры данных, которые потребуются для реализации программной системы.
Разработка архитектуры выделяет основные структурные компоненты и фиксирует связи между ними.Процедурная разработка описывает последовательность действий в структурных компонентах, т.е. определяет их содержание.
Далее создаются тексты программных модулей, проводится тестирование для объединения и проверки ПС. На проектирование, кодирование
и тестирование приходится более 75% стоимости конструирования ПС.
Принятые здесь решения оказывают решающее воздействие на успех реализации ПС и лёгкость, с которой ПС будет сопровождаться.
Следует отметить, что решения, принимаемые в ходе проектирования, делают его стержневым этапом процесса синтеза. Важность проектирования можно определить одним словом – качество. Проектирование – этап, на котором «выращивается» качество разработки ПС. Справедлива следующая аксиома разработки: может быть плохая ПС при хорошем проектировании, но не может быть хорошей ПС при плохом проектировании. Проектирование обеспечивает нас такими представлениями ПС, качество которых можно оценить. Проектирование – единственный путь, обеспечивающий правильную трансляцию требований заказчика в конечный программный продукт.