Схема построения модели

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

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

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

1. Размещать на каждой диаграмме от 3 до 6—7 процессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.

2. Не загромождать диаграммы несущественными на данном уровне деталями.

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

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

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

6. Пользоваться простейшими диаграммными техниками: если что-либо возможно описать с помощью одной диаграммы, то это и необходимо делать, а не использовать для описания более сложные объекты.

7. Отделять управляющие структуры от обрабатывающих структур (т. е. процессов), локализовать управляющие структуры.

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

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

2. Идентификация внешних объектов, с которыми система должна быть связана.

3. Идентификация основных видов информации, циркулирующей между системой и внешними объектами.

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

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

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

7. Формирование диаграммы первого уровня на базе процессов предварительной контекстной диаграммы.

8. Проверка основных требований по диаграмме первого уровня.

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

10. Проверка основных требований по диаграммам соответствующего уровня.

11. Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах.

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

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

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

Методология SADT

SADT (Structured Analysis and Design Technique), технология структурного анализа и проектирования – одна из самых известных методологий анализа и проектирования систем, введенная в 1973 году.

SADT успешно использовалась в военных, промышленных и коммерческих организациях для решения широкого спектра задач, таких как:

– программное обеспечение телефонных сетей;

– системная поддержка и диагностика;

– долгосрочное и стратегическое планирование;

– автоматизированное производство и проектирование;

– конфигурация компьютерных систем;

– обучение персонала;

– встроенное программное обеспечение (ПО) для оборонных систем;

– управление финансами и материально-техническим снабжением и др.

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

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

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

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

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

Основным рабочим элементом при моделировании является диаграмма. Модель SADT объединяет и организует диаграммы в иерархические древовидные структуры, при этом чем выше уровень диаграммы, тем она менее детализирована.

В состав диаграммы входят блоки, изображающие активности моделируемой системы, и дуги, связывающие блоки вместе и изображающие взаимодействия и взаимосвязи между блоками. SADT требует, чтобы в диаграмме было 3–6 блоков: в этих пределах диаграммы и модели удобны для чтения, понимания и использования. Вместо одной громоздкой модели используются несколько небольших взаимосвязанных моделей, значения которых взаимодополняют друг друга, делая понятной структуризацию сложного объекта. Однако такое жесткое требование числа блоков на диаграмме ограничивает применение SADT для ряда предметных областей. Например, в банковских структурах имеется 15–20 равноправных деятельностей, которые сообразно отразить на одной диаграмме. Искусственное их растаскивание по разным уровням SADT-модели явно не улучшает ее понимание (понимаемость).

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

– левая сторона блока предназначена для Входов;

– верхняя для Управления;

– правая для Выходов;

– нижняя для Исполнителей или Механизмов.

Такое обозначение отражает определенные принципы активности:

– Входы преобразуются в Выходы;

– Управления ограничивают или предписывают условия выполнения;

– Механизмы описывают, за счет чего выполняются преобразования.

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

Рис. 4. Структура диаграммы SADT

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

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

Дуги SADT, как правило, изображают комплексы действий или наборы предметов, поэтому они могут разветвляться и соединяться вместе различным образом. Разветвления дуги означают, что часть ее содержимого (или весь набор предметов) может появиться в каждом ответвлении дуги. Дуга всегда помечается до разветвления, чтобы дать название всему набору. Кроме того, каждая ветвь дуги может быть помечена в соответствии со следующими правилами: считается, что непомеченная ветвь содержит все предметы, указанные в метке перед разветвлением; каждая метка ветви уточняет, что именно содержит эта ветвь. Слияние дуг указывает, что содержимое каждой ветви участвует в формировании после слияния объединенной дуги.

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

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

Примеры SADT-диаграмм, моделирующих деятельность компаний, приведены на рис. 5 и 6.

Рис. 5. Пример SADT-диаграммы, моделирующей деятельность гостиницы

Рис. 6. Пример SADT-диаграммы цеха производственного предприятия

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

IDEF-технологии

На основе методологии SADT в начале 90-х годов в США был принят стандарт моделирования бизнес-процессов IDEF, включающий семейство стандартов от IDEFO, IDEF1, IDEF2 и т.д. Это семейство стандартов является независимым от частных организаций и принято в нескольких международных организациях, например, в НАТО и МВФ. С их помощью можно эффективно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина исследования процессов в системе определяются самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.

В настоящий момент к наиболее востребованным стандартам семейства IDEF относят следующие:

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

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

– IDEF1X (IDEFI Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий «Сущность—взаимосвязь» (ER – Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

– 1DEF2 – методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм 1DEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN – Color Petri Nets);

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

– 1DEF4 – методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

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

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

Основная цель стандарта – построение древовидной функциональной модели предприятия.

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

I ЭТАП. Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом.

Таким образом, сначала функциональность предприятия описывается в целом, без подробностей. Такое описание носит название «Контекстная диаграмма».

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

– входа (данные или объекты, потребляемые или изменяемые функцией);

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

– управлений (стратегии и процедуры, которыми руководствуется функция);

– механизмов (необходимых ресурсов).

При создании диаграммы формулируется:

1. Цель моделирования – purpose. Она должна отвечать на вопросы:

– почему нужно моделировать данный процесс?

– что должна показывать модель?

– что может получить пользователь?

Примеры:

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

или более конкретные: «Описать функциональность предприятия с целью написания спецификаций информационной системы», «Описать и проанализировать организационную структуру предприятия с целью повышения эффективности принятия решений» и т. д.

2. Область – definition, т. е. описание того, что будет рассматриваться как компонент системы, а что – как внешнее воздействие.

3. Точка зрения – View Point, т. е. позиция, с которой будет строиться модель системы управления.

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

При выборе точки зрения важно задокументировать дополнительные альтернативные точки зрения.

II ЭТАП. Общая функция разбивается на крупные подфункции. Этот процесс называется функциональной декомпозицией. Каждая полученная функция разбивается на более мелкие и т. д. до достижения необходимой детализации описания.

На схеме показано дерево функций, называемое «деревом узлов функциональной модели» (рис. 7).

Рис. 7. Пример декомпозиции – дерево узлов функциональной модели предприятия

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

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

Рис. 8. Декомпозиция функциональной модели

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

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

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

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

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

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

CASE-средства

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

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

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

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

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

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

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

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

2. Широкое использование базовых программных средств, получивших массовое распространение в других приложениях (БД и СУБД, компиляторы с различных языков программирования, отладчики, документаторы, издательские системы, оболочки экспертных систем и базы знаний, языки четвертого поколения и др.).

3. Автоматизированная или автоматическая кодогенерация, выполняющая несколько видов генерации кодов: преобразования для получения документации, формирования БД, ввода/модификации данных, получения выполняемых машинных кодов из спецификаций ПО, автоматической сборки модулей из словарей и моделей данных и повторно используемых программ, автоматической конверсии ранее используемых файлов в форматы новых требований (требование для программистов и системных администраторов).

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

5. Доступность для разных категорий пользователей.

6. Рентабельность.

7. Сопровождаемость, обеспечивающая способность адаптации при изменении требований и целей проекта.

Интегрированный CASE-пакет содержит четыре основных компонента:

1. Средства централизованного хранения всей информации о проектируемом объекте в течение всего ЖЦ (репозитарий) являются основой CASE-пакета. Соответствующая БД должна иметь возможность поддерживать большую систему описаний и характеристик и предусматривать надежные меры по защите от ошибок и потерь информации.

Репозитарий должен обеспечивать:

– инкрементный режим при вводе описаний объектов;

– распространение действия нового или скорректированного описания на информационное пространство всего проекта;

– синхронизацию поступления информации от различных пользователей;

– хранение версий проекта и его отдельных компонентов;

– сборку любой запрошенной версии;

– контроль информации на корректность, полноту и состоятельность.

2. Средства ввода предназначены для ввода данных в репозитарий, а также для организации взаимодействия с CASE-паке- том. Эти средства должны поддерживать различные методологии и использоваться на всем ЖЦ разными категориями разработчиков: аналитиками, проектировщиками, инженерами, администраторами и т. д.

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

4. Средства вывода служат для документирования, управления проектом.

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