Формальное описание методики разработки модульной архитектуры программной системы

Проектирование «сверху вниз»

Как было рассмотрено выше, при разработке программных систем сформировались два основных метода: аналитический метод, или метод «сверху вниз» (top-down), и синтетический метод, или метод «снизу вверх» (bottom-up). В первом случае при разработке проекта идут от абстрактного к конкретному, от общего к частному, от целого к деталям. Во втором методе порядок обратный. Оба метода можно иллюстрировать схемой, приведенной на рис. 6.11. Здесь M,{i = 1,2, п)- вирту

альная машина /-го уровня.

Технология проектирования по методу «сверху вниз» сосредотачивается вокруг двух основных моментов [6, 14, 19, 41]:

• задание директив, касающихся того, как осуществлять пошаговые уточнения и как объединять в модули выделенные функции про-

граммнои системы, установленные на этапе внешнего проектирования системы;

• задание методов представления проектируемого потока управления и его взаимодействия с данными.

Работу в соответствии с таким подходом можно прежде всего разделить на два главных этапа:

  • 1) на первом этапе (шаг 1) выполняется начальный набросок системы (на основании установленных требований, предъявляемых к системе), причем модулей как таковых нет;
  • 2) на втором этапе (шаги 2-п) определяются и реализуются модули с помощью пошагового уточнения.

Целое

Целое

шаг

машины

машины

шаг

>

1

УМ!

УЫП

п

2

УМ2

п4

п-1

?

а

?

а

а

?

а

п-1

Том

УМ2

2

N

V

п

УМ!

1

Детали

--->

Детали

Рис. 6.11. Обобщенная схема проектирования многослойного

программного продукта

Рассмотрим теперь более подробно эти шаги [26].

Шаг 1. Исследуется внешний проект системы (внешние спецификации, определяющие все функции пользователей и взаимодействующих систем) и предлагается общая структура программной системы в виде некой виртуальной машины УМ, снабженной соответствующими операндами (структурами данных) и некоторым множеством операторов (структурами программ).

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

УМ = <Ои ?>!>, (6.13)

где 0 - множество операторов виртуальной машины УМХ - множество данных виртуальной машины УМХ, причем Ох и Ох определяются

внешними спецификациями системы 5/317' (см. главу 5).

Шаги 2-п. На последовательно выполняемых шагах предложенная структура уточняется посредством разложения на модули (структуры данных и программные структуры). Это уточнение продолжается до тех пор, пока на шаге п не будут получены модули, которые могут быть сформулированы с помощью имеющихся в распоряжении разработчиков языков программирования и реализованы на имеющемся (или заранее заданном) компьютере.

Уточнение, выполняемое на каждом шаге, можно рассматривать как два параллельно выполняемых процесса:

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

Этот процесс уточнения может быть описан следующим образом.

I. Процесс состоит из дискретной последовательности шагов.

II. На шаге / в результате принятия решений 5) вводятся новые (более простые) модули (компоненты) ту е М, и соответствующие множества операторов Оу и множества операндов с1у.

Виртуальная машина /-го уровня представляется следующим образом:

УМ1 = <М/, ои ?>/>, (6.14)

где М,- = {ту | у =1,2,___, } — множество модулей уровня /, Д - количе

ство модулей уровня /; Д = {оу | у = 1, 2,..., Д-} - множество операторов модулей виртуальной машины М„ в котором каждый оператор можно представить как отображение некоторой функциональной Д и синтаксической спецификации Бу конкретного модуля ту'.

тУ .< /у, б у >—> Оу, где е и Яу е БР™, где БР™ - внутренние спецификации, определяющие 1-й уровень виртуальной машины, заметим, что на уровне / — 1 используются внешние спецификации виртуальной

машины пользователя ЗД (см. гл. 5); Д = {Д | у = 1, 2,..., Д} - множество операндов модулей Мь в котором каждый операнд можно представить как отображение некоторой синтаксической и семантической спецификации ББу данных конкретного модуля ту. ББу —> с1у где

ББу е 5Р31", БР™ - внутренние спецификации, определяющие интерфейс

соответствующей виртуальной машины.

Заметим, что любой модуль ту е М, выполняет некоторый набор операторов О у и использует некоторый набор данных Ду, для которых выполняются следующие условия.

1. Возможно, что множества операторов различных модулей пересекается (т.е. модули используют одни и те же операторы): ОуСФ&, ]Фк, при этом Д >| Оу п0 |> 1. Замечание: на первом

уровне виртуальной машины имеется один модуль, представляющий виртуальный процессор с требуемыми свойствами. Каждый следующий уровень в результате декомпозиции содержит большее число модулей, т.е. АД, > ТУ,.. Если предположить, что возможно соотношение АД, > ТУ,., то это бы значило, что модули /-го уровня идентичны модулям / + 1 уровня).

2. Возможно также, что множества операндов различных модулей пересекаются (модули используют одни и те же операнды): Д п Д. 0, / Ф к, при этом ТУ,- >| Д п Д |> 1 (справедливо замечание,

указанное в п. 1).

  • 3. (X с (9,, при этом возможно, что для некоторого модуля О,у = 0. Это означает, что модуль тч используют только операторы базового слоя.
  • 4. Д с Д при этом возможно, что для некоторого модуля Д = 0. Это означает, что модуль ту не обрабатывает данные слоя /.
  • 5. невозможно одновременное выполнение условий Д = 0

и Д = 0 для одного и того же модуля.

III. Шаги процесса уточнения зависят от определяющих декомпозицию решений 3,. На основе этих решений определяются множества операторов и операндов, реализуемых модулями следующего слоя, которые необходимы для выполнения модулей предыдущего слоя:

IV. На основе полученных результатов решения 3, формируется множество модулей слоя (виртуальной машины) А/,+1:

(6.16)

VMj+1 < А/,+,, Oi+1, Д+| >

где Л/,+1 = {т,+1 , | j = 1, 2,..., АД,} - множество модулей уровня / + 1, АД, - количество модулей уровня / + 1, при этом АД, > АД Д+, = {о,+1 . | j = 1, 2,..., АД,} - множество операторов модулей виртуальной машины АД,, в котором спецификации каждого оператора можно представить как отображение часты функциональной и синтаксической спецификации модулей виртуальной машины АД А+, = ДД, • | j - 1, 2,..., АД,} - множество операндов модулей виртуальной машины АД,, в котором спецификации каждого операнда можно представить как отображение части синтаксической и семантической спецификации модулей ту виртуальной машины А/,-.

V. Решение 3, принимается на основе некоторой стратегии. Имеются три основные стратегии разбиения при применении композиционного анализа [20]. Для разбиения модулей (подмодулей) используется одна из следующих стратегий. Разбиение STS (исток - преобразование -сток) предполагает деление модуля на функции, занимающиеся получением данных, изменением из формы (преобразованием), а затем доставкой их в некоторую точку вне модуля. Операционное разбиение состоит в делении модуля на части, каждая из которых выполняет операции отдельного типа. Функциональное разбиение - это деление задачи на функции, выполняющие преобразования данных.

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

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

Теоретически процесс уточнения является однопроходным процессом, но практически это все же не так. На каждом шаге подходящие решения выбираются из некоторого множества альтернатив. На каком-либо из последующих шагов может выясниться, что это решение неприемлемо. Поэтому в процессе работы приходится возвращаться назад и выбирать там другое решение, обеспечивающее возможность успешного продолжения. Каждый шаг в процессе уточнения соответствует некоторой ступени абстракции или одному слою системы. В результате шага 1 получается слой 1, в результате шага 2 - слой 2 и т.д. Слой 0 представляет систему в самой абстрактной (общей) форме. Все прочие слои служат для определения модулей системы. В самом нижнем слое модули уточнены настолько, что их можно выразить с помощью имеющихся языков программирования.

Как было уже сказано, каждый слой можно рассматривать как множество компонентов, выполняемых с помощью некоторой виртуальной машины. Слой i реализуется машиной ТМ, с помощью слоев j (J > i). Слой i следует рассматривать как логически полный, когда в нем можно задать выполнимый на машине А/, алгоритм Л,-, реализующий постановку задачи системы в предположении существования машины М,.

Интерфейс между слоем i - 1 и более конкретизированным слоем i находится в модулях, которые слой i предоставляет слою i — 1 и которые зафиксируются при выборе решений во время проектирования. Таким образом, задача слоя / состоит в моделировании машины, существование которой предполагалось в слое / - 1.

Очевидно, что применение этого метода дает следующее:

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

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

  • 1. Основываясь на потоке данных в системе (задаче), представить ее структуру в виде нескольких (3-10) процессов.
  • 2. Определить главный поток данных системы и главный выходной поток.
  • 3. Проследить входной поток данных по структуре системы (модуля). При этом можно обнаружить два явления: входной поток изменяет форму, становясь все абстрактнее по мере того, как идет продвижение по структуре процессов системы. В конце концов будет найдена точка, где поток как будто пропадает. Точка, где он появляется в последний раз, - точка наивысшей абстракции входного потока.
  • 4. Подобный анализ нужно выполнить для выходного потока данных, двигаясь в обратном направлении, и определить точку, где выходной поток появляется в самой абстрактной форме. Эти точки представляют особый интерес, поскольку они делят систему (модуль) на наиболее независимые части.
  • 5. Две найденные точки обычно делят систему на три части. Эти части представляются модулями с соответствующими функциями. Определенные таким образом модули становятся подчиненными по отношению к модулю, разбиение которого выполняется.
  • 6. Определяются сопряжения этих модулей на уровне качественного описания входных и выходных аргументов. Детали этих сопряжений будут определены при внешнем проектировании модулей.

Рассмотрев технологию проектирования по методу «сверху вниз», следует задаться вопросом: когда прекратить разбиение системы, т.е. сколько уровней должно быть или чему равно nt Этот момент определяется по следующему правилу: логика модулей должна стать интуитивно понятной. Это означает, что модуль, вероятно, будет содержать не более 50-100 предложений [13, 32].

 
< Пред   СОДЕРЖАНИЕ     След >