Полная версия

Главная arrow Информатика arrow Архитектура и проектирование программных систем

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ   >>

Представление архитектуры программных систем

Модульно-интерфейсный подход

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

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

  • 1) модуль вызывается на выполнение вышестоящим по иерархии модулем и, закончив работу, возвращает ему управление;
  • 2) принятие основных решений в алгоритме выносится на максимально высокий по иерархии уровень;
  • 3) если в разных местах алгоритма используется одна и та же функция, то она оформляется в отдельный модуль, который будет вызываться по мере необходимости.

Структурное проектирование обычно подразумевает использование структур для разделения различных частей системы. Каждая часть при этом может проектироваться отдельно. Один из наиболее традиционных методов проектирования операционных систем в 70-е гг. XX в. состоял в том, что проект каждого основного модуля системы выполнялся отдельно. Этот подход называется модульно-интерфейсным.

Анализируя существующие системы, можно заключить [35, 41], что операционная система состоит из системы ввода-вывода, планировщика времени процессора, менеджера памяти, системы управления файлами и т.д. Каждый модуль выделяется и описывается. Кроме того, определяется его интерфейс с другими модулями. Модули и их взаимные связи образуют абстракцию системы высокого уровня. После этого этапа для дальнейшего проектирования и реализации модули рассматриваются по отдельности.

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

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

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

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

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

Модульно-интерфейсный подход- один из методов структурного проектирования. Спецификации модулей и их интерфейсов дают структурную основу для проектирования каждого модуля и системы в целом. Спецификация программного модуля состоит из функциональной спецификации, описывающей семантику функций, выполняемых этим модулем по каждому из его входов, и синтаксической спецификации его входов, позволяющей построить на используемом языке программирования синтаксически правильное обращение к модулю [33].

Существуют различные методы разработки модульной структуры программной системы, в зависимости от которых определяется порядок разработки структуры системы, программирования и отладки модулей, указанных в этой структуре. Обычно в литературе выделяют два основных метода [10, 17, 30, 37, 40]: метод нисходящей разработки (метод «сверху вниз», или top-down) и метод восходящей разработки (метод «снизу вверх», или bottom-up).

По мнению В. Турского [37], формулировка «аналитический и синтетический подходы» к проектированию программ является более правильной, поскольку действительная суть проблемы не столько в выборе направления при проектировании, сколько в определении того, что именно преобладает: факторизация (аналитические шаги) или композиция (синтетические шаги). Ни один из этих подходов в их чистом виде не является жизнеспособной методологией проектирования: чисто аналитическое проектирование сравнимо с построением «пирамиды с плавающей в воздухе вершиной», а чисто синтетическое - с построением пирамиды, «стоящей на голове». Реальная стратегия проектирования почти всегда представляет собой разумное сочетание этих двух подходов.

 
<<   СОДЕРЖАНИЕ   >>