Средства и способы программирования
Основные средства разработки программного обеспечения. Встроенная и открытая компьютерная система. Архитектура процессора. Операционная система реального времени. Кросс-система программирования. Разработка, отладка и тестирование программного средства.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | шпаргалка |
Язык | русский |
Дата добавления | 11.11.2013 |
Размер файла | 1,1 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Следует отметить, что мониторы-отладчики работают на том же процессоре и используют то же пространство памяти, что и прикладные программы, которые они отлаживают. Это весьма важное обстоятельство: процессор используется для выполнения прикладной программы и программы-отладчика. Данный процесс легко осуществить на компьютере, но его трудно реализовать в микроконтроллере, который имеет намного меньший объем памяти для размещения прикладной программы и монитора. Встречаются мониторы, которые занимают всего 512 байт и могут располагаться в памяти микроконтроллера. В таком случае программа-монитор может быть совмещена с прикладной программой без существенного увеличения объема памяти программ.
Другая проблема состоит в следующем. Так как программа-монитор выполняется микроконтроллером, то в случае использования прикладной программой аппаратных ресурсов, необходимых монитору, работа приложения или процесс отладки будут нарушены.
Чтобы резидентный монитор мог реализовать перечисленные выше функции, микроконтроллер должен иметь ряд встроенных аппаратных средств. Процессор микроконтроллера должен иметь возможность чтения-записи содержимого памяти программ и возможность записи в память программ из выполняющейся программы, иначе монитор не может быть использован для отладки приложения.
В Принстонской архитектуре, описанной ранее, существует только одно адресное пространство, которое используется для кола программы, переменных и стека. В этом случае, программный код, который надо отладить, может быть помешен в память RAM. что даст возможность легко его модифицировать.
Возможно, это кажется очевидным, но необходимо иметь несколько линий ввода-вывода для связи монитора с ведущей системой (или терминалом). Если используется микроконтроллер с очень малым числом выводов, то их может не хватить для соединения с ведущей системой. Линия приема данных от ведущей системы должна иметь возможность генерировать прерывания, чтобы ведущая система могла прерывать выполнение текущей программы. Либо ведущая система должна иметь возможность сбрасывать микроконтроллер и запускать монитор вместо прикладной программы.
Загрузка программы в микроконтроллер с помощью монитора является важной темой для обсуждения. Проблема заключается в том, что микроконтроллер должен иметь возможность записывать в свою память программ. Такая возможность требуется для обновления программы и расстановки контрольных точек останова.
Стоит уточнить, что представляет собой монитор. На основании выше сказанного можно подумать, что монитор это отдельная программа, которая позволяет загружать и выполнять другие программы. Это в некоторой степени верно, но более правильно будет сказать, что монитор это специализированный обработчик прерываний. Монитор вступает в действие только при определенных условиях (прерываниях). Так как эти условия могут возникнуть в любой момент времени, то используется соответствующий обработчик прерываний, который останавливает выполнение прикладной программы, когда пользователь хочет взаимодействовать с монитором. В микроконтроллере или любом другом компьютере монитор активизируется только, когда работа приложения прерывается пользователем. Это дает возможность приложению выполняться с полной скоростью, не затрачивая время на выполнение команд для поддержки монитора.
В то время как большинство обработчиков прерываний просты, предназначены для обслуживания определенных аппаратных средств и выполняются очень быстро, монитор является очень сложной программой, которая не только контролирует выполнение приложения, но также осуществляет интерфейс с пользователем. Часто требуется осуществить интерфейс с пассивным терминалом, это означает, что монитор должен уметь проводить анализ команд, вводимых пользователем с таких терминалов. Управление выполнением приложения главным образом осуществляется путем манипуляции с содержимым программного счетчика для прикладной программы, которое сохраняется в стеке при запуске монитора. Эти манипуляции сводятся к контролю и обновлению адреса возврата в стеке. Например, если требуется запустить программу с определенного адреса, то монитор загружает этот адрес в стек в качестве адреса возврата. Когда монитор будет готов к запуску программы, выполняется возврат из прерывания, который осуществляется путем извлечения требуемого адреса из стека и загрузки его в программный счетчик.
17. Эмулятор ЭВМ и интерпретатор системы команд ЦП
Эмулямция (англ. emulation) -- воспроизведение программными или аппаратными средствами либо их комбинацией работы других программ или устройств.
Цели
§ Создание нового микропроцессора/микроконтроллера. В этом случае при помощи эмулятора (программы или устройства) выполняются команды этого процессора.
§ Необходимость выполнения также программного обеспечения, написанного для другого устройства или операционной системы.
§ Тестирование программ, написанных для различных систем.
Аппаратная и программно-аппаратная эмуляция
В случае программно-аппаратного комплекса эмулятором является специальное электронное устройство, выполненное в виде платы.
Программная эмуляция
Эмуляция позволяет выполнять компьютерную программу на платформе (компьютерной архитектуре и/или операционной системе), отличной, или в некоторых случаях идентичной той, для которой она была написана в оригинале. Эмуляцией также называют сам процесс этого выполнения. В отличие от симуляции, которая лишь воспроизводит поведение программы, при эмуляции ставится цель точного моделирования состояния имитируемой системы, для выполнения оригинального машинного кода.
При использовании языков высокого уровня, иногда в целях сохранения быстродействия исполняемой программы, вместо эмуляции делают портирование программ в новую среду. В этом случае производится переписывание заново аппаратно-зависимых участков кода.
Одно из популярных применений эмуляции -- выполнение на персональном компьютере игр, написанных для игровых автоматов или игровых приставок.
Теоретически, согласно тезису Чёрча -- Тьюринга, любая операционная среда может быть эмулирована в любой другой среде. На практике, однако, встречается ряд трудностей; в частности, точное поведение эмулируемой системы часто не документированно (или скрывается под грифом коммерческой тайны) и должно быть исследовано и определено с помощью обратной разработки.
Достаточно полная эмуляция некоторой аппаратной платформы требует предельной точности, до уровня отдельных тактовых циклов, недокументированных особенностей и даже ошибок реализации. Это особенно важно для таких моделей классических домашних машин, как Commodore 64, ZX Spectrum, программное обеспечение которых сильно зависит от программистских решений. Выбор конкретного решения происходит с целью оптимизации (по размеру или скорости выполнения программы), применяемой, например программистами игр, а также энтузиастами демосцены. Такие программы достаточно часто бывают основаны на недокументированных возможностях процессора или операционной системы.
В противоположность этому, на некоторых других платформах довольно мало использовался прямой доступ к оборудованию. В этом случае оказывается достаточным обеспечить некоторый уровень совместимости, обеспечивающий трансляцию системных вызовов эмулируемой системы в вызовы работающей системы.
Обычно, эмулятор состоит из нескольких модулей, отвечающих за различные подсистемы эмулируемого компьютера. Чаще всего, эмулятор состоит из:
§ эмулятора или симулятора центрального процессора;
§ модуля подсистемы памяти, эмулирующего ОЗУ и ПЗУ;
§ модуля или модулей эмуляции различных устройств ввода-вывода.
Системная шина обычно не эмулируется, по причинам упрощения или повышения производительности, и виртуальная периферия обращается непосредственно к модулю ЦП и модулю памяти.
ИНТЕРПРЕТАТОР - программа (или комплекс программ), которая сочетает последовательный перевод текста программы пользователя в двоичные коды процессора с выполнением. Работает интерпретатор по схеме: считывание строки текста программы, перевод считанного в последовательность двоичных кодов процессора, выполнение и переход к следующей строке. интерпретатор сочетает перевод текста программы в команды процессора с их выполнением! Очевидно, что под управлением интерпретатора программа выполняется медленнее, чем та же программа подготовленная к исполнению компилятором.
18. СУБД и базы данных=банк данных
Системма управлемния бамзами дамнных (СУБД) -- совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных.
§ Основные функции СУБД
§ ? управление данными во внешней памяти (на дисках);
§ ? управление данными в оперативной памяти с использованием дискового кэша;
§ журнализация изменений, резервное копирование и восстановление базы данных после сбоев;
§ поддержка языков БД (язык определения данных, язык манипулирования данными).
Обычно современная СУБД содержит следующие компоненты:
§ ядро, которое отвечает за управление данными во внешней и оперативной памяти, и журнализацию,
§ процессор языка базы данных, обеспечивающий оптимизацию запросов на извлечение и изменение данных и создание, как правило, машинно-независимого исполняемого внутреннего кода,
§ подсистему поддержки времени исполнения, которая интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД
§ а также сервисные программы (внешние утилиты), обеспечивающие ряд дополнительных возможностей по обслуживанию информационной системы.
Классификации СУБД
? По модели данных
? Примеры:ИерархическиеСетевые
Реляционные
§ Объектно-ориентированные
§ Объектно-реляционные
По степени распределённости
§ Локальные СУБД (все части локальной СУБД размещаются на одном компьютере)
§ Распределённые СУБД (части СУБД могут размещаться на двух и более компьютерах).
По способу доступа к БД
§ Файл-серверные
В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. СУБД располагается на каждом клиентском компьютере (рабочей станции). Доступ СУБД к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера. Недостатки: потенциально высокая загрузка локальной сети; затруднённость или невозможность централизованного управления; затруднённость или невозможность обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность. Применяются чаще всего в локальных приложениях, которые используют функции управления БД; в системах с низкой интенсивностью обработки данных и низкими пиковыми нагрузками на БД.
На данный момент файл-серверная технология считается устаревшей.
Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.
§ Клиент-серверные
Клиент-серверная СУБД располагается на сервере вместе с БД и осуществляет доступ к БД непосредственно, в монопольном режиме. Все клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно. Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу. Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокаябезопасность.
Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Cachй, ЛИНТЕР.
§ Встраиваемые
Встраиваемая СУБД -- СУБД, которая может поставляться как составная часть некоторого программного продукта, не требуя процедуры самостоятельной установки. Встраиваемая СУБД предназначена для локального хранения данных своего приложения и не рассчитана на коллективное использование в сети. Физически встраиваемая СУБД чаще всего реализована в виде подключаемой библиотеки. Доступ к данным со стороны приложения может происходить через SQL либо через специальные программные интерфейсы.
Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР.
Бамза дамнных -- представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ) (Гражданский кодекс РФ, ст. 1260).
Другие определения из авторитетных монографий и стандартов:
§ База данных -- организованная в соответствии с определёнными правилами и поддерживаемая в памяти компьютера совокупность данных, характеризующая актуальное состояние некоторой предметной области и используемая для удовлетворения информационных потребностей пользователей.
§ База данных -- совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных.
§ База данных -- некоторый набор перманентных (постоянно хранимых) данных, используемых прикладными программными системами какого-либо предприятия.
§ База данных -- совместно используемый набор логически связанных данных (и описание этих данных), предназначенный для удовлетворения информационных потребностей организации.
Существует множество других определений, отражающих скорее субъективное мнение тех или иных авторов, однако общепризнанная единая формулировка отсутствует. Наиболее часто используются следующие отличительные признаки
1. БД хранится и обрабатывается в вычислительной системе. Таким образом, любые внекомпьютерные хранилища информации (архивы, библиотеки, картотеки и т. п.) базами данных не являются.
2. Данные в БД логически структурированы (систематизированы) с целью обеспечения возможности их эффективного поиска и обработки в вычислительной системе. Структурированность подразумевает явное выделение составных частей (элементов), связей между ними, а также типизацию элементов и связей, при которой с типом элемента (связи) соотносится определённая семантика и допустимые операции.
3. БД включает схему, или метаданные, описывающие логическую структуру БД в формальном виде (в соответствии с некоторой метамоделью).В соответствии с ГОСТ Р ИСО МЭК ТО 10032-2007, «постоянные данные в среде базы данных включают в себя схему и базу данных. Схема включает в себя описания содержания, структуры и ограничений целостности, используемые для создания и поддержки базы данных. База данных включает в себя набор постоянных данных, определенных с помощью схемы. Система управления данными использует определения данных в схеме для обеспечения доступа и управления доступом к данным в базе данных».
Из перечисленных признаков только первый является строгим, а другие допускают различные трактовки и различные степени оценки. Можно лишь установить некоторую степень соответствия требованиям к БД.
В такой ситуации не последнюю роль играет общепринятая практика. В соответствии с ней, например, не называют базами данных файловые архивы, Интернет-порталы или электронные таблицы, несмотря на то, что они в некоторой степени обладают признаками БД. Принято считать, что эта степень в большинстве случаев недостаточна (хотя могут быть исключения).
Многие специалисты указывают на распространённую ошибку, состоящую в некорректном использовании термина «база данных» вместо термина «система управления базами данных», и указывают на необходимость различения этих понятий.
История
История возникновения и развития технологий баз данных может рассматриваться как в широком, так и в узком аспекте.
В широком аспекте понятие истории баз данных обобщается до истории любых средств, с помощью которых человечество хранило и обрабатывало данные. В таком контексте упоминаются, например, средства учёта царской казны и налогов в древнем Шумере (4000 г. до н. э.),[8] узелковая письменность инков -- кипу, клинописи, содержащие документы Ассирийского царства и т. п. Следует помнить, что недостатком этого подхода является размывание понятия «база данных» и фактическое его слияние с понятиями «архив» и даже «письменность».
История баз данных в узком аспекте рассматривает базы данных в традиционном (современном) понимании. Эта история начинается с 1955 года, когда появилось программируемое оборудование обработки записей. Программное обеспечение этого времени поддерживало модель обработки записей на основе файлов. Для хранения данных использовались перфокарты.[8]
Оперативные сетевые базы данных появились в середине 1960-х. Операции над оперативными базами данных обрабатывались в интерактивном режиме с помощью терминалов. Простые индексно-последовательные организации записей быстро развились к более мощной модели записей, ориентированной на наборы. За руководство работой Data Base Task Group (DBTG), разработавшей стандартный язык описания данных и манипулирования данными, Чарльз Бахман получил Тьюринговскую премию.
В это же время в сообществе баз данных COBOL была проработана концепция схем баз данных и концепция независимости данных.
Следующий важный этап связан с появлением в начале 1970-х реляционной модели данных, благодаря работам Эдгара Ф. Кодда. Работы Кодда открыли путь к тесной связи прикладной технологии баз данных с математикой и логикой. За свой вклад в теорию и практику Эдгар Ф. Кодд также получил премию Тьюринга.
Сам термин database (база данных) появился в начале 1960-х годов, и был введён в употребление на симпозиумах, организованных фирмой SDC (System Development Corporation) в1964 и 1965 годах, хотя понимался сначала в довольно узком смысле, в контексте систем искусственного интеллекта. В широкое употребление в современном понимании термин вошёл лишь в 1970-е годы.
Виды баз данных
Существует огромное количество разновидностей баз данных, отличающихся по различным критериям. Например, в «Энциклопедии технологий баз данных», по материалам которой написан данный раздел, определяются свыше 50 видов БД.
Основные классификации приведены ниже.
Классификация по модели данных
Примеры:
§ Иерархическая
§ Сетевая
§ Реляционная
§ Объектная и объектно-ориентированная
§ Объектно-реляционная
§ Функциональная.
Классификация по среде постоянного хранения
§ Во вторичной памяти, или традиционная (англ. conventional database): средой постоянного хранения является периферийная энергонезависимая память (вторичная память) -- как правило, жёсткий диск.
В оперативную память СУБД помещает лишь кеш и данные для текущей обработки.
§ В оперативной памяти (англ. in-memory database, memory-resident database, main memory database): все данные на стадии исполнения находятся в оперативной памяти.
§ В третичной памяти (англ. tertiary database): средой постоянного хранения является отсоединяемое от сервера устройство массового хранения (третичная память), как правило на основе магнитных лент или оптических дисков.
Во вторичной памяти сервера хранится лишь каталог данных третичной памяти, файловый кеш и данные для текущей обработки; загрузка же самих данных требует специальной процедуры.
Классификация по содержимому
Примеры:
§ Географическая
§ Историческая
§ Научная
§ Мультимедийная.
Классификация по степени распределённости
§ Централизованная, или сосредоточенная (англ. centralized database): БД, полностью поддерживаемая на одном компьютере.
§ Распределённая (англ. distributed database): БД, составные части которой размещаются в различных узлах компьютерной сети в соответствии с каким-либо критерием.
§ Неоднородная (англ. heterogeneous distributed database): фрагменты распределённой БД в разных узлах сети поддерживаются средствами более одной СУБД
§ Однородная (англ. homogeneous distributed database): фрагменты распределённой БД в разных узлах сети поддерживаются средствами одной и той же СУБД.
§ Фрагментированная, или секционированная (англ. partitioned database): методом распределения данных является фрагментирование (партиционирование, секционирование), вертикальное или горизонтальное.
§ Тиражированная (англ. replicated database): методом распределения данных является тиражирование (репликация).
Другие виды БД
§ Пространственная (англ. spatial database): БД, в которой поддерживаются пространственные свойства сущностей предметной области. Такие БД широко используются в геоинформационных системах.
§ Временная, или темпоральная (англ. temporal database): БД, в которой поддерживается какой-либо аспект времени, не считая времени, определяемого пользователем.
§ Пространственно-временная (англ. spatial-temporal database) БД: БД, в которой одновременно поддерживается одно или более измерений в аспектах как пространства, так и времени.
Циклическая (англ. round-robin database): БД, объём хранимых данных которой не меняется со временем, поскольку в процессе сохранения данных одни и те же записи используются циклически.
Сверхбольшие базы данных
Сверхбольшая база данных (англ. Very Large Database, VLDB) -- это база данных, которая занимает чрезвычайно большой объём на устройстве физического хранения. Термин подразумевает максимально возможные объёмы БД, которые определяются последними достижениями в технологиях физического хранения данных и в технологиях программного оперирования данными. Количественное определение понятия «чрезвычайно большой объём» меняется во времени; в настоящее время считается, что это объём, измеряемый по меньшей мере петабайтами. Для сравнения, в 2005 г. самыми крупными в мире считались базы данных с объёмом хранилища порядка 100 терабайт. Специалисты отмечают необходимость особых подходов к проектированию сверхбольших БД. Для их создания нередко выполняются специальные проекты с целью поиска таких системотехнических решений, которые позволили бы хоть как-то работать с такими большими объёмами данных. Как правило, необходимы специальные решения для дисковой подсистемы, специальные версии операционной среды и специальные механизмы обращения СУБД к данным. Исследования в области хранения и обработки сверхбольших баз данных VLDB всегда находятся на острие теории и практики баз данных. В частности, с 1975 года проходит ежегодная конференция International Conference on Very Large Data Bases («Международная конференция по сверхбольшим базам данных»). Большинство исследований проводится под эгидой некоммерческой организации VLDB Endowment (Фонд целевого капитала «VLDB»), которая обеспечивает продвижение научных работ и обмен информацией в области сверхбольших БД и смежных областях.
19. Структурное программирование и его основные конструкции
Технология структурного программирования в самой краткой формулировке есть нисходящее проектирование, т.е. выстраивание текста программы, точнее алгоритмической компоненты, от общего к частному, от внешней конструкции к внутренней. Естественно, что надо знать, из чего выстраивать. В идеале, у опытного программиста действительно очередная нужная конструкция появляется «из головы». Но это не значит, что он не имеет общего плана действий и обобщенного представления процесса, который реализуется проектируемой программой.
Именно поэтому в 3.1 технология программирования была обозначена как заключительный этап выстраивания программы из имеющегося набора фрагментов. Перед этим необходимо пройти другие этапы:
? формулировка целей (результатов) работы программы;
? образное представление процессы ее работы (образная модель);
? выделение из образной модели фрагментов: определение переменных и их смыслового наполнения, стандартных программных контекстов. Попробуем теперь встроить в общую схему процесса проектирования самое трудное направление «движения» при построении программы - от общего к частному. И тогда получим примерно такую картину.
Рис. 33.1. Этапы структурного проектирования
1. Исходным состоянием процесса проектирования является более или менее точная формулировка цели алгоритма, или результата, который должен быть получен при его выполнении. Формулировка, само собой, производится на естественном языке.
2. Создается образная модель происходящего процесса, используются графические и какие угодно способы представления, образные «картинки», позволяющие лучше понять выполнение алгоритма в динамике;
3. Выполняется сбор фактов, касающихся любых характеристик алгоритма, и попытка их представления средствами языка. Такими фактами является наличие определенных переменных и их «смысл», а также соответствующих им программных контекстов. Понятно, что не все факты удастся сразу выразить в виде фрагментов программы, но они должны быть сформулированы хотя бы на естественном языке;
4. В образной модели выделяется наиболее существенная часть - «главное звено», для которой подбирается наиболее точная словесная формулировка;
5. Производится определение переменных, необходимых для формального представления данного шага алгоритма и формулируется их «смысл»;
6. Выбирается одна из конструкций - простая последовательность действий, условная конструкция или цикл. Составные части выбранной формальной конструкции (например, условие, заголовок цикла) должны быть переписаны в словесной формулировке в виде цели или результата, которые должны давать эти части алгоритма.
7. Для оставшихся неформализованных частей алгоритма (в словесной формулировке) - перечисленная последовательность действий повторяется. Обычно разработка образного представления программы опережает ее «выстраивание», поэтому следующим этапом для неформализованной части алгоритма может быть п.4 (в лучшем случае, при его проработке в образной модели) или п.1-3. В любом случае для вложенных конструкций мы возвращаемся на предыдущие этапы проектирования.
Здесь мы видим много непривычного:
? на любом промежуточном шаге программа состоит из смеси конструкций языка, соответствующих пройденным шагам проектирования, и словесных формулировок, соответствующих еще не раскрытым вложенным конструкциям нижнего уровня;
? процесс заключается в последовательной замене словесных формулировок конструкциями языка. На каждом шаге в программу добавляется всего одна конструкция, а содержимое ее составных частей снова формулируется в терминах «цель» или «результат»;
? «свобода выбора» ограничена тремя управляющими конструкциями языка: последовательностью действий, ветвление или цикл. При этом даже не принципиален конкретный синтаксис оператора, важен лишь вид конструкции, например, что это цикл, а не последовательность действий.
Как и любая технология, структурное проектирование задает лишь «правила игры», но не гарантирует получение результата. Основная проблема - выбор синтаксической конструкции и замена формулировок - все равно технологией формально не решается. И здесь находится камень преткновения начинающих программистов. «Главное звено» - это не столько особенности реализации алгоритма, которые всегда на виду и составляют его специфику, а действие, которое включает в себя все остальные. То есть все равно программист должен «видеть» в образной модели все элементы, отвечающие за поведение программы, и выделять из них главный, в смысле - самый внешний или объемлющий. Единственный совет: постараться извлечь из образной модели как можно больше фактического материала.
И, наконец, на практике
Заповеди структурного программирования
Обычно технология структурного программирования формулируется в виде «заповедей», о содержательной интерпретации которых мы уже догадываемся.
1. нисходящее проектирование;
2. пошаговое проектирование;
3. структурное проектирование (программирование без goto);
4. одновременное проектирование алгоритма и данных;
5. модульное проектирование;
6. модульное, нисходящее, пошаговое тестирование.
Одним словом, структурное программирование - модульное нисходящее пошаговое проектирование и отладка алгоритма и структур данных .
Нисходящее пошаговое структурное проектирование. В структурном программировании достаточно сложно отделить друг от друга принципы нисходящего, пошагового и структурного проектирования, поскольку каждый из них по отдельности является достаточно тривиальным, а весь эффект состоит в их совместном использовании в рамках процесса проектирования:
? нисходящее проектирование программы состоит в процессе формализации от самой внешней синтаксической конструкции алгоритма к самой внутренней, в движении от общей формулировки алгоритма к частной формулировке составляющего его действия;
? структурное проектирование заключается в замене словесной формулировки алгоритма на одну из синтаксических конструкций - последовательность, условие или цикл. При этом синтаксическая вложенность конструкций соответствует последовательности их проектирования и выполнения. Использование оператора перехода goto запрещается из принципиальных соображений;
? пошаговое проектирование состоит в том, что на каждом этапе проектирования в текст программы вносится только одна конструкция языка, а составляющие ее компоненты остаются в неформальном, словесном описании, что предполагает аналогичные шаги в их проектировании.
Нисходящее пошаговое структурное проектирование алгоритма состоит в движении «от общего к частному» в процессе формулировки действий, выполняемых программой. В записи алгоритма это соответствует движению от внешней (объемлющей) конструкции к внутренней (вложенной). Конкретно в структурном программировании это выражается в том, что любая словесная формулировка действий (алгоритма) может быть заменена на одну из трех формальных конструкций языка программирования:
? простая последовательности действий (блок);
? конструкция выбора (выбора) (условный оператор);
? конструкция повторения (оператор цикла).
Выбранная формальная конструкция представляет собой часть процесса перевода словесного описания алгоритма на формальный язык. Естественно, что эта конструкция не определяет полностью всего содержания алгоритма. Поэтому составными ее частями остаются словесные формулировки более конкретных (вложенных) действий. В результате проектирования получается программа, в которой принципиально отсутствует оператор перехода goto, поэтому структурное программирование иначе называется как программирование без goto.
Другое достоинство нисходящего проектирования: при обнаружении «тупика», то есть ошибки в логических рассуждениях можно вернуться на несколько уровней вверх и продолжить процесс проектирования в другом направлении.
Одновременное проектирование алгоритма и структур данных. При нисходящей пошаговой детализации программы необходимые для работы структуры данных и переменные появляются по мере перехода от неформальных определений к конструкциям языка, то есть процессы детализации алгоритма и данных идут параллельно. Однако это касается, прежде всего, отдельных локальных переменных и внутренних параметров. С самой общей точки зрения предмет (в нашем случае - данные) всегда первичен по отношению к выполняемым с ним действиям (в нашем случае -алгоритм). Поэтому способ организации данных в программе более существенно влияет на ее структуру алгоритма, чем что-либо другое, и процесс проектирования структур данных должен опережать процесс проектирования алгоритма их обработки.
Нисходящее пошаговое модульное тестирование. Кажется очевидным, что отлаживать можно только написанную программу. Но это далеко не так. Разработка программы по технологии структурного программирования может быть произведена не до конца. На нижних уровнях можно поставить «заглушки», воспроизводящие один и тот же требуемый результат, можно обойти в процессе отладки еще не написанные части, используя ограничения во входных данных. То же самое касается модульного программирования. Можно проверить уже разработанные функции на тестовых данных. Сказанное означает, что отладка программы может производиться в некоторой степени параллельно с ее детализацией.
Одно из трех
Обратим внимание на некоторые особенности процесса, которые остались за пределами «заповедей» и которые касаются содержательной стороны проектирования.
Цель (результат) = действие + цель (результат). Каждый шаг проектирования программы заключается в том, что словесная формулировка алгоритма заменяется на одну из трех возможных конструкций языка, элементы которой продолжают оставаться в неформальной, словесной формулировке. Если же с каждым фрагментом программы связать результат ее работы (или цель), то каждый шаг детализации должен сопровождаться преобразованием формулировок: цель (результат) = выбранная конструкция + цель (результат) вложенной конструкции.
Последовательность действий, связанных результатом. Многие почему-то считают, что основа логики сложной программы -условные и циклические действия. Понятно, что они определяют лицо программы.
Но на самом деле наиболее часто используемой программной конструкцией является простая последовательность действий. Поэтому первое, что необходимо сделать на очередном шаге детализации алгоритма - проверить, нельзя ли его представить в виде последовательности шагов «делай раз, делай два…». Во-вторых, между различными шагами существуют связи через общие переменные: предыдущий шаг формирует значение переменной, придавая ей определенный «смысл», последующие шаги ее используют. Это является обязательным элементом проектирования, без него нельзя продвигаться дальше в детализации выделенных шагов.
Последовательность действий, связанных результатом является предпочтительной конструкцией еще и потому, что она обеспечивает синтаксическую независимость (отсутствие вложенности) выполняемых действий. Если в алгоритме выполняется проверка условий (в виде нетривиального действия), а также действия, являющиеся следствием этой проверки, то лучше использовать связующую переменную (например, признак). Например, при проверке и сохранении простого числа лучше использовать признак, а сохранение вынести за пределы цикла проверки.
//------------------------------------------------------------------------------
// Запоминание простого числа в виде
// последовательности действий, связанных признаком
int pr=0;
for (int n=2; n<v; n++) // Проверка - Установить признак делимости
if (v%n==0) { pr=1; break; }
if (pr==0) A[i++]=v; // Признак не установлен - запоминание
//-----------------------------------------------------------------------------
// Неструктурированный вариант - запись внутри цикла
n=2;
while (v%n!=0){
n++;
if (n==v) { A[i++]=v; break; }
}
О том, какая конструкция должна быть выбрана на следующем шаге детализации, можно судить и по внешнему виду формулировки. Другое дело, что эта формулировка должна как можно точнее отражать сущность алгоритма и, что самое главное, «покрывать» его целиком, не оставляя не оговоренных действий:
? если в формулировке присутствует набор действий, объединенных соединительным союзом И, то речь, скорее всего, идет о последовательности действий. Например, шаг сортировки выбором: выбрать минимальный элемент И перенести его в выходную последовательность И удалить его из входной путем сдвига «хвоста» последовательности влево;
? когда в формулировке присутствует слово ЕСЛИ, речь идет о условной конструкции (конструкции выбора);
? если в формулировке присутствуют обороты типа «для каждого… выполнить» или «повторять…пока», речь идет о циклической конструкции.
И последнее достоинство: шаги последовательности действий, после того как они определены, могут конкретизироваться в любом порядке, например «по линии наименьшего сопротивления» от простых к более сложным.
Программирование без goto.
«Среда обитания» программы. Каждая конструкция языка не просто встраивается в программу, а определяет свойства используемых ею данных, «смысл» переменных, которые появились в программе одновременно с ней. Поэтому при использовании исключительно вложенных конструкций мы получим в каждой точке программы определенный набор выполняемых условий, своего рода «среду обитания» алгоритма. Эти переменные являются исходными данными для очередного шага детализации алгоритма.
Рис. 33.2. «Среда обитания» программы
Почему «программирование без goto»? Нисходящее пошаговое проектирование исключает использование оператора goto, более того, запрещает его применение как нарушающего структуру программы. И дело здесь не в том, что «бог любит троицу» и три основных логических конструкции являются достаточными. Goto страшен не тем, что «неправильно» связывает разные части алгоритма, а в том, что переводит алгоритм из одних «условий обитания» в другие: в точке перехода они составлены без учета того, что кто-то сюда войдет «не по правилам».
Допустимые случай использования goto. Чрезвычайными обстоятельствами, вынуждающими прибегнуть к помощи оператора goto, являются глобальные нарушения логики выполнения программы, например грубые неисправимые ошибки во входных данных. В таких случаях делается переход из нескольких вложенных конструкций либо в конец программы, либо к повторению некоторой ее части. В других обстоятельствах его использование свидетельствует скорее о неправильном проектировании структуры программы - наличии неявных условных или циклических конструкций (см. 1.4 «историческое программирование»). Пример правильного использования goto.
retry: for(...) { for (...)
{...
if () goto retry;... // Попытаться сделать все сначала
if () goto fatal; } // Выйти сразу же к концу
}
fatal:
Все равно при использовании оператора перехода нужно изменить условия текущего выполнения программы применительно к точке перехода, например, переоткрыть файлы, установить начальное (заключительное) значение переменных. Операторы continue, break и return. Чаще встречаются случаи более «мягкого» нарушения структурированной логики выполнения программы, не выходящие за рамки текущей синтаксической конструкции: цикла или функции. Они реализуются операторами continue, break, return, которые рассматриваются как ограниченный вариант goto:
? continue - переход завершающую часть цикла;
? break - выход из внутреннего цикла;
? return - выход из текущего модуля (функции).
void F(){
for (i=0; i<n; m1: i++)
{
if (A[i]==0) continue; //goto m1;
if (A[i]==-1) return; //goto m2;
if (A[i] <0) break; //goto m3;
}
m2: ... продолжение тела функции
m3: }
Хотя такие конструкции нарушают чистоту подхода, все они имеют простые структурированные эквиваленты c с использованием дополнительных переменных - признаков.
for (i=0; i<n; i++) // Выход по break при обнаружении
{ if (..a[i]...) break; ... } // элемента с заданным свойством
if (i==n) A else B // Косвенное определение причин выхода
int found; // Эквивалент с признаком обнаружения элемента
for (found=0, i=0; i<n && !found; i++)
{ if (..a[i]..) found++; ... }
if (!found) A else B
При отсутствии в массиве элемента с заданным свойством выполняется A, в противном случае - B. Во втором фрагменте используется специальный признак для имитации оператора break.
20. Модульное программирование и раздельная компиляция.
Модульное программирование осуществляется путём разбиения задачи на некоторое число различных модулей. Под модульным программированием понимают умение широко (всесторонне) использовать стандартные модули путём настройки их параметров; автоматизацию сборки готовых модулей из библиотек, банков модулей. Модуль, в свою очередь, отдельная функционально-законченная программная единица. Как правило, каждый модуль содержит паспорт, в котором указаны все основные его характеристики: язык программирования, объём, входные и выходные переменные, их формат, ограничения на них, точки входа, параметры настройки и так далее.
Объём модуля обычно не превышает 1000 команд ЭВМ или операторов языка программирования. В противном случае модуль становится громоздким и трудным к восприятию и использованию. Модуль можно сравнить с устройством, имеющим средства сопряжения (подключения), через которые происходит как управление самим устройством, так и обмен данными. Это своего рода чёрный ящик, для которого импорт и экспорт определяют его интерфейс и зависимость от других устройств. Стандартизация интерфейса между отдельными программными единицами - вот основная черта модульного программирования. Интерфейс в модульном программировании рассматривается как жёсткая спецификация, контракт, который должен неукоснительно соблюдаться клиентами модуля (импортирующими его) и реализацией данного модуля (или несколькими альтернативными реализациями). Основные концепции модульного программирования: - каждый модуль реализует единственную независимую функцию; - каждый модуль имеет единственную точку входа и выхода - на входе программный модуль получает определённый набор исходных данных, выполняет содержательную обработку и возвращает один набор результатных данных, то есть реализуется стандартный принцип IPO (Input-Process-Output - вход-процесс-выход); - размер модуля по возможности должен быть минимизирован; - каждый модуль может быть разработан и закодирован различными членами бригады программистов и может быть отдельно протестирован; - вся система построена из модулей; - модуль не должен давать побочных эффектов; - каждый модуль не зависит от того, как реализованы другие модули. В результате такого подхода сложная система разделяется на несколько частей, одновременно создаваемых различными программистами. Каждый модуль реализует единственную функцию. Размер модуля не велик, поэтому тестирование управляемо и может быть проведено тщательным образом.
После кодирования и тестирования всех модулей происходит их интеграция, и тестируется вся система. При сопровождении тестируется и отлаживается только тот модуль, который плохо работает. Очевидны преимущества в облегчении написания и тестирования программ, уменьшается стоимость их сопровождения. Модульная структура программных продуктов Принципы модульного программирования программных продуктов строятся на такой системе: сначала определяются состав и подчинённость функций, а затем - набор программных модулей, реализующих эти функции. Однотипные функции реализуются одними и теми же модулями. Функция верхнего уровня обеспечивается главным модулем; он управляет выполнением нижестоящих функций, которым соответствуют подчинённые модули. При определении набора модулей, реализующих функции конкретного алгоритма, необходимо учитывать следующее: - каждый модуль вызывается на выполнение вышестоящим модулем и, закончив работу, возвращает управление вызвавшему его модулю; - принятие основных решений в алгоритме выносится на максимально «высокий» по иерархии уровень; - для использования одной и той же функции в разных местах алгоритма создаётся один модуль, который вызывается на выполнение по мере необходимости. В результате дальнейшей детализации алгоритма создаётся функционально-модульная схема (ФМС) алгоритма приложения, которая является основой для программирования. Пример такой схемы можно увидеть в приложении, где видно, что функция Ф1 реализуется в виде последовательности выполнения программных модулей.
Функция Фm реализуется с помощью иерархии связанных модулей. Модуль n управляет выбором на выполнение подчинённых модулей. Функция Фх реализуется одним программным модулем. Чтобы более подробно разобраться в природе модульного программирования, обратимся к истории. До начала 1970-х годов программы создавались в виде монолитных блоков, либо делались из независимых частей, сопряжение которых было достаточно примитивным - на уровне вызовов подпрограмм (процедур). Отсюда появились два понятия - цельная компиляция и независимая компиляция. В свою очередь, под компиляцией понимают трансляцию программы или отдельного программного модуля, составленных на языке программирования высокого уровня (исходная программа, исходный модуль) в программу или модуль на машинном языке или языке, близком к машинному (объектная программа, объектный модуль). Первый случай, то есть цельная компиляция - простой: транслируется вся программа целиком. Во втором случае, при независимой компиляции каждый блок (файл) транслируется отдельно, фактически без наличия информации о точках сопряжения. Все проблемы увязки возлагались на компоновщик. Именно он состыковывал оттранслированные части, соединял программу с библиотеками, которые та использовала. В процессе компиляции программа преобразуется в промежуточную форму, к которой впоследствии необходимо присоединить библиотечные средства, содержащие стандартные подпрограммы и процедуры, а если нужно, то можно добавить любые другие модули, написанные самим пользователем, и скомпилированные в объектные модули, возможно, с иных языков высокого уровня.
Для модульного программирования характерно использование раздельной компиляции, когда компиляция интерфейса и реализации модуля делается отдельно от реализации других модулей, но с обязательным участием интерфейсов всех прямо и косвенно импортируемых модулей. Если нет возможности отделить интерфейс в текстовом или бинарном виде от реализации модуля, то такую систему программирования нельзя считать системой раздельной компиляции, ибо нарушается главный принцип - компиляции модуля при отсутствии в пределах досягаемости компилятора реализаций импортируемых им модулей. Все ошибки несостыковки обнаруживаются на этапе трансляции (причём даже до реализации других модулей, ведь нужны только контракты-интерфейсы). Более примитивная и распространённая схема независимой компиляции не использует эту информацию и вынуждена заниматься выявлением расхождений в сопряжении файлов лишь на этапе компоновки. Высокая гибкость в модульном программировании достигается за счёт совмещения фазы компоновки и загрузки. А в некоторых случаях совмещается на этом этапе (перед компоновкой) и фаза генерирования машинного кода для конкретной целевой архитектуры. То есть безо всякой виртуальной машины достигается эффективное выполнение модулей на любой операционной платформе.
21. Объектно-ориентированное программирование и визуальное программирование
Объемктно-ориентимрованное, или объектное, программимрование (в дальнейшем ООП) -- парадигма программирования, в которой основными концепциями являются понятия объектов и классов. В случае языков с прототипированием вместо классов используются объекты-прототипы.
Определение ООП и его основные концепции
В центре ООП находится понятие объекта. Объект -- это сущность, которой можно посылать сообщения, и которая может на них реагировать, используя свои данные. Данные объекта скрыты от остальной программы. Сокрытие данных называется инкапсуляцией.
Наличие инкапсуляции достаточно для объектности языка программирования, но ещё не означает его объектной ориентированности -- для этого требуется наличие наследования.
Но даже наличие инкапсуляции и наследования не делает язык программирования в полной мере объектным с точки зрения ООП. Основные преимущества ООП проявляются только в том случае, когда в языке программирования реализован полиморфизм; то есть возможность объектов с одинаковой спецификацией иметь различную реализацию.
Язык Self, соблюдая многие исходные положения объектно-ориентированного программирования, ввёл альтернативное классам понятие прототипа, положив начало прототипному программированию, считающемуся подвидом объектного.
Сложности определения
ООП имеет уже более чем сорокалетнюю историю, но, несмотря на это, до сих пор не существует чёткого общепринятого определения данной технологии[2]. Основные принципы, заложенные в первые объектные языки и системы, подверглись существенному изменению (или искажению) и дополнению при многочисленных реализациях последующего времени. Кроме того, примерно с середины 1980-х годов термин «объектно-ориентированный» стал модным, в результате с ним произошло то же самое, что несколько раньше с термином «структурный» (ставшим модным после распространения технологии структурного программирования) -- его стали искусственно «прикреплять» к любым новым разработкам, чтобы обеспечить им привлекательность. Бьёрн Страуструп в 1988 году писал, что обоснование «объектной ориентированности» чего-либо, в большинстве случаев, сводится к ложному силлогизму: «X -- это хорошо. Объектная ориентированность -- это хорошо. Следовательно, X является объектно-ориентированным».
Тимоти Бадд пишет:
Роджер Кинг аргументированно настаивал, что его кот является объектно-ориентированным. Кроме прочих своих достоинств, кот демонстрирует характерное поведение, реагирует на сообщения, наделён унаследованными реакциями и управляет своим, вполне независимым, внутренним состоянием.
По мнению Алана Кея, создателя языка Smalltalk, которого считают одним из «отцов-основателей» ООП, объектно-ориентированный подход заключается в следующем наборе основных принципов (цитируется по вышеупомянутой книге Т. Бадда).
1. Всё является объектом.
2. Вычисления осуществляются путём взаимодействия (обмена данными) между объектами, при котором один объект требует, чтобы другой объект выполнил некоторое действие. Объекты взаимодействуют, посылая и получая сообщения. Сообщение -- это запрос на выполнение действия, дополненный набором аргументов, которые могут понадобиться при выполнении действия.
3. Каждый объект имеет независимую память, которая состоит из других объектов.
4. Каждый объект является представителем класса, который выражает общие свойства объектов (таких, как целые числа или списки).
5. В классе задаётся поведение (функциональность) объекта. Тем самым все объекты, которые являются экземплярами одного класса, могут выполнять одни и те же действия.
6. Классы организованы в единую древовидную структуру с общим корнем, называемую иерархией наследования. Память и поведение, связанное с экземплярами определённого класса, автоматически доступны любому классу, расположенному ниже в иерархическом дереве.
...Подобные документы
Требования к информационной системе интернет-магазина на базе "1С:Предприятие 8". Выбор средства для разработки. Реализация и тестирование программного средства. Редактирование базы данных. Оценка функционального качества программного средства.
курсовая работа [1,7 M], добавлен 07.09.2012Особенности визуальной среды программирования Microsoft Visual Studio 2015 Enterprise. Средства объектно-ориентированного программирования. Этапы проектирования программного комплекса. Отладка и тестирование программы игры "Виселица".
курсовая работа [2,4 M], добавлен 31.01.2016Особенности разработки кода программного модуля на современных языках программирования. Отладка и тестирование программы, оформление документации на программные средства. Применение инструментальных средств для автоматизации оформления документации.
отчет по практике [203,8 K], добавлен 12.04.2015Виды и классификация программного обеспечения. Операционные системы. Виды прикладного программного обеспечения. Программные средства работы с текстом, для вычислительных работ, с графикой, со звуком. Базы данных. Языки и системы программирования.
реферат [87,7 K], добавлен 07.03.2009Характеристика устройств реального времени: принципы их создания, виды, практическое применение к операционным системам для персональных компьютеров. Основные свойства системы LynxOS, поддержка приложений, сетевые возможности. Средства кросс-разработки.
реферат [33,1 K], добавлен 02.12.2013Архитектура программного продукта и требования к платформе, обоснование выбора разработки. Закономерности и основные этапы алгоритмизации и программирования, а также отладка и тестирование продукта. Разработка и содержание руководства пользователя.
дипломная работа [2,3 M], добавлен 19.01.2017Тестирование и отладка программного обеспечения: понятие, принципы, этапы, цели и задачи. Тестирование методом сандвича как компромисс между восходящим и нисходящим подходами. Сущность метода "белого и черного ящика", отладки программного обеспечения.
курсовая работа [36,9 K], добавлен 21.07.2012Описание существующих информационных систем в данной сфере. Система управления "Fidelio". Выбор средства для разработки. Тестирование программного средства, оценка его функционального качества. Описание выявленных недостатков разработанной программы.
курсовая работа [856,6 K], добавлен 24.09.2014Возможности среды программирования delphi при разработке приложения с визуальным интерфейсом. Разработка спецификации программного обеспечения и на ее основе кода программного продукта. Отладка программы "трассировкой", ее тестирование и оптимизация.
курсовая работа [501,4 K], добавлен 07.12.2016Проект системы автоматизированного аудита программного обеспечения вычислительного центра ЛГТУ; функциональное назначение, методы и средства разработки концептуальных статических и динамических моделей пользовательского интерфейса; технические средства.
курсовая работа [4,2 M], добавлен 04.01.2012Возможности среды программирования delphi при разработке приложения с визуальным интерфейсом. Отладка программных модулей с использованием специализированных программных средств. Тестирование программного обеспечения. Оптимизация программного кода.
курсовая работа [974,0 K], добавлен 21.12.2016Архитектура и история создания операционной системы Android. Язык программирования Java. Выбор средства для реализации Android приложения. Программная реализация Android приложения. Проведение тестирования разработанного программного обеспечения.
курсовая работа [167,8 K], добавлен 18.01.2017Порядок разработки пользовательской документации. Руководство по инсталляции программного средства. Справочник по применению программного средства. Печать с помощью функций файлового ввода/вывода. Печать текстов в обогащенном формате методом Print.
курсовая работа [78,3 K], добавлен 05.02.2016Основные требования к составу и параметрам технических средства. Верификация программного продукта. Расширение функционала программы и его реализация. Отладка и тестирование программного продукта. Тестирование программы в граничных и реальных условиях.
курсовая работа [1,3 M], добавлен 29.12.2014Выбор, обоснование и особенности языка программирования. Вербальное и графическое описание функционального назначения системы. Разработка диаграммы классов, описывающей логическую модель системы. Проектирование физической структуры программного средства.
курсовая работа [2,4 M], добавлен 26.05.2014Вычислительная система, необходимая для создания программного средства. Создание диалогового процесса интерфейса пользователя. Элементы управления и визуализации. Справочная система программного средства. Редактирование, добавление и удаление вопросов.
курсовая работа [2,8 M], добавлен 08.07.2012Анализ и разработка информационной системы, структура сети предприятия. Описание процесса разработки конфигураций и выявление потребностей в автоматизации функций. Средства разработки проектирования и архитектура базы данных. Разработка модели угроз.
дипломная работа [1,4 M], добавлен 13.07.2011Разработка информационно-справочной системы на тему "Наука и техника. Средства передвижения". Характеристика программного продукта. Анализ существующих аналогов. Выбор языка программирования Turbo Pascal версии 7.0. Метод и алгоритм решения задачи.
курсовая работа [262,5 K], добавлен 29.01.2009Эффективные средства разработки программного обеспечения. Технология визуального проектирования и событийного программирования. Конструирование диалоговых окон и функций обработки событий. Словесный алгоритм и процедуры программы Borland Delphi 7 Studio.
дипломная работа [660,2 K], добавлен 21.05.2012Этапы разработки и отладки приложения "Помощь почтальону". Составление сопроводительной документации. Выбор средств и методов программирования. Анализ проектных данных. Особенности создания базы данных, СУБД. Тестирование созданного программного продукта.
контрольная работа [2,5 M], добавлен 17.12.2014