Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

Введение

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

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

Создание АИС способствует повышению эффективности производства экономического объекта и обеспечивает качество управления.

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

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

Объект курсовой работы – структурный подход к проектированию информационных систем.

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

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

В ходе выполнения курсовой работы следует решить следующие задачи:

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

Глава 1. Структурный подход к проектированию информационных систем

1.1 Основные понятия проектирования информационных систем

Проектированием информационных систем называется многоступенчатый процесс их создания и/или модернизации путём применения упорядоченной совокупности методологий и инструментария. Проектирование (в отличие от моделирования) предполагает работу с пока несуществующим объектом и направлено на создание информационной системы в области:

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

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

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

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

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

Организацию проектирования ИС принято разделять на 2 типа:

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

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

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

Предпроектная стадия. Производится предпроектный анализ и составляется техническое задание. То есть, формируются требования к ИС, разрабатывается её концепция, составляется технико-экономическое обоснование и пишется ТЗ.
Проектная стадия предусматривает составление эскизного и технического проектов, разработку рабочей документации.
Послепроектная стадия даёт старт мероприятиям по внедрению ИС, обучению персонала, анализу результатов испытания. Частью этой стадии становится сопровождение ИС и устранение выявленных недостатков.

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

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

Декомпозиция может иметь несколько уровней, что позволяет выделить классы ТПР:

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

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

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

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

SADT. Методология функционального моделирования работ, которая основана на структурном анализе и графическом представлении организации как системы функций. Тут выделяется функциональная, информационная и динамическая модели. В настоящее время методология известна как нотация (стандарт) IDEF0. Анализируемый процесс графически представляется в виде четырёхугольника, где сверху изображаются регламентирующие и управляющие воздействия, снизу – объекты управления, слева – входные данные, а справа – выходные.
RAD. Методология быстрой разработки приложений. В RAD быстрая разработка приложений возможна за счёт применения компонентно-ориентированного конструирования. Методология применяется на проектах с ограниченным бюджетом, нечёткими требованиями к ИС, при сжатых сроках реализации. К ней прибегают, если пользовательский интерфейс можно продемонстрировать в прототипе, а проект разделить на функциональные элементы.
RUP. В методологии RUP реализуются итерационный и наращиваемый (инкрементный) подходы. Построение системы происходит на базе архитектуры информационной системы, а планирование и проектное управление – на базе функциональных требований к ИС. Разработка общей информационной системы происходит итерациями, как комплекс отдельных небольших проектов со своими планами и задачами. Для итерационного цикла характерна периодическая обратная связь и адаптация к ядру ИС.

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

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

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

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

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

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

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

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

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

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

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

SADT (Structured Analysis and Design Technique) - модели и соответствующие функциональные диаграммы;
DFD (Data Flow Diagrams) - диаграммы потоков данных;
ERD (Entity-Relationship Diagrams) - диаграммы «сущность-связь».

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

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

Методология SADT (Structured Analisys and Design Technique - технология структурного анализа и проектирования) разработана Дугласом Т. Россом в 1969-1973 годах. Технология изначально создавалась для проектирования систем более общего назначения по сравнению с другими структурными методами, выросшими из проектирования программного обеспечения. SADT - одна из самых известных и широко используемых методик проектирования. Новое название методики, принятое в качестве стандарта - IDEF0 (Icam DEFinition) - часть программы ICAM (Integrated Computer-Aided Manufacturing - интегрированная компьютеризация производства), проводимой по инициативе ВВС США.

IDEF0 — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является ее акцент на соподчиненность объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (поток работ).

Стандарт IDEF0 был разработан в 1981 году в США департаментом Военно-воздушных сил для автоматизации промышленных предприятий. В процессе разработки программного обеспечения разработчики столкнулись с необходимостью разработки новых методов анализа бизнес-процессов. В результате появилась методология функционального моделирования IDEF0, в которой для анализа применяются специальные нотации IDEF0.

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

Стрелки могут быть:

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

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

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

IDEF0 – это очень простой и одновременно наглядный язык описания бизнес-процессов. С помощью этого стандарта возможна передача информации между разработчиками, консультантами и пользователями. Стандарт очень тщательно разрабатывался, он удобен для проектирования, универсален. Для работы с ним существует множество инструментов, например, VISIO, BPWIN, ERWIN, Bussines studio и т.д.

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

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

Базовые требования стандарта IDEF0:

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

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

Выгоды использования IDEF0

Самая первая выгода очевидна – это наглядность. Проектировщик сам начинает понимать, как работает та или иная система, и может также наглядно пояснить, где в этой системе «тонкие места» и какие решения помогут избавиться от них.
Взаимопонимание и отсутствие разночтений. При обсуждении работы компании с использованием функциональной модели имеются наглядные и понятные интуитивно блоки задач с управляющими элементами. Кроме того, функциональное моделирование предполагает создание в случае необходимости глоссария, в котором раскрываются условные обозначения и термины.
Простота и высокая скорость создания модели. Конечно, научиться моделированию не так просто, как кажется. Ведь схема — это, по сути, сверхплотная подача информации, что очень хорошо для понимания, но для реализации такой подачи требуется особый подход. Мозг аналитика выступает в данном случае как очень мощный пресс с одной стороны, и фильтр – с другой. Но с опытом этот процесс становится очень быстрым. В результате аналитик получает инструмент, который поможет и самому разобраться, что же происходит в той или иной системе, и при помощи созданного в сжатые сроки наглядного пособия проиллюстрировать важные моменты коллегам или заказчикам.
Дисциплина и отсутствие ошибок. Стандарт IDEF0 предполагает строгие рамки и правила. Такой подход дисциплинирует, а привычка действовать в рамках стандарта помогает избежать ошибок по невнимательности. Любые нарушения стандарта становятся сразу заметны.

2.2 Метод моделирования процессов IDЕF3

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

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

В общем случае, процесс – это упорядоченная последовательность действий. Следовательно, процессная модель IDEF3 позволяет:

Отразить последовательность процессов;
Показать логику взаимодействия элементов системы.

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

Основными элементами IDEF3-модели являются:

1) единицы работ;

2) связи;

3) перекрестки;

4) объекты ссылок.

Единица работ (UOW, Unit of Work) является центральным компонентом модели. Связи показывают взаимоотношения работ. Связи однонаправлены и могут быть направлены куда угодно. Обычно диаграммы рисуют таким образом, чтобы связи были направлены слева направо Различают 3 типа связей:

Старшая стрелка;
Стрелка отношений;
Поток объектов.

Связь типа «временное предшествование» - Precedence. Соединяет единицы работ Показывает, что работа-источник должна быть закончена прежде, чем начнется работа-цель

Связь типа нечеткое отношение – Relational. Изображается в виде пунктирной линии, используется для изображения связи между единицами работ, а также между единицами работ и объектами ссылок

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

Перекрестки (соединения) используются для отображения логики взаимодействия стрелок при их слиянии или разветвлении, для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния и разветвления стрелок. Перекрестки не могут быть одновременно использованы для слияния и разветвления стрелок. Все перекрестки на диаграммах нумеруются, каждый номер имеет префикс J. В отличие от других методологий (IDEF0, DFD) стрелки могут сливаться или разветвляться только через перекрестки.

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

2.3 Моделирование потоков данных DFD

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

Диаграмма потоков данных (data flow diagram, DFD) – один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Непосредственно DFD нотация состоит из следующих элементов:

1. Процесс (англ. Process), т.е. функция или последовательность действий, которые нужно предпринять. чтобы данные были обработаны. Это может быть создание заказа, регистрация клиента и т.д. В названиях процессов принято использовать глаголы, т.е. «Создать клиента» (а не «создание клиента») или «обработать заказ» (а не «проведение заказа»). Здесь нет строгой системы требований, как, например, в IDEF0 или BPMN, где нотации имеют жестко определенный синтаксис, так как они могут быть исполняемыми. Но все же определенных правил стоит придерживаться, чтобы не вносить путаницу при чтении DFD другими людьми.

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

3. Хранилище данных (англ. Data store). Внутреннее хранилище данных для процессов в системе. Поступившие данные перед обработкой и результат после обработки, а также промежуточные значения должны где-то храниться. Это и есть базы данных, таблицы или любой другой вариант организации и хранения данных. Здесь будут храниться данные о клиентах, заявки клиентов, расходные накладные и любые другие данные, которые поступили в систему или являются результатом обработки процессов.

4. Поток данных (англ. Data flow). В нотации отображается в виде стрелок, которые показывают, какая информация входит, а какая исходит из того или иного блока на диаграмме.

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

Какие правила необходимо знать, чтобы создать DFD диаграмму:

Каждый процесс должен иметь хотя бы один вход и один выход. Смысл процессов здесь заключается в обработке именно данных, а потому процесс должен получить данные (входящая стрелка) и отдать куда-то после обработки (исходящая стрелка);
Процесс обработки данных должен иметь внешнюю входящую стрелку (данные от внешней сущности). Для того, чтобы любой подобный процесс начал работать, мало использовать данные из хранилища, должна поступить новая информация для последующей обработки;
Стрелки не могут связывать напрямую хранилища данных, все связи идут через процессы. Нет смысла просто перемещать данные из одного места в другое, а именно так читается прямая связь двух хранилищ стрелкой. Данные поступают для того, чтобы производились какие-то действия, в нашем примере - осуществлялся процесс продажи. А это возможно только посредством обработки (процесса);
Все процессы должны быть связаны либо с другими процессами, либо с другими хранилищами данных. Процессы не существуют сами по себе, а потому результат должен куда-то передаваться;
Декомпозиция. В DFD-диаграммах предусмотрена возможность создавать крупные процессы и декомпозировать их на подпроцессы с подробным описанием действий. Например, мы можем создать процесс «создание заявки», который потом декомпозировать на последовательность действий, например, на получение заявки, отдельно – проверку и получение данных клиента, если товар в интернет-магазине продается под заказ, то также при формировании заявки потребуется получить данные от поставщика о наличии нужных наименований и т.д. И тогда на верхней диаграмме у нас будет блок «обработка заявки», а при декомпозировании мы получим диаграмму с подробной последовательностью действий на этом этапе.

DFD-диаграммы активно применяются при разработке программного обеспечения. При этом:

- хранилища данных - это электронные таблицы и базы данных,

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

- процессы - это выполняемые функции и модули в системе.

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

2.4 Диаграммы переходов состояний (SDT)

STD - State Transition Diagrams - диаграммы переходов состояний - методология моделирования последующего функционирования системы на основе ее предыдущего и текущего функционирования.

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

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

STD состоит из следующих объектов:

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

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

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

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

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

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

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

1) Программный пакет Design/IDEF (Meta Software Corp.) – графическая среда, позволяющая осуществлять проектирование и моделирование систем различного уровня сложности и назначения. Программный пакет поддерживает несколько методология, а именно:

методологии по описанию и моделированию системных функций (IDEF0/SADT)
методологии описания структуры системы и потоков данных внутри системы (IDEF1, IDEF1X,E-R)
методологии описания поведения проектируемой системы(IDEF/CPN).

С помощью пакета Design/IDEF был были созданы проекты систем высокого уровня сложности. Анные системы автоматизировали производство, управление контролем, компьютезировали телекоммуникации и аэрокосмонавтику. Данный программный пакет использован в качестве составной части в таких известных пакетах как «САЕ» и «CIM». Он принят за стандарт для выполнения проектов, финансирование которых производится американскими и европейскими разработчиками.

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

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

Возможности пакета программ Design/IDEF:

Возможность представления графики. Пакет Design/IDEF позволяет быстро и качественно представить проектируемую информационную систему в графическом виде, включая создание различных объектов – как стандартных, так и пользовательских, манипуляции с этими объектами, указание атрибутов и надписей. Дополнительно имеются возможности для осуществления редактирования данных, построения различного типа линий, а также осуществление маршрутизации и связывания дуг.
Обеспечение поддержки проверки непротиворечивости модели. В пакет Design/IDEF включены специальные возможности, позволяющие осуществить проверку разрабатываемой модели на точность, целостность и непротиворечивость. Причем данная проверка может проводится на любом этапе создании информационной системы, и не один раз. Так при изменении текста, описывающего дугу или функциональный блок в одной части модели, то и в случае нахождения этого блока или дуги на других страницах модели, соответствующий текст будет изменен автоматически.
Наличие словаря данных. Пакет Design/IDEF имеет поддержку встроенного словаря, позволяющего хранить информации, производить оздание отчетов о функциях и потоках данных. Так же он позволяет определить начальную информацию о каждом объекте. С помощью словаря возникает возможность востановления и сохранения целостности файлов данных. Все возможности использования словаря данных имеют большую гибкость и позволяют для каждого параметра указывать неограниченное количество параметров.
Возможность генерации отчетов. Пакет Design/IDEF позволяет генерировать пять видов отчетов: отчет по контролю за полнотой модели, отчет по функциям, отчетом по дугам, отчет по ссылкам, IDEF-отчет. Отчеты можно как отобразить на экране компьютера, так и вывести на принтер. Также отчеты могут быть экспортированы для использования данных в других программных пакетах.
Возможность коллективной работы. Пакет Design/IDEF позволяет работать группе разработчиков работать одновременно над одной IDEF-моделью. Причем все подмодели легко объединяются в одну модель.

Пакет Design/IDEF имеет поддержку все первые стадии создания информационной системы:

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

2) Программный пакет Power Designer функционально разбит на несколько модулей:

Process Analyst – модуль для функционального моделирования, имеют поддержку нотаций Йордона-де Марко, Гейна-Сарсона и некоторых других. Существует возможность описания элементов данных, связанных с потоками данных, а также с хранилищами данных. Все элементы впоследствии передаются на следующий этап проектирования, при этом имеется возможность автоматического преобразования хранилища данных в сущности.
Data Analyst – модуль, служащий для построения моделей «сущность-связь». Также существует возможность автоматически генерировать на основе модели «сущность-связь» реляционной структуры. Причем исходные данные для модели «сущность-связь» можно получить из DFD-моделей, созданных ранее. Существует поддержка синтаксиса языка SQL приблизительно для 30 реляционных СУБД, при этом существует возможность генерации структуры базы данных. Для этого создается сценарий языка SQL (набор команд CREATE для создания таблиц и связей между ними), после выполнения которого создаст спроектированную структуру базы данных. Также можно задать параметры соединения с СУБД (как правило используя интерфейс ODBC) и получить готовую базу данных автоматически. Имеются возможности автоматической проверки правильности моделей, расчета размера проектируемой базы данных, построения диаграмм и т.д.
Application Modeler – модуль, позволяющий автоматически генерировать прототипы программ для обработки данных, основываясь на моделях, построенных в модуле Data Analyst. Результатом работы модуля является программный код для языков Visual Basic и Delphi, либо для систем разработки PowerBuilder, Uniface, Progress и др. Программный код генерируется на основе шаблонов, поэтому управление процессом генерации может осуществляться только путем соответствующего шаблона.

На российском сервере компании Sybase находится ознакомительная демо-версия пакета Power Designer. Ограничение её функционала лишь в заблокированной возможности сохранения построенных моделей.

3) Silverrun. В основе CASE-системы Silverrun заложена собственно разработанная компанией Silverrun Technologies Ltd методология Datarum, которая специализированно направлена на создание информационных систем и полноценно описывающая все этапы жизненного цикла – начиная стадией первоначальной оценки затрат заканчивая получением реального приложения. Этапы построения информационной системы по данной методологии:

создание бизнес-модели по предметной области;
проектирование и создание архитектуры информационной системы;
проектирование и создание подсистем;
внедрение подсистем в единую систему.

CASE-система Silverrun включает в себя следующие инструменты:

BPM – служит для построения DFD-диаграмм. Поддерживаются нотации Йордона-де Марко, Гейна-Сарсона, Уорда-Меллора и многие другие. Основные функции – автоматическая проверка целостности построенной модели, при этом список критериев для проверки задается пользователем.
ERX – используется для построения диаграмм «сущность-связь». Здесь поддерживаются не только бинарные связи, но и более высокий порядок связей, существует возможность задания атрибутов у связей. Полученные в результате ER-модели можно сконвертировать, используя входящую в пакет внешнюю утилиту.
RDM – инструмент для реляционного моделирования. Служит для генерации SQL-скриптов, с помощью которых в дальнейшем генерируется структура базы данных. Заложена поддержка 25 СУБД.

На сервере компании Argussoft находится ознакомительная версия программного пакета Silverrun, в которой имеется ограничение на количество элементов при создании модели.

4) BPWin и ERWin. Программные пакеты BPWin и ERWin являются «детищами» компании LogickWorks.

BPWin – служит для функционального моделирования на основе методологии IDEF0. Существует возможность использования нотаций IDEF3 и DFD. Существует поддержка экспорта моделей в систему ERWin.

ERWin – основное назначение данного пакета - информационное моделирование, при котором используется нотация IDEF1X. Заложена поддержка свыше 20 целевых СУБД и возможность сгенерировать исходный код для Visual Basic, Delphi. Информационная модель в системе строится в виде диаграммы «сущность — связь», на которой располагаются все основные объекты предметной области, а также связи между ними. У каждой сущности задаются атрибуты, индексы и ключевые поля. У связей можно указать их характеристики. После завершения процесса создания ER-диаграммы существует возможность автоматической генерации SQL-кода для создания всех сущностей в виде таблиц, и связей для связи этих таблиц. Существует также возможность обратного процесса – генерировать ER-диаграммы по SQL-коду.

5) Oracle Designer. Программный продукт Oracle Designer является одним из наиболее полностью поддерживающих все этапы создания информационной системы. Его минус – это поддержка только одной СУБД - Oracle Server. То же самое относится и к средствам создания пользовательского интерфейса, хотя имеется возможность генерации кода на Visual Basic, C, Java. Наиболее полный функционал от системы можно получить при использовании её в комплексе со средой разработки Oracle Developer.

В своем составе пакет Oracle Designer имеет несколько модулей:

1. Инструменты анализа предметной области:

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

Dataflow Diagrammer – основываясь на моделях, созданных в Process Modeler, детализирует функции по нотации Йордона-де Марко.
Function Hierarchy Diagrammer – позволяет автоматически выстраивать иерархии функций.
Entity Relationships Diagrammer – создание диаграмм « сущность-связь»
Matrix Diagrammer – исследование связей между функций и данными

2. Инструменты для генерации структур:

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

3. Инструменты проектирования приложения:

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

4. Генераторы данных и кода:

Server Generator – служит для генерации базы данных, основываясь на созданные реляционные модели.
Генераторы кода – на основе моделей, построенных в Module Data Diagrammer, позволяют создать исходный код для Visual Basic, C, Java а также инструментов среды Oracle Developer (Oracle Forms, Oracle Reports).
Preferences Navigator – средство управления предпочтениями при генерации программных модулей.

Помимо этого в Oracle Designer имеется несколько других не менее важных инструментов: утилита для интерактивного выполнения SQL-запросов, средства управления проектом и т.д.

6) CASE.Аналитик. В основе пакета CASE.Аналитик лежит методология Гейна — Сарсона. Данный программный пакет поддерживает несколько типов диаграмм: диаграммы функциональной иерархии, контекстные диаграммы, диаграммы потоков данных и структурограммы. В ходе выполнения работы с помощью пакета строится информационно-логическая модель системы. Данная модель представляется в иерархическом виде.

В составе пакета имеется несколько компонентов:

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

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

7 CASE/4/0. Пакет CASE/4/0 включает в себя структурные средства для системного анализа, проектирования и программирования. Он обеспечивает поддержку всего жизненного цикла разработки. Позволяет используя сетевой репозиторий контролировать целостность проекта. Анализ основан на методологии Уорда – Меллора. Данное инструментальное средство имеет поддержку следующих типов диаграмм:

древовидные диаграммы функциональной декомпозиции;
диаграммы потоков данных;
диаграммы переходов состояний;
диаграммы “сущность — связь”;
структурные карты Джексона.

В состав пакета включены следующие компоненты:

инструмент создания диалогов для моделирования интерфейса пользователя;
средства разработки на языках Си/ Си++, Visual Basic;
синтаксически-ориентированные редакторы кодов;
инструменты генерации документов.

Пакет состоит из клиентской части, которая устанавливается на рабочих местах разработчиков, и интегрированного сетевого репозитория, устанавливаемого на сервере.

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

Таблица 3.1 – Сравнительные характеристики рассмотренных CASE-средств

Название	Фирма	BPR	Функции	Данные	События
BPWin	Logic Works	+	+	-	-
CASE-Аналитик	Эйтэкс	-	+	+	+
CASE/4/0	MicroTOOL	-	+	+	+
Design/IDEF	Meta Software	+	+	+	-
Designer	Oracle	+	+	+	-
ERWin	Logic Works	-	-	+	-
Designer	Sybase/Powersoft	-	+	+	-
SILVERRUN	CSA	-	+	+	+

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

Заключение

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

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

Среди подобных средств на российском рынке выделяют целый ряд программных продуктов, таких как BPWin, СASE.Аналитик, CASE/4/0, Design/IDEF, Designer, ERWin, , S-Designor, SILVERRUN.

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

Список литературы

Аверченков В. И. Информационные системы в производстве и экономике: учебное пособие 2-е изд., стер. - М.: Флинта , 2016.
Балдин К. В. Информационные системы в экономике. М.: Дашков и Ко , 2016.
Брусакова И. А. Информационные системы и технологии в экономике - М.: Финансы и статистика , 2017.
Вендров. А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2013 г. – 352 с.
Венчковский Л.Б. Разработка сложных программных изделий. М.: ЮРАЙТ , 2014
Герчикова И.Н. Менеджмент: Учебник 2-ое изд., перераб. и доп. - М.: Банки и биржи, ЮНИТИ, 2015.
Голицына О.Л., Максимов Н.В., Попов И.И. Информационные системы: учебное пособие. – М.:ИНФРА-М, 2013 г. – 496 стр.
Горбенко А. О. Информационные системы в экономике. М.: БИНОМ. Лаборатория знаний , 2015.
Илюшечкин В. М. Основы использования и проектирования баз данных: Учебное пособие. – М.: ЮРАЙТ, 2014 г. – 483 с.
Информационные технологии в профессиональной деятельности: Учебное пособие. - М.: Академия, 2014 г. - 384 с.
Карминский А.М.. Информатизация бизнеса. Концепции, технологии, системы: Учебник. – М.: Астрэль, 2015 г. – 624 стр.
Ребекка М. Райордан Основы реляционных баз данных. Учебник. – М: Русская редакция, 2015 г. – 384 стр.
Романенко А. Г., Самойлюк О. Ф., Максимович Г. Ю., Информационные системы: Учебное пособие – М.: Издательский центр РГГУ, 2014 г. – 192 с.
Семакин И. Г. Информационные системы и модели. Методическое пособие. - М.: БИНОМ. Лаборатория знаний , 2015 г. – 176 с.
Смирнов Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем: Учебник. – М.: Финансы и статистика, 2013 г. – 542с.
Сорокин А.В. Разработка баз данных. Учебник. – Санкт – Петербург: ИД Питер, 2014 г. – 477стр.
Фаронов В.В. Программирование баз данных. Учебное пособие. – С-Пб: ИД Питер, 2016 г. – 187 с.
Фатрепп Р., Шафер Д., Шафер Л. - Управление программными проектами. Достижение. Достижение оптимального качества при минимуме затрат. Учебник. – М.: Вильямс, 2014 г. – 274 с.
Чекалов А.П. - Базы данных: от проектирования до разработки приложений. Учебник. – СПб.: БХВ-Петербург, 2016 г. – 384 с.