4 как составляются структурные карты джексона
Перейти к содержимому

4 как составляются структурные карты джексона

Структурные карты Джексона

Техника структурных карт Джексона основана на методе структурного программирования Джексона, который выявляет соответствие между структурой потоков данных и структурой программы [39]. Основное внимание в методе сконцентрировано на соответствии входных и выходных потоков данных. Структуры на диаграммах Джексона строятся из четырех основных компонентов, представленных на рис. 4.9:

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

Рис. 4.9. Элементы структурных диаграмм Джексона

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

С точки зрения структурного программирования Джексона алгоритм программы будет следующим:

4 как составляются структурные карты джексона

Технология разработки программного обеспечения

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

Оборудование:

  1. Персональный компьютер
  2. ПО: Microsoft Office
ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

Проект технический – образ намеченного к созданию объекта, представленный в виде его описания, схем, чертежей, расчетов, обоснований, числовых показателей.

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

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

Технический проект программной системы подробно описывает:

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

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

При разработке технического проекта оформляются:

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

Структурная схема

Структурная схема определяется архитектурой разрабатываемого ПО.

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

Рисунок 1 — Структурная схема ПП

Функциональная схема

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

Разработка алгоритмов

Метод пошаговой детализации реализует нисходящий подход к программированию и предполагает пошаговую разработку алгоритма.

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

Любой алгоритм можно представить в виде одного предписания — в виде постановки задачи.

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

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

Достоинства метода пошаговой детализации:

  1. Сохраняется концептуальная целостность программы: от сложного к простому.
  2. Проектирование программы, кодирование, проверку и документирование можно делать параллельно.
  3. В каждый момент времени (даже в начале разработки) имеется работающий вариант программы.
  4. Фразы естественного языка, будучи закомментированными, служат хорошим путеводителем по программе.

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

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

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

Структурные карты

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

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

Описание функциональной схемы программного продукта

Функциональная схема — документ, разъясняющий процессы, протекающие в отдельных функциональных цепях изделия (установки) или изделия (установки) в целом. Функциональная схема является экспликацией (поясняющим материалом) отдельных видов процессов, протекающих в целостных функциональных блоках и цепях.

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

Пример функциональной схемы «Разработка виртуальной экскурсии», представлена на рисунке 2, отражает основные функции исследования.

Программа должна соответственно реагировать на действия пользователя. Результат должен быть ожидаемым. Действия пользователя не должно оставаться без результата.

Рисунок 2 — Функциональная схема ПП

ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ
  1. На основе технического задания из практической работы № 1 и спецификаций из работы № 2 разработать уточненные алгоритмы программ, составляющих заданный программный модуль. Использовать метод пошаговой детализации.
  2. На основе уточненных и доработанных алгоритмов разработать структурную схему программного продукта.
  3. Разработать функциональную схему программного продукта.
  4. Оформить результаты, используя MS Office или MS Visio в виде технического проекта.
  5. Сдать и защитить работу.

Содержание отчета:

  1. Тема практической работы
  2. Цель практической работы
  3. Ответы на контрольные вопросы
  4. Задание на практическую работу
  5. Структурная схема программного продукта
  6. Функциональная схема программного продукта

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

5.2. Структурные карты Джексона

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

По аналогии со структурными картами Константайна диаграмма Джексона может включать объекты следующих типов:

СТРУКТУРНЫЙблок (базовая компонента методологии) представляет частную функцию или блок кодов с одним входом и одним выходом.

ПРОЦЕДУРНЫЙблок является специальным видом структурного блока, представляющим вызов ранее определенной процедуры.

БИБЛИОТЕЧНЫЙблок аналогичен процедурному и представляет вызов библиотечного модуля.

Для взаимоувязывания блоков используются связи следующих типов:

последовательная связь, обеспечивающая последовательное выполнение слева направо;

параллельная связь, обеспечивающая одновременное выполнение блоков;

условная связь, обеспечивающая выбор одной из альтернатив;

итерационная связь, обеспечивающая выполнение блока в цикле.

Пример структурной карты Джексона приведен на рис. 5.7.

Рис 5.7. Структурная карта Джексона

5.3. Характеристики хорошей модели реализации

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

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

5.3.1. Сцепление

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

уменьшение количества соединений между двумя модулями приводит к уменьшению вероятности появления “волнового эффекта” (ошибка в одном модуле влияет на работу других модулей);

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

при сопровождении модуля отсутствие необходимости беспокоиться о внутренних деталях других модулей;

упрощение системы для понимания, насколько это возможно.

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

удаления необязательных связей;

уменьшения количества необходимых связей;

упрощением необходимых связей.

Специалистами предлагаются следующие практические рекомендации для ослабления сцепления модулей:

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

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

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

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

Создавайте гибкие связи для облегчения модификаций.

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

Два модуля А и В являются нормально сцепленными, если

В возвращает управление А,

вся информация, передаваемая между А и В, представляется значениями параметров при вызове.

Существует три типа нормального сцепления: сцепление по данным, сцепление по образцу, сцепление по управлению. На практике наиболее часто используемым типом сцепления является сцепление по данным (data coupling). Два модуля сцеплены по данным, если они взаимодействуют через передачу параметров и при этом каждый параметр является элементарным информационным объектом. В случае небольшого количества передаваемых параметров сцепление по данным обладает наилучшими характеристиками в соответствии с п.п.1-5.

Два модуля сцеплены по образцу (stamp coupling), если один посылает другому составной информационный объект, т.е. объект, имеющий внутреннюю структуру. Примером составного объекта может быть объект Данные о клиенте, включающий в себе поля: Название организации, Почтовый адрес, Номер счета и т.п.

Два модуля сцеплены по управлению (control coupling), если один посылает другому информационный объект — флаг, предназначенный для управления его внутренней логикой. Существует два типа флагов — описательный и управляющий. Описательный флаг обычно описывает ситуацию, которая произошла, и именуются с использованием существительных и прилагательных: Конец файла, Введенная кредитная карта. Управляющий флаг используется для декларирования определенных действий в вызываемом модуле и именуется с использованием глаголов: Читать следующую запись, Установить в начало. В общем случае управляющие флаги усиливают сцепление и, следовательно, ухудшают качество проекта.

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

Два модуля являются сцепленными по общей области (common coupling), если они ссылаются к одной и той же области глобальных данных. Сцепление по общей области является плохим по следующим причинам. Во-первых, ошибка в любом модуле, использующем глобальную область, может неожиданно проявить себя в любом другом модуле, также использующем эту глобальную область, поскольку эти глобальные данные не находятся “под защитой” модуля. Во-вторых, модули, ссылающиеся к глобальным данным, обычно используют точные имена (в отличие от модулей, которые вызываются с использованием параметров). Следовательно, гибкость модулей, сцепленных глобально, намного хуже, чем гибкость нормально сцепленных модулей. В-третьих, программы с большим количеством глобальных данных чрезвычайно трудны для понимания сопровождающим программистом, поскольку трудно определить, какие данные используются отдельным модулем.

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

Добавить комментарий

Ваш адрес email не будет опубликован.