Структуры социально-экономических систем

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

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

- отношение «часть-целое». Обозначим отношение часть целое, как r. Пусть отдел А входит в состав фирмы S. Тогда между А и S имеется отношение r, что математически можно записать так: ArS или r(A, S). Подобные отношения служат основой для разработки иерархических структурных схем предприятий (организационной структуры);

- отношение «вид-род». Например, конкретная фирма ООО «Мебель» может быть видом (частным случаем) рода фирм «Производители мебели», т.е. ООО «Мебель» и «Производители мебели» связаны отношением «вид-род»;

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

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

- отношение «роль-исполнитель». Такое отношение наблюдается между отдельным этапом (функцией) процесса и тем работником, кто его исполняет;

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

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

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

Можно сформулировать некоторые рекомендации при построении структурных схем в процессе анализа и синтеза систем:

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

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

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

Т.4.3. Опишите синтаксис и назначение SADT-модели (стандарт idef0)

Методология SADT разработана Дугласом Россом и получила дальнейшее развитие в работе [4]. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

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

Основные элементы этой методологии основываются на следующих концепциях:

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

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

ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

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

уникальность меток и наименований (отсутствие повторяющихся имен);

синтаксические правила для графики (блоков и дуг);

разделение входов и управлений (правило определения роли данных).

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

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

В основе методологии IDEF0 лежат следующие правила:

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

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

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

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

Дуги могут разветвляться и соединяться.

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

Эти блоки представляют основные подфункции (подмодули) единого исходного модуля.

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

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

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

В IDEF0 реализованы три базовых принципа моделирования процессов:

принцип функциональной декомпозиции;

принцип ограничения сложности;

принцип контекста.

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

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

Принцип контекстной диаграммы. Моделирование делового процесса начинается с построения контекстной диаграммы. На этой диаграмме отображается только один блок - главная бизнес-функция моделируемой системы. Если речь идет о моделировании целого предприятия или даже крупного подразделения, главная бизнес-функция не может быть сформулирована как, например, “продавать продукцию”. Главная бизнес-функция системы - это “миссия” системы, ее значение в окружающем мире. Нельзя правильно сформулировать главную функцию предприятия, не имея представления о его стратегии. При определении главной бизнес- функции необходимо всегда иметь ввиду цель моделирования и точку зрения на модель. Одно и то же предприятие может быть описано по-разному, в зависимости от того, с какой точки зрения его рассматривают: директор предприятия и налоговой инспектор видят организацию совершенно по-разному. Контекстная диаграмма играет еще одну роль в функциональной модели. Она “фиксирует” границы моделируемой бизнес- системы, определяя то, как моделируемая система взаимодействует со своим окружением. Это достигается за счет описания дуг, соединенных с блоком, представляющим главную бизнес-функцию.

Основные элементы и понятия IDEF0

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

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

Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия:

Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1.5) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”).

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

Верхняя сторона имеет значение “Управление” (Control); (стрелки сверху, означающие на основании чего выполняется данный процесс - законы, стандарты, приказы и т.д.);

Левая сторона имеет значение “Вход” (Input); (стрелки слева, - данные или объекты, потребляемые или изменяемые процессом);

Правая сторона имеет значение “Выход” (Output); (стрелки справа, - основные результаты деятельности процесса, конечные продукты);

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

ОСНОВНЫЕ КОНЦЕПЦИИ IDEF0

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

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

Обмен информацией. Существуют некоторые концепции IDEF0, которые определены для обмена информацией:

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

Текст на русском языке определяет понятия в блоках и стрелках.

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

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

Ограничения (не более 6 блоков на диаграмму) введены для простого восприятия диаграмм.

Диаграммы сопровождаются текстом и глоссарием, для улучшения восприятия графического представления.

Точность и однозначность. Правила IDEF0 включают:

Подробное описание на каждом уровне (3-6 блоков).

Ограниченный контекст (только то, что относится к делу и ничего лишнего; ничего не упущено).

Синтаксические правила построения диаграмм (блоки и стрелки).

Неповторяющиеся названия блоков и стрелок.

Переходы между диаграммами (дерево диаграмм).

Переход между объектами/данными (коды ICOM и туннельные переходы).

Разделение входа и управления (правила для определения роли данных или объекта).

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

Сегменты стрелок (разделение или соединение), метки для стрелок.

Требования к наименованию стрелок

Назначение и точка зрения (все модели должны иметь назначение и точку зрения)

Методология. Пошаговые процедуры, предназначенные для моделирования, обзора и сбора данных.