Анализ и оценка средств реализации структурных методов анализа и проектирования экономической информационной системы (Теоретические аспекты структурного анализа)

Содержание:

НЕГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ ЧАСТНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

«МОСКОВСКИЙ ФИНАНСОВО-ПРОМЫШЛЕННЫЙ «УНИВЕРСИТЕТ УНИВЕРСИТЕТ»

Факультет Информационных систем и технологий

курсовая работа

по дисциплине

Методы и средства проектирования информационных систем и технологий

на тему

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

Работу выполнил студент

группы ОБИ-1705МОиб

Направление подготовки: ИСиТ

Профиль: Информационная безопасность

Добромыслов Виталий Геннадьевич

Научный руководитель:

Аверин Антон Андреевич

МОСКВА

2019 г.

СОДЕРЖАНИЕ

ВВЕДЕНИЕ………………………………………………………………………3

Глава 1. Теоретические аспекты структурного анализа…………….…...…….5

Глава 2. Основные методологии структурного анализа ………………….....11

Глава 3. Программные средства реализации структурных методов анализа и проектирования……………………………………………………….………….20

ЗАКЛЮЧЕНИЕ………………………………………………………………….30

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ…………………….…...…31

ВВЕДЕНИЕ

Теория систем впервые была применена в точных науках и технике как вклад школы науки управления. Как самостоятельная дисциплина теория систем оформилась в 40-50-х годах XX века.

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

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

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

Широкое признание теории, осознание системности мира началось в 1948 году после публикации американским математиком Н.Винером книги «Кибернетика». Первоначально он определяет кибернетику как «науку об управлении и связи в животных и машинах» (аналогии процессов в живых организмах и машинах), позже анализирует с позиций кибернетики процессы, происходящие в обществе.

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

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

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

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

Близко к ОТС расположены другие науки, занимающиеся изучением систем: кибернетика, теология, теория информации, инженерная теория связи, теория ЭВМ, системотехника, исследование операций и связанные с ними научные и инженерные направления.

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

Предмет исследования – экономическая информационная система.

Глава 1. Теоретические аспекты структурного анализа

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

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

В инженерии ПО (software engineering), Структурный анализ (Structured Analysis, SA) и одноименное с ним Структурное проектирование (Structured Design, SD) – это методы для анализа и преобразования бизнес-требований в спецификации и, в конечном счете, в компьютерные программы, конфигурации аппаратного обеспечения и связанные с ними ручные процедуры.

Структурный анализ, СА (Structured Analysis, SA) и Структурное проектирование, СП (Structured Design, SD) являются фундаментальными инструментами системного анализа и развивались из классического системного анализа 1960-70-х годов. [2, c.182]

Структурный подход заключается в поэтапной декомпозиции системы при сохранении целостного о ней представления Основные принципы структурного подхода (первые два являются основными):

1) принцип «разделяй и властвуй» – принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;

2) принцип иерархического упорядочивания – принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

3) принцип абстрагирования – заключается в выделении существенных аспектов системы и отвлечения от несущественных;

4) принцип формализации – заключается в необходимости строгого методического подхода к решению проблемы;

5) принцип непротиворечивости – заключается в обоснованности и согласованности элементов.

История структурного анализа и проектирования

Структурный анализ – это часть серии структурных методов, представляющих набор методологий анализа, проектирования и программирования, которые были разработанны в ответ на проблемы, с которыми столкнулся мир ПО в период с 1960 по 1980 гг.

В этот период большинство программ было создано на Cobol и Fortran, потом на C и BASIC. Это было новым положительным сдвигом в направлении проектирования и программирования, но при этом не было стандартных методологий для документирования требований и самих проектов.

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

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

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

1) анализ – определение того, что система будет делать;

2) проектирование – определение подсистем и их взаимодействие;

3) реализация – разработка подсистем по отдельности;

4) объединение – соединение подсистем в единое целое;

5) тестирование – проверка работы системы;

6) установка – введение системы в действие;

7) функционирование – использование системы.

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

И, тем не менее, с этой моделью создания системы, ориентированной на управление, постоянно возникали сложности. Эксплуатационные расходы, возникавшие после сдачи системы, стали существенно превышать расходы на ее создание и продолжали расти с огромной скоростью из-за низкого качества исходно созданной системы. [7, c.151]

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

Например, исправление ошибки на стадии проектирования стоит в 2 раза, на стадии тестирования – в 10 раз, а на стадии эксплуатации системы – в 100 раз дороже, чем на стадии анализа.

На обнаружение ошибок, допущенных на этапе анализа и проектирования, расходуется примерно в 2 раза больше времени, а на их исправление – примерно в 5 раз, чем на ошибки, допущенные на более поздних стадиях.

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

1) не было единого подхода;

2) привлечение пользователя к процессу разработки не контролировалось;

3) проверка на согласованность проводилась нерегулярно или вообще отсутствовала, результаты одного этапа не согласовывались с результатами других;

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

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

Кроме того, ошибки в создании систем становились все менее доступны выявлению с помощью аппаратных средств или программного обеспечения, а наиболее катастрофические ошибки допускались на ранних этапах создания системы. [2, c.187]

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

Эту предпосылку нужно было принять как неизбежную. Но ошибочное определение системы не является неизбежным: оно – результат неадекватности методов создания систем.

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

Для помощи в управлении большим и сложным ПО с конца 1960 годов появляется множество разнообразных структурных методов программирования, проектирования и анализа. Эти методы на начальных этапах создания системы позволяют гораздо лучше понять рассматриваемую проблему. А это сокращает затраты как на создание, так и на эксплуатацию системы, а кроме того, повышает ее надежность.

В 1960-70 появляются следующие концепции:

• примерно 1967 – Структурное программирование (Structured programming) – Edsger Dijkstra,

• примерно 1975 – Структурное программирование Джексона (Jackson Structured Programming) – Michael A. Jackson. Структурное программирование приводит к Структурному проектированию, что в свою очередь приводит к Структурному системному анализу:

• примерно 1975 – появление на рынке Метода структурного анализа и проектирования SADT (Structured Analysis and Design Technique) – Douglas T. Ross;

• примерно 1975 – Структурное проектирование (Structured Design) – Larry Constantine, Ed. Yourdon и Wayne Stevens;

• примерно 1978 – Структурный анализ (Structured Analysis) – Tom DeMarco, Yourdon, Gane & Sarson, McMenamin & Palmer;

• в 1979 опубликован Структурный анализ и системная спецификация (Structured Analysis and System Specification) – Tom DeMarco. В течение 1980х начинают появляться инструменты для автоматизации черчения диаграмм:

• 1981 – опубликована (и в 85-93 получает развитие) Методология IDEF0, основанная на SADT и инструментальных средствах создания диаграмм (разработана Дугласом Т. Россом, Douglas T. Ross).

• в 1983 впервые представлен Метод структурного системного анализа и проектирования SSADM (Structured Systems Analysis and Design Method), разработанный в UK Office of Government Commerce.

По аналогии с Computer-Aided design and Computer-Aided Manufacturing (CAD/CAM), использование этих инструментов было названо Computer-Aided Software Engineering (CASE). Методы СА и СП (в частности, SSADM) сопровождаются нотациями (диаграммами), облегчающими взаимодействие между пользователями и разработчиками. [3, c.19]

Это были:

• структурные схемы (Structure Charts) – для структурного проектирования;

• диаграммы потоков данных (Data Flow Diagrams, DFD) – для структурного анализа;

• модели данных (Data Model Diagrams). Эти диаграммы использовались структурными методами в различных комбинациях. Среди них встречалось множество вариаций. Примерно в 1990 появляется термин «инженерия разработки ПО» (Information Engineering, IE, James Martin), являющаяся логическим расширением структурных методов, появившихся в течение 1970х.

Глава 2. Основные методологии структурного анализа

SADT (аббревиатура выражения Structured Analysis and Design Technique - методология структурного анализа и проектирования) - это методология, разработанная специально для того, чтобы облегчить описание и понимание искусственных систем, попадающих в разряд средней сложности. SADT была создана и опробована на практике в период с 1969 по 1973 г.

Затем эта методология была принята в качестве стандарта в ВВС США и получила название IDEF0. Настоящее время IDEF0 получил статус международного стандарта.

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

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

- Функциональный

- Объектный.

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

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

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

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

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

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

Принципы SADT-моделирования

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

Принцип первый – принцип «черного ящика»

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

По этой причине в методологии SADT подчеркивается необходимость точного определения границ системы. SADT-модель всегда ограничивает свой объект, то есть, модель устанавливает точно, что является и что не является объектом моделирования, описывая то, что входит в систему, и подразумевая то, что лежит за ее пределами. Отделенная от окружающей среды система с указанием связей с этой средой называется контекстом системы. Контекст системы изображается в виде «черного ящика», имеющего входы и выходы, которые отображают взаимодействие системы с окружающей средой (рис.4.1). Каждая из показанных на рисунке стрелок имеет свое название и назначение.

1. Стрелки слева Вход (Input) отображают необходимые для исполнения процесса входы.

1. Стрелки справа Выход(Output) отображают результаты исполнения процесса (выходы).

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

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

Принцип второй – принцип неизменности точки зрения

Ответы на поставленные вопросы будут зависеть от того, чья точка зрения отражается при создании модели. Например, мы получим разные модели предприятия при отражении точки зрения генерального директора, главного инженера или начальника отдела кадров. Поскольку качество описания системы резко снижается, если оно делается с различных позиций, SADT требует, чтобы модель рассматривалась все время с одной и той же позиции.У модели может быть только одна точка зрения, иона не должна меняться при декомпозиции.

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

Принцип третий «функции – объекты»

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

Объекты изображаются дугами (стрелками) и именуются существительными: «деталь», «студент», «станок», «паспорт» и т.д.

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

Принцип четвертый – принцип декомпозиции диаграмм

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

Принцип пятый –принцип сохранения дуг

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

Принцип шестой – принцип декомпозиции дуг

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

Принцип седьмой – принцип единства оформления диаграмм

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

Нотация DFD (диаграммы потоков данных)

DFD — общепринятое сокращение от англ. data flow diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML.

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

Исторически синтаксис этой нотации применяется в двух вариантах — Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson).

Непосредственно DFD нотация состоит из следующих элементов:

• Процесс (англ. Process), т.е. функция или последовательность действий, которые нужно предпринять, чтобы данные были обработаны. Это может быть создание заказа, регистрация клиента и т.д. В названиях процессов принято использовать глаголы, т.е. «Создать клиента» (а не «создание клиента») или «обработать заказ» (а не «проведение заказа»). Здесь нет строгой системы требований, как, например, в IDEF0 или BPMN, где нотации имеют жестко определенный синтаксис, так как они могут быть исполняемыми. Но все же определенных правил стоит придерживаться, чтобы не вносить путаницу при чтении DFD другими людьми.
• Внешние сущности (англ. External Entity). Это любые объекты, которые не входят в саму систему, но являются для нее источником информации либо получателями какой-либо информации из системы после обработки данных. Это может быть человек, внешняя система, какие-либо носители информации и хранилища данных.
• Хранилище данных (англ. Data store). Внутреннее хранилище данных для процессов в системе. Поступившие данные перед обработкой и результат после обработки, а также промежуточные значения должны где-то храниться. Это и есть базы данных, таблицы или любой другой вариант организации и хранения данных. Здесь будут храниться данные о клиентах, заявки клиентов, расходные накладные и любые другие данные, которые поступили в систему или являются результатом обработки процессов.
• Поток данных (англ. Data flow). В нотации отображается в виде стрелок, которые показывают, какая информация входит, а какая исходит из того или иного блока на диаграмме.

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

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

Т.е. в этой нотации описывается не столько непосредственно процесс, сколько движение потоков данных.

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

Джексон структурированное развитие ( JSD ) является линейной методологией разработки программного обеспечения , разработанная Майкл А. Джексоном и Джон Камерон в 1980 - х годах.

JSD был впервые представлен Майклом А. Джексоном в 1982 году, в статье под названием «Система Метод разработки».

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

Первый метод Джексона, Джексон Структурное программирование (JSP), используется для получения конечного кода. Выход из ранних стадий JSD представляет собой набор дизайнерских программ задач, разработка которых является предметом JSP.

Три основных принципа работы JSD:

• Развитие должно начинаться с описания и моделирования реального мира, а не указывать или структурирования функции, выполняемой системой. Система с использованием метода JSD выполняет имитацию реального мира.
• Главная цель состоит в том, чтобы отобразить прогресс в реальном мире
• Способ реализации системы основан на преобразовании спецификации в эффективное множество процессов. Эти процессы должны быть разработаны таким образом, чтобы можно было бы запускать их на доступных программных и аппаратных средствах.

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

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

Глава 3. Программные средства реализации структурных методов анализа и проектирования

Erwin Data Modeler (ранее название было стилизовано ERwin)— является компьютерным программным обеспечением для моделирования данных. Первоначально разработанный Logic Works, erwin с тех пор был приобретен рядом компаний, прежде чем был куплен частной инвестиционной компанией Parallax Capital Partners, которая зарегистрировала erwin, Inc. как отдельную фирму.

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

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

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

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

ERwin был создан Logic Works в Принстоне, Нью-Джерси. В мае 1993 года Logic Works выпустила ERwin / ERX, версию инструмента, предназначенную для работы совместно с PowerBuilder. Модели баз данных, созданные с использованием ERwin, могут быть переведены в программное обеспечение, встроенное в интегрированную среду разработки PowerBuilder (IDE).

В мае 1995 года Logic Works ERwin был расширен, чтобы включить несколько других IDE, добавив SQLWindows от Gupta Technologies и Visual Basic от Microsoft. С 1996 года ERwin был одним из нескольких программных решений для моделирования данных, используемых для облегчения широкого перехода к модели клиент-сервер в управлении базой данных.

В 1998 году Logic Works была приобретена Platinum Technology, которая была позже приобретена в мае 1999 года Computer Associates (CA). ERwin изначально был частью набора Jasmine CA, но позже был добавлен в новый пакет AllFusion под названием AllFusion ERwin Data Modeler. Инструмент позже был переименован в CA ERwin Data Modeler.

В 2014 году Embarcadero Technologies стремилась приобрести продукт от CA, Inc. Это приобретение было заблокировано Департаментом юстиции по антиконкурентным проблемам.

В апреле 2016 года Parallax Capital Partners, частная инвестиционная компания, приобрела программное обеспечение от CA Technologies и назначила Адама Фамуларо генеральным директором. В настоящее время компания работает под новым названием erwin, Inc. В сентябре 2016 года erwin объявила, что приобрела Corso- британского поставщика услуг по корпоративной архитектуре. В декабре того же года erwin приобрел программное обеспечение для моделирования бизнес-процессов Casewise для того чтобы встроить его в свою программу.

По своей сути, erwin представляет собой средство автоматизации разработки программного обеспечения (англ. – CASE). Пользователи могут использовать Data Modeler для создания логических моделей данных из концептуальных, и при этом реализация не будет зависеть от конкретной технологии баз данных.

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

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

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

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

Рис. 1 Пример построения логической модели 0 уровня

Функционал

• Редактор метаданных: позволяет редактировать различные наборы объектов в рамках единого интерфейса вида электронной таблицы, позволяющего вносить массовые изменения, экспортировать в Excel, выполнять запросы к метаданным.
• Полное сравнение: автоматизирует полную двунаправленную синхронизацию моделей, скриптов и баз данных, сравнивая каждый из элементов, отображая все различия, и позволяет выполнить двунаправленное выборочное обновление.
• Создание структуры базы данных: erwin позволяет создать структуру базы данных непосредственно из визуальных моделей, увеличивая эффективность и снижая ошибки. Лидирующая в отрасли поддержка различных баз данных включает оптимизированные шаблоны триггеров целостности ссылок и богатый универсальный макроязык, позволяющий разработчикам настраивать триггеры, скрипты и хранимые процедуры.
• Настраиваемые шаблоны облегчают полную физическую реализацию модели и определений.
• Реверсивное проектирование баз данных: недокументированная информация, содержащаяся внутри скриптов SQL или базах данных, может быть визуализирована или повторно использована для создания новых моделей данных и/или объектов базы данных.
• Стандарты проектирования для многократного использования: Расширенный набор объектов моделирования для многократного использования позволяет вам создавать, поддерживать, применять и использовать отображение трансформаций имен, отображение типов данных, шаблоны создания схем, определения доменов и множество других стандартов моделирования для увеличения возможности многократного использования внутри вашей организации.
• Отчеты и печать: Каждая копия erwin Data Modeler включает копию SAP Business Objects Crystal Reports. Отчеты могут быть сгенерированы в различных форматах, включая HTML, PDF, RTF и TXT.
• Интеграция и обмен метаданных с другими инструментами: можно объединить erwin с другими проектами и инструментами, благодаря средствам импорта и экспорта для разнообразных источников, включая BI tools, MDM hubs, другие средства моделирования данных, Extract, Transform, инструменты Load (ETL) и инструменты Unified Modeling Language (UML).
• Возможность визуализировать сложные структуры данных, используя графическую модель данных, - эффективный способ к пониманию, как требований организации, так и базы данных, которая поддерживает их.

Поддержка СУБД

erwin Data Modeler поддерживает следующие базы данных:

• DB2, в том числе DB2 для i5/OS (System I)
• IDS (Informix)
• MySQL
• ODBC
• Oracle
• Progress
• SQL Server
• Sybase
• Sybase IQ
• Teradata

ОптимаСофт: ПРИМА — разработка российского производителя «ОптимаСофт». Программа позиционируется как среда моделирования бизнес-процессов организации. По заявлениям разработчиков, в ближайших версиях планируется реализовать полноценную BPMS с поддержкой исполнения процессов, смоделированных в нотациях work flow, поддержку KPI, стратегические карты с целями и показателями BSC.

Учитывая, что рабочей платформой ОптимаСофт: ПРИМА является 1С, то при интеграции в КИС организации на 1С получается единое информационное пространство организации, где в одной базе и моделируются процессы и исполняются и хранятся все данные для сравнения план-факта KPI.

Отличительными особенностями являются использование собственного графического движка и платформы 1С. Эти особенности можно рассматривать как с отрицательной стороны, так и с положительной.

Отрицательными сторонами могут являться, например:

1. Возможность запустить программу только на компьютере, где установлена платформа 1С.
2. Пользователь должен обладать минимальными навыками работы в 1С.
3. У потенциального покупателя может быть сложившееся мнение — «Это же бухгалтерская программа и не больше!».

Как положительные стороны, могут быть, например:

1. 1С работает на абсолютном большинстве организаций, значит пользователи уже знакомы и обслуживающий персонал имеется.
2. Возможность объединения ОптимаСофт:ПРИМА с корпоративной базой данных для получения ОДНОЙ программы,
   в которой можно сразу и смоделировать процесс и запустить его на выполнение, из которой пользователи будут получать задачи.
3. Нет необходимости приобретать дополнительное ПО типа VISIO, WORD, EXCEL и прочих для получения отчетов.

Интерфейс ОптимаСофт:ПРИМА имеет одно стандартное окно Навигатора бизнес-процессов на котором располагается Дерево элементов модели и поле диаграммы.

Рис. 2 Интерфейс ОптимаСофт:ПРИМА 

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

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

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

Скорость работы ОптимаСофт:ПРИМА вполне высокая на диаграммах с небольшим количеством элементов, например IDEF0 или блок-схемы. При работе с большим количеством элементов начинает ощущаться задумчивость программы на некоторых действиях..

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

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

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

Создание элементов на схеме реализовано через перетаскивание из Дерева процессов. При этом один элемент может создаваться на разных диаграммах в виде разного графического элемента.

Например, бумажный документ на IDEF0 создается в виде стрелки, на EPC создается в виде графического элемента «Документ».

Рис. 3 Документ ОптимаСофт:ПРИМА 

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

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

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

Отчеты можно сохранять в pdf, html и xls.

Коллективная работа в ОптимаСофт:ПРИМА пока не реализована. Хоть это и редкая ситуация, но возможно редактирование одной модели несколькими бизнес-аналитиками одновременно. Пока вся ответственность за непротиворечивость лежит на пользователе.

Настройка ОптимаСофт:ПРИМА.

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

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

Есть возможность строить оргструктуры, декомпозируемую модель бизнес-процессов из нотаций IDEF0 и EPC, есть поддержка UML (use case), есть возможность автоматической генерации отчетов (регламентов). Моделей можно строить несколько (например как есть и как будет) с использованием общего репозитория элементов группы «Объекты деятельности».

По сути, стандартный набор функционала для подобных программ.

ЗАКЛЮЧЕНИЕ

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

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

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

При этом исправление ошибки на стадии проектирования стоит в 2 раза, на стадии тестирования – в 10 раз, а на стадии эксплуатации системы – в 100 раз дороже, чем на стадии анализа.

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Балдин, К.В. Информационные системы в экономике: учебное пособие/ Балдин К.В., Уткин В.Б. - М.: Дашков и К, 2012.

2. Буч Г., Якобсон А., Рамбо Дж. UML. Классика CS. 3-е изд./ Пер. с англ.; Под общей редакцией проф. С. Орлова – СПб.: Питер, 2016.

3. Боггс У., Боггс М.. UML и Rational Rose: Пер. с англ. - М.: Издательство «Лори», 2000. - 581 с.

4. Дубаков А.А. Проектирование информационных систем: Учебное пособие. Томск.: Изд. ТПУ, 2011.

5. Иванова Г. С. Технология программирования: Учебник для вузов / Г. С. Иванова. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. - 320 с.

6. Леоненков А. В. Объектно-ориентированный анализ и проектирование с использованием UML и IBM RATIONAL ROSE: учебное пособие/ А.В. Леоненков. 2006г

7. Орлов, С.А. Технологии разработки программного обеспечения: учеб. / С.А. Орлов. – СПб. : Питер, 2014. – 464 с.

8. Проектирование информационных систем: учеб. пособие / П. В. Минеев ; Сиб. федер. ун-т, ХТИ - филиал СФУ. - Абакан : РИСектор ХТИ - филиала СФУ, 2012

9. Петров, В.И. Информационные системы / В.Н. Петров. – СПб. : Питер, 2013. – 688 с.

10. Терра-Лексикон: Иллюстрированный энциклопедический словарь. – М.: ТЕРРА, 2015. - 672 с.

11. Элиенс, А. Принципы объектно-ориентированной разработки программ / А. Элиенс. – М.: Издательский дом «Вильямс», 2014. – 496 с.

12. Якобсон, А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. - СПб.: Питер, 2014. - 496 с.