Основные функции отдела сбыта заключаются в реализации автомобилей и ведении их учета. Деятельность отдела сбыта регулирует начальник отдела сбыта, который осуществляет руководство по развитию и функционированию, организовывает подготовку и проводит внутренние проверки, анализирует их результаты, контролирует выполнение корректирующих мероприятий.
Менеджер по продажам осуществляет связь между покупателем и производителем товаров или услуг. Главная задача менеджера по продажам - реализация товара. Продавцы-консультанты - это специалисты по консультационным продажа. Консультационные продажи предполагают информационное сопровождение клиента, ведение переговоров с клиентами всех уровней, обслуживание покупателей в соответствии с технологиями продаж, оказание консультационной помощи покупателям относительно свойств, характеристик товаров, расчет итоговой стоимости покупки.
Описание бизнес-процессов учета реализации автомобилей
Организация учета реализации автомобилей в автосалоне предполагает следующие бизнес-процессы:
1. Заказ автомобиля - после выбора автомобиля оформляется заказ на выбранную модель, подготавливается и отправляется запрос на завод - изготовитель, принимается предоплата и выдается квитанция о предоплате;
2. Прием автомобиля - принятие автомобиля на внутренний учет, проведение предпродажной подготовки и диагностики автомобиля, оповещение покупателя;
3. Реализация автомобиля - осмотр автомобиля покупателем, оформление договора купли-продажи;
4. Регистрация оплаты;
5. Формирование отчетных документов:
Формирование отчета «Прайс-лист»;
Формирование отчета «Анализ продаж»;
Формирование отчета «Заказы автомобилей»;
Формирование отчета «Состояние заказов».
Для формализованного описания вышеописанных бизнес-процессов построим функциональную модель IDEF0. Основной структурной единицей IDEF0-модели является диаграмма, представляющая собой графическое описание модели предметной области или ее части. Главными компонентами IDEF0-диаграммы являются блоки. Каждый блок диаграммы соответствует некоторой функции, для которой необходимо определить исходные данные, результат, управляющую функцию и механизм ее реализации. Взаимодействие функций с внешним миром и между собой описывается с помощью дуг (связей). В IDEF0 различают пять типов дуг:
1) Вход - материал или информация, которые используются или преобразуются блоком для получения результата (выхода);
2) Выход - результат выполнения функции (материал или информация);
3) Управление - условия, правила, стандарты, которые влияют на выполнение функции;
4) Механизм - ресурсы, с помощью которых выполняется работа;
5) Вызов - специальная дуга, указывающая на другую модель предметной области.
На рисунках 1.3 (а, б, в) представлена IDEF0-модель «Информационная система автосалона», декомпозированная на 3 подуровня. На первом уровне блок А0 отвечает за реализацию автомобилей на основе следующих данных: заказ клиента и поставщик автомобилей. В результате на выходе получаем выполненный заказ. В качестве управления выступают: законодательство РФ, лицензия на продажу, каталог автомобилей. Механизм - Автосалон «AlongTheRoad».
Рисунок 1.3 (а)
При декомпозиции (рис. 1.3(б)) блок А0 разбивается на 4 блока: А1, А2, А3, А4. В блоке А1 формируется план закупок, руководствуясь входными данными заказ клиента, поставщик автомобилей. Блок А2 - Договор с поставщиками соединяется с блоком А3 - Формирование каталога автомобилей. Блок А4 отвечает за сбыт автомобилей, на выходе - выполненный заказ. Механизмами выступают: отдел по закупке автомобилей, юридический отдел, отдел рекламы и PR, отдел бухгалтерии, отдел сбыта автомобилей. Таким образом, выделили 4 подзадачи, произведя детализацию первого уровня.
Рисунок 1.3 (б) - Диаграмма декомпозиции
Перейдем на 3 уровень декомпозиции блока А4 - Сбыт автомобилей (рис. 1.3(в)). Диаграмма представлена тремя блоками: А41 - Принятие заявки, А42 - Оформление договора, А43 - Продажа автомобиля. В качестве управления остаются те же стандарты и правила, что и на первом уровне, на выходе получаем выполненный заказ.
Рисунок 1.3 (в) - Диаграмма декомпозиции
Исследование информационных потоков
В результате анализа деятельности отдела сбыта был выявлен комплекс информационных потоков.
Входные данные:
Сведения о клиентах;
Заказы клиентов;
Сведения об автомобилях;
Данные для формирования отчетов;
Сведения о поставщиках.
Выходные документы:
Отчет «Прайс-лист»;
План закупок;
Договор с поставщиками;
Каталог автомобилей;
Отчет «Анализ продаж»;
Отчет «Заказы автомобилей»;
Отчет «Состояние заказов».
В результате исследования информационных потоков была построена DFD модель, которая показывает, какие информационные потоки возникают при выполнении функций. Она будет применяться при проектировании базы данных. В приложении А представлены диаграммы потоков данных ИС «Автоматизация торговых операций в автосалоне».
Таким образом, целью методологии является построение модели рассматриваемой системы в виде диаграммы потоков данных (DFD). Диаграммы потоков данных предназначены для описания документооборота и обработки информации. При создании диаграммы потоков данных используются четыре основных понятия:
– Потоки данных;
– Процессы (работы) преобразования входных потоков данных в выходные;
– Внешние сущности;
– Накопители данных (хранилища).
Потоки данных являются абстракциями, использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации.
Процессы (работы) служат для преобразования входных потоков данных в выходные. Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели. Хранилище (накопитель) данных моделирует данные, которые будут сохраняться в памяти между процессами. Информация, которую содержит хранилище, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником данных.
Отчет о проведении научно-исследовательской работы «разработка методических рекомендаций по описанию и оптимизации процессов в органах исполнительной власти в рамках подготовки внедрения эар»
ОтчетЭЛЕКТРОННЫЙ АДМИНИСТРАТИВНЫЙ РЕГЛАМЕНТ, АДМИНИСТРАТИВНЫЙ РЕГЛАМЕНТ, ДОЛЖНОСТНОЙ РЕГЛАМЕНТ, АДМИНИСТРАТИВНО-УПРАВЛЕНЧЕСКИЙ ПРОЦЕСС, ОПИСАНИЕ АДМИНИСТРАТИВНО-УПРАВЛЕНЧЕСКИХ ПРОЦЕССОВ,
управление процессами
ДокументПозняковский Валерий Михайлович – директор НИИ биотехнологии и сертификации, зав. кафедры биотехнологии, товароведения и управления качеством Кемеровского технологического института пищевой промышленности,
Технологии защиты информации в сети Курс лекций Введение В данном курсе изложены теоретические основы криптографии и вопросы сетевой безопасности Предназначено для чтения курса «Технологии защиты информации в сети» Содержание
ОбзорИнформационные технологии в профессиональной деятельности
Учебно-методический комплексУчебно-методический комплекс по учебной дисциплине «Информационные технологии в профессиональной деятельности» для специальности 030503.52 – «Правоведение» среднего профессионального образования.
Учебно-методический комплекс по дисциплине «информационные технологии в бизнес-планировании»
Учебно-методический комплекс-
Цель - создание контекстной диаграммы функциональной модели деятельности автосалона с помощью All Fusion PM.
Технология работы
- 1. Запустите All Fusion PM. (Кнопка Start/All Fusion PM ).
- 2. Если появляется диалоговое окно ModelMart Connection Manager , нажмите на кнопку Cancel .
- 3. Щелкните по кнопке. Появляется диалоговое окно I would like to . Внесите имя модели «Деятельность компании » и выберите Туре - IDEF0. Нажмите ОК.
- 4. Автоматически создается контекстная диаграмма.
- 5. Создайте стрелки на контекстной диаграмме.
- 6. Создайте отчет по модели. Меню Tools/Reports/Model Report .
Рис. 1
Рис. 2 Отчет по модели автосалона
Создание диаграмм декомпозиции в стандарте IDEF0
Цель - научиться создавать диаграммы декомпозиции функциональной модели деятельности салона в стандарте IDEF0 с помощью All Fusion PM 4.0.
В IDEF0 существуют соглашения по рисованию диаграмм, которые призваны облегчить чтение и экспертизу модели. Некоторые из этих правил All Fusion PM поддерживает автоматически, выполнение других следует обеспечить вручную.
Технология работы
1. Выберите кнопку перехода на нижний уровень в палитре инструментов и в окне Activity Box Count установите число работ на диаграмме нижнего уровня - 3 и нажмите ОК.
Автоматически будет создана диаграмма декомпозиции. Правой кнопкой мыши щелкните по работе, выберите Name и внесите имя работы. Повторите операцию для всех трех работ. Затем внесите определение, статус и источник для каждой работы.
- 2. Перейдите в режим рисования стрелок. Свяжите граничные стрелки (кнопка на палитре инструментов).
- 3. Альтернативный метод внесения имен и свойств стрелок - использование словаря стрелок (меню Dictionary/Arrow ).
- 4. Создайте новые внутренние стрелки.
- 7. Создайте новую граничную стрелку выхода
Рис. 3 Диаграмма декомпозиции IDEF0 первого уровня
Жизненный цикл разработки информационной системы
В процессе создания информационная система проходит несколько стадий, начиная от ее задумки и заканчивая внедрением. В рамках курса «Базы данных и информационные технологии» наибольший интерес представляет первые два - проектирование и разработка. Давайте разберемся, что стоит за каждым из пунктов, перечисленных на слайде.
- Исследование и анализ. Главной задачей информационной системы является удовлетворение информационных потребностей бизнеса. Поэтому на первом этапе важно разобраться как протекают бизнес-процессы внутри организации, на какие потоки информации они опираются. Чаще всего это происходит в виде интервью с представителями разных отделов предприятия. На этом этапе важно получить исчерпывающую картину работы предприятия в формате который будет с одной стороны понятен разработчикам, а с другой - представителям бизнеса. На этом этапе нам на помощь могут прийти методологии IDEF0 и DFD, которые будут рассмотрены в этой лекции.
- Прототипирование . На этом этапе моделируется структура информационной системы, структура хранилищ данных, пользовательские интерфейсы.
- Построение и документирование. На этом этапе происходит согласование прототипа системы с требованиями заказчика. Поведение информационной системы детально документируется, для того чтобы в дальнейшем можно было сравнить ожидаемое и полученное поведение системы.
- Внедрение. На этом этапе выполняется верификация соответствия реального и ожидаемого поведения системы. Зачастую это происходит в виде пиремо-сдаточных испытаний.
- Использование. Этот этап разработки информационной системы рассматривается дисциплиной Техническая поддержка программных решений (Technical Solution Support). Он характеризуется гарантийным и послегарантийным обслуживанием информационной системы. Примером такого обслуживания может быть исправление ошибок, внесение новых функций, повышение производительности, обучение персонала и прочее.
Стоит заметить, что разработка может затрагивать как весь продукт, так и происходить итеративно - добавляя с каждым этапом новые функции или модули к существующему ядру системы. При этом все этапы с первого по пятый повторяются для каждой из иттераций.
Одним из важных понятий при разработке программного обеспечения является «концептуальная модель».
Концептуальная модель - это абстрактная модель, определяющая структуру моделируемой системы, свойства её элементов и причинно-следственные связи, присущие системе и существенные для достижения цели моделирования.
При этом «концептуальная модель» это:
- результат абстрагирования части реального мира - все факты,которые не влияют на порядок функционирования моделируемой системы отбрасываются;
- описание моделируемого объекта в принятой нотации, то есть с использованием некоторой системы правил и обозначений, которые понятны как разработчику так и аналитику и не вызывают между ними недопонимания;
- описание моделируемого объекта, присущих ему бизнес-правил и потоков, и хранилищ данных.
Методология IDEF0
Одной из распространенных методологий построения концептуальных моделей является IDEF0.
Методология IDEF0 описывает процессы движения и обработки информации звеньями моделируемого объекта с точки зрения их функционального назначения. Например, отделами предприятия.
IDEF0 - это подмножество SADT (Structured Analisys and Design Technique). Методология SADT разрабатывалась Дугласом Т. Россом в 1969-1973 годах и изначально применялась для проектирования систем общего назначения. В данной методологии ключевым является в какую из сторон процесса направлен поток управления.
Поясним суть методологии IDEF0 на примере производства товара. Процесс производства условно изображен на слайде.
Здесь слева представлены ингредиенты, которые используют для производства товара, сверху - инструкции, регламентирующие процесс производства, внизу инструменты, которые используют в процессе производства, а справа - готовый товар.
В терминах IDEF0 моделируемое информационной системой производство представляется блоком и дугами, как показано на слайде.
В блоке отражена главная функция моделируемого информационной системой производства, дуги - множество объектов, участвующих и являющихся результатом производства: информация или действия. Место соединения дуги с блоком определяет тип интерфейса.
Правила интерпретации модели:
- функциональный блок (функция) преобразует входные объекты в выходные;
- управление определяет, когда и как это преобразование может или должно произойти;
- исполнитель осуществляет это преобразование
- с дугами связываются метки на естественном языке, описывающие данные, которые они представляют. Дуги показывают, как функции системы связаны между собой, как они обмениваются данными и осуществляют управление друг другом. Выходы одной функции могут быть входами, управлением или исполнителями другой;
- дуги могут разветвляться и соединяться. Ветвление означает множественность (идентичные копии одного объекта) или расщепление (различные части одного объекта). Соединение означает объединение или слияние объектов.
Каждый блок IDEF0-диаграммы может быть представлен несколькими блоками, соединенными интерфейсными дугами, на диаграмме следующего уровня. Эти блоки представляют подфункции (подмодули) исходной функции. Каждый из подмодулей может быть декомпозирован аналогичным образом. Число уровней не ограничивается, однако рекомендуют на одной диаграмме использовать от трех до шести блоков.
Анализ объекта на основе построения его IDEF0-модели является этапом, который должен предварять разработку информационной системы по целому ряду причин. Во-первых, при ознакомлении с объектом строят модель "КАК ЕСТЬ". Такая модель фиксирует бизнес процессы и используемые ими информационные потоки. Во-вторых, функциональная модель "КАК ЕСТЬ" позволяет увидеть информационно перегруженные бизнес процессы - "узкие" места обследуемого объекта. В-третьих, на основании модель "КАК ЕСТЬ" можно построить модель "КАК БУДЕТ". То есть предложить более совершенную структуру организации объекта. Но это уже вопросы реинжиниринга и мы их не будем касаться. Можно только отметить, что реинжиниринг подчеркивает важную роль информационных технологий в жизни общества. В-четвертых, в процессе построения модели "КАК ЕСТЬ" выявляются бизнес-правила - положения, которые регламентируют процесс функционирования моделируемого объекта. Например, представленный на слайде фрагмент функциональной модели должен быть зафиксирован бизнес-правилом: "служба снабжения обязана определять потребности в материалах для производства готовой продукции только на основании плана выпуска".
И последнее. Очевидно, что IDEF0-модель - это лучший способ совместно с заказчиком разработать модель функционирования его фирмы. Дело в том, что такая нотация (описание с помощью прямоугольников и стрелок) понятна и заказчику и исполнителю.
После этапа моделирования исследуемого объекта наступает этап физической реализации этой модели в виде информационной системы. И тут возникает естественный вопрос об адекватности отображения. Другими словами, как представить в информационной системе, например, управляющие потоки. Хотя понятно, например, что потоки данных в информационной системе будут реализованы как хранилища данных, то есть файлы.
Методология Data Flow Diagram
Тот факт, что IDEF0-модель не разделяет потоки данных на материальные, информационные и управляющие приводит разработчиков к необходимости использовать диаграммы потоков данных (Data Flow Diagrams - DFD ). Это можно делать после составления IDEF0-модели, либо вместо этого в зависимости от сложности моделируемого объекта или предпочтений исполнителя.
Основы методологии построения диаграмм потоков данных DFD были описаны в 1979 году C. Gane и T. Sarson в книге "Structured Systems Analysis".
Ее назначение - ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда.
Методология DFD оперирует 4 типами объектов. Их графическое представление представлено на слайде. Обратите внимание, что существует несколько нотаций в рамках методологии DFD. Графическое представление элементов в них несколько отличается. Но внутренне содержание остается неизменным. Давайте разберемся с типами объектов, которые используются в рамках DFD.
- External Entity ( Внешняя сущность ) представляет собой материальный предмет или физическое лицо, представляющее собой источник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность. Внешняя сущность обозначается квадратом, расположенным как бы "над" диаграммой и бросающим на нее тень, для того, чтобы можно было выделить этот символ среди других обозначений.
- Process ( Процессы , Системы и подсистемы) - при построении модели сложной ИС она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем. Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д.
- Datastore ( Хранилище данных ) представляет собой абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
- Dataflow ( Поток данны х) определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т.д. и т.п.
Аналогично IDEF0, для удобства DF-диаграммы разделяют на уровни.
При этом на нулевом уровне отображаются только один процесс (который представляет всю моделируемую ИС), внешние сущности и потоки данных между ними. Задача этого уровня установить - какие потоки данных передаются в/из системы. Хранилища данных при этом не моделируются.
На 1 уровне выделяются основные компоненты системы. С 0-го уровня сюда переносятся все потоки данных. Диаграмма дополняется потоками данных внутри системы и хранилищами данных.
Внешние сущности:
- объекты взаимодействующий с системой, но не относящийся к ней (поставщики и потребители информации, те для кого информационная система строится и кто задействован при работе с ней);
- должны быть отображены на уровнях 0 и 1 DF-диаграммы;
- не должны присутствовать на уровнях 2(3, …) диаграммы;
- должны иметь содержательное имя;
- могут иметь дубликаты на диаграмме.
Процессы:
- описывают действия с информацией;
- должны быть представлены на всех уровнях диаграммы:
- Уровень 0 - один процесс, описывающий систему;
- Уровень 1+ -рекомендуется размещать не более 7 процессов;
- дубликаты (процессы с одинаковым именем или содержанием) не допускаются.
Хранилища данных:
- указывает вид информации которые хранятся в системе (товары, накладные, персонал);
- не отображаются на уровне 0;
- все хранилища данных, которые есть в ИС должны быть указаны на уровне 1.
Потоки данных:
- отображают направление передачи данных;
- отображаются на всех уровнях диаграммы;
- должны иметь содержательное имя.
Алгоритм построения диаграммы
- Определите входящие запросы или события, на которые должна реагировать система. Определите что система отвечает на них.
- Определите кто формирует эти запросы и получает ответ (это внешние сущности).
- Постройте диаграмму уровня 0 - на ней отображены только внешние сущности и главный процесс системы.
- Постройте диаграмму уровня 1 - на ней должны быть отображены все внешние сущности, все хранилища данных, главные процессы и потоки информации между ними.
- Проанализируйте и оптимизируйте диаграмму уровня 1. Рекомендуется на одном уровне диаграммы размещать 7±2 процесса.
- Если требуется, детализируйте отдельные процессы на уровне 2(3,4 …).
Типичные ошибки построения DF-диаграмм
У каждого процесса, хранилища данных, внешней сущности и потока данных должно быть имя.
На DFD диаграмме не отображаются точки начала и окончания, решения(if) и циклы.
Внешние сущности не могут быть связаны потоками информации (это выходит за рамки моделируемой системы)
Внешние сущности не могут напрямую обращаться к хранилищам данных
Хранилище данных не может напрямую обращаться к другому хранилищу. Между ними должен быть процесс.
Избегайте хранилищ в которые только записывается или только читается информация. Нужна ли в системе информация, которая не используется?
На диаграмме не должно быть несоединенных объектов. Если такой объект появляется, то вы либо не учли все потоки данных, либо объект можно безболезненно удалить.
Избегайте процессов которые не имеют входящих потоков информации.
Избегайте процессов которые не имеют исходящих потоков информации.
Давайте построим DF-диаграмму для информационной системы риэлтерской конторы.
Фирма функционирует следующим образом:
- Заказчики могут оставлять заявки на аренду.
- Менеджер подыскивает надвижимость и готовит проект договора.
- Клиент подписывает договор.
Строя DF-диаграмму нулевого уровня необходимо отобразить все основные хранилища данных и все внешние сущности. Диаграмма должна быть построена так, чтобы она отвечала на основные вопросы: "Как работает моделируемый объект?", "Откуда поступают эти данные?", "Какой процесс использует эти данные?" и т.д.
При построении DFD-диаграмм нижних уровней необходимо соблюдать принцип "вертикального балансирования" - ввод или вывод данных не может быть произведен, если этого не делает родитель.
Приведем пример DFD-диаграммы некоторой риелтерской конторы, которая специализируется на заключении договоров аренды жилых помещений.
Диаграмма построена в предположении, что круг клиентов конторы относительно стабилен.
Как видно из контекстной диаграммы первого уровня внешние сущности - это потенциальные Арендатор и Владелец . Поскольку элементами контекстной диаграммы являются одноименные хранилища: Арендатор и Владелец , то можно усомниться в правильности определения внешних сущностей. Но, так как потенциальные Арендатор и Владелец могут быть арендатором и владельцем лишь после заключения договора, то конфликтов с определением здесь нет. Другими словами, это разные сущности.
Для составления договора используют данные хранилищ Арендатор и Владелец . Эти хранилища необходимы по причине того, что круг клиентов риэлтерской конторы относительно стабилен. Не подвержен значительным изменениям и перечень арендуемых объектов недвижимости, что отражает на контекстной диаграмме хранилище Недвижимость .
Наличие на диаграмме процесса "Подготовить договор аренды" - это следствие того, что "черновик" договора аренды готовит клерк, а менеджер принимает решение о заключении договора. Это повышает эффективность работы фирмы в целом.
Роль методологий в анализе моделируемого объекта (Выводы)
В результате анализа моделируемого информационной системой объекта на основе построения IDEF0 и DFD-диаграмм:
Определяют главную функцию проектируемой системы. Например, "сопровождать аренду недвижимости".
Описывают происходящие в моделируемом объекте бизнес процессы.
Например, так:
- заключать договора аренды;
- сопровождать хранение информации об объектах недвижимости.
Определяют обрабатываемые бизнес процессами информационными потоки . Например, так: "отправка договора менеджеру".
Разрабатывают концептуальную модель системы, которая представляет собой описание моделируемого объекта, присущих ему бизнес-правил и потоков и хранилищ данных .
Как видим назначение концептуальной модели объекта:
- прийти к общему с заказчиком представлению о моделируемом объекте;
- представить, в общих чертах, проектируемую информационную систему. Дело в том, что потоки данных - это прообразы процедур приложения, а хранилища данных - таблиц базы данных.
Подводя итог, можно отметить, что построение концептуальной модели системы в соответствии с IDEF0- или DFD-методологией позволяет прийти к общему с заказчиком представлению о проектируемой информационной системе.
Использование UML для проектирования систем
Диаграмма прецедентов позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций .
Каждая такая диаграмма или, как ее обычно называют, каждый Use case - это описание сценария поведения, которому следуют действующие лица (Actors).
Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей программной системе. Отражает объекты, как системы, так и предметной области и задачи, выполняемые ими.
Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть "железа", а не программ. В прямом переводе с английского Deployment означает "развертывание", но термин "топология" точнее отражает сущность этого типа диаграмм.
Для каждой модели создается только одна такая диаграмма, отображающая процессоры (Processor), устройства (Device) и их соединения.
Обычно этот тип диаграмм используется в самом начале проектирования системы для анализа аппаратных средств, на которых она будет эксплуатироваться .
State Maсhine diagram (диаграммы состояний)
Каждый объект системы, обладающий определенным поведением, может находиться в определенных состояниях, переходить из состояния в состояние, совершая определенные действия в процессе реализации сценария поведения объекта. Поведение большинства объектов реальных систем можно представить с точки зрения теории конечных автоматов, то есть поведение объекта отражается в его состояниях, и данный тип диаграмм позволяет отразить это графически. Для этого используется два вида диаграмм: Statechart diagram (диаграмма состояний) и Activity diagram (диаграмма активности)
Statechart diagram (диаграмма состояний)
Диаграмма состояний предназначена для отображения состояний объектов системы, имеющих сложную модель поведения . Это одна из двух диаграмм State Machine, доступ к которой осуществляется из одного пункта меню.
Activity diagram (диаграммы активности)
Это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение Activity diagram в том, чтобы отражать бизнес-процессы объекта . Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов.
Этот тип диаграмм позволяет проектировать алгоритмы поведения объектов любой сложности, в том числе может использоваться для составления блок-схем.
Interaction diagram (диаграммы взаимодействия)
Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.
Sequence diagram (диаграммы последовательностей действий)
Взаимодействие объектов в системе происходит посредством приема и передачи сообщений объектами-клиентами и обработки этих сообщений объектами-серверами. При этом в разных ситуациях одни и те же объекты могут выступать и в качестве клиентов, и в качестве серверов.
Данный тип диаграмм позволяет отразить последовательность передачи сообщений между объектами.
Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений. Для того чтобы окинуть взглядом все взаимосвязи объектов, служит Collaboration diagram.
Collaboration diagram (диаграммы сотрудничества)
Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений.
Class diagram (диаграммы классов)
Этот тип диаграмм позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов .
Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на котором отображаются объекты системы. Классы имеют различные нотации. В нотации, предложенной Г. Бучем классы изображаются в виде чего-то нечеткого, похожего на облако. Таким образом Г.Буч пытается показать, что класс - это лишь шаблон, по которому в дальнейшем будет создан конкретный объект.
Component diagram (диаграммы компонентов)
Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы . Часто данный тип диаграмм называют диаграммами модулей.
При проектировании больших систем может оказаться, что система должна быть разложена на несколько сотен или даже тысяч компонентов, и этот тип диаграмм позволяет не потеряться в обилии модулей и их связей.
Цель работы:
- изучение основных принципов методологии IDEF0,
- создание нового проекта в BPWin,
- формирование контекстной диаграммы,
- проведение связей.
Описание системы с помощью IDEF0 называется функциональной моделью. Функциональная модель предназначена для описания существующих бизнес-процессов, в котором используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником графического языка является сама методология IDEF0.
Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности.
Каждая IDEF0-диаграмм а содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними.
Функциональные блоки (работы) на диаграммах изображаются прямоугольниками, означающими поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Имя работы должно быть выражено отглагольным существительным, обозначающим действие.
IDEF0 требует, чтобы в диаграмме было не менее трех и не более шести блоков. Эти ограничения поддерживают сложность диаграмм и модели на уровне, доступном для чтения, понимания и использования.
Каждая сторона блока имеет особое, вполне определенное назначение. Левая сторона блока предназначена для входов, верхняя - для управления, правая - для выходов, нижняя - для механизмов. Такое обозначение отражает определенные системные принципы: входы преобразуются в выходы управление ограничивает или предписывает условия выполнения преобразований, механизмы показывают, что и как выполняет функция.
Блоки в IDEF0 размещаются по степени важности, как ее понимает автор диаграммы. Этот относительный порядок называется доминированием. Доминирование понимается как влияние, которое один блок оказывает на другие блоки диаграммы. Например, самым доминирующим блоком диаграммы может быть либо первый из требуемой последовательности функций, либо планирующая или контролирующая функция, влияющая на все другие.
Наиболее доминирующий блок обычно размещается в верхнем левом углу диаграммы, а наименее доминирующий - в правом углу.
Расположение блоков на странице отражает авторское определение доминирования. Таким образом, топология диаграммы показывает, какие функции оказывают большее влияние на остальные. Чтобы подчеркнуть это, аналитик может перенумеровать блоки в соответствии с порядком их доминирования. Порядок доминирования может обозначаться цифрой, размещенной в правом нижнем углу каждого прямоугольника: 1 будет указывать на наибольшее доминирование, 2 - на следующее и т. д.
Взаимодействие работ с внешним миром и между собой описывается в виде стрелок, изображаемых одинарными линиями со стрелками на концах. Стрелки представляют собой некую информацию и именуются существительными.
Типы стрелок
В IDEF0 различают пять типов стрелок.
Вход - объекты, используемые и преобразуемые работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Стрелка входа рисуется как входящая в левую грань работы.
Управление -.информация, управляющая действиями работы. Обычно управляющие стрелки несут информацию, которая указывает, что должна выполнять работа. Каждая работа должна иметь хотя бы одну стрелку управления, которая изображается как входящая в верхнюю грань работы.
Выход - объекты, в которые преобразуются входы. Каждая работа должна иметь хотя бы одну стрелку выхода, которая рисуется как исходящая из правой грани работы.
Механизм - ресурсы, выполняющие работу. Стрелка механизма рисуется как входящая в нижнюю грань работы. По усмотрению аналитика стрелки механизма могут не изображаться на модели.
Вызов - специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней части работы и используется для указания того, что некоторая работа выполняется за пределами моделируемой системы.
Рис. 2.1 Типы стрелок
В методологии IDEF0 требуется только пять типов взаимодействий между блоками для описания их отношений: управление, вход, обратная связь по управлению, обратная связь по входу, выход-механизм. Связи по управлению и входу являются простейшими, поскольку они отражают прямые воздействия, которые интуитивно понятны и очень просты.
Рис. 2.2. Связь по выходу
Рис. 2.3. Связь по управлению
Отношение управления возникает тогда, когда выход одного блока непосредственно влияет на блок с меньшим доминированием.
Обратная связь по управлению и обратная связь по входу являются более сложными, поскольку представляют собой итерацию или рекурсию. А именно выходы из одной работы влияют на будущее выполнение других работ, что впоследствии повлияет на исходную работу.
Обратная связь по управлению возникает тогда; когда выход некоторого блока влияет на блок с большим доминированием.
Связи «выход-механизм» встречаются нечасто. Они отражают ситуацию, при которой выход одной функции становится средством достижения цели для другой.
Рис. 2.4. Обратная связь по входу
Рис. 2.5. Обратная связь по управлению
Связи «выход-механизм» характерны при распределении источников ресурсов (например, требуемые инструменты, обученный персонал, физическое пространство, оборудование, финансирование, материалы).
В IDEF0 дуга редко изображает один объект. Обычно она символизирует набор объектов. Так как дуги представляют наборы объектов, они могут иметь множество начальных точек (источников) и конечных точек (назначений). Поэтому дуги могут разветвляться и соединяться различными способами. Вся дуга или ее часть может выходить из одного или нескольких блоков и заканчиваться в одном или нескольких блоках.
Разветвление дуг, изображаемое в виде расходящихся линий, означает, что все содержимое дуг или его часть может появиться в каждом ответвлении. Дуга всегда помечается до разветвления, чтобы дать название всему набору. Кроме того, каждая ветвь дуги может быть помечена или не помечена в соответствии со следующими правилами:
- непомеченные ветви содержат вес объекты, указанные в метке дугиперед разветвлением;
- ветви, помеченные после точки разветвления, содержат все объектыили их часть, указанные в метке дуги перед разветвлением.
Слияния дуг в IDEFO, изображаемое как сходящиеся вместе линии, указывает, что содержимое каждой ветви идет на формирование метки для дуги, являющейся результатом слияния исходных дуг. После слияния результирующая дуга всегда помечается для указания нового набора объектов, возникшего после объединения. Кроме того, каждая ветвь перед слиянием может помечаться или не помечаться в соответствии со следующими правилами:
Рис. 2.6. Связь выход-механизм
- непомеченные ветви содержат вес объекты, указанные в общей меткедуги после слияния;
- помеченные перед слиянием ветви содержат все или некоторые объекты из перечисленных в общей метке после слияния,
Количественный анализ диаграмм
Для проведения количественного анализа диаграмм перечислим показатели модели:
- количество блоков на диаграмме - N;
- уровень декомпозиции диаграммы - L ;
- сбалансированность диаграммы - В;
- число стрелок, соединяющихся с блоком, - А
Данный набор факторов относится к каждой диаграмме модели. Далее будут перечислены рекомендации по желательным значениям факторов диаграммы.
Необходимо стремиться к тому, чтобы количество блоков на диаграммах нижних уровней было бы ниже количества блоков на родительских диаграммах, т. е. с увеличением уровня декомпозиции убывал бы коэффициент. Таким образом, убывание этого коэффициента говорит о том. что по мере декомпозиции модели функции должны упрощаться, следовательно, количество блоков должно убывать.
Диаграммы должны быть сбалансированы. Это означает, что в рамках одной диаграммы не должно происходить ситуации, изображенной на рис. 2.7: у работы 1 входящих стрелок и стрелок управления значительно больше, чем выходящих. Следует отметить, что данная рекомендация может не выполняться в моделях, описывающих производственные процессы. Например, при описании процедуры сборки в блок может входить множество стрелок, описывающих компоненты изделия, а выходить одна стрелка -- готовое изделие.
Рис. 2.7. Пример несбалансированной диаграммы
Введем коэффициент сбалансированности диаграммы
Необходимо стремиться, чтобы Кь был минимален для диаграммы.
Помимо анализа графических элементов диаграммы необходимо рассматривать наименования блоков. Для оценки имен составляется словарь элементарных (тривиальных) функций моделируемой системы. Фактически в данный словарь должны попасть функции нижнего, уровня декомпозиции диаграмм. Например, для модели БД элементарными могут являться функции «найти запись», «добавить запись в БД», в то время как функция «регистрация пользователя» требует дальнейшего описания.
После формирования словаря и составления пакета диаграмм системы необходимо рассмотреть нижний уровень модели. Если на нем обнаружатся совпадения названий блоков диаграмм и слов из словаря, то это говорит, что достаточный уровень декомпозиции достигнут. Коэффициент, количественно отражающий данный критерий, можно записать как L*C - произведение уровня модели на число совпадений имен блоков со словами из словаря. Чем ниже уровень модели (больше L), тем ценнее совпадения.
Инструментарий BPWin
При запуске BPWin по умолчанию появляется основная панель инструментов, палитра инструментов и Model Explorer.
При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново, или она будет открыта из репозитария ModelMart, внести имя модели и выбрать методологию, в которой будет построена модель (рис. 2.8).
Рис.2.8 Диалог создания модели
BPWin поддерживает три методологии - IDEF0, IDEF3 и DFD. В BPWin возможно построение смешанных моделей, т. е. модель может содержать одновременно как диаграммы IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.
Модель в BPWin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется всплывающее контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.
Пример
Построение модели системы должно начинаться с изучения всех документов, описывающих ее функциональные возможности. Одним из таких документов является техническое задание, а именно разделы "Назначение разработки", "Цели и задачи системы" и "Функциональные характеристики системы " .
После изучения исходных документов и опроса заказчиков и пользователей системы необходимо сформулировать цель моделирования и определить точку зрения на модель. Рассмотрим технологию ее построения на примере системы "Служба занятости в рамках вуза", основные возможности которой были описаны в лабораторной работе № 1.
Сформулируем цель моделирования: описать функционирования системы, которое было бы понятно ее пользователю, не вдаваясь в подробности, связанные с реализацией. Модель будем строить с точки зрения пользователей (студент, преподаватель, администратор, деканат, фирма).
Начнем с построения контекстной IDEF0-диаграммы- Согласно описанию системы основной функцией является обслуживание ее клиентов посредством обработки запросов, от них поступающих. Таким образом, определим единственную работу контекстной диаграммы как «Обслужить клиента системы». Далее определим входные и выходные данные, а также механизмы и управление.
Для того чтобы обслужить клиента, необходимо зарегистрировать его в системе, открыть доступ к БД и обработать его запрос. В качестве входных данных будут использоваться «имя клиента», «пароль клиента», «исходная БД», «запрос клиента». Выполнение запроса ведет либо к получению информации от системы, либо к изменению содержимого БД (например, при составлении экспертных оценок), поэтому выходными данными будут являться «отчеты» и «измененная БД». Процесс обработки запросов будет выполняться монитором системы под контролем администратора.
Контекстная диаграмма
Таким образом, определим контекстную диаграмму системы (рис. 2.9).
Рис 2.9. Контекстная диаграмма системы
Проведем декомпозицию контекстной диаграммы, описав последовательность обслуживания клиента:
- Определение уровня доступа в систему.
- Выбор подсистемы.
- Обращение к подсистеме.
- Изменение БД (при необходимости).
Получим диаграмму, изображенную на рис. 2.10.
Закончив декомпозицию контекстной диаграммы, переходят к декомпозиции диаграммы следующего уровня. Обычно при рассмотрении третьего и более нижних уровней модели возвращаются к родительским диаграммам и корректируют их.
Рис. 2.10. Декомпозиция работы «Обслуживание, клиента системы»
Декомпозируем последовательно все блоки полученной диаграммы. Первым этапом при определении уровня доступа в систему является определение категории пользователя. По имени клиента осуществляется поиск в базе пользователей, определяя его категорию. Согласно определенной категории выясняются полномочия, предоставляемые пользователю системы. Далее проводится процедура доступа в систему, проверяя имя и пароль доступа. Объединяя информацию о полномочиях и уровне доступа в систему, для пользователя формируется набор разрешенных действий. Таким образом, определение уровня доступа в систему будет выглядеть как показано на рис. 2.11.
Рис. 2.11. Декомпозиция работы «Определение уровня доступав систему»
После прохождения процедуры доступа в систему монитор анализирует запрос клиента, выбирая подсистему, которая будет обрабатывать запрос. Декомпозиция работы «Обращение к подсистеме» не отвечает цели и точке зрения модели. Пользователя системы не интересуют внутренние алгоритмы ее работы. В данном случае ему важно, что выбор подсистемы будет произведен автоматически, без его вмешательства, поэтому декомпозиция обращения к подсистеме только усложнит модель.
Декомпозируем работу «Обработка запроса клиента», выполняемую подсистемой обработки запросов, определения категорий и полномочий пользователей. Перед осуществлением поиска ответа на запрос необходимо открыть БД (подключиться к ней). В общем случае БД может находиться на удаленном сервере, поэтому может потребоваться установление соединения с ней. Определим последовательность работ:
- Открытие БД.
- Выполнение запроса.
- Генерация отчетов.
После открытия БД необходимо сообщить системе об установлении соединения с БД, после чего выполнить запрос и сгенерировать отчеты для пользователя (рис. 2.12).
Необходимо отметить, что в «Выполнение запроса» включается работа различных подсистем. Например, если запрос включает в себя тестирование, то его будет исполнять подсистема профессиональных и психологических тестов. На этапе выполнения запроса может потребоваться изменениесодержимого БД, например при составлении экспертных оценок. Поэтому, на диаграмме необходимо предусмотреть такую возможность.
Рис. 2.12.
Корректировка диаграммы
При анализе полученной диаграммы возникает вопрос, по каким правилам происходит генерация отчетов? Необходимо наличие заранее сформированных шаблонов, по которым будет производиться выборка из БД, причем эти шаблоны должны соответствовать запросам и должны быть заранее определены. Кроме того, клиенту должна быть предоставлена возможность выбора формы отчета.
Скорректируем диаграмму, добавив в нее стрелки «Шаблоны отчетов» и «Запросы на изменение БД» и туннельную стрелку «Клиент системы». Туннелирование «Клиента системы» применено для того, чтобы не выносить стрелку на диаграмму верхнего, так как функция выбора формы отчета не является достаточно важной для отображения ее на родительской диаграмме.
Изменение диаграммы потянет за собой корректировку всех родительских диаграмм (рис. 2.13 - 2.15).
Декомпозицию работы «Выполнение запроса» целесообразно провести при помощи диаграммы DFD (лабораторная работа № 3), так как методология IDEF0 рассматривает систему как совокупность взаимосвязанных работ, что плохо отражает процессы обработки информации.
Рис. 2.13. Декомпозиция работы «Обработка запроса клиента»
Рис. 2.14. Декомпозиция работы «Обслуживание клиента системы»(вариант 2)
Рис. 2.15. Контекстная диаграмма системы (вариант 2)
Перейдем к декомпозиции последнего блока «Изменение БД». С точки зрения клиента, данные системы располагаются в одной БД. Реально в системе присутствует шесть БД:
- БД пользователей,
- БД студентов,(вариант 2)
- БД вакансий,
- БД успеваемости,
- БД тестов,
- БД экспертных оценок,
- БД резюме.
Согласно цели моделирования клиенту важно понимать, что поступившие данные не сразу обновляются в системе, а проходят дополнительный этап обработки и контроля. Алгоритм изменения можно сформулировать следующим образом:
- Определяется БД, в которой будет изменяться информация.
- Оператором формируется временный набор данных и предоставляется администратору.
- Администратор осуществляет контроль данных и вносит их в БД.
Данную модель реализовать другим способом, предоставив возможность обновления БД непосредственно по запросам, минуя процесс контроля данных. В этом случае необходимо обеспечить контроль целостности БД для избежания ее повреждения. В этом случае диаграмма будет выглядеть следующим образом (рис. 2.17).
Рис. 2.16. Декомпозиция работы «Изменение БД»
Рис. 2.17. Декомпозиция работы «Изменение БД» (вариант 2) Для первого варианта, изображенного нарис. 2.12
Проведение дальнейшей декомпозиции «Изменения БД» будет усложнять модель, объясняя, как осуществляется физическое изменение БД в системе. При этом пользователь не получит никакой дополнительной информации о работе системы службы занятости. Декомпозицию этой работы целесообразно проводить в процессе проектирования БД системы на этапе создания логической модели БД.
Декомпозиция работы «Выполнение запроса» будет проведена в следующей лабораторной работе, иллюстрируя применение диаграмм DFD для описания процессов обработки информации.
Проведем количественный анализ моделей, изображенных на рис. 2.12 и 2.13, согласно вышеописанной методике. Рассмотрим поведение коэффициента ^ у этих моделей. У родительской диаграммы «Обработка запроса клиента» коэффициент равен 4/2 = 2, а диаграммы декомпозиции 3/3 = 1. Значение коэффициента убывает, что говорит об упрощении описания функций с понижением уровня модели.
Рассмотрим изменение коэффициента К b у двух вариантов моделей.
для второго варианта
Коэффициент К b не меняет своего значения, следовательно, сбалансированность диаграммы не меняется.
Будем считать, что уровень декомпозиции рассмотренных диаграмм достаточен для отражения цели моделирования, и на диаграммах нижнего Уровня в качестве наименований работ используются элементарные функции (с точки зрения пользователя системы).
Подводя итоги рассмотренного примера необходимо отметить важность рассмотрения нескольких вариантов диаграмм при моделировании системы. Такие варианты могут возникать при корректировке диаграмм, как это было сделано с «Обработкой запроса клиента» или при создании альтернативных реализаций функций системы (декомпозиция работы «Изменение БД»). Рассмотрение вариантов позволяет выбрать наилучший и включить его в пакет диаграмм для дальнейшего рассмотрения.
Контрольные вопросы
Список Контрольных вопросов :
- Что представляет собой модель в нотации IDEF0?
- Что обозначают работы в IDEF0?
- Назовите порядок наименования работ?
- Какое количество работ должно присутствовать на одной диаграмме?
- Что называется порядком доминирования?
- Как располагаются работы по принципу доминирования?
- Каково назначение сторон прямоугольников работ на диаграммах?
- Перечислите типы стрелок.
- Назовите виды взаимосвязей.
- Что называется граничными стрелками?
- Объясните принцип именования разветвляющихся и сливающихся стрелок.
- Какие методологии поддерживаются BPWin?
- Перечислите основные элементы главного окна BPWin.
- Опишите процесс создания новой модели в BPWin.
- Как провести связь между работами?
- Как задать имя работы.
- Опишите процесс декомпозиции работы.
- Как добавить работу на диаграмму?
- Как разрешить туннелированные стрелки?
- Может ли модель BPWin содержать диаграммы нескольких методологий?