Структурное кодирование модулей программ заключается в особом оформлении их текстов. У модуля должен быть легко различимый заголовок с комментарием, поясняющим функциональное назначение модуля. Имена переменных должны быть мнемоническими. Суть переменных и порядок размещения в них информации должны быть пояснены комментариями, а код модуля закодирован с использованием типовых алгоритмических структур с использованием отступов.
Нисходящее проектирование рациональной иерархии модулей программ заключается в выделении первоначально модулей самого верхнего уровня иерархии, а затем подчиненных модулей.
Нисходящая реализация программы состоит в первичной реализации группы модулей верхних уровней, которые называются ядром программы, и далее постепенно, в соответствии с планом, реализуются модули нижних уровней. Необходимые для линковки программы, недостающие модули имитируются заглушками.
Осуществление планирования на всех стадиях проекта позволяет первоначально спланировать как состав стадий, так и продолжительность всех этапов работ. Такое планирование позволяет завершить разработку в заданный срок при заданных затратах на разработку. Далее планируются порядок и время интеграции модулей во все расширяющееся ядро. Планируются мероприятия по тестированию программы от ранних до заключительных этапов.
Язык Си с нуля — Урок 47 — Многофайловые проекты. Создание и подключение. Заголовочные файлы.
Сквозной структурный контроль заключается в соблюдении заранее намеченного плана тестирования, который охватывает период от разработки внешних спецификаций, далее внутренних спецификаций и их корректировку в периоде реализации вплоть до приемо-сдаточных испытаний. Составляющие программу модули тестируются как во время написания их кода, так и при автономном тестировании, инспекции их исходного кода, при тестировании сразу по подключению к ядру.
7.2.2. Понятие заглушки модуля
При структурном программировании программа в основном реализуется (собирается и тестируется) сверху вниз. Сначала из 20-30 модулей пишется ядро. Чтобы начать тестировать, недостающие модули нижних уровней заменяются заглушками. По окончании тестирования ядра, заглушки заменяются новыми готовыми модулями, но если программа еще не закончена, то для успешной ее линковки понадобятся все новые заглушки недостающих модулей. Теперь можно приступать к тестированию собранной части и т. д.
Заглушка — это макет модуля. Самая простая заглушка — это подпрограмма или функция без действий. Более сложная заглушка может выводить сообщение о том, что отработал такой-то модуль. Еще более сложные заглушки могут выводить входную информацию в какой-нибудь файл отладки. Наконец, еще более сложные заглушки выдают на выход тестовую информацию, необходимую для проверки уже реализованных модулей.
Написание заглушек — «лишняя» работа, но требуется искусство проектировщика, чтобы максимальное количество заглушек были простыми, а тестирование уже собранной части программы было бы полным.
7.2.3. Средства изменения топологии иерархии программы
Программная работа с условным оформлением
В процессе нисходящего проектирования рациональной иерархии модулей программы необходимо получить оптимальную подчиненность.
Схеме иерархии можно придать любой топологический рисунок. Так, схеме иерархии, изображенной на рис. 7.2, а, можно придать вид, изображенный на рис. 7.2, б.
Фрагменты с вертикальными вызовами могут быть преобразованы в вызовы с одного уровня посредством введения дополнительного модуля, который может не выполнять никаких полезных функций с точки зрения алгоритма программы. Функция нового модуля может состоять лишь в мониторинге, т. е. вызове других модулей в определенном порядке.
Рис. 7.2. Схема иерархии одной и той же программы: а — с вертикальными вызовами; б — с горизонтальными вызовами
Фрагменты с горизонтальными вызовами на одном уровне могут быть преобразованы в вертикальные вызовы модулей разных уровней посредством введения дополнительных переменных. Эти переменные не могут быть получены путем декомпозиции функционального описания на подфункции. Эти дополнительные переменные обычно имеют тип целый или логический и называются флагами (семафорами, ключами) событий. Их смысл обычно характеризуется фразой: «В зависимости от предыстории действий, выполнить такие-то действия».
В процессе проектирования нужно сделать несколько проектных итераций, генерируя каждый раз новую схему иерархии, и сравнить эти иерархии по критериям оценки качества схемы иерархии.
7.2.4. Критерии оценки качества схемы иерархии
Проектированию структуры программы предшествует разработка внешних функциональных описаний. Функциональные описания (алгоритмы выполнения программы) для достижения их восприятия должны быть декомпозированы от общего к частному. Также они должны включать описания форм представления и объема внутренних данных.
Итак, сначала имеется первый вариант схемы иерархии, полученный путем простого членения функций программы на подфункции с указанием переменных, необходимых для размещения данных на разных шагах обработки. Скорее этот вариант не является оптимальным, и требуются проектные итерации (обычно выполняются методом «проб и ошибок») для улучшения топологии схемы.
Каждый новый вариант сравнивается с предшествующим вариантом по описанным здесь критериям. Генерация вариантов прекращается при невозможности дальнейших улучшений.
Фонд критериев оптимальности схем иерархии является необходимым подспорьем при оптимизации схем иерархии и состоит из 13 критериев.
Первый — полнота выполнения специфицированных функций.
Второй — возможность быстрого и дешевого пополнения новыми, ранее не специфицированными функциями.
Третий, вытекающий из блочно-иерархического подхода, — обозримость (понятность) для проектировщика составных частей программы.
Четвертый критерий оценки качества структуры — максимальная независимость по данным отдельных частей программы.
Пятый — возможность связывания программы с обширной многоуровневой схемой иерархии конкретным редактором связей (линковщиком). Если начинаете работать над новой программой, то очень полезно выполнить на ЭВМ ее модель в виде пустых заглушек модулей, которые не содержат никаких действий.
Шестой — достаточность оперативной памяти. Здесь рассматриваются варианты с описанием особенно структурированных статических и динамических переменных на разных уровнях схемы иерархии. Проверка удовлетворения данного критерия осуществляется расчетами с некоторыми машинными экспериментами.
Седьмой — оценка влияния топологии схемы иерархии на скорость выполнения программы при использовании оверлеев (динамической загрузки программы) и механизма подкачки страниц при разработке программы, которая целиком не может быть размещена в оперативной памяти.
Восьмой — отсутствие разных модулей, выполняющих похожие действия. В идеале — один и тот же модуль вызывается на разных уровнях схемы иерархии.
Девятый — достижение при реализации программы такого сетевого графика работы коллектива программистов, который обеспечивает равномерную загрузку коллектива по ключевым датам проекта.
Десятый — всемерное сокращение затрат на тестирование уже собранного ядра программы по ключевым датам сетевого графика реализации. Характеризуется простотой используемых заглушек и качеством тестирования по всем вычислительным маршрутам модулей. Достигается первичной реализацией сверху вниз модулей ввода и вывода программы с отсрочкой реализации остальных ветвей схемы иерархии. Обычно затраты на тестирование как по срокам, так и деньгам составляют около 60 % стоимости всего проекта. Хорошая схема иерархии сокращает затраты на тестирование по сравнению с первоначальным вариантом в 2-5 раз и более.
Одиннадцатый — использование в данном проекте как можно большего числа разработанных в предшествующих проектах модулей и библиотек при минимальном объеме изготавливаемых заново частей.
Двенадцатый — удачное распределение модулей по компилируемым файлам программы и библиотекам.
Тринадцатый — накопление уже готовых модулей и библиотек модулей для использования их во все новых разработках.
Итак, хорошая структура программы обеспечивает сокращение общего объема текстов в 2 или 3 раза, что соответственно удешевляет проект; на несколько порядков удешевляет тестирование (на тестирование обычно приходится не менее 60 % от общих затрат проекта), а также облегчает и удешевляет сопровождение программы.
Источник: sharlib.com
В Камаев: Технологии программирования
Выбрав категорию по душе Вы сможете найти действительно стоящие книги и насладиться погружением в мир воображения, прочувствовать переживания героев или узнать для себя что-то новое, совершить внутреннее открытие. Подробная информация для ознакомления по текущему запросу представлена ниже:
Технологии программирования
Издательство:
Издательство «Высшая школа»
5-06-004870-5
Рейтинг книги:
Добавить книгу в избранное
Ваша оценка:
- Описание
- Другие книги автора
- Правообладателям
- Похожие книги
В книге изложены технологии структурного программирования, объектно-ориентированного проектирования, визуального программирования, технология, основанная на абстракции данных Дейкстеры. Рассмотрено использование средств автоматизации проведения программных разработок. Второе издание (1-е — 2005 г.) дополнено главами по структуре данных и основам инженерии создания программ. Для студентов вузов, обучающихся по направлению «Информатика».
В Камаев: другие книги автора
Кто написал Технологии программирования? Узнайте фамилию, как зовут автора книги и список всех его произведений по сериям.
В течение 24 часов мы закроем доступ к нелегально размещенному контенту.
Эндрю Троелсен
Джесс Либерти
Нейл Мэтью
Бертран Мейер
Владимир Липаев
Технологии программирования — читать онлайн бесплатно полную книгу (весь текст) целиком
Ниже представлен текст книги, разбитый по страницам. Система сохранения места последней прочитанной страницы, позволяет с удобством читать онлайн бесплатно книгу «Технологии программирования», без необходимости каждый раз заново искать на чём Вы остановились. Поставьте закладку, и сможете в любой момент перейти на страницу, на которой закончили чтение.
Структурный подход к программированию представляет собой как методологию, так и технологию создания программ. В свое время его внедрение обеспечило повышение производительности труда программистов при написании и отладке программ; получение программ, которые состоят из модулей и пригодны для сопровождения; создание программ коллективом разработчиков; окончание создания программы в заданный срок.
Структурный подход к программированию воспринял и использует многие методы из области проектирования сложных технических систем. Среди них блочно-иерархический подход к проектированию сложных систем, стадийность создания программ, нисходящее проектирование, методы оценки и планирования.
Структурный подход рекомендует соблюдать следующие принципы при создании программного изделия:
— структурное кодирование модулей программ;
— нисходящее проектирование рациональной иерархии модулей программ;
— нисходящая реализация программы с использованием заглушек;
— осуществление планирования на всех стадиях проекта;
— сквозной структурный контроль программных комплексов в целом и составляющих их модулей.
Модульность программ характеризуется тем, что вся программа состоит из модулей. Некоторые смысловые группы модулей сосредоточиваются в отдельных файлах. Например, в отдельных файлах (Unit) могут быть сосредоточены модули текстового редактора и модули иерархического меню.
Структурное кодирование модулей программ заключается в особом оформлении их текстов. У модуля должен быть легко различимый заголовок с комментарием, поясняющим функциональное назначение модуля. Имена переменных должны быть мнемоническими. Суть переменных и порядок размещения в них информации должны быть пояснены комментариями, а код модуля закодирован с использованием типовых алгоритмических структур с использованием отступов.
Нисходящее проектирование рациональной иерархии модулей программ заключается в выделении первоначально модулей самого верхнего уровня иерархии, а затем подчиненных модулей.
Нисходящая реализация программы состоит в первичной реализации группы модулей верхних уровней, которые называются ядром программы, и далее постепенно, в соответствии с планом, реализуются модули нижних уровней. Необходимые для линковки программы, недостающие модули имитируются заглушками.
Осуществление планирования на всех стадиях проекта позволяет первоначально спланировать как состав стадий, так и продолжительность всех этапов работ. Такое планирование позволяет завершить разработку в заданный срок при заданных затратах на разработку. Далее планируются порядок и время интеграции модулей во все расширяющееся ядро. Планируются мероприятия по тестированию программы от ранних до заключительных этапов.
Сквозной структурный контроль заключается в соблюдении заранее намеченного плана тестирования, который охватывает период от разработки внешних спецификаций, далее внутренних спецификаций и их корректировку в периоде реализации вплоть до приемо-сдаточных испытаний. Составляющие программу модули тестируются как во время написания их кода, так и при автономном тестировании, инспекции их исходного кода, при тестировании сразу по подключению к ядру.
7.2.2. Понятие заглушки модуля
При структурном программировании программа в основном реализуется (собирается и тестируется) сверху вниз. Сначала из 20–30 модулей пишется ядро. Чтобы начать тестировать, недостающие модули нижних уровней заменяются заглушками. По окончании тестирования ядра, заглушки заменяются новыми готовыми модулями, но если программа еще не закончена, то для успешной ее линковки понадобятся все новые заглушки недостающих модулей. Теперь можно приступать к тестированию собранной части и т. д.
Заглушка — это макет модуля. Самая простая заглушка — это подпрограмма или функция без действий. Более сложная заглушка может выводить сообщение о том, что отработал такой-то модуль. Еще более сложные заглушки могут выводить входную информацию в какой-нибудь файл отладки. Наконец, еще более сложные заглушки выдают на выход тестовую информацию, необходимую для проверки уже реализованных модулей.
Написание заглушек — «лишняя» работа, но требуется искусство проектировщика, чтобы максимальное количество заглушек были простыми, а тестирование уже собранной части программы было бы полным.
Источник: libcat.ru
Оформление научной статьи по ГОСТу с примерами
Оформление научной статьи регламентируется следующими ГОСТами:
Издательства научных журналов могут предъявлять свои требования. Список требований к оформлению размещается на сайте издательства.
Самые строгие требования у журналов ВАК (Высшая Аттестационная Комиссия). Если статья не соответствует требованиям, ее отправляют на доработку.
Вариант оформления научной статьи
Статью с ошибками в оформлении отправляют на доработку (Скачать)
Общие требования к оформлению научной статьи
Технические требования к оформлению научной статьи у большинства издательств одинаковые:
- Текст печатается шрифтом Times New Roman, размер 12 или 14, с интервалом 1,5.
- Текстовый редактор Word (в разных издания могут требовать работу в редакторе разных версий).
- Поля: верхнее и нижнее от 20 мм, правое — от 10 мм, левое от 30 мм. ГОСТ позволяет использовать поля до 25 мм по всем сторонам.
- Инициалы и фамилия всегда разделяются пробелами (например: Р. Л. Лимонов).
- Нумерация листов исключительно арабскими цифрами по центру листа. Запрещены точки, римские цифры, расположение номера в другом месте страницы.
- Для десятичного разделителя используется только точка (например 37.05).
- Абзац — возможен отступ от 12 до 15 мм.
- Параметры страницы: формат А4, книжная ориентация.
- Выравнивание основного текста по ширине, а заголовков — по центру.
- Не рекомендуется использовать в тексте жесткие концы строк и переносов, а также макрокоманды и шаблоны.
- В тексте различаются дефис и тире.
- В предложении на русском используются «», в предложении на английском — “”.
- При указании единиц измерения, используется система СИ.
- Сокращения и аббревиатуры расшифровываются при первом упоминании.
Внимательно читайте требования журналов в отношении программ для создания и текста и графических материалов. Например, некоторые издательства требуют присылать текст и таблицы в формате LaTeX.
Структура научной работы
Структура научной статьи состоит из: