Cтраница 2
Самым сильным сцеплением элементов модуля является функциональное. Это и понятно: основным принципом разделения программы был провозглашен функциональный. Любое отклонение от этого принципа усложняет процесс внесения изменений, повторные использования модуля в функциональной структуре. Конечно, точное определение функциональной связи затруднительно. Особенно сложно проведение границы между функциональным и процедурным сцеплением на нижних уровнях иерархии структурной схемы. [16]
С разными вариациями они базируются на функциональном принципе разделения проектируемой программы на составные части. Такой подход довольно естествен, так как функциональное содержание задачи должно быть хорошо известно, а при сопровождении программ возникающие изменения носят, как правило, функциональный характер. Поэтому при функциональной структуре программы облегчается локализация изменяемого модуля и ограничивается влияние изменения на другие программные модули. В связи с тем что функциональная структура у каждой задачи своя, то рекомендации по разделению программ носят достаточно общий характер, хотя и обладают высокой степенью универсальности. [17]
Неоднозначность и сложность эвристических методов структурирования заставляет искать другие пути решения этой проблемы. Цель состоит в том, чтобы найти объективный критерий разделения программы на составные части. В общем случае структура программы определяется свойствами обрабатываемых данных ( входных и выходных) и содержанием выполняемых над ними преобразований. Для задач, обрабатывающих данные сложной структуры, связь структуры программы со структурой данных оказывается достаточно заметной. Так, если во входном потоке встречаются независимые и независимо обрабатываемые данные, то в программе эту обработку выполняют разные модули. Если входные данные имеют повторяющуюся структуру ( однотипные записи одного и того же набора), то и в программе встретится элемент, многократно выполняющий одни и те же действия. [18]
Принцип развития заключается в необходимости создания программного обеспечения с учетом возможных дополнений и изменений. Этот принцип реализуется модульной организацией программного обеспечения, состоящей в разделении программ и пакетов прикладных программ на самостоятельные программные модули определенного функционального назначения. Такая организация позволяет при необходимости совершенствования программного обеспечения легко вводить новые модули, удалять ненужные или заменять модифицируемые. [19]
Однако, такого рода paccyamthvin уволят нас к свойствам языков программирования, компиляторов, KOMiiououLUHKOi сред выполнения программ, что нссьмл далеко от алгоритмов. Поэтому, чаше нес го булем придерживаться простого, об те при н итого разделения программы на дна фдйлаь где АТД реализуете л н ни е классов О, общедоступные функции-члены составляют интерфейс, а реал мнения объединяется с интерфейсом и отдельном файле, который включается в программы - клиенты н компилируется кажлык раз, когда компилируются клиентские программы. [20]
Помимо удобства программирования, применение сегментирования адресного пространства дает определенные преимущества при управлении ресурсами в операционной системе. Операционная система, конечно, может использовать атрибуты сегментов и автоматическое расширение размера сегментов для реализации своих функций. Но особенно большие преимущества дает возможность динамической связи и разделения программ. [21]
Способы документирования также различны в разных методах проектирования, но общим в них является требование, чтобы документирование проекта осуществлялось не после окончания этапа, а в процессе его выполнения, являясь необходимым инструментом самого процесса проектирования. В этом случае не только сокращается время разработки, но и достигается более высокая достоверность документации. Одни способы документирования могут быть тесно связаны с соответствующими им способами разделения программ, другие, более универсальные, могут использоваться в рамках различных методик проектирования. [22]
Система IDS поддерживает сетевую оргакчг-зацию данных на магнитных дисках и обеспечивает возможность многоцелевого активного использования наборов. С помощью способа, в котором часть описания данных содержится в самом файле, стало возможным разделение программ и данных. [23]
В большинстве реальных систем ПО межмодульные интерфейсы описываются таким образом, что ответственность за обнаружение внешних ошибок и реакция на них возлагаются на модули, которые непосредственно имеют дело с внешним интерфейсом. Например, ответственность за обнаружение несоответствий в сообщениях оператора ( типа буква в числовом поле) перепоручается программе, обеспечивающей работу с пультом оператора. Это, казалось бы, не противоречит интуитивному понятию модульности, но на самом деле является нарушением принципа распределения информации, принятого при разделении программ на модули. [24]
Получение программы с перекрытием обеспечивается управляющими операторами РЕДАКТОРА и специальными средствами языка программирования. Формирование фаз происходит на этапе редактирования из объектных модулей. При этом среди всех фаз выделяется одна, называемая корневой, которая осуществляет загрузку остальных фаз. Разделение программы на фазы и выделение корневой производит программист на этапе подготовки программы. [25]
Ядро GPS состоит из основной исполнительной программы ( executive) и эвристических методов, которые позволяют исполнительной программе ставить и оценивать цели ( goals) и пытаться их достигнуть. В GPS входит также набор вспомогательных структур и механизмов обработки информации. Разделение программы на ядро решения и среды задач позволяет ядру работать в достаточно абстрактных и общих терминах, В частности, ядро GPS работает с объектами, операторами для изменения объектов, характерными признаками объектов и различиями между объектами. [26]
Программа вводится по строкам. Допустимое количество символов в строке программы определяется шириной экрана дисплея. Однако не следует стремиться всегда заполнять строку полностью. При разделении программы на строки нужно исходить из соображений удобства восприятия программы и внесения в нее исправлений. При вводе строки пробелы могут вводиться произвольно, это не влияет на выполнение введенной строки. Не допускается использование пробелов в именах переменных и в служебных словах. При высвечивании ( или распечатке) текста программы машина игнорирует пробелы, введенные пользователем, и расставляет их стандартным образом. [27]
Известны 2 класса методов разработки программного обеспечения: методы, ориентированные на представление данных и проблемно-ориентированные методы. К 1-му классу относится метод Джексона, постулировавшего, что программа представляет собой отображение перерабатываемых данных и их структур. Приводится пример программной инверсии, которая в соответствии с этим методом связывает программы, отображающие входные и выходные структуры данных. Различные проблемно-ориентированные методы вытекают из предложенного Парнасом принципа разделения программы на модули. Как следует из этого принципа, внутренняя структура программного модуля, выключая применяемые структуры данных, должна, насколько это возможно, оставаться скрытой от соседних модулей, а сами данные должны иметь локальный характер. Приводится пример нисходящего программирования, иллюстрирующий этот принцип. Указывается, что, несмотря на существенное различие подходов, реализованных в методах Джексона и Парнаса, возможно развитие концепций, объединяющих оба эти принципа. [28]
Система 8.2, г предусматривает разделение функций на еще более низком уровне - уровне базисных механизмов. Таким образом, все подсистемы работают при поддержке собственной операционной системы. На рис. 8.2, г представлены четыре операционных системы: две DOS и две OS. В отличие от системы 8.2, в в системе 8.2, г не предусмотрено разделение программ ядра. Параллельная работа нескольких операционных систем координируется лишь с помощью примитивного базисного механизма, называемого интерфейсом виртуальной машины. Такой интерфейс гарантирует одновременное функционирование на одной вычислительной машине нескольких подсистем, ориентированных на работу с различными операционными системами. На рис. 8.2, д схематически изображена мини-сеть, в которой совместно не используется даже аппаратура. В целом рис. 8.2 дает представление о том, сколь разнообразные системы, от простых систем без мультипрограммирования до мини-сетей, можно получить в зависимости от того, какими именно функциями предстоит пользоваться совместно и какие именно интерфейсы решено обеспечить в рамках каждого из независимых параллельных средств. [29]
Кроме того, сформулированных требований оказалось явно недостаточно для разрешения всех возникших проблем. Необходимо было более тщательно разработать процесс разделения программы и внутреннего построения каждого отдельного модуля. [30]