Файл: Анализ и оценка средств реализации структурных методов анализа и проектирования экономической информационной системы.pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 25.04.2023

Просмотров: 104

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
  • модуль состоит из множества операторов языка программирова­ния, записанных последовательно;
  • модуль имеет имя, по которому к нему можно ссылаться как к единому фрагменту;
  • модуль может принимать и/или передавать данные как парамет­ры в вызывающей последовательности или связывать данные через фик­сированные ячейки или общие области.

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

Фундаментальные элементы структурных карт в соответствии со стандартами IBM, ISO и ANSI.

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

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

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

Библиотека. Отличается от подсистемы тем, что определена вне проекта данной системы.

Область данных. Используется для указания модулей, со­держащих исключительно области глобальных/распределенных данных.

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

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

Условный узел используется для условного вызова модуля-потомка. Он изображается с помощью ромба, потоки – альтернативные вызовы изображаются выходящими из него. Таким образом, если из ром­ба выходят два потока, это соответствует конструкции IF-THEN-ELSE, если один поток – конструкции IF-THEN.

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


Если необходимо показать, что подчиненный модуль не вызывает­ся повторно при активации главного, это осуществляется указанием циф­ры "1" в главном модуле напротив потока – вызова наследника.

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

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

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

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

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

SADT (Structured Analysis and Design Technique) – это методология инженерии разработки ПО (software engineering) для описания систем в виде иерархии функций (функциональной структуры).

Структурный анализ возник в конце 60-х годов в ходе революции, вызванной структурным программированием. Метод SADT был предложен Дугласом Т. Россом как способ уменьшить количество дорогостоящих ошибок за счет структуризации на ранних этапах создания системы, улучшения контактов между пользователями и разработчиками и сглаживания перехода от анализа к проектированию. Дуглас Т. Росс часть своих PLEX-теорий относящихся к методологии и языку описания систем, назвал «Методология структурного анализа и проектирования» (SADT). Исходная работа над SADT началась в 1969 г.

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


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

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

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

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

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

SADT использует два типа диаграмм:

  • модели деятельности (activity models);
  • модели данных (data models).

SADT использует стрелки для построения этих диаграмм и имеет следующее графическое представление:

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

SADT использует декомпозицию на основе подхода «сверху вниз».

Каждый уровень декомпозиции содержит до 6 блоков.

SADT начинается с уровня (level) 0, затем может быть детализирован на более низкие уровни (1, 2, 3, ...). Например, на уровне 1, блок уровня 0 будет детализирован на несколько элементарных блоков и так далее.

Рисунок. 1.5. Пример уровня 0

На уровне 1 действие «Manufacture computers», может быть разбито (de- clined), например на 4 блока:

  • получить электронные компоненты («receive electronic components»);
  • сохранить электронные компоненты («store electronic components»);
  • доставить электронные компоненты на сборочную линию («bring electronic components to the assembly line»);
  • собрать компьютеры («Assemble computers»).

Семантика стрелок для действий (activities):

  • входы (Inputs) входят слева и представляют данные или предметы по- требления (consumables), нужные действию (that are needed by the activity);
  • выходы (Outputs) выходят справа и представляют данные или продукты, производимые действием (activity);
  • управления (Controls) входят сверху и представляют команды, которые влияют на исполнение действия, но не потребляются. В последней редак- ции IDEF0 – условия, требуемые для получения корректного выхода. Данные или объекты, моделируемые как управления, могут быть транс- формированы функцией, создающей выход; механизмы означают средства, компоненты или инструменты, используемые для выполнения действия; представляют размещение (allocation) действий.

Семантика стрелок для данных (data):

  • входы (Inputs) – это действия, которые генерируют эти данные (are activities that produce the data);
  • выходы (Outputs) потребляют эти данные (consume the data);
  • управления (Controls) влияют на внутреннее состояние этих данных (influence the internal state of the data). [4]

Метод SADT получил дальнейшее развитие. На его основе в 1981 году разработана известная методология функционального моделирования IDEF0.

Методология функционального моделирования IDEF0

IDEF0 (Integration Definition for Function Modeling) – методология функционального моделирования для описания функций предприятия, предлагающая язык функционального моделирования для анализа, разработки, реинжиниринга и интеграции информационных систем бизнес процессов; или анализа инженерии разработки ПО (or software engineering analysis).

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

Методология IDEF0 является развитием метода структурного анализа и проектирования SADT (Structured Analysis and Design Technique).

IDEF0 как стандарт был разработан в 1981 году в рамках программы ICAM (Integrated Computer Aided Manufacturing – интегрированная компьютер- ная поддержка производства).

IDEF0 – Integration DEFinition language 0 – основан на SADT и в своей исходной форме включает одновременно:

  • определение языка графического моделирования (синтаксис и семантику);
  • описание полной (comprehensive) методологии разработки моделей. Последняя редакция IDEF0 была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).В 1993 году IDEF0 была принята в качестве федерального стандарта в США, а в 2000 году – в качестве стандарта в Российской Федерации. [4]

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

Методология IDEF0 может быть использована для моделирования широкого спектра как автоматизированных, так и неавтоматизированных систем.

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

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

Основные цели (objectives) стандарта:

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

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

1.3. Анализ доступного программного обеспечения для наглядного представления средств структурного анализа

Dia Diagram Editor — бесплатный редактор для создания графиков различной сложности. Эта программа послужит крутой альтернативой для Microsoft Visio. Простой и понятный интерфейс, сотни фигур, поддержка баз данных и собственных фигур в XML или SVG. А ещё благодаря опенсорсному коду программа доступна на Windows, Mac и Linux. [9]