Методы и инструментальные средства моделирования информационных процессов и систем
Материалы раздела написаны на основе работы Черемных С.В., Семенов И.О., Ручкин В.С. Моделирование и анализ систем. IDEF-технологии: практикум. — М.: Финансы и статистика, 2006. — 188 с.
http://victor-safronov.narod.ru/systems-analysis/papers.html
В методологии системного анализа, как было рассмотрено выше, заложены два основных принципа:
– принцип детализации;
– принцип иерархического упорядочивания.
Понимание этих принципов, знание предметной области и общей логики научного анализа вполне достаточно для решения прикладных задач системного анализа.
Эти принципы воплощаются в разбиении исследуемого процесса на функциональные блоки – подпроцессы, а также декомпозиции требующих детализации подпроцессов. Эта детализация реализовывается в иерархических структурах. Это разбиение выполняется в графической форме по определенным правилам, которые известны для всех.
Рассмотрим графические формы представления процессов известными методологиями, которые также позволяют анализировать эти процессы:
IDEF0–технология структурного анализа и проектирования. Согласно этой технологии анализируемый процесс представляется в виде совокупности множества взаимосвязанных действий, работ (Activities), которые взаимодействуют между собой на основе определенных правил (Control), с учетом потребляемых информационных, человеческих и производственных ресурсов (Mechanism), имеющих четко определенный вход (Input) и не менее четко определенный выход (Output);
IDEF3–технология сбора данных, необходимых для проведения структурного анализа системы, дополняющая технологию IDEF0. С помощью этой технологии уточняется процесс, анализируется очередность выполнения функций и бизнес-процессов в целом, что не делается с помощью IDEF0. Логика технологии IDEF3 позволяет строить и анализировать альтернативные сценарии развития изучаемых бизнес-процессов (модели типа "Что – если"?);
DFD (Data Flow Diagram) – структурный анализ потоков данных. Диаграммы DFD позволяют описать процесс обмена информацией между элементами изучаемой системы, что нельзя проанализировать с помощью технологий IDEF0 и IDEF3. DFD отображает источники и адресаты данных, идентифицирует процессы и группы данных, связывающие в потоки одну функцию с другой, а также, что важно, определяет накопители (хранилища) данных, которые используются в исследуемом процессе;
IDEF5–технология онтологического описания данных. Методология IDEF5 обеспечивает наглядное представление данных, полученных в результате обработки онтологических запросов в простой естественной графической форме.
Методология функционального моделирования IDEF0
Методология функционального моделирования IDEF0 – это технология описания системы в целом как множества взаимозависимых действий или функций. Для исследования системы или процесса применяем функциональную направленность IDEF0 – функции системы исследуются независимо от объектов, которые обеспечивают их выполнение. Пример типовой диаграммы IDEF0 приведен в Приложении А, рисунок А4.
Технология IDEF0 применяется как технология исследования и проектирования систем на логическом уровне. Используется на ранних этапах разработки проекта, до IDEF3 моделирования для сбора данных и моделирования процесса "как есть". Результаты IDEF0 анализа могут применяться при проведении проектирования с использованием моделей IDEF3 и диаграмм потоков данных.
Синтаксис и семантика моделей IDEF0
Модели IDEF0. Графическая нотация IDEF0 лаконична, она содержит только два обозначения: блоки и стрелки со строгими и четко определенными рекомендациями, что служит для построения качественной и понятной модели системы, показаны на рисунке 5.
Рисунок 5 – Два обозначения: блоки и стрелки
Первый шаг при построении модели IDEF0 заключается в определении назначения модели – набора вопросов, на которые должна отвечать модель. Например, для приведенной на рисунке А4 Приложения А модели: Какие действия надо совершить, чтобы провести индивидуальную работу со студентами?
Границы моделирования предназначены для обозначения ширины охвата предметной области и глубины детализации и являются логическим продолжением уже определенного назначения модели. Как читающий модель, так и непосредственно ее автор должны понимать степень детальности ответов на поставленные в назначении модели вопросы. Например, для осуществления индивидуальной работы со студентами куратора необходимо проводить кураторские часы, организовывать внеучебный досуг, определять проблемы студентов и помогать в их решении, тестировать и анкетировать студентов.
Следующим шагом указывается предполагаемая целевая аудитория, для нужд которой создается модель. Зачастую от выбора целевой аудитории зависит уровень детализации, с которым должна создаваться модель. В нашем случае целевая аудитория – кураторы студенческих групп.
Прежде чем строить модель надо собрать весь исходный материал о предмете моделирования, определить, какие дополнительные материалы и (или) техническая документация для понимания модели могут быть необходимы целевой аудитории, какие язык и стиль изложения являются наиболее подходящими.
Под точкой зрения понимается перспектива, с которой наблюдалась система при построении модели. Точка зрения выбирается таким образом, чтобы учесть уже обозначенные границы моделирования и назначение модели. Однажды выбранная точка зрения остается неизменной для всех элементов модели. При необходимости могут быть созданы другие модели, отображающие систему с других точек зрения. Вот несколько примеров точек зрения при построении моделей: студент, куратор, администрация, преподаватель.
Действия. Как было сказано выше, в графической нотации IDEF0 существуют два обозначения: блок и стрелки. В блоках описывается действие, которое называется функцией. Действие направлено на обработку или перевод входных параметров (сырье, информацию и т.п.) в выходные. Поскольку модели IDEF0 представляют систему как множество иерархических (вложенных) функций, в первую очередь должна быть определена функция, описывающая систему в целом – контекстная функция.
Функции изображаются на диаграммах как поименованные прямоугольники, или функциональные блоки. Имена функций в IDEF0 подбираются с использованием глаголов или отглагольных существительных. Именовать функции нужно кратко, точно, отражать процесс (или систему) с точки зрения выбранного персонажа.
Пример функционального блока приведен на рисунке А5 в Приложении А.
IDEF0 модель есть иерархическое множество вложенных блоков. Основной контекстный блок (рисунок А5 Приложение А) декомпозирован на составляющие его блоки на рисунке А4 Приложение А. «Декомпозицию часто ассоциируют с моделированием "сверху вниз", однако это не совсем верно. Функциональную декомпозицию корректнее определять как моделирование "снаружи вовнутрь", в котором мы рассматриваем систему наподобие луковицы, с которой последовательно снимаются слои» [29].
Границы и связи. Второе обозначение – стрелки имеют также конкретные назначения. Блоки помимо названия имеют описание, которое должно включать в себя описание того, что на входе и выходе, т.е. объектов, которые блок потребляет или преобразует ("вход") и создает в результате своей работы ("выход").
В IDEF0 также моделируются управление и механизмы исполнения. Под управлением понимаются объекты, воздействующие на способ, которым блок преобразует вход в выход. Механизм исполнения – объекты, которые непосредственно выполняют преобразование входа в выход, но не потребляются при этом сами по себе.
Для отображения категорий информации, присутствующих на диаграммах IDEF0, существует аббревиатура ICOM, отображающая четыре возможных типа стрелок:
I (Input) – вход – нечто, что потребляется в ходе выполнения процесса;
С (Control) – управление – ограничения и инструкции, влияющие на ход выполнения процесса;
О (Output) – выход – нечто, являющееся результатом выполнения процесса;
М (Mechanism) – исполняющий механизм – нечто, что используется для выполнения процесса, но не потребляется само по себе.
Рисунок 6 показывает четыре возможных типа стрелок в IDEF0, каждый из типов соединяется со своей стороной функционального блока.
Рисунок 6 – Типы стрелок и направления их соединения со своей стороной функционального блока
Для названия стрелок, как правило, употребляются имена существительные. Описание стрелки может представлять собой профессии, законы, места, вещи, информацию или события. Как и в случае с функциональными блоками, присвоение имен всем стрелкам на диаграмме является только необходимым условием для понимания читателем сути изображенного. Отдельное описание каждой стрелки в текстовом виде может оказаться критическим фактором для построения точной и полезной модели.
Стрелки входа. Вход представляет собой сырье, или информацию, потребляемую или преобразуемую функциональным блоком для производства выхода. Стрелки входа всегда направлены в левую сторону прямоугольника, обозначающего в IDEF0 функциональный блок. Входные стрелки на диаграмме могут отсутствовать, так как возможно, что некоторые блоки ничего не преобразуют и не изменяют. Примером блока, не имеющего входа, может служить "принятие решения руководством", где для принятия решения анализируется несколько факторов, но ни один из них непосредственно не преобразуется и не потребляется в результате принятия какого-либо решения.
Стрелки управления. Стрелки управления отвечают за регулирование того, как и когда выполняется функциональный блок, и, если он выполняется, какой выход получается в результате его выполнения. Так как управление контролирует поведение функционального блока для обеспечения создания желаемого выхода, каждый функциональный блок должен иметь, как минимум, одну стрелку управления. Стрелки управления всегда входят в функциональный блок сверху.
Управление часто существует в виде правил, инструкций, законов, политики организации, набора необходимых процедур или стандартов. Влияя на работу блока, оно непосредственно не потребляется и не трансформируется в результате. Однако, может оказаться, что целью функционального блока является как раз изменение того или иного правила, инструкции, стандарта и т.п. В этом случае стрелка, содержащая соответствующую информацию, должна рассматриваться не как управление, а как вход функционального блока.
Управление можно рассматривать как специфический вид входа. В случаях, когда неясно, относить ли стрелку к входу или к управлению, предпочтительно относить ее к управлению до момента, пока неясность не будет разрешена.
Стрелки выхода. Выход – это продукция или информация, получаемая в результате работы функционального блока. Каждый блок должен иметь, как минимум, один выход. Действие, которое не производит никакого четко определяемого выхода, не должно моделироваться вообще (по меньшей мере, должно рассматриваться в качестве одного из первых кандидатов на исключение из модели).
При моделировании непроизводственных предметных областей выходами, как правило, являются данные, в каком-либо виде обрабатываемые функциональным блоком. В этом случае важно, чтобы названия стрелок входа и выхода были достаточно различимы по своему смыслу. Например, блок "Выявление проблем студентов" может иметь стрелку "Информация об успеваемости" как на входе, так и на выходе. В такой ситуации входящую стрелку можно назвать "Предварительная информация об успеваемости", а исходящую – "Корректированная информация об успеваемости".
Стрелки механизма исполнения. Механизмы являются ресурсом, который непосредственно исполняет моделируемое действие. С помощью механизмов исполнения могут моделироваться ключевой персонал, техника и (или) оборудование. Стрелки механизма исполнения могут отсутствовать в случае, если оказывается, что они не являются необходимыми для достижения поставленной цели моделирования.
Не смотря на то, что было отмечена возможность отсутствия стрелок входа и механизмов, желательно наличие всех четырех стрелок.
Диаграммы
На рисунке А4 Приложение А была представлена типовая диаграмма IDEF0 вместе с находящейся на ее полях служебной информацией. Служебная информация состоит из хорошо выделенных верхнего и нижнего колонтитулов (заголовка и "подвала"). Элементы заголовка используются для отслеживания процесса создания модели. Элементы "подвала" отображают наименование модели, к которой относится диаграмма, и показывают ее расположение относительно других диаграмм модели.
Все элементы заголовка диаграммы перечислены в табл. 4.1.
Таблица 4.1. Элементы заголовка диаграммы IDEF0
Поле |
Назначение |
USED AT |
Используется для отражения внешних ссылок на данную диаграмму (заполняется на печатном документе вручную) |
Author, date, project |
Содержит ФИО автора диаграммы, дату создания, дату последнего внесения изменений, наименование проекта, в рамках которого она создавалась |
Notes 1 ... 10 |
При ручном редактировании диаграмм пользователи могут зачеркивать цифру каждый раз, когда они вносят очередное исправление |
Status |
Статус отражает состояние разработки или утверждения данной диаграммы. Это поле используется для реализации формального процесса публикации с шагами пересмотра и утверждения |
Working |
Новая диаграмма, глобальные изменения или новый автор для существующей диаграммы |
|
Продолжение Таблицы 4.1 |
Поле |
Назначение |
Draft |
Диаграмма достигла некоторого приемлемого для читателей уровня и готова для представления на утверждение |
Recommended |
Диаграмма одобрена и утверждена. Какие-либо изменения не предвидятся |
Publication |
Диаграмма готова для окончательной печати и публикации |
Reader |
ФИО читателя |
Date |
Дата знакомства читателя с диаграммой |
Context |
Набросок расположения функциональных блоков на родительской диаграмме, на котором подсвечен декомпозируемый данной диаграммой блок. Для диаграммы самого верхнего уровня (контекстной диаграммы) в поле помещается контекст ТОР |
Все элементы «подвала» диаграммы перечислены в табл. 4.2
Таблица 4.2. Элементы «подвала» диаграммы IDEF0
Поле |
Назначение |
Node |
Номер диаграммы, совпадающий с номером родительского функционального блока |
Title |
Имя родительского функционального блока |
Number (еще называют С-Number) |
Уникальный идентификатор данной версии данной диаграммы. Таким образом, каждая новая версия данной диаграммы будет иметь новое значение в этом поле. Как правило, C-Number состоит из инициалов автора (которые предполагаются уникальными среди всех аналитиков проекта) и последовательного уникального идентификатора, например SDO005. При публикации эти номера могут быть заменены стандартными номерами страниц. Если диаграмма замещает другую диаграмму, номер заменяемой диаграммы может быгь заключен в скобки – SDO005 (SDO004). Это обеспечивает хранение истории изменений всех диаграмм модели |
Построение моделей
Прежде чем приступить к созданию модели необходимо определить целесообразность этого построения.
! |
Выбранное определение цели моделирования должно отвечать на следующие вопросы:
|
Следует отметить, что технология IDEF0 позволяет провести анализ процесса на основе диаграмм, которые наглядно показывают функциональные блоки. Однако, как и в случае с определением цели моделирования, четкое определение точки зрения необходимо для обеспечения внутренней целостности модели и предотвращения постоянного изменения ее структуры. Может оказаться необходимым построение моделей с разных точек зрения для детального отражения всех особенностей выделенных в системе функциональных блоков.
Границы моделирования имеют два компонента: ширину охвата и глубину детализации. Ширина охвата обозначает внешние границы моделируемой системы. Глубина детализации определяет степень подробности, с которой нужно проводить декомпозицию функциональных блоков.
Чтобы облегчить правильное определение границ моделирования при разработке моделей IDEF0, существенные усилия затрачиваются на разработку и рецензирование контекстной диаграммы IDEF0 (диаграммы «самого верхнего» уровня). Иногда даже прибегают к построению дополнительной диаграммы для отображения уровня, более высокого, чем контекстный, для данной модели, что позволяет обозначить систему, внутри которой располагается объект для моделирования.
Существенные затраты на разработку контекстной диаграммы вполне оправданы, поскольку она является своего рода «точкой отсчета» для остальных диаграмм модели и вносимые в нее изменения каскадом отражаются на все лежащие ниже уровни.
Когда границы моделирования понятны, становятся ясными и причины, по которым некоторые объекты системы не вошли в модель.
Выбор наименования контекстного блока
Рекомендуемой последовательностью действий при построении модели «с нуля» являются: формулирование цели моделирования, выбор точки зрения, определение границ моделирования. Наименование контекстного блока – функционального блока самого высокого уровня – обобщает определение границ моделирования.
Правила подбора имени для контекстного блока в целом не отличаются от общих правил наименования функциональных блоков, поэтому для них обычно подбирают обобщающие названия, типа «Управление отделом по работе с клиентами», «Обработка заказов» и т.п.
Определение стрелок на контекстной диаграмме. Рекомендуется проектировать стрелки диаграмм IDEF0 в следующем порядке: выход, вход, механизм исполнения, управление. Каждый функциональный блок обозначает отдельную функцию, и эта функция часто имеет ясно и кратко описываемые результаты работы.
Наличие неясностей при анализе выходов того или иного функционального блока – возможный сигнал необходимости проведения реинжиниринга рассматриваемого бизнес-процесса.
Определение выходов. После идентификации возможных выходов полезно провести анализ модели на предмет покрытия ею всех возможных сценариев поведения процесса. Это означает, что если существует вероятность возникновения той или иной ситуации в ходе процесса, модель отражает возможность возникновения такой ситуации.
Многие начинающие аналитики забывают отразить негативные результаты работы функциональных блоков. Например, блок «Провести экзамен по дисциплине» определенно произведет поток сдавших экзамен, но вполне правомерно ожидать и потока лиц, не сдавших экзамен. Негативные результаты часто используются в качестве обратных связей, анализ на их наличие должен проводиться для каждого блока. Важным также является необходимость включения в модель спорных стрелок, принятие решения, о наличии которых в модели, вполне можно переложить на плечи рецензирующих модель экспертов.
Определение входов. Входы можно рассматривать как особым образом преобразуемые функциональными блоками для производства выхода сырье или информацию. В производственных отраслях определить, как входное сырье преобразуется в готовую продукцию, обычно довольно просто. Однако при моделировании информационных потоков входной поток данных может представляться не потребляемым и не обрабатываемым вообще. Как было отмечено выше, случаи, когда входящие и исходящие стрелки называются в точности одинаково, крайне редки и в основном указывают на бесполезность данного блока для системы в целом или на некорректный выбор имени для исходящей стрелки.
Определение механизмов исполнения. После создания входов и выходов можно приступить к рассмотрению механизмов исполнения, или ресурсов, относящихся к функциональному блоку. В понятие механизма исполнения входят персонал, оборудование, информационные системы и т.п. Например, функциональный блок «Сформировать отчет» может потребовать использования какого-либо персонала, например куратора. При сборке декораций потребуется как персонал, так и специальный инструмент.
Определение управления. Должно быть определено управление, контролирующее ход работы функционального блока. Все функциональные блоки в IDEF0 должны иметь хотя бы одно управление. Например, функциональному блоку «Сформировать отчет» может в качестве управления быть стрелка «Правила оформления отчета». В случаях, когда не ясно, относить ли стрелку к входу или к управлению, следует ее рисовать как управление. Важно помнить, что управление можно рассматривать как особую форму входа функционального блока.
Когда контекстная диаграмма представляется завершенной, попробуйте задать следующие вопросы:
Обобщает ли диаграмма моделируемый бизнес-процесс?
Согласуется ли диаграмма с границами моделирования, точкой зрения и целью моделирования?
Подходит ли выбранный уровень детализации стрелок для контекстного блока?
! |
Правило. Обычно на контекстной диаграмме рекомендуется рисовать не более шести стрелок каждого типа. |
Нумерация блоков и диаграмм. Все функциональные блоки IDEF0 нумеруются. В номерах допускается использование префиксов произвольной длины, но в подавляющем большинстве моделей используется префикс А. Номер блока проставляется за префиксом. Контекстный блок всегда имеет номер АО.
Префикс повторяется для каждого блока модели. Номера используются для отражения уровня декомпозиции, на котором находится блок. Блок АО декомпозируется в блоки А1, А2, A3 и т.д. А1 декомпозируется в А11, А12, А13 и т.д. А11 декомпозируется в А111, А112, А113 и т.д. Для каждого уровня декомпозиции в конец номера добавляется одна цифра.
Связь между диаграммой и ее родительским функциональным блоком. Функциональный блок декомпозируется, если необходимо детально описать его работу. При декомпозиции блока полезно рассмотреть его жизненный цикл, это поможет определить функциональные блоки получающейся "дочерней" диаграммы.
При моделировании IDEF0 важно иметь в виду, что граница дочерней диаграммы есть граница родительского функционального блока. Это означает, что вся работа выполняется блоками самого нижнего уровня. В отличие от иерархии, применяемой в структурном программировании, блоки верхнего уровня не являются субъектами управления для блоков нижнего уровня. Это означает, что в IDEF0 «дети» – это те же объекты, что и их «родители», только показанные с большей детализацией.
При необходимости дальнейшей детализации отдельных процессов могут быть использованы диаграммы IDEF3.
Другие диаграммы IDEF0. В дополнение к контекстным диаграммам и диаграммам декомпозиции при разработке и представлении моделей могут применяться другие виды IDEF0-диаграмм.
Для более полного представления действий функционального блока можно создать отдельные модели IDEF3 для каждого из этих действий, что будет описано дальше.
Итак, методология функционального моделирования IDEF0 – это технология описания системы в целом как множества взаимозависимых действий, или функций. IDEF0 имеет функциональную направленность. Однако в технологии IDEF0 – функции системы исследуются независимо от объектов, которые обеспечивают их выполнение. Одной из основных идей моделей IDEF0 является построение двух видов моделей: "как есть" и "как должно быть". Это нужно при проведении реинжиниринга бизнес-процессов организации. Кроме того, IDEF0 обеспечивает удобный язык обмена информацией о моделируемой системе. Моделировать деловой процесс в IDEF0 можно исходя из различных перспектив и временных рамок. С функциональной точки зрения можно абстрагироваться от проблем физической реализации модели.
Методология описания бизнес-процессов IDEF3
IDEF3 – способ описания процессов, позволяющий описать процесс в виде упорядоченной последовательности действий, событий с учетом объектов, имеющих непосредственное отношение к процессу.
Технология IDEF3 позволяет качественно проводить структурный анализ системы, что очень важно при системном анализе системы или процесса. Эта технология показывает временную последовательность действий в процессе, что не отражается в других технологиях. Технология хорошо приспособлена для сбора данных, требующихся для проведения того или иного действия. Также ее отличает от большинства технологий моделирования бизнес-процессов отсутствие жестких синтаксических или семантических ограничений, которые влияют на описание неполных или нецелостных систем. «Кроме того, автор модели (системный аналитик) избавлен от необходимости смешивать свои собственные предположения о функционировании системы с экспертными утверждениями в целях заполнения пробелов в описании предметной области» [29]. На рис. 7 изображен пример описания процесса с использованием методологии IDEF3.
Рисунок
7 – Описание процесса в методологии
IDEF3
Синтаксис и семантика моделей IDEF3
Основой модели IDEF3 служит сценарий процесса, который описывает последовательность действий или подпроцессов анализируемой системы. Поскольку сценарий определяет назначение и границы модели системы, необходимо тщательно проводить подбор наименования для обозначения действий. Для подбора необходимого имени применяются стандартные рекомендации по предпочтительному использованию глаголов и отглагольных существительных. Например, "Изготовление декораций для спектакля" или "Изменить топологию интеграционной системы нового поколения". Как уже указывалось ранее, важно определить, через кого, через какое «действующее лицо» будет рассматриваться процесс. Точка зрения для большинства моделей должна быть явным образом документирована. Обычно это название набора должностных обязанностей человека, являющегося источником информации о моделируемом процессе.
Для системного аналитика также важно понимание цели моделирования – набора вопросов, ответами на которые будет служить модель, границ моделирования (какие части системы войдут в модель, а какие не будут в ней отображены) и целевой аудитории (для кого разрабатывается модель) [29].
Диаграммы. Главной организационной единицей модели IDEF3 является диаграмма, отражающая взаимную последовательность диаграмм внутри модели. Информационное наполнение диаграмм должно быть таким, чтобы каждая из них была самодостаточной и в то же время понятной специалисту.
Единица работы. Действие. Аналогично другим технологиям моделрфования действие, или в терминах IDEF3 "единица работы" (Unit of Work – UOW) – другой важный компонент модели. В диаграммах IDEF3 отображают действие в виде прямоугольника. Действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер.
! |
Правило: идентификационный номер не используется повторно, даже если в процессе построения модели действие удаляется. |
Рисунок 8 – Изображение и нумерация действия в диаграмме IDEF3
В диаграммах IDEF3 номер действия обычно предваряется номером его родителя (рис. 8).
Связи. Связи определяют существенные взаимоотношения между действиями.
! |
Правило: Все связи в IDEF3 являются однонаправленными. |
Стрелка связи может начинаться или заканчиваться на любой стороне блока, обозначающего действие. Но следует помнить, что диаграммы IDEF3 обычно организовываются слева направо таким образом, что стрелки начинаются на правой и заканчиваются на левой стороне блоков. В табл. 4.3 приведены три возможных типа связей.
Связь типа "Временное предшествование". Как видно из названия, связи этого типа отражают, что исходное действие должно полностью завершиться, прежде чем начнется выполнение конечного действия. Связь должна быть поименована таким образом, чтобы специалисту, просматривающему модель, была понятна причина ее появления. Во многих случаях завершение одного действия инициирует начало выполнения другого, как показано на рис. 7.
Таблица 4.3. Типы связей в модели IDEF3
Соединения. Завершение одного действия может инициировать начало выполнения сразу нескольких других действий, или, наоборот, определенное действие может требовать завершения нескольких других действий для начала своего выполнения. Соединения разбивают или соединяют внутренние потоки и используются для описания ветвления процесса.
Разворачивающие соединения используются для разбиения потока. Завершение одного действия вызывает начало выполнения нескольких других.
Сворачивающие соединения объединяют потоки. Завершение одного или нескольких действий вызывает начало выполнения только одного другого действия.
В таблице 4.4 приведены три типа соединений и их описания.
Таблица 4.4. Типы соединений в модели IDEF3
Графическое обозначение |
Название |
Вид |
Правила инициации |
& |
Соединение "И" |
Разворачивающее |
Каждое конечное действие обязательно инициируется |
Сворачивающее |
Каждое исходное действие обязательно должно завершиться |
||
Х |
Соединение "Эксклюзив-ное ИЛИ" |
Разворачивающее |
Одно и только одно конечное действие инициируется |
Сворачивающее |
Одно и только одно исходное действие должно завершиться |
||
О |
Соединение "ИЛИ" |
Разворачивающее |
Одно (или более) конечное действие инициируется |
Сворачивающее |
Одно (или более) исходное действие должно завершиться |
Примеры разворачивающих и сворачивающих соединений приведены на рис. 9.
Рисунок 9 – Два вида соединений
Таблица 4.5. Синхронные соединения модели IDEF3
Графическое обозначение |
Тип |
Вид |
Правила инициации |
|
И |
Разворачивающее |
Все действия начнутся одновременно |
Сворачивающее |
Все действия закончатся одновременно |
||
|
ИЛИ |
Разворачивающее |
Может быть, несколько действий начнутся одновременно |
Сворачивающее |
Может быть, несколько действий закончатся одновременно |
||
|
Эксклюзивное ИЛИ |
Разворачивающее |
Одновременное начало действий невозможно |
Сворачивающее |
Одновременное окончание действий невозможно |
! |
Правило: синхронное разворачивающее соединение не обязательно должно иметь парное себе сворачивающее соединение. |
Очень редко начинающиеся одновременно действия оканчиваются также одновременно. Также возможны ситуации синхронного окончания асинхронно начавшихся действий. Зрители, направляющиеся в театр, начинают свое действие из разных точек города, разными маршрутами, но спектакль смотреть они начинают одновременно.
! |
Правило: все соединения на диаграммах должны быть парными. |
! |
Правило: типы соединений вовсе не обязательно должны совпадать. |
Из этого правила следует, что любое разворачивающее соединение имеет парное себе сворачивающее.
На рис. 10 разворачивающее "И"–соединение имеет парное сворачивающее "ИЛИ"–соединение. Соединение J2 интерпретируется следующим образом: после включения пожарной сигнализации и (или) вызова пожарных и (или) начала тушения производится запись в журнал.
Рисунок 10 – Пример комбинации двух типов соединений
Рисунок
11 – Диаграмма IDEF3 с комбинацией соединений
Комбинации соединений. Соединения могут комбинироваться для создания более сложных правил ветвления (рис. 11). Комбинации соединении следует использовать с осторожностью, поскольку перегруженные ветвлением диаграммы могут оказаться сложными для восприятия.
Указатели – это специальные символы, которые ссылаются на другие разделы описания процесса. Они выносятся на диаграмму для привлечения внимания читателя к каким-либо важным аспектам модели.
Указатель изображается на диаграмме в виде прямоугольника, похожего на изображение действия. Имя указателя обычно включает его тип (например, ОБЪЕКТ, UOB и т.п.) и идентификатор.
Декомпозиция действий. Действия в IDEF3 могут быть декомпозированы, или разложены на составляющие, для более детального анализа. Декомпозировать действие можно несколько раз. Это позволяет документировать альтернативные потоки процесса в одной модели.
Таблица 4.6. Типы указателей модели IDEF3
Тип указателя |
Назначение |
ОБЪЕКТ (OBJECT) |
Для описания того, что в действии принимает участие какой-либо заслуживающий отдельного внимания объект |
ССЫЛКА (GOTO) |
Для реализации цикличности выполнения действий. Указатель ССЫЛКА может относиться и к соединению |
ЕДИНИЦА ДЕЙСТВИЯ (Unit of Behavior – UOB) |
Для помещения на диаграмму дополнительного экземпляра уже существующего действия без зацикливания. Например, если действие "Подсчет наличных" выполняется несколько раз, в первый раз оно создается как действие, а последующие его появления на диаграмме оформляются указателями UOB |
ЗАМЕТКА (NOTE) |
Для документирования любой важной информации общего характера, относящейся к изображенному на диаграммах. В этом смысле ССЫЛКА служит альтернативой методу помещения текстовых заметок непосредственно на диаграммах |
УТОЧНЕНИЕ (Elaboration – ELAB) |
Для уточнения или более подробного описания изображенного на диаграмме. Указатели УТОЧНЕНИЕ обычно используются для описания логики ветвления у соединений |
Для корректной идентификации действий в модели с множественными декомпозициями схема нумерации действий расширяется и наряду с номерами действия и его родителя включает в себя порядковый номер декомпозиции. Например, в номере действия 1.2.5: 1 – номер родительского действия, 2 – номер декомпозиции, 5 – номер действия.
Определение сценария, границ моделирования, точки зрения. Перед тем как попросить экспертов предметной области подготовить описание моделируемого процесса, должны быть документированы границы моделирования, чтобы экспертам была понятна необходимая глубина и полнота требуемого от них описания. Кроме того, если точка зрения аналитика на процесс отличается от обычной точки зрения для эксперта, это должно быть ясно и аккуратно описано.
Вполне возможно, что эксперты не смогут сделать приемлемое описание без применения формального опроса автором модели. В таком случае автор должен заранее приготовить набор вопросов таким же образом, как журналист заранее подготавливает вопросы для интервью.
Определение действий и объектов. Результатом работы экспертов обычно является текстовый документ, описывающий интересующий аналитика круг вопросов. В дополнение к нему может иметься письменная документация, позволяющая пролить свет на природу изучаемого процесса. Вне зависимости от того, является ли информация текстовой или вербальной, она анализируется и разделяется частями речи для идентификации списка действий (глаголы и отглагольные существительные), составляющих процесс, и объектов (имена существительные), участвующих в процессе.
В некоторых случаях возможно создание графической модели процесса в присутствии экспертов. Такая модель также может быть разработана после сбора всей необходимой информации, что позволяет не отнимать время экспертов на детали форматирования получающихся диаграмм.
! |
Таким образом, методология IDEF3 – это методология моделирования, предназначенная для обеспечения структурированного подхода к описанию бизнес-процесса как упорядоченной последовательности событий одновременно с описанием любых участвующих в бизнес-процессе объектов и относящихся к ним правил. |
Создание диаграмм потоков работ – техника, хорошо подходящая для сбора данных о системе и применяющаяся как часть структурного подхода к анализу и проектированию системы. В отличие от других методов моделирования бизнес-процессов, IDEF3 требует строгого использования синтаксиса и семантики во избежание получения неполного или противоречивого описания системы.
Диаграммы IDEF3 применяются:
для улучшения понимания результатов моделирования бизнес-процессов;
для определения момента окончания моделирования;
для сбора информации о схеме работы моделируемой компании.
Построение моделей IDEF3 иногда позволяет упростить функциональное моделирование системы по методологии IDEF0, что позволяет использовать ее как удобный способ анализа потенциальных усовершенствований системы. Диаграммы IDEF3 обеспечивают дискретность моделирования процесса, что может использоваться для контроля за ходом выполнения работ.
Структурный анализ потоков данных (DFD – Data Flow Diagrams)
Назначение диаграмм потоков данных
Диаграммы потоков данных моделируют систему как набор действий, соединенных друг с другом стрелками. Диаграммы потоков данных могут содержать два новых типа объектов:
объекты, собирающие и хранящие информацию – хранилища данных;
объекты, моделирующие взаимодействие с теми частями системы (или другими системами), которые выходят за границы моделирования – внешние сущности.
На рис. 12 приведен внешний вид диаграммы потоков данных.
Рисунок 12 – Пример диаграммы DFD вставить рисунок пришлю вместо этого
В отличие от стрелок в IDEF0, которые иллюстрируют отношения, стрелки в DFD показывают, как объекты (включая и данные) реально перемещаются от одного действия к другому. Это представление потока вместе с хранилищами данных и внешними сущностями обеспечивает отражение в DFD-моделях физических характеристик системы:
движение объектов (потоки данных),
хранение объектов (хранилища данных),
источники и потребители объектов (внешние сущности).
Синтаксис и семантика диаграмм потоков данных
В отличие от IDEF0, рассматривающего систему как множество взаимопересекающихся действий, в названиях объектов DFD-диаграмм преобладают имена существительные. Контекстная DFD-диаграмма может представлять собой один функциональный блок и нескольких внешних сущностей. Тогда функциональный блок обычно имеет имя, совпадающее с именем всей системы (рис. 13).
Добавление на диаграмму внешних ссылок не изменяет фундаментального требования, что модель должна строиться с единственной точки зрения и должна иметь четко определенные цель и границы, что уже обсуждалось ранее.
Рисунок 13 – Контекстная диаграмма DFD
Функциональные блоки. Функциональный блок DFD моделирует некоторую функцию, которая преобразует какое-либо сырье в какую-либо продукцию (или, в терминах IDEF, вход в выход). Хотя функциональные блоки DFD и изображаются в виде прямоугольников с закругленными углами, они почти идентичны функциональным блокам IDEF0 и действиям IDEF3. Как и действия IDEF3, функциональные блоки DFD имеют входы и выходы, но не имеют управления и механизма исполнения как IDEF0.
Внешние сущности. Внешние сущности обеспечивают необходимые входы для системы и/или являются приемниками для ее выходов. Одна внешняя сущность может одновременно предоставлять входы (функционируя как поставщик) и принимать выходы (функционируя как получатель). Внешние сущности изображаются как прямоугольники и обычно размещаются у краев диаграммы.
! |
Правило: одна внешняя сущность может быть размещена на одной и той же диаграмме в нескольких экземплярах. |
Этот прием полезно применять для сокращения количества линий, соединяющих объекты на диаграмме.
Стрелки (потоки данных). Стрелки описывают передвижение (поток) объектов от одной части системы к другой. Поскольку все стороны обозначающего функциональный блок DFD прямоугольника равнозначны (в отличие от IDEF0), стрелки могут начинаться и заканчиваться в любой части блока. В DFD также используются двунаправленные стрелки, которые нужны для отображения взаимодействия между блоками (например, диалога типа приказ – результат выполнения). На рис. 14 двунаправленная стрелка обозначает взаимный обмен информацией между департаментами информационного сопровождения и маркетинга и рекламы.
Рисунок 14 – Двунаправленный поток между блоком и внешней сущностью
Хранилища данных. В то время как потоки данных представляют объекты в процессе их передвижения, хранилища данных моделируют их во всех остальных состояниях. При моделировании производственных систем хранилищами данных служат места временного складирования, где хранится продукция на промежуточных стадиях обработки. В информационных системах хранилища данных представляют любой механизм, который поддерживает хранение данных для их промежуточной обработки. На рис. 15 приведен пример обозначения хранилищ данных на DFD-диаграммах.
Рисунок 15 – Обозначение хранилища данных на DFD-диаграмме
Ветвление и объединение. Стрелки на DFD-диаграммах могут быть разбиты (разветвлены) на части, и при этом каждый получившийся сегмент может быть переименован таким образом, чтобы показать декомпозицию данных, переносимых данным потоком (рис. 16).
Рисунок 16 – Разветвление стрелки, иллюстрирующее декомпозицию данных
Стрелки могут и соединяться между собой (объединяться) для формирования так называемых комплексных объектов.
Построение диаграмм потоков данных
В работе [29] рассматриваются два подхода к построению DFD-моделей. Диаграммы DFD можно строить с использованием подхода, аналогичного структурному методу анализа и проектирования, применяемому в IDEF0. Вначале строится модель физической реализации реальной системы, которая используется пользователями в настоящее время. Затем создается логическая модель текущего состояния системы для моделирования основных требований существующей системы. После этого создается новая логическая модель для отражения основных параметров предлагаемой разрабатываемой системы. Наконец, создается новая физическая модель, реализующая логическую модель новой системы.
В настоящее время при разработке информационных систем завоевывает все большую популярность альтернативный подход, известный как разделение событий, в котором для моделирования системы строится несколько моделей DFD. Вначале строится логическая модель, отображающая систему как набор действий и описывающая, что должна делать система. Затем строится модель окружения, описывающая систему как объект, отвечающий на события, порождаемые внешними сущностями. Такая модель обычно состоит из описания назначения системы, одной диаграммы контекстного уровня и списка событий. Контекстная диаграмма содержит один функциональный блок, представляющий систему в целом, и внешних сущностей (окружения), с которыми система взаимодействует [29].
На заключительном этапе создается модель поведения, показывающая, как система обрабатывает те или иные события. Эта модель начинается с единственной диаграммы с одним функциональным блоком на каждый ответ системы на событие, описанное в модели окружения. Хранилища данных в модели поведения используются для моделирования данных, которые должны сохраняться в промежутках между обработкой событий. Потоки применяются для соединения элементов диаграмм между собой и для проверки согласованности моделей поведения и окружения.
Итак, диаграммы потоков данных (DFD) обеспечивают удобный способ описания передаваемой информации как между частями моделируемой системы, так и между системой и внешним миром. Это качество определяет область применения DFD – они используются для создания моделей информационного обмена организации, например модели документооборота. Кроме того, различные вариации DFD широко применяются при построении корпоративных информационных систем.
Стрелки в DFD показывают, как объекты (данные) фактически взаимодействуют между собой. Это представление, объединяющее хранимые в системе данные и внешние для системы объекты, дает DFD-моделям большую гибкость для отображения физических характеристик системы, таких, как проблемы обмена данными, разработка схем их хранения и обработки.
Методология IDEF3 – это методология моделирования, предназначенная для обеспечения структурированного подхода к описанию бизнес-процесса как упорядоченной последовательности событий одновременно с описанием любых участвующих в бизнес-процессе объектов и относящихся к ним правил.
Создание диаграмм потоков работ – техника, хорошо подходящая для сбора данных о системе и применяющаяся как часть структурного подхода к анализу и проектированию системы. В отличие от других методов моделирования бизнес-процессов, IDEF3 требует строгого использования синтаксиса и семантики во избежание получения неполного или противоречивого описания системы.
Диаграммы IDEF3 применяются:
для улучшения понимания результатов моделирования бизнес-процессов;
для определения момента окончания моделирования;
для сбора информации о схеме работы моделируемой компании.
Построение моделей IDEF3 иногда позволяет упростить функциональное моделирование системы по методологии IDEF0 и получило заслуженное признание как довольно удобный способ анализа потенциальных усовершенствований системы. Диаграммы IDEF3 обеспечивают дискретность моделирования процесса, что может использоваться для контроля за ходом выполнения работ. Временная шкала использования разных методологий моделирования показана на рис. 17.
Рисунок 17 – Временная шкала использования разных методологий моделирования
Стандарт онтологического исследования IDEF5
Параграф написан по материалам работ Бабак В.Ф., Рыженко И.Н. Совершенствование методологии проектирования информационных систем. http://emanual.ru/download/1638.html; Верников Г. Стандарт онтологического исследования IDEF5 / http://www.itrealty.ru
Стандарт онтологического исследования IDEF5 (INTEGRATED DEFintion) представитель семейства государственных стандартов США IDEFx включающих 14 стандартов, представляющих методологии исследования систем в различных отраслях знаний [32].
Исторически, понятие онтологии появилось в одной из ветвей философии, называемой метафизикой, которая изучает устройство реального мира. Основной характерной чертой онтологического анализа является, в частности, разделение реального мира на составляющие и классы объектов (at its joints) и определение их онтологий, или же совокупности фундаментальных свойств, которые определяют их изменения и поведение. Таким образом, естественная наука представляет собой типичный пример онтологического исследования. Например, атомная физика классифицирует и изучает свойства наиболее фундаментальных объектов реального мира, таких как элементарные частицы, а биология, в свою очередь, описывает характерные свойства живых организмов, населяющих планету.
Однако фундаментальные и естественные науки не обладают достаточным инструментарием для того, чтобы полностью охватить область, представляющую интерес для онтологического исследования. Например, существует большое количество сложных формаций или систем, созданных и поддерживаемых человеком, таких как производственные фабрики, военные базы, коммерческие предприятия и т.д. Эти формации представляют собой совокупность взаимосвязанных между собой объектов и процессов, в которых эти объекты тем или иным образом участвуют. Онтологическое исследование подобных сложных систем позволяет накопить ценную информацию об их работе, результаты анализа которой будут иметь решающее мнение при проведении процесса реорганизации существующих и построении новых систем.
Методология IDEF5 обеспечивает наглядное представление данных, полученных в результате обработки онтологических запросов в простой естественной графической форме.
Основные принципы онтологического анализа
Онтологический анализ обычно начинается с составления словаря терминов, который используется при обсуждении и исследовании характеристик объектов и процессов, составляющих рассматриваемую систему, а также создания системы точных определений этих терминов. Кроме того, документируются основные логические взаимосвязи между соответствующими введенным терминам понятиями. В дальнейшем мы не будем делать различия между понятиями и терминами. Результатом этого анализа является онтология системы, или же совокупность словаря терминов, точных их определений взаимосвязей между ними.
Таким образом, онтология включает в себя совокупность терминов и правила, согласно которым эти термины могут быть скомбинированы для построения достоверных утверждений о состоянии рассматриваемой системы в некоторый момент времени. Кроме того, на основе этих утверждений, могут быть сделаны соответствующие выводы, позволяющие вносить изменения в систему, для повышения эффективности её функционирования.
В любой системе существует две основные категории предметов восприятия, такие как сами объекты, составляющие систему (физические и интеллектуальные) и взаимосвязи между этими объектами, характеризующие состояние системы. В терминах онтологии, понятие взаимосвязи, однозначно описывает или, другими словами, является точным дескриптором зависимости между объектами системы в реальном мире, а термины – являются, соответственно, точными дескрипторами самих реальных объектов.
! |
Таким образом, онтология представляет собой некий словарь данных, включающий в себя терминологию и модель поведения системы. |
Процесс построения онтологии, согласно методологии IDEF5 состоит из пяти основных действий:
Изучение и систематизирование начальных условий. Это действие устанавливает основные цели и контексты проекта разработки онтологии, а также распределяет роли между членами проекта
Сбор и накапливание данных. На этом этапе происходит сбор и накапливание необходимых начальных данных для построения онтологии
Анализ данных. Эта стадия заключается в анализе и группировке собранных данных и предназначена для облегчения построения терминологии.
Начальное развитие онтологии. На этом этапе формируется предварительная онтология, на основе отобранных данных.
Уточнение и утверждение онтологии – заключительная стадия процесса.
При построении онтологии, в первую очередь происходит создание списка или базы данных дескрипторов и с помощью них, если их набор достаточен, создается модель системы. Таким образом, на начальном этапе должны быть выполнены следующие задачи:
Создание и документирования словаря терминов.
Описание правил и ограничений, согласно которым на базе введенной терминологии формируются достоверные утверждения, описывающие состояние системы.
Построение модели, которая на основе существующих утверждений, позволяет формировать необходимые дополнительные утверждения.
Что мы имеем в виду под необходимыми дополнительными утверждениями? Дело в том, что при рассмотрении каждой системы существует огромное количество утверждений, достоверно отображающих ее состояние в различных разрезах, а построенная онтологическим способом модель должна выбирать из них наиболее полезные для эффективного рассмотрения в том или ином контексте. Дополнительно, эта модель помогает описывать поведение объектов и соответствующее изменение взаимосвязей между ними, или, другими словами, поведение системы.
Таким образом, онтология представляет собой некий словарь данных, включающий в себя и терминологию, и модель поведения системы.
Язык описания онтологий в IDEF5
Для поддержания процесса построения онтологий в IDEF5 существуют специальные онтологические языки: схематический язык (Schematic Language-SL) и язык доработок и уточнений (Elaboration Language-EL). SL является наглядным графическим языком, специально предназначенным для изложения компетентными специалистами в рассматриваемой области системы основных данных в форме онтологической информации. Этот несложный язык позволяет естественным образом представлять основную информацию в начальном развитии онтологии и дополнять существующие онтологии новыми данными. EL представляет собой структурированный текстовой язык, который позволяет детально характеризовать элементы онтологии.
Язык SL позволяет строить разнообразные типы диаграмм и схем в IDEF5. Основная цель всех этих диаграмм – наглядно и визуально представлять основную онтологическую информацию.
Таблица 4.7 – Схематические графические изображения IDEF5
Обозначения классов, отдельных элементов |
Обозначение взаимосвязей и изменения состояния |
Обозначение процессов, соединений и перекрестков |
Обозначение класса:
Обозначение отдельного элемента:
|
Обозначение первичных взаимосвязей: 1) Взаимосвязь многие со многими
2) Взаимосвязь двух классов
Обозначение вторичных взаимосвязей между двумя классами:
Обозначения изменения состояния: 1) Медленное изменение
2) Быстрое изменение
3) Мгновенное изменение
|
Обозначение процесса
Обозначение соединений:
Обозначение перекрестков:
|
Несмотря на кажущееся сходство, семантика и обозначения схематичного языка SL существенно отличается от семантики и обозначений других графических языков. Дело в том, что часть элементов графической схемы SL может быть изменен или вовсе не приниматься во внимание языком EL. Причина этого состоит в том, что основной целью применения SL является создание лишь вспомогательной структурированной конструкции онтологии, и графические элементы SL не несут достаточной информации для полного представления и анализа системы, тем самым они не предназначены для сохранения при конечном этапе проекта. Тщательный анализ, обеспечение полноты представления структуры данных, полученных в результате онтологического исследования, являются задачей применения языка EL.
Виды схем и диаграмм IDEF5
Как правило, наиболее важные и заметные зависимости между объектами всегда являются преобладающими, когда конкретные люди высказывают свои знания и мнения, касающиеся той или иной системы. Подобные взаимосвязи явным образом описываются языками IDEF5. Всего существует четыре основных вида схем, которые наглядно используются для накопления информации об онтологии в достаточно прозрачной графической форме.
Диаграмма классификации. Диаграмма классификации обеспечивает механизм для логической систематизации знаний, накопленных при изучении системы. Существует два типа таких диаграмм:
диаграмма строгой классификации (Description Subsumption – DS)
диаграмма естественной или видовой классификации (Natural Kind Classification – NKC).
Рисунок 18 – Виды диаграмм IDEF5: диаграмма строгой классификации (слева) и диаграмма естественной классификации (справа)
Основное отличие диаграммы DS заключается в том, что определяющие свойства классов высшего и всех последующих уровней являются необходимым и достаточным признаком принадлежности объекта к тому или иному классу. На рисунке 18 приведен пример такой диаграммы, построенной на основе тривиальной возможности классификации многоугольников по количеству углов.
Из геометрии известно точное математическое определение многоугольника, суть определяющих свойств родительского класса. Определяющим свойством каждого дочернего класса дополнительно является количество углов в многоугольнике. Очевидно, зная это определяющее свойство для любого многоугольника, можно однозначно отнести его к тому или иному дочернему классу. С помощью диаграмм DS, как правило, классифицируются логические объекты.
Диаграммы естественной классификации или же диаграммы NKC, наоборот, не предполагают того, что свойства класса являются необходимым и достаточным признаком для принадлежности к ним тех или иных объектов. В этом виде диаграмм определение свойств класса является более общим. Пример такой диаграммы также приведен на рис.18.
Композиционная схема. Композиционные схемы (Composition Schematics) являются механизмом графического представления состава классов онтологии и фактически представляют собой инструменты онтологического исследования по принципу "Что из чего состоит". В частности, композиционные схемы позволяют наглядно отображать состав объектов, относящихся к тому или иному классу. На рисунке 19 изображена композиционная схема шариковой ручки, относящейся к классу шариковых автоматических ручек. В данном случае шариковая ручка является системой, к которой применяем методы онтологического исследования. С помощью композиционной схемы можно наглядно документировать, что авторучка состоит из нижней и верхней трубки,
Рисунок 19 – Пример композиционной схемы
нижняя трубка в свою очередь включает в себя кнопку и фиксирующий механизм, а верхняя трубка включает в себя стержень и пружину.
Схема взаимосвязей. Схемы взаимосвязей (Relation Schematics) позволяют разработчикам визуализировать и изучать взаимосвязи между различными классами объектов в системе. В некоторых случаях схемы взаимосвязей используются для отображения зависимостей между самими же классовыми взаимосвязями. Мотивацией для развития подобной возможности послужило то тривиальное правило, что все вновь разработанные концепции всегда базируются на уже существующих и изученных. Это тесно согласуется с теорией Новака и Гоуэна (Novak & Gowin, 1984), суть которой в том, что изучение любой системы часто происходит от частного к общему, то есть, происходит изыскание и исследование новой частной информации, влияющее на конечные характеристики более общей концепции, к которой эта информация имела прямое отношение. Исходя из этой гипотезы, естественным образом изучения новой или плохо понимаемой взаимосвязи является соотнесение ее с достаточно изученной взаимосвязью, для исследования характеристик их сосуществования.
Диаграмма состояния объекта. Диаграмма состояния объекта (Object State Schemantic) позволяет документировать тот или иной процесс с точки зрения изменения состояния объекта. В происходящих процессах могут произойти два типа изменения объекта: объект может поменять свое состояние или класс. Между этими двумя видами изменений по сути не существует принципиальной разницы: объекты, относящиеся к определенному классу K в начальном состоянии в течение процесса могут просто перейти к его дочернему или просто родственному классу. Например, полученная в процессе нагревания теплая вода, уже относится не к классу ВОДА, а к его дочернему классу ТЕПЛАЯ ВОДА. Однако при формальном описании процесса, во избежание путаницы, целесообразно разделять оба вида изменений, и для такого разделения используется обозначения следующего вида: "класс: состояние". Например, теплая вода будет описываться следующим образом: "вода: теплая", холодная – "вода: холодная" и так далее. Таким образом, диаграммы состояния в IDEF5 наглядно представляют изменения состояния или класса объекта в течение всего хода процесса. Пример такой диаграммы приведен на рис.20.
Рисунок 20 – Пример диаграммы состояния
Суммируя вышеизложенное, еще раз отметим, что строение и свойства любой системы могут быть эффективно исследованы и задокументированы при помощи следующих средств: словаря терминов, используемых при описании характеристик объектов и процессов, имеющих отношение к рассматриваемой системе, точных и однозначных определений всех терминов этого словаря и классификации логических взаимосвязей между этими терминами.
Набор этих средств, по сути, и является онтологией системы, а стандарт IDEF5 предоставляет структурированную методологию, с помощью которой можно наглядно и эффективно разрабатывать, поддерживать и изучать эту онтологию.
?
Вопросы по четвертому разделу.
Когда и для чего используют технологии IDEF0, IDEF3, DFD?
Расскажите о синтаксисе и структуре технологий IDEF0.
Расскажите о синтаксисе и структуре технологий IDEF3.
Расскажите о синтаксисе и структуре технологий DFD.
Что из себя представляет онтология?
Назовите типы онтологических диаграмм.
ИФ
Вопрос о научном подходе к управлению сложными системами впервые в конкретном виде был поставлен А. М Ампером (1735 – 1876) в его работе «Исследование философии наук, или аналитическое изложение классификации всех человеческих знаний», в которой была выделена наука об управлении государством, названная кибернетикой [36].
ИФ
Полноценные системные идеи появились вместе с возникновением новой науки – социологи. Так, французский мыслитель Огюст Конт (1851-1854) одним из первых социологов широко применял термины «социальная система» для обозначения социальной реальности наряду с терминами «общество», «социальный организм», «социальные явления», «социальное существование» и т.п. [36].
ТЕМАТИЧЕСКИЙ ПЛАН ДИСЦИПЛИНЫ
Дисциплина "Системный анализ и моделирование информационных процессов и систем" относится к общепрофессиональному модулю базовой части дисциплин по направлениям подготовки магистров «Информационные системы и технологии», «Прикладная информатика», «Интеллектуальные системы в гуманитарной среде». На нее отводится 144 часа, что составляет 4 зачетные единицы. Эти часы распределяются на лекции – 16 часов, на лабораторные работы – 68 часов и самостоятельную работу магистрантов – 60 часов.
Необходимыми условиями для освоения дисциплины являются: знание основ теории систем, их развития, приобретенные в бакалавриате, умения применять математическое моделирование и теорию принятия решений, использовать техническую документацию к программным системам и стандартам в области программирования интеллектуальных систем.
Содержание дисциплины является логическим продолжением содержания дисциплин «Математическое моделирование и теория принятия решений», «Методология организации проектирования и разработки информационных систем» и служит основой для освоения дисциплин вариативной части.