Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Учебное пособие 1438

.pdf
Скачиваний:
2
Добавлен:
30.04.2022
Размер:
1.16 Mб
Скачать

Простейшие из методов проектирования являются средствами графической иллюстрации проекта, к ним относятся:

метод функциональных схем [12, 15]; метод НІРО-диаграмм [11, 13]; диаграммы Варнье-Орра [6, 13]; ПЕРТ-диаграммы [1, 11]; сети Петри [1, 11].

На декомпозиции проекта по функциональному принципу основаны следующие методы проектирования:

нисходящее проектирование [1]; восходящее проектирование[1].

На декомпозиции проекта по данным, обрабатываемым задачей, построены следующие методы проектирования:

метод «исток-преобразование-сток» [11, 12, 15] структурные карты Джексона [6, 13].

На декомпозиции проекта по объектам предметной области задачи основан метод объектно-ориентированного проектирования [1].

На анализе контекста постановки задачи базируется метод структурного анализа и проектирование SADT [13].

4.2. Метод функциональных схем

Метод используется для проектирования небольших программных систем или отдельных программ, в которых можно выделить достаточно независимые вычислительные процессы [1, 11, 15].

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

33

В функциональных схемах применяют условные обозначения, которые, как правило, стандартизированы. Подобные обозначения используются в известных блок-схемах. Единая система программной документации (ЕСПД) регламентирует условные обозначения в схемах данных, программ, систем, ресурсов и взаимодействия процессов (ГОСТ 19.002-80, ГОСТ 19.003-80, ГОСТ 19.701-90 и т.п.). Эти же обозначения применяются в функциональных схемах.

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

4.3. Метод нисходящего проектирования

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

Задача, подлежащая решению, разбивается на подзадачи (т.е. детализируется) так, чтобы при известном решении подзадач можно было решить основную задачу. Каждая из подзадач,

34

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

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

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

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

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

35

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

4.4.Метод «исток-преобразование-сток»

Воснове метода лежит анализ внутренних потоков данных задачи и декомпозиция проекта no принципу обработки этих потоков. Метод имеет несколько различных названий: ИПС, STS, композиционный анализ [11], анализ сообщений [12]. Метод основан на предложении, что любая задача обработки данных может быть разделена на три части:

получение исходных данных (исток), изменение формы данных (преобразование), формирование выходных данных (сток).

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

Если деление задачи на исток, преобразование и сток не очевидно, то применяется методика анализа внутренних потоков данных [12, 13].

1. На основании анализа внутренних потоков данных задачи представить предварительную структуру задачи в виде 3-10 процессов.

2. Определить главный входной поток данных, поступающих в задачу, и главный выходной поток результатов задачи.

36

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

4.Выполнить аналогичный анализ выходного потока данных, начиная с конца структуры задачи и двигаясь в обратном направлении. Определить точку, где выходной поток впервые появляется в своей самой абстрактной форме, т.е. точку наивысшей абстракции выходного потока В.

5.Две найденные точки А и В делят задачу на три час-

ти:

исток, от начала до точки А; преобразование, от точки А до точки В; сток, от точки В до конца задачи.

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

4.5. Разбиение подсистемы на модули

Модуль – это фрагмент программы, строительный блок физической структуры системы [15].

Интерфейсная часть

Модуль

Реализация

Модульностьэто свойство системы. Модули должны быть внутренне связанные и слабо зависящие друг от друга.

37

По определению Г. Майэрса [16] «модульность – это свойство ПО, которое обеспечивает интеллектуальную возможность создания сколь угодно сложной программы».

Логическими выводами и практическими результатами для двух проблем P1 и P2 функция T(x) – затрат времени на решение P1 и P2 подчиняется правилу треугольника

T(P1 + P2) > T(P1) + T(P2).

Это соотношение – обоснование модульности, т.е. математическое обоснование того, что сложную задачу легче решить, разложив еѐ на несколько частей.

Всегда необходимо искать «золотую середину» – компромисс между количеством модулей и стоимостью их сопряжения. Обычно существуют негласные правила, которых придерживаются разработчики:

модуль должен быть снаружи проще, чем внут-

ри;

модуль легче использовать, чем разработать.

4.5.1.Свойства модулей

4.5.1.1.Информационная закрытость

Содержание модуля должно быть скрытым от других (автор Х. Парнас, 1972 г.) т.е. содержимое модуля должно быть недоступно тем модулям, которые не требуют этой информа-

ции [15].

Информационная закрытость означает, что:

модули независимы, обмениваются только той частью информации, которая необходима для работы;

доступ внутрь модуля к его операциям и данным ограничен.

За счѐт информационной закрытости уменьшается волновой эффект ошибки; становится возможной работа несколь-

38

ких разработчиков; облегчается тестирование, модификация программ.

4.5.1.2. Связность модуля

Связность (cohesion) характеризуется внутренней структурой модуля [1, 15]. Чем выше связанность, тем лучше измеряется связность с помощью силы связанности (СС). Различают 7 типов связанности.

1)По совпадению (СС=0), т.е. в модуле отсутствуют явно выраженные внутренние связи.

2)Логическая связность (СС=1). Части модуля объединяются по функциональному подобию. Например, модули

это разные подпункты обработки ошибок.

3)Временная связность (СС=3). Части модуля не связаны, но необходимы в один и тот же период работы ПО.

4)Процедурная связность (СС=5). Части модуля реализуют некоторый сценарий, т.е. связаны порядком действия.

5)Коммуникативная связность (СС=7). Части связанны по данным (т.е. работают с одной и той же структурой данных)

6)Информационная связность (СС=9). Выход 1-й части является входом другой.

7)Функциональная связность (СС=10). Части реализуют одну функцию.

Типы связности 1) - 3) появляются в результате неправильного проектирования; типы 4) – в результате небрежного проектирования; типы 5) – 7) – приемлемого проектирования.

Рассмотрим подробнее перечисленные типы связности модулей.

1. Связность по совпадению.

39

Части модуля обычно не имеют друг к другу никакого отношения.

Например:

Модуль Разное (<список параметров>) Позвонить в ЖЭУ (… )

Полить цветы ( …) Купить скрепки ( …)

Проверить исправность выключателя ( …) Конец Разное

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

2. Логическая связность

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

Например:

Модуль Переслать сообщение (<список параметров>) Переслать по e-mail ( …)

Переслать по факсу ( …) Переслать по FIDO ( …)

Конец Переслать сообщение В модуле перечислены доступные действия, которые

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

3. Временная связность

40

В этом случае части модуля выполняют различные действия, но привязаны к одному моменту (периоду) времени.

Например:

Модуль Разметка МП (<список параметров>) Перемотать ленту на начало Таблица текущих записей :=..

Таблица количества записей := Запросить метку ленты Записать метку ленты

Конец Разметка МП Действия модуля никак не связанны между собой, но

должны выполняться в один период времени. Модули непрозрачны, обычно линейны.

4. Процедурная связность

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

Например:

Модуль Вычислить средние значение Открыть таблицу А Открыть таблицу В Вычислить среднее по А Вычислить среднее по В

Вернуть среднее по В, среднее по А Конец Вычислить среднее значение

Если, например, А и В одной размерности, то, как это ни сократит код, нельзя объединить действия по таблице А и В в одном цикле, т.к. при изменении размера одной из таблиц, изменения в коде станут излишне трудоемкими.

5.Коммуникативная связность

Части модуля используют одни и те же данные, например, внешние данные.

Например:

41

Модуль Отчѐт и средняя зарплата Открыть таблицу зарплаты Сгенерировать отчѐт по зарплате Высчитать среднюю зарплату Вернуть отчѐт, среднюю зарплату

Конец Отчѐт и средняя зарплата С точки зрения пользователя – в модуле присутствует

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

6.Информационная связность

Части модуля образуют конвейер по обработке данных: вход одной – это выход предыдущей части.

Пример:

Модуль Приѐм и проверка записи Прочитать запись из файла Проверить контрольные данные в записи

Удалить контрольные данные в записи Вернуть обработанную запись

Конец Приѐм и проверка записи

7.Функциональная связанность

Части модуля решают только одну общую задачу. Например, вычисляются доход фирмы, адрес сотрудника, № телефона и т.д. Т.е. модуль имеет единичное назначение. Дополнительные действия не привлекаются.

4.5.1.3. Определение связности модуля

Связность модуля [15, 16] можно установить по следующему алгоритму.

1. Если модуль – единичная проблемноориентированная функция, то уровень связности - функциональный; конец алгоритма. В противном случае перейти к п.2.

42