9. Назовите основные задачи разработки архитектуры пс.

Архитектура ПС – представление ПС в виде системы, состоящей из некоторой совокупности взаимодействующих подсистем. Подсистема представляет собой некоторую программу. Разработка архитектуры является первым и очень важным этапом борьбы со сложностью ПС, так как позволяет выделять относительно независимые модули или подсистемы. Результатом правильного выделения модулей является уменьшение сложности ПС. Основные задачи разработки архитектуры ПС:

1) выделение программных подсистем и отображение на них внешних функций;

2) определение способов взаимодействия между выделенными программами

подсистемы.

10. Назовите основные классы апс, что такое апс?

АПС – архитектура ПС. Выделяют следующие основные классы АПС:

1) цельная программа;

2) комплекс автономно выполняемых программ;

3) слоистая программная система;

4) коллектив параллельно выполняемых программ.

11. Что используют для контроля апс? Расскажите об этих видах контроля.

Для контроля АПС используются смежный контроль и ручная имитация.

Смежный контроль – двусторонний контроль: сверху – контроль разработчиками внешнего описания, снизу – контроль разработчиками отдельных компонентов программы, входящих в состав данного ПС.

Целью ручной имитации является проверка взаимодействия программных

подсистем. Разрабатываются тесты (исходные данные), затем группой разработчиков имитируется работа каждой подсистемы ПС. Контролируется взаимодействие и обеспечивается имитация работы ПС в целом.

12. Что из себя представляет цельная программа?

Цельная программа представляет вырожденный случай АПС. В состав ПС

входит одна программа. Такую архитектуру выбирают тогда, когда у ПС ярко выраженная функция, и её реализация не представляется слишком сложной.

13. Что такое программный модуль?

При разработке каждой программы ПС, нужно иметь в виду, что она является

большой системой, и мы должны принять меры для её упрощения. Для этого ПС разрабатывают по частям, которые называются программными модулями. Метод такой разработки программ называют модульным программированием. Программный модуль (ПМ) – это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях процесса. При этом каждый ПМ программируется, компилируется и отлаживается отдельно от других модулей программы (физически разделён с другими модулями программы). Кроме того, каждый разработанный программный модуль может включаться в состав разных программ. Таким образом, ПМ может рассматриваться и как средство борьбы со сложностью программ, и как средство борьбы с дублированием в программировании.

Применение модульного программирования в процессе разработки программ

реализует общие методы борьбы со сложностью, а именно, обеспечение независимости компонент системы и использование иерархических структур.

14. Перечислите и опишите конструктивные характеристики пм.

Не всякий ПМ способствует упрощению программы. Выделить хороший с этой точки зрения модуль является серьёзной творческой задачей. Для оценки приемлемости выделенного модуля используются некоторые критерии. Майерс предлагает для этого использовать конструктивные характеристики ПМ:

– размер модуля;

– прочность модуля;

– сцепление с другими модулями;

– рутинность модуля (независимость от предыстории обращений к нему).

Размер модуля измеряется числом содержащихся в нём операторов или строк.

Модуль не должен быть слишком маленьким или слишком большим. Маленькие модули приводят к громоздкой модульной структуре программы и увеличению накладных расходов на их оформление. Большие модули неудобны для изучения и изменений, они могут существенно увеличить суммарное время повторных трансляций программы при отладке. Обычно рекомендуются ПМ размером от нескольких десятков до нескольких сотен операторов или строк.

Прочность модуля – это мера его внутренних связей. Чем выше прочность модуля, тем больше связей он может спрятать от внешней по отношению к нему части программы и, следовательно, тем больший вклад в упрощение программы он может внести. Для оценки степени прочности модуля Майерс предлагает упорядоченный по степени прочности набор из семи классов модулей. Самой слабой степенью прочности обладает модуль прочный по совпадению. Только два высших по прочности класса модулей рекомендуются для использования.

Функционально прочный модуль – это модуль, выполняющий (реализующий)

одну какую-либо определённую функцию. При реализации этой функции такой модуль могут использовать и другие модули.

Информационно прочный модуль – это модуль, выполняющий (реализующий) несколько операций (функций) над одной и той же структурой данных (информационным объектом). Для каждой из этих операций в таком модуле имеется свой вход со своей формой обращения к нему. Такой класс следует рассматривать как класс ПМ с высшей степенью прочности. Информационно прочный модуль может реализовывать, например, абстрактный тип данных.

Сцепление модуля – это мера его зависимости по данным от других модулей. Характеризуется способом передачи данных. Чем слабее сцепление модуля с другими модулями, тем сильнее его независимость от других модулей. Для оценки степени сцепления Майерс предлагает упорядоченный набор из шести видов сцепления модулей. Худшим видом сцепления модулей является сцепление по содержимому. Таким является сцепление двух модулей, когда один из них имеет прямые ссылки на

содержимое другого модуля (например, на константу, содержащуюся в другом модуле). Такое сцепление модулей недопустимо. Не рекомендуется использовать так же сцеплений по общей области – это такое сцепление модулей, когда несколько модулей используют одну и ту же область памяти. Единственным видом сцепления модулей, которое рекомендуется для использования современной технологией программирования, является параметрическое сцепление. Это случай, когда данные передаются модулю либо при обращении к нему как значение его параметров, либо как

результат его обращения к другому модулю для вычисления некоторой функции. Такой вид сцепления модулей реализуется на языках программирования при использовании обращений к процедурам (функциям).

Рутинность модуля – это его независимость от предыстории обращений к

нему. Модуль будем называть рутинным, если результат обращения к нему зависит только от значений его параметров (и не зависит от предыстории обращений к нему). Модуль будем называть зависящим от предыстории, если результат обращения к нему зависит от внутреннего состояния этого модуля, изменяемого в результате предыдущих обращений к нему. Майерс не рекомендует использовать зависящие от предыстории (непредсказуемые) модули, так как они провоцируют появление в программах хитрых (неуловимых) ошибок. Однако такая рекомендация является малоконструктивной, так как во многих случаях именно зависящий от

предыстории модуль является лучшей реализацией информационно прочного модуля. Поэтому более справедлива следующая рекомендация:

– всегда следует использовать рутинный модуль, если это не приводит к пло-

хим (не рекомендуемым) сцеплениям модулей;

– модули, зависящие от предыстории, следует использовать только в случае,

когда это необходимо для обеспечения параметрического сцепления;

– в спецификации модуля, зависящего от предыстории, должна быть чётко

сформулирована эта зависимость для возможного прогнозирования поведения

данного модуля при разных последующих обращениях к нему.