Рекомендации по моделированию предметных областей

Реализация моделей бизнес - процесса заданной предметной области.

Формирование требований к модели.

Инструменты реализации задач

Методы реализации задач

Технология реализации проекта

Анализ применяемых в работе методов и программных средств

Анализ возможностей применения программных средств для анализа и проектирования бизнес - процессов

Анализ основных процессов предметной области.

Детальное обследование и анализ предметной области

1.1. Описательная характеристика предметной области (объектно – субъектный состав).

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

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

Во второй главе описываются основные этапы разработки модели, методы и средства проектирования. В конце главы делаются четкие и конкретные выводы.

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

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

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

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

Задача по разработке модели процесса с помощью метода моделирования бизнес – процессов IDEF0 реализуется с помощью программного продукта CA ERwin Modeling Suite (CA ERwin Process Modeler (BPwin) в нотации IDEF0. Результатом выполнения задачи является модель соответствующего процесса в нотации IDEF0.

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

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

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

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

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

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

3. Передача информации. В IDEF0 существует ряд средств, разработанных для улучшения передачи информации:

- диаграммы, основанные на очень простой графике блоков и дуг,

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

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

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

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

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

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

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

- связность интерфейса диаграмм (номера узлов, номера блоков, C-номера);

- связность структуры данных (ICOM-коды и использование туннельных дуг);

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

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

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

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

- требования к меткам дуг данных (правила минимальных меток);

- минимальное управление для функций (для каждой функции нужна, по крайней мере, одна управляющая дуга;

- цель и точка зрения (у каждой модели есть цель и точка зрения).

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

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

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

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

Блоки на диаграммах изображаются прямоугольниками и сопровождаются текстами на естественном языке, описывающим функции. При этом каждая сторона блока имеет вполне определенное назначение: левая сторона предназначена для Входов (Input – I), верхняя – для Управления (Control – C), правая – для Выходов (Output – O), нижняя – для Механизмов (Исполнителей) (Mechanism – M).

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

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

Рисунок 1 - Пример IDEF0-диаграммы (контекстный блок)

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

Рисунок 2 - Декомпозиция диаграммы (контекстного блока)

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

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

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

Дуги в IDEF0 представляют наборы предметов (данных) и маркируются текстами на естественном языке. Данные могут состоять с функциями в четырех возможных отношениях: Вход, Выход, Управление, Механизм.

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

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

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

Создание функциональных моделей и диаграмм происходит в следующей последовательности:

1. Сбор информации.

2. Декомпозиция объекта исследования.

3. Моделирование:

3.1. Выбор цели о точки зрения.

3.2. Составление списка данных.

3.3. Составление списка функций.

3.4. Построение и обобщение диаграммы А0(А0 – А-0).

3.5. Декомпозиция ограниченного объекта.

3.6. Итерационный процесс рецензирования.

3.7. Завершение моделирования.

3.8. Документирование.

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

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

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

Цель и точка зрения модели определяется на самой ранней стадии создания модели. Выбор цели осуществляется с учетом вопросов, на которые должна ответить модель, а выбор точки зрения – в соответствии с выбором позиции, с которой описывается модель. Если выбор цели и точки зрения затруднен, то можно вначале построить диаграммуА0, и с ее помощью установить это. Иногда приходится строить несколько альтернативных диаграмм А-0 для достаточной уверенности в правильности выбранной цели и точки зрения.

Помочь могут списки данных и списки функций. При этом лучше, если данных больше, чем меньше. Данные можно сразу группировать по типам. Функции системы тоже лучше объединить по типу используемых данных. Затем функции объединяются в группы (от 3 до 6) Желательно, чтобы эти группы имели один и тот же уровень сложности, содержали примерно одинаковый объем действий и функции в каждой из них имели сходные операции и цели.

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

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

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

Начало процесса декомпозиции заключается в выборе блока рассматриваемой диаграммы и рассмотрении объекта, определяемого этим блоком и его дугами. При этом надо учесть, что рассматривать следует в первую очередь такой блок, декомпозиция которого выявит многие аспекты диаграммы А0 и будет оказывать большее влияние на будущие декомпозиции других блоков этой системы. При выборе самого содержательного блока нужно учесть и доминирование, и функциональную сложность и понятность. Лучшим блоком для первой декомпозиции будет тот, который позволит наиболее глубоко проникнуть в суть рассматриваемой системы. Детализация блока производится путем составления списка данных и списка функций и последующего построения диаграммы. Если Вы сомневаетесь, стоит ли включать некоторые блоки и дуги в диаграмму, то лучше ее включить, снабдив соответствующими записями.

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

Одна из самых важных проблем, возникающих при моделировании – когда следует завершить построение конкретной модели. IDEF0-модели иерархичны и поэтому их размер может увеличиваться со скоростью геометрической прогрессии. Хотя многие IDEF0-модели имеют глубину 5-6 уровней, они чаще всего состоят не более чем из нескольких десятков диаграмм. Декомпозиция модели или ее части прекращается, если модель достигла уровня детализации, достаточного для достижения цели. Декомпозиция блока может быть прекращена, если окажется, что функции блока очень сходны с другой частью модели, которая уже декомпозирована. Таким образом, достаточность деталей, изменение уровня абстракции, изменение точки зрения и сходная функциональность являются основными критериями для прекращения декомпозиции.

Дата добавления: 2015-06-29