Частные принципы проектирования АИС.

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

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

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

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

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

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

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

Этапы проектирования.

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

Метод решения: функциональное моделирование.

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

2 этап «формализация бизнес - модели.Разработка логической модели бизнес-процесса»

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

Метод решения: разработка диаграмма сущность-связь.

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

3 этап «выбор лингвистического обеспечения, разработка ПО АИС»: выбирается лингвистическое обеспечение, проводится разработка программного и методического обеспечений. Разработанная на втором этапе логическая модель воплощается в реальные объекты: лог. схемы в объекты БД, функциональные схемы в пользовательские формы и приложения. Метод решения: разработка программного кода с использованием внутреннего инструментария.

Результат: работоспособная ИС.

4 этап «тестирование и отладка ИС» осуществляется корректировка информационного, аппаратного, программного обеспечения, разработка методического обеспечения (документация разработчика-пользователя).

Результат: оптимальный состав и эффективное функционирование ИС.

5этап «эксплуатация и контроль версий»

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

Результат: наращиваемость и безизбыточный состав гибкой масштабируемой ИС.

28. Функциональный блок и интерфейсные дуги. Методология IDEF0 является развитием хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique).

IDEFO как стандарт был разработан в 1981 г. в рамках обширной программы автоматизации промышленных предприятий Integra ted Computer Aided Manufacturing (ICAM) предложенной департаментом военно-воздушных сил США.

Со времени появления стандарт 1DEF0 претерпел несколько незначительных изменений, в основном, ограничивающего характера; последняя его редакция была выпущена в декабре 1993 г. Национальным институтом по стандартам и технологиям США (NIST).

Графический язык IDEF0 прост и гармоничен. В основе методологии лежат четыре основных понятия, первым из которых является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (рис. 2.7) и представляет собой некоторую конкре. функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги», а не «производство услуг»).

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

• верхняя сторона имеет значение «Управление» (Control);

• левая сторона имеет значение «Вход» (Input);

• правая сторона имеет значение «Выход» (Output);

• нижняя сторона имеет значение «Механизм» (Mechanism).

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

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

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

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

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

На рис. 2.8 приведен пример диаграммы, изображающий функциональный блок «Обработать заготовку» [5, 8, II, 13]. Для получения детали рабочему выдают заготовку и технологические указания. Неверно считать, что технологические указания (какой-то документ или документы) и заготовка являются входящими объектами. На самом деле в этом процессе заготовка обрабатывается по правилам, отраженным в технологических указаниях, которые должны изображаться управляющей интерфейсной дугой.

Другой пример [5, 8, 11, 13] приведен на рис. 2.9, где описывается процесс обработки и изменения главным технологом технологических указаний. Здесь технологические указания отображаются входящей интерфейсной дугой, а управляющим объектом являются, например, новые промышленные стандарты, учитывая которые производятся изменения.

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

• материальные потоки (детали, товары, сырье и т. д.);

• финансовые потоки (наличные и безналичные, инвестиции и т. д.);

• потоки документов (коммерческие, финансовые и организационные);

• потоки информации (информация, данные о намерениях, устные распоряжения и т. д.);

• ресурсы (сотрудники, станки, машины и т. д.).

При этом в разных случаях входящими и исходящими интерфейсными дугами могут отображаться все виды объектов, управляющими - только относящиеся к потокам документов и информации, а дугами-механизмами — только ресурсы [5, 7, 10, 11, 13].

Одно из главных отличий стандарта 1DEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram) — обязательное наличие управляющих интерфейсных дуг.