3. Примеры организационно-функциональных моделей

П ример описания фрагментов организационно-функциональной модели производственного предприятия:

Пример описания фрагментов организационно-функциональной модели торгового предприятия:

5. Методологии моделирования предметной области.

1. Структурная модель

Зачем нужно моделирование?

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

Требования к моделям ПО:

- формализация (обеспечивает однозначное описание ПО)

- понятность (графические средства - для легкого восприятия заказчиком и разработчиком)

- реализуемость (наличие средств физической реализации модели в ИС)

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

Аспекты моделей ПО:

1. Структурный аспект предполагает построение:

- объектной структуры (состав взаимодействующих материальных и информационных объектов)

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

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

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

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

2. Оценочные аспекты (показатели эффективности):

- время решения задачи

- стоимостные затраты на обработку данных

- надежность процессов

- косвенные показатели(объем производства, производительность труда, оборачиваемость капитала..)

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

3 уровня, на которых строится модель:

- внешний (определение требований) – Что должна делать система? Состав основных компонентов: объекты, функции, события, организационные единицы, технические средства.

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

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

2. Функционально-ориентированные, объектно-ориентированные методологии

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

Функциональная методика IDEF0

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

В основе лежат 4 компоненты:

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

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

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

4. Глоссарий: набор определений для каждого компонента, которые характеризуют объект, отраженный данным элементом.

Контекстная диаграмма – модель с 1 функц.блоком. В пояснительном тексте должна быть указана цель (важнейшие области диаграммы) и зафиксирована точка зрения (направление развития модели и уровни детализации).

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

Ограничение сложности: представлять на диаграмме 3-6 функц.блоков, кол-во входящих дуг к 1 блоку не больше 4х.

Этапы разработки:

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

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

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

Функциональная методика потоков данных(Data Flow Diagram — DFD).

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

В основе 4 понятия:

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

2) Процессы(работы) преобразования входных данных в выходные: продуцирование выходных потоков из входных. Имя процесса – глагол в НФ с дополнением (н-р: получить документы по отгрузке продукции). Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы.

3) Внешние сущности: материальный объект вне системы, являющийся источником или приемником системных данных. Имя является существительным(н-р склад товаров)

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

Кроме этих понятий входят еще словари данных(каталог всех элементов) и миниспецификации (описание процессов нижнего уровня).

Процесс построения DFD начинается с создания основной диаграммы типа «звезда»-включает моделируемый процесс и все внешние уровни, с которыми он взаимодействует. Этап заключается в выборе глагола, определяющий как внешняя сущность использует основной процесс(н-р: процесс-учет обращений граждан; внешняя сущность: граждане; описание взаимодействия: подает заявление и получает ответы). Для всех внешних сущностей строится таблица событий(взаимодействие с основным потоком).

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

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

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

-возможность однозначно определить внешние сущности

-возможность проектирования сверху вниз

-наличие спецификаций процессов нижнего уровня (преодоление незавершенности модели)

Недостатки:

-необходимость искусственного ввода управляющих процессов

-отсутствие понятия времени

Объектно-ориентированная методика

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

Объектная модель строится с учетов принципов: абстрагирование; инкапсуляция; модульность; иерархия; типизация; параллелизм; устойчивость.

Основные понятия:

1) Объект: предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением и индивидуальностью.

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

3) Полиморфизм: способность классу принадлежать к более чем 1 типу.

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

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

Плюсы:

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

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

-модель естественна, т.к. ориентирована на человеческое восприятие

Минусы:

-высокие начальные затраты

-диаграммы менее наглядны

-подход не дает немедленной отдачи

3. Синтетическая методика

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

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

- Выделение сценариев использования (при помощи критерия полезности строят для каждой внешней сущности набор сценариев)

- Добавление системных сценариев использования (определяют сценарии, необходимые для реализации целей системы, отличных от целей пользователей)

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

- Функциональная декомпозиция диаграмм активностей как контекстных диаграмм методики IDEF0

- Формальное описание отдельных функциональных активностей в виде административного регламента (с применением различных нотаций).