Проектирование систем обработки данных

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

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

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

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

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

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

Модель организационной структуры.

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

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

1. Методологии структурного анализа и проектирования (функционально ориентированный подход) .

2. Методология объектно-ориентированного анализа и проектирования (объектно-ориентированный подход).

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

07.05.09

В функциональных моделях (DFD диаграммы ,SADT диаграммы) главными структурными компонентами являются функции(операции , действия , работа), которые на диаграммах связываются между собой потоками объектов. Несомненным достоинством функциональных моделей является реализация структурного подхода проектирования информационной системы. По принципу *сверху-вниз*. В этом случае каждый функциональный блок может быть декомпозирован на множество подфункций и так далее. Таким образом выполняется модульное проектирование информационной системы. При функциональном подходе объектные модели данных разрабатываются отдельно виде ER диаграмм, т е диаграмм *сущность -связь*. Для проверки корректности моделирования устанавливается взаимосоответствие . Основной недостаток функциональных моделей связан с неясностью выполнения процессов обработки информации которая может динамично изменяться. Кроме того возможно повторяемость использования одинаковых функций, а следовательно и программных модулей в различных процессах. В последнем случае одни и те же функции в различных иерархия-декомпозиция, могут быть спроектированы несколько раз. Перечисленные недостатки функциональных моделей снимаются в объектно-ориентированных моделях. Главным компонентом таких моделей является класс объектов с набором функций которые могут обращаться к атрибутам этого класса(скрытые данные). Для класса объектов характерна иерархия обобщения которая позволяет осуществлять наследование не только атрибутов объектов от нижестоящего класса к выше стоящему но и функции(методы). В случае наследования функций можно абстрагироваться от конкретной реализации процедур (абстрактные типы данных) , которые отличаются для определенных подклассов ситуаций. Это дает возможность обращаться к подобным программным модулям по общим именам(полиморфизм), или осуществлять повторное использование программного кода при модификации программного обеспечения. Таким образом адаптивность объектно-ориентированных систем к изменениям проблемной области значительно выше чем при использовании функционального подхода. Для объектно-ориентированного моделирования разработаны соответствующие методы моделирования проблемной области, которые обобщены в языке UML(универсальный язык моделирования). Однако по наглядности представление модели пользователю заказчику объектно-ориентированные модели явно уступают в функционале. При выборе подхода для построения моделей предметной области обычно в качестве критерия выбора выступает степень ее динамичности. Для регламентированных задач больше подходят функциональные модели, а для более адаптивных бизнес процессов - объектно-ориентированные модели. Однако в рамках одной и той же информационной системы для различного класса задач могут требоваться различные виды модели. В таких случаях лучше использовать комбинированные модели. В полной мере комбинированный подход к моделированию реализован в инструментальном средстве - ARIS. Это инструментальное средство соответствует различным взглядам на проектирование. DFD-диаграммы и SADT диаграммы стали основой для разработки в конце 80 годов в США серии стандартов методологий структурного анализа и проектирования. Эти стандарты применялись для моделирования первоначально, сложных военных систем , а затем систем корпоративного управления. IDEF0 - моделирование функций IDEF1 - информационное моделирование, 1Х - моделирование данных. 2- динамическое моделирование, 3 - описание процессов, 4 - объектно-ориентированные методы проектирования , 8 - интерфейс пользователя, 14 - проектирование вычислительной сети. В конце 90 годов увеличилась конкуренция и рентабельность предприятий стала резко падать. Руководители столкнулись с большими сложностями пытаясь оптимизировать затраты и сделать продукцию одновременно и прибыльной и конкурентно способной. Четко обозначилась необходимость иметь модель деятельности предприятия которая отражает все механизмы и принципы взаимосвязи различных подсистем в рамках одного бизнеса. Понятие моделирование бизнес процессов вошло в обиход аналитиков одновременно с появлением на рынке сложных программных продуктов, называемых корпоративная информационная система.

13.05.09

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

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

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

IDEF1Х - методология построения реляционных структур. Она относится к методологиям типа *сущность-связь*(ER). Она как правило используется для моделирования реляционных баз данных которые имеют отношение к рассматриваемой системе.

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

Автоматизированное проектирование корпоративных информационных систем(CASE)

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

Преимущества:

- улучшения качества разрабатываемого программного приложения. За сет средств автоматического контроля и генерации.

- Возможность повторного использования компонентов разработки.

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

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

- возможность коллективной разработки проектно-информационной системы в режиме реального времени.

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

14.05.09

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

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

- диаграммы

- компонентов диаграмм

- связи между диаграммами

- библиотеки модулей

- и т д

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

Другими компонентами архитектуры CASE средства являются :

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

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

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

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

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

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

Классификация CASE средств

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

- по поддерживаемым методологиям проектирования

1. структурно-ориентированный

2. объектно - ориентированный

3. комплексно-ориентированный.

- по поддерживаемым графическим нотациям

1. с фиксированной нотацией.

2. с отдельной нотацией

3. наиболее распространенными нотациями

- по степени интеграции

1. отдельные локальные средства

2.Набор не интегрируемых средств охватывающих большинство этапов проектирования

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

- по режиму коллективной разработки проекта

1. не поддерживающие коллективной разработки

2. ориентированные на режим реального времени разработки проекта

3. ориентированные на режим объединения под проектов.

- по типу и архитектуре вычислительной техники.

1. ориентированные на ПК

2. ориентированные на локальную, глобальную или смешенную вычислительную сеть.

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

Функционально-ориентированное проектирование информационных систем.

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

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

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

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

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

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

В структурном анализе используется в основном 3 группы моделей, которые

1. Иллюстрируют функции выполняемые системой

2. Описывающие отношения между данными

3. Описывающие поведение системы во времени.

Литература:

1. Смирнова Г. Н., Сорокин А. А., Тельнов Ю. Н. «Проектирование экономических информационных систем. Учебник». Москва «Финансы и статистика», 2003 г.

2. Мещеряков С. В., Иванов В. Н. «Эффективные технологии создания информационных систем». Спб «Политехника», 2005 г.

3. Уэнди Боггс, Майкл Боггс «UML Rational Rose 2002». Москва «Лорик», 2004 г.

4. Терри Кватрани «Визуальное моделирование с помощью RR2002 и UML». Москва, издательство «Вильямс» 2003 г.

5. Калянов Г. Н. «Case-технологии, консалтинг в автоматизации бизнес процессов». Москва «Горячая линия - телеком», 2002 г.

6. Федотова Д. Н., Семёнов Ю. Д., Чижик К. Л. «CASE-технологии, практикум». Москва «Горячая линия - телеком», 2005 г.

7. Вендров А. Н. «Практикум по проектированию программного обеспечения экономических информационных систем». Москва, «Финансы и статистика», 2002 г.

8. www.interface.ru

Размещено на Allbest.ru