Модель потока данных предназначена для описания процессов перемещения данных в предметной области базы данных . Модель потока данных представляется в виде диаграммы потока данных ( Data Flow Diagram ). Основными элементами диаграммы являются:
- источники данных (Data Source);
- процессы обработки данных (Data Process) ;
- хранилища данных (Data store) ;
- потоки данных ( Data Flow ).
Источники данных показывают, кто использует или работает c данными. Процессы обработки данных показывают операции, производимые над данными. Хранилища данных показывают места хранения данных.
Потоки данных показывают способ передачи данных между источниками и хранилищами данных . Для представления диаграмм потока данных обычно используются сетевые структуры, допускающие повторение сущностей; циклы не используются. Поток изображается слева направо. На диаграммах помечаются допустимые и недопустимые пути перемещения данных, но не показываются процессы управления потоком.
Учим Базы Данных за 1 час! #От Профессионала
На рис. 2.12 приведен упрощенный вариант диаграммы потока данных для обработки заказа. Квадраты обозначают источники данных, окружности — процессы обработки данных , две параллельные черты — хранилище данных . Линии со стрелками показывают способ передачи данных из одной области в другую. Процессы можно подвергать функциональной декомпозиции, порождая тем самым иерархию диаграмм потока данных .
Рис. 2.12. Простая диаграмма потока данных для обработки заказа
На этом рисунке сущность Клиент (Client) продублирована: клиент делает заказ и получает его. На диаграмме показано два хранилища данных, два процесса и потоки данных между клиентом, процессами и хранилищами данных.
Диаграмма потока данных позволяет:
- представить систему с точки зрения источников и потребителей данных;
- показать перемещение данных в процессе их обработки;
- показать внешние механизмы подачи данных;
- показать метод сбора данных.
Диаграмма потока данных предоставляет проектировщику баз данных информацию:
- хранилищах данных , что позволит на последующих стадиях проектирования обоснованно определить число баз данных для информационной системы;
- принятых схемах преобразования информации в процессе ее обработки, что позволит в ходе проектирования приложений составить спецификацию приложений. Спецификации приложений вместе с диаграммами потоков данных передаются разработчикам приложений.
Модель жизненного цикла сущности
Модель жизненного цикла (ЖЦ) сущности предназначена для описания изменения состояний сущности и переходов между ними.
Модель ЖЦ сущности представляется в виде диаграммы ЖЦ сущности ( Entity Lifecycle Diagram ), на которой изображаются пути перехода сущности из некоторого начального состояния в конечное состояние и события, инициирующие изменения состояния сущности. Модель ЖЦ сущности может быть также представлена в виде текстового описания.
Что такое базы данных? ДЛЯ НОВИЧКОВ / Про IT / Geekbrains
Для проектировщика баз данных особенно важны диаграммы ЖЦ тех сущностей, которые многократно меняют свое состояние. Обычно такая сущность имеет атрибут Status (Состояние), характеризующий состояние сущности в текущий момент времени; домен этого атрибута является некоторым множеством значений, задаваемым перечислением. Проектировщику баз данных на стадии создания физической модели базы данных потребуется знание диаграмм ЖЦ сущностей для того, чтобы прописать ограничения на реализацию атрибута Status (Состояние) в базе данных.
На рис. 2.13 приведен пример диаграммы жизненного цикла сущности Чек.
Рис. 2.13. Диаграмма жизненного цикла Чек
Набор спецификаций функций системы (требования), описание функций системы через сущности и атрибуты, бизнес-правила
Одной из задач проектирования базы данных является отображение функций системы, содержащихся в требованиях и бизнес-правилах, в набор спецификаций модулей приложений базы данных. При этом проектирование модулей осуществляется параллельно и в согласовании с проектированием базы данных . Поэтому важным дополнением к моделям процессов и состояний, необходимым для проектирования базы данных , является информация о функциональности системы.
Аналитики должны предоставить проектировщикам баз данных набор спецификаций функций системы, которые описывают функциональность системы в форме бизнес-категорий — четко сформулированных требований к системе, сгруппированных по направлениям деятельности организации. Иногда предоставляется список зависимостей между функциями и вызывающими их событиями.
Помимо информации об иерархии функций , содержащейся в бизнес-модели процессов области, проектировщику базы данных необходимо иметь текстовое описание каждой из функций системы. При этом оно должно содержать выделенные сущности, применяемые в каждой функции, и используемые атрибуты сущностей , а также однозначно интерпретироваться при прочтении.
Получив набор спецификаций и описание функций системы через атрибуты и сущности, проектировщик базы данных может приступать к разработке спецификаций модулей приложений базы данных.
Бизнес-правила представляют собой конкретные требования и условия для функций, задающие поведение данных. В практике проектирования бизнес-правила используются для поддержки целостности данных в базе данных.
Общесистемные требования и решения
Общесистемные требования и решения о реализуемости базы данных, как правило, формируются менеджером ИТ-проекта на основе анализа данных предметной области. Среди них наиболее важными для проектировщиков базы данных являются следующие требования и решения.
- Требования по аппаратно-программной платформе:
- тип компьютеров (Intel, SUN, HP и т.д.);
- топология сети и протоколы передачи данных (NetBIOS, TCP/IP и т. д.);
- тип операционной системы (MS Windows, Unix, OpenVMS и т.д.);
- архитектура базы данных («клиент-сервер», параллельная архитектура);
- СУБД, на которой будет реализована база данных (MS SQLServer, Oracle, DB2 и т.д.);
- язык программирования или средства разработки приложений (C++, Delphi , MS VB и т.д.);
- требования, позволяющие оценить объем базы данных;
- требования, позволяющие оценить интенсивность потока транзакций в системе;
- требования, позволяющие оценить пропускную способность сети;
- требования по максимально возможному числу активных пользователей базы данных ;
- требования по актуализации данных;
- требования по производительности системы;
- требования по гибкости базы данных, т.е. открытость к модификациям структуры и кода.
Большинство перечисленных требований идут транзитом на следующие этапы процесса проектирования. Проектировщику базы данных на стадии планирования проектирования базы данных необходимо убедиться, что эти требования присутствуют в исходной документации, и в случае, если какие-либо требования отсутствуют, запросить их.
Рассмотрим некоторые примеры возможного неверного принятия решения по выбору СУБД. Предположим, что принято решение о разработке некоторой базы данных на СУБД Oracle. Закуплено и установлено оборудование. Однако информация об объеме базы данных и его потенциальном росте на этапе анализа требований к базе данных отсутствовала.
База данных спроектирована и создана, готовится план тестирования приложений базы данных. При составлении плана тестирования базы данных выясняется, что в базе данных будет размещено 1000 записей длиной 100 байт, а рост числа записей базы данных оценивается как 10 записей в год! Базой данных будут пользоваться 4 раза в год для получения 5 видов отчетов.
На производство всех отчетов за период требуется один день. Таким образом, цикл простоя системы будет много больше, чем время ее активной работы. В этом случае ответ на вопрос «А зачем выбрана промышленная СУБД Oracle?» имеет вполне экономический смысл.
Имеет место и обратная ситуация. Выбрали СУБД SQLBase. А через два года эксплуатации вышли на объем базы данных в 10 млн записей — цифра, характерная для финансовых подсистем крупного предприятия. И база данных «захлебнулась»!
Проектировщики баз данных! Будьте внимательны! Требуйте предоставления полного набора необходимой для принятия проектных решений информации!
Источник: intuit.ru
Анализ бизнес-правил: техника BABOK®Guide для документирования операций и разработки требований
В этой статье рассмотрим, что такое бизнес-правила, какие они бывают, зачем их определять, анализировать и документировать при описании процессов, а также спецификации требований. Анализ бизнес-правил как техника BABOK®Guide и метод фиксации особенностей предметной области при разработке технического задания (ТЗ).
Что такое бизнес-правила: определение BABOK®Guide и примеры
Анализ бизнес-правил является одной из 50 техник BABOK®Guide и используется для выявления, определения, описания, проверки и организации ежедневных операций, а также условий принятия операционных решений. Если бизнес-правила являются основанием для принятия решений, с ними можно дальше работать в технике «Моделирование решений», структурировав в виде таблицы или дерева, что мы рассматриваем в отдельной статье. А сегодня сфокусируемся именно на технике «Анализ бизнес-правил» (Business Rules Analysis).
Бизнес-правила не стоит путать с организационными (деловыми) политиками, область действия которых шире чем у правил и направлена больше на предприятие в целом, чем на отдельные процессы и управленческие решения. Бизнес-правило — это конкретная проверяемая директива как условие или критерий управления поведением/процессом или принятия рутинных (операционных) решений. Оно всегда практически осуществимо, контролируемо и не требует дополнительной интерпретации для применения в бизнесе. BABOK выделяет 2 категории бизнес-правил:
- определительные, которые относятся не к людям, а отражают операционные знания организации. Например, обращения привилегированных клиентов получают наивысший приоритет. Определительные бизнес-правила невозможно нарушить, но можно неправильно применить. При разработке функциональных требований и их спецификации в ТЗ или SRS такие правила являются основанием для вычислений и изменения поведения/состояний объектов в ходе бизнес-процессов. Например, атрибуту «Статус» объекта «Клиент» задать значение «Привилегированный», если значение атрибута «Сумма заказа» больше 1 млн.
- поведенческие, которые относятся к людям, даже если их поведение автоматизировано. Они используются для организации и регулирования ежедневной деятельности в качестве обязательств или запретов на способы выполнения операций, действия, практики или процедуры. Часто поведенческие бизнес-правила закреплены в политики организации для снижения рисков или повышения продуктивности. Они могут использовать информацию из определительных правил, чтобы направлять действия людей, обязывая их решать рабочие задачи определённым образом, запрещать какие-то действия или описывать условия корректного выполнения процессов и процедур. Поскольку поведенческие бизнес-правила относятся к людям, они могут быть нарушены. Например, обращение привилегированного клиента должно быть обработано оператором в течение 1-го часа после его поступления независимо от дня недели и времени суток.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
24 июля, 2023
Длительность обучения
12 ак.часов
Стоимость обучения
20 000 руб.
Бизнес-правила напрямую связаны с бизнес-требованиями. Например, есть бизнес-требование «Выиграть войну (стать победителем)». Связанные с ним определительные бизнес-правила могут звучать так: «Выигрывает в войне, т.е. становится победителем тот, кто захватил всю территорию противника» и «Дата окончания войны фиксируется в акте капитуляции от проигравшей стороны». А поведенческое бизнес-правило в этом кейсе может быть таким: «Проигравший должен выплатить денежную контрибуцию победителю в течение месяца после окончания войны».
Как анализировать бизнес-правила: рекомендации BABOK®Guide
BABOK отмечает, что техника анализа бизнес-правил включает следующие действия:
- сбор из явных и неявных источников (организационные регламенты и другие внутренние документы, договоры, контракты, деловые политики, отраслевые стандарты, эксперты предметной области и другие стейкхолдеры, а также негласные, но общепринятые практики и нормы корпоративной культуры);
- описание в виде текстовых определений (для определительных бизнес-правил) или наглядных схем бизнес-процессов в формальных нотаций моделирования (IDEF0, BPMN, EPC или UML) для поведенческих бизнес-правил;
- валидация описанных бизнес-правил, т.е. их проверка на соответствие реальности со стейкхолдерами, которые могут это подтвердить или опровергнуть;
- уточнение описанных и проверенных бизнес-правил, чтобы они лучше соответствовали реальности и бизнес-целям;
- организация описанных и проверенных бизнес-правил так, чтобы их было удобно использовать и администрировать по мере необходимости, т.е. изменять, создавать их новые версии, выводить из эксплуатации (объявлять устаревшими).
Все эти действия направлены на то, чтобы сделать бизнес-правила явными, конкретными, ясными, доступными и централизованными. Если по результатам сбора информации из явных и неявных источников бизнес-аналитику необходимо сформулировать правило самостоятельно, BABOK®Guide рекомендует придерживаться следующих принципов:
- говорить на языке стейкхолдеров в терминах профессионального жаргона или глоссария организации/отрасли, чтобы эксперты предметной области смогли быстро их понять и подтвердить или опровергнуть;
- формулировать атомарно и декларативно, отделяя их от точек применения (бизнес-процессы или принятие решений), чтобы обеспечить возможность повторного использования. Однако, ссылку на процессы или управленческие решения, которые бизнес-правила поддерживают или ограничивают, поставить следует.
- предусмотреть способы их хранения и поддержки так, чтобы по мере развития бизнеса и влияния внешних обстоятельств правила была возможность отслеживать и менять правила.
Таким образом, можно сказать, что бизнес-правила являются своеобразной структурой регулирования поведения, а их ясное определение и администрирование позволяет организации корректировать свои деловые политики без изменения процессов или систем. Однако, если бизнес-правил слишком много, они описаны некорректно, сформулированы непонятно, не соответствуют действительности или противоречат друг другу, то ценность этого артефакта невелика. Впрочем, одной из рабочих обязанностей бизнес-аналитика является как раз наведение порядка в бизнес-правилах. Однако, разработка и улучшение организационных регламентов с помощью анализа бизнес-правил – не единственное приложение этой техники BABOK. BABOK®Guide рекомендует применять ее для решения следующих задач:
- планирование вовлечения стейкхолдеров из области знаний «Планирование и мониторинг бизнес-анализа»;
- проведение выявления из области знаний «Выявление и сотрудничество»;
- поддержание требований из «Управление жизненным циклом требований»;
- оценка изменений требований из «Управление жизненным циклом требований»;
- спецификация и моделирование требований из области знаний «Анализ требований и определение дизайна»;
- оценка ограничений решения из области «Оценка решения».
Как именно бизнес-правила связаны со спецификацией требований в ТЗ и SRS мы рассмотрим далее.
Источник: babok-school.ru
Бизнес-правила
Бизнес-правила позволяют автоматизировать операции принятия решений в рамках бизнес-процессов. Для создания бизнес-правил в системе ELMA используется стандарт DMN (Decision Model and Notation). Переведенная на русский язык нотация принятия решений DMN доступна по адресу https://www.elma-bpm.ru/dmn/.
Перейдите в раздел Бизнес-правила . Он включает в себя два подраздела: Бизнес-правила и Глобальные переменные .
Работа с этим разделом доступна только пользователям с соответствующими правами доступа. Подробнее об этом можно прочитать в статье Настройки бизнес-правил.
На странице этого раздела отображается список всех созданных бизнес-правил. Таблицу можно настроить.
Для удобства работы вы можете создать фильтры по бизнес-правилам. Для работы с фильтрами в дереве нажмите на форме поиска на кнопку .
Список бизнес-правил можно экспортировать в файл Excel. Для этого на панели настроек таблицы нажмите .
Вы можете перейти в карточку бизнес-правила, нажав на его название.
В контекстном меню каждого бизнес-правила можно выполнить следующие действия:
- Перейти в карточку бизнес-правила.
- Изменить данные, указанные при создании бизнес-правила.
- Создать копию бизнес-правила.
- Удалить его.
Группировка бизнес-правил
Для удобства бизнес-правила можно сгруппировать по папкам. Чтобы создать папку, на панели инструментов в выпадающем меню кнопки Создать выберите Папку и заполните поля.
Укажите название папки и пользователя, ответственного за работу с ней. Любой пользователь, указанный в поле Ответственный * (даже если он не является создателем папки), будет получать оповещения об изменении, о добавлении комментария к ней другими пользователями. При необходимости добавьте описание и папку, в которую будет вложена создаваемая папка.
Для сохранения папки нажмите на кнопку Сохранить .
Поиск бизнес-правил
При работе с бизнес-правилами доступен быстрый и расширенный поиск.
Подробнее о быстром поиске читайте в этой статье.
Расширенный поиск
Вы можете задать дополнительные параметры для поиска. Можно показать удаленные бизнес-правила, указать автора создания, текущую версию и ответственного за бизнес-правило. Для этого нажмите кнопку , укажите параметры и нажмите на кнопку Найти бизнес-правила или на клавишу Enter .
На форме расширенного поиска также доступны следующие функции:
- EQL-поиск — поиск бизнес-правил с помощью EQL-запроса;
- Сохранить как фильтр — сохранение выбранных параметров в качестве фильтра, если вы планируете несколько раз использовать один и тот же набор параметров для поиска.
Чтобы скрыть форму расширенного поиска, нажмите повторно на кнопку . Вы можете также нажать Скрыть поля поиска . При этом скроются только все незаполненные поля формы расширенного поиска.
Нашли опечатку? Выделите текст, нажмите ctrl + enter и оповестите нас
Источник: www.elma-bpm.ru