Инструменты моделирования для разработки ИС

1

Инструменты моделирования для

разработки ИС

2

Инструменты разработки

• Средства моделирования

– Диаграммы потоков данных (DFD)– Блок-схемы процедур (flowchart)– Модели процессов

(IDEF0, IDEF3, BPMN)– Модели данных (ERD, IDEF1X, UML)– Комбинированные (ARIS)

3Основы семейства стандартов менеджмента качества ISO 9000:2000

• Процессный подход• Наглядность описания организации

для обеспечения «прозрачности» (модели)• Несколько моделей организации («проекции»)

– Функциональная и поведенческая (процессы)– Информационная (данные)– Параметрическая (нормы расхода ресурсов)

• Выделение деятельности по управлению качеством и изменениями (измерение и анализ деятельности)

4

Процессный подход

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

5

Процесс

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

6Моделирование административных процессов в 1858 году

9

Диаграммы потоков данных

•

Data flow diagram (DFD)

10

Диаграммы потоков данных

• DFD – основное средство моделирования функциональных требований к проектируемой системе

• Цели описания:– информационные процессы– преобразования входных данных в выходные

для каждого процесса– отношения между процессами

(потоки данных)

11

Потоки данных

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

13

DFD

Нотации:

1.Йодана

2.Гейна-Сарсона

14

Контекстная диаграмма

Подразделения

Отдел кадров

Начисление зарплаты

1

Гос. органы

Касса

Банк

Руководители

Налог. отчеты

Табели раб. времени

Данные о работниках

Ведомость

Заказденег

Отчет

15

Декомпозиция DFD• Контекстная диаграмма

(DFD первого уровня)– имеет один процесс (основной)– идентифицирует объекты внешнего мира – описывает обмен данными с внешними

источниками и потребителями

• DFD нижнего уровня детализируют процессы DFD верхнего уровня (дерево DFD)

16

Пример: Контекстная диаграмма

17

Пример: детализация процесса 1

18

Пример: детализация процесса 1.3

20

Построение модели (процесс)

• Выделение функциональных групп (процессов) в множестве требований

• Идентификация внешних объектов

• Разработка контекстной DFD

• Декомпозиция процессов (описание дочерних процессов)

• Проверка требований, корректности и улучшение восприятия модели

21

Требования к модели (группировка)• На каждой диаграмме от 3 до 6-7

процессов• Несущественные детали группировать

и раскрывать в DFD более низкого уровня

• На каждом уровне описывать логически связанные процессы

• Выбирать короткие имена в соответствии и расшифровывать их в спецификации (словаре данных)

23

Блок-схемы процедур

•

flowchart

24

Элементы блок-схемы• Переправка, передача

• Ручной ввод, дисплей

• Документ, пакет документов

• Хранение, данные

• Процесс, ручной процесс

• Решение, подготовка

25

Различия: “Что” и “Как”

Источник

Обработка Хранение

Потребитель

DFD vs flowchart

26

IDEF0 – Методология функционального моделирования

•

Integrated DEFinition

27

История IDEF0

• 1969 : Дуглас Росс – SADT (Structured Analysis and Design Technique)

• 1970-е: ВВС США (ICAM - Integrated Computer-Aided Manufacturing)

• 1993 г. : Федеральный стандарт США• 2000 г. : Р50.1.028-2001. Методология

функционального моделирования. М.: Госстандарт России, 2000

28

Нотация IDEF0

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

ресурсов

(механизмов)

в управляемых

условиях

29

Декомпозиция

Диаграмм IDEF0

30

Пример: госуслуга

31

Пример: госуслуга

34Построение IDEF0-модели (процесс)

• Определение цели модели;

• Сбор информации об объекте, определение его границ;

• Построение, агрегирование и декомпозиция диаграмм;

• Критическая оценка, рецензирование и комментирование.

• Утверждение

35

Построение IDEF0-модели

• На каждой диаграмме не должно быть более 5-6 действий.• На каждой диаграмме действия должны быть объединены

общей логикой.• Наименования действий должны быть краткими и емкими, в

прилагаемом словаре краткие имена должны расшифровываться.

• Каждое действие должно иметь основание для начала (один или несколько входов) и результат (один или несколько выходов).

• Действиям присваиваются номера, отражающие их положение в иерархии.

• Входы и выходы на каждой диаграммы нумеруются

36

Построение IDEF0-модели1. Ветвления процесса (альтернативные или одновременные

результаты действий) должны сопровождаться описанием условий их наступления.

2. Каждое действие должно иметь ответственного (исполнителя).

3. Каждое действие должно регулироваться нормативно-правовым или административным документом.

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

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

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

40

Методология моделирования процессов (IDEF3)

• конец 1980-х годов

• не является стандартом

Integrated Definition for Function Modeling (IDEF)

41

Компоненты моделиДиаграмма• Действие

(единица работы – Unit of Work)

• Связи – Временное предшествование – Объектный поток– Необязательное отношение

• Соединения (инициирование действий)– И (&), ИЛИ (O), Исключающее ИЛИ (X)

42Соединение «И»

(разворачивающее и сворачивающее)

43Соединение «Исключающее ИЛИ» (разворачивающее и сворачивающее)

44Соединение «ИЛИ» (И / ИЛИ) (разворачивающее и сворачивающее)

45

Условные обозначения для моделирования бизнес-

процессов (BPMN)•

Business Process Model Notation (BPMN)

46

BPMN• Объекты потока управления:

– события, действия и логические операторы

• Соединяющие объекты: – поток управления, поток сообщений и ассоциации

• Роли: – пулы и дорожки

• Артефакты: – данные, группы и текстовые аннотации.

47

BPMN

48

BPMN

49События

Нотация – круг

Линия окружности:• Начальные• Промежуточные• Завершающие

Знак в круге – смысл события

Штриховка знака:• Обработка • Генерация (создание)

50Действия

Нотация – прямоугольник со скругленными углами

Виды действий:• Задания• Подпроцессы

51Логические операторы

Нотация – ромбИспользование – точки принятия решений в процессе

(ветвления)

Виды операторов:

• Исключающее ИЛИ

• ИЛИ

• И

52Соединения

Нотация – стрелкаИспользование – для обозначения последовательности

действий, передачи информации и комментирования

Виды соединений:

• Поток управления

• Поток сообщений

• Ассоциация

53Роли

Нотация – прямоугольникИспользование – для группировки действий

Виды ролей:

• Пул

• Дорожка

54Артефакты

Использование – для дополнительной информации

Виды артефактов:

• Данные

• Группа

• Текстовая аннотация

Комментарий

55

BPMN

56

BPMN

57

BPMN

58

Моделирование данных

• Сущностная модель

• REA модель

• E-R диаграммы (ERD, ERM)

• Реляционная модель

60

Схемы данныхСхема данных – это

описание ее

логической

структуры.

Виды схем:

• Внешняя

• Концептуальная

• Внутренняя

Шкаф 232 Стол 341 Диван 520 Стул 45

Подсхема СПодсхема ВПодсхема А Внешний уровеньНабор индивидуальных логических представлений о частях БД

Отображение внешних представлений на концептуальную схему

КлиентыТовары Продажи

Кассовые операции

Концептуальный уровеньОбщий взгляд на всю базу данных

Отображение концептуальной схемы на внутреннее представление

ДЕТАЛИ ХРАНЕНИЯ ДАННЫХЗапись о запасахItem number- integer (5), non-null, index = itemxDescription- character (15)Cost- currency (6,2) и т.д.Запись о продажахInvoice number- integer (6), non-null, index = salesxи т.д.

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

61

Концептуальные модели данных

- Сущностная модель

Сущность – объект, субъект, событие.

Атрибут – свойство сущности.

Экземпляр сущности – конкретный объект

- REA модель - классификация сущностей:

Ресурсы (Resource) – активы организации

События (Event) – изменяют ресурсы

Участники (Agent) – вовлечены в события

62

Концептуальные модели данных

- E-R диаграммы (Entity-Relation)

Виды товаров

Продажи Продавцы

Клиенты

Счет Платежи Кассиры

Оплата за

Продается Оформляют

Кому

От кого

Получают

СОБЫТИЯ УЧАСТНИКИРЕСУРСЫ

** *

*

*

*

1 *

*

*

1

1

1

1Увелич.

63

Концептуальные модели данных

- E-R: тип отношения между сущностями

ПлатежиПродажи Оплата за 11

ПлатежиПродажи Оплата за *1

ПлатежиПродажи Оплата за 1*

ПлатежиПродажи Оплата за **

Отношение один к одному (1:1)

Отношение один ко многим (1:*)

Отношение многие к одному (*:1)

Отношение многие ко многим (*:*)

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

Пример - продажа в кредит. Каждая сделка продажи оплачивается в несколько приемов.

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

Пример - регулярные взносы на приобретение товаров. Дебиторские задолженности.

64

Концептуальные модели данныхРеляционная модель

Таблица = сущностьЗапись таблицы = экземпляр сущностиПоле таблицы = атрибут сущностиСвязь таблиц = отношение сущностей

Код товара

Описаниетовара

Количество на складе

Цена Описание поставщика

Адрес

1036 Холодильник 23 12310 “Бирюса” Россия,..

1038 Холодильник 0 13100 BOSCH ФРГ,…

1039 Стир. машина 52 12500 BOSCH ФРГ,…

65

Концептуальные модели данныхСвязь реляционных таблиц

Первичный ключ – уникальный атрибутВнешний ключ – ссылка на перв. ключ

Код товара

Описание Код поставщика

Количество на складе

Цена

1036 Холодильник 10023 23 12310

1038 Холодильник 10034 0 13100

1039 Стиральная машина 10034 52 12500

Код поставщика

Описание Адрес

10011 “Горизонт” Россия, …

10023 “Бирюса” Россия, …

10034 BOSCH ФРГ, …

67

Методология ARIS (eEPC)• ARIS: Архитектура

Интегрированных Информационных Систем

• eEPC: Расширенная нотация описания последовательности действий процесса, управляемого событиями

• ARIS: Architecture of Integrated Information Systems

• eEPC: extended Event Driven Process Chain

68

Методология ARIS eEPC• бизнес-процесс описывается в виде потока

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

• С каждой функцией связаны:– Цели– Исходное и конечное события– Используемая информация

(данные и документы)– Ресурсы (прикладные системы,

подразделения, их представители, затраты)

69Модель функции процесса

С чего началось?

К чему привело?

Чтосделали?

Что использовали?

Что получили?

Откуда?

Куда?

Кто?

При помощи чего?

При помощи чего?

Отображение Пример

Экспортныепоставки

отклонены

Поступила письменная

заявка

Поступила устнаязаявка

Обработать заявкуклиента

Отдел продажпо Германии

Данныео продажах

Заявкиклиентов

SAPSD

70Событие

Функция

Событие

Функция

Событие

Функция

Событие Событие

Функция Функция

OE

OEOE

Событие Событие

Событие

ФункцияФункция OE

Событие Событие

Функция

OE

OE

Событие

71

Естьнеобходимость в

посещениитерапевта

СПРАВКИ083/у - Медицинская справка для представления в госавтоинспекцию086/у - Медицинская справка (врачебное профессиональное заключение)046/1 - Получение оружия

Справки

Клиент обратилсяв кабинет

платных услуг

Естьнеобходимость в

медосмотре

Справки

Заключитьдоговор на

оказание услуги

Менеджеркабинета платных

услуг

Естьнеобходимость в

обследовании

Обследованиепроведено

Менеджеркабинета платных

услуг

Лечебно-диагностическое

обеспечение

Выдатьрезультаты

обследования

Медосмотрпроведен

Лечениезакончено

Результатыпациенту выданы

Лечить пациента

Провестимедосмотр

Журналы учетавыдачи справок

Врач

Медсестра

Чек

ТАПФ025-12/у

МКАБФ025/У

Договорна оказаниеплатных услуг

ТАПФ025-12/у

МКАБФ025/У

72

Занестиифнормацию в

БД

Операторстатистики

Информациязанесена

Вызов обработан

Лечениезакончено

Услуга пациентуоказана

Выдать пациентусправку

Справка пациентувыдана

Запрос обработан

Идентифицировать клиента

Полис

Естьнеобходимость в

посещениитерапевта

Естьнеобходимость в

оказании платныхуслуг

Естьнеобходимость в

смотровомкабинете

Есть необходимостьоказать

доврачебный прием

Медиалог

Появился запросклиента

Паспорт

Направление

Обработатьзапрос клиента

Клиент обратилсяв регистратуру

Телефон

Появился вызовпациента

Сформироватьрабочий график

врача

Принять пациентав смотровом

кабинете

Оказатьдоврачебный

прием

Лечить пациента

Выдатьдокументы

на посещениетерапевта

МКАБФ025/У

ТАПФ025-12/у

Талон наприем к варчу

ТАПФ025-12/у

Первичныйпациент на приеме

у терапевта

Регистраторы

Доврачебныйприем оказан

Прием всмотровомкабинете

завершился

Определить цельпациента

Терапевт

Пациентунеобходимо

лечениеТерапевтПациенту

необходимасправка

ВЫДАТЬ ПАЦИЕНТУ СПРАВКУПроизвольная форма документа (врачебная справка универсал):" Бассейн" О состоянии здоровья" О диагнозе" Освобождение от физкультуры" Выписка из АК" Ходатайство в департамент (на дорогостоящие виды лечения)" Ходатайство в управление здравоохранения (по лекарствам)" Ответы на запросы по больным из ОВД и страховых компаний Строгая форма:" Рекомендации КЭК (ограничение в труде после болезни)" №088/у-06 направление на МСЭ" Медицинское заключение о реабилитации инвалидов (КЭК)" Справка получения путевки №070/у-04" Санаторно-курортная карта №072/у-04" Опекунство

ТАПФ025-12/у

МКАБФ025/У

МКАБФ025/У Сортировать АК

АКотсортированы

Регистратор№2

Зам.ГВ пополиклинике

Ст.мед.регистратор

Врач

Оказать платнуюуслугу

Стат.талоннаходится в

отделе статистики

Сдать документыпо пациенту врегистратуру

Документы попациенту сданы в

регистратуру

ОтнестиСтат.талон в

отдел статистики

Статистик

Медсестра

ТАП - талон амбулаторного пациентаМКАБ - медицинская карта амбулаторногобольного

Зам.ГВ по КЭР

Регистратор№2

Регистратор№4

Регистратор№3

Медиалог

73

Обозначения ARIS eEPC• Функция

• Событие

• Орг.единица

• Документ

• Прикл.сист.

• Данные

• Связь

• И

• ИЛИ

• Искл.ИЛИ

74

Обозначения ARIS eEPC

• Представитель

• Цель

• Хранение

• Мат.ресурс

75

Правила формирования модели

• каждая функция должна быть инициирована событием и должна завершаться событием;

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

76

78

Информационный вид Управленческий вид Функциональный вид

Организационный вид

Вход - выход

Орг.диаграмма

ERM-диаграммаЦепочка процесса,

управляемая событиями

(ЕРC)

Дерево функций

Дерево целей

79

Текущий процесс“Выполнение заказа“

Текущий процесс“Выполнение заказа“

Контроль процесса

Зонд 2

Зонд 1

Зонд 3

ARIS ARIS Хранилище Хранилище процессовпроцессов

87

Конец