Бизнес правила для программ

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

Ключевые слова: приложение, пользователь, поле, список, редактор кода, контроль, отображение

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

Простейшим способом уменьшения пользовательских ошибок является указание набора значений. Например, для нашего приложения в сущности ОценкиЗаСеместр поле Оценка может принимать одно из значений диапазоне: Отлично, Хорошо, Удовл., Неудовл.

О программе Бизнес Практика

Добавим эти значения в список значений сущности ОценкиЗаСеместр. Выделите поле Оценка и в окне Свойства выберите кнопку Список значений.

увеличить изображение
Рис. 14.1.

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

увеличить изображение
Рис. 14.2.

Другим способом реализации бизнес-правил является использование кода программы. Например, при внесении оценок логично будет, что дата ее выставления находится в диапазоне +- 3 дня от текущей, все остальные даты могут рассматриваться как ошибки.

Для реализации этой функциональности откройте в конструкторе сущность ОценкиЗаСеместр, выделите поле ДатаЭкзамена. Затем в окне свойств выберите команду Настраиваемая проверка .

увеличить изображение
Рис. 14.3.

Откроется редактор кода , где следует записать код:

partial void ДатаЭкзамена_Validate(EntityValidationResultsBuilder results) < // results.AddPropertyError(«»); if (ДатаЭкзамена > DateTime.Now.AddDays(3) || ДатаЭкзамена < DateTime.Now.AddDays(-3)) < results.AddPropertyError(«»); > >

После этого, везде, где будет использоваться данное поле , будет осуществляться контроль ошибок ввода и отображение соответствующих предупреждений.

КАК ВЫРВАТЬСЯ ИЗ НИЩЕТЫ / ТРИ ГЛАВНЫХ ПРАВИЛА ПОБЕДИТЕЛЯ

увеличить изображение
Рис. 14.4.

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

Самостоятельная работа

1. Для таблицы Дисциплины для поля НазваниеДисциплины установите ограничение не больше 20 символов и не меньше 5 .
2. Для поля Год рождения в таблице Студенты установите проверку, что год рождения в диапазоне от 1970 до 2000 года.

Источник: intuit.ru

Чистая архитектура. Часть 3

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

Глава 20. Бизнес-правила

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

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

Сущность — это контейнер, который содержит набор критичных правил и данных для их работы.

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

Юзкейсы зависят от входных данных и производят выходные данные, но при этом не зависят от формы, в которой эти данные передаются.

Глава 21. Говорящая архитектура

• Архитектура — это не про фреймворки.
• Хорошая архитектура рассказывает, какую систему она описывает, а не на чём построена.

Фреймворки — это инструмент, а не материал. Архитектура должна основываться на юзкейсах, а не на фреймворках. Хорошая архитектура позволяет откладывать решения о выборе фреймворка и менять их, если придётся.

Веб — это механизм ввода-вывода.

Хорошая архитектура рассказывает, какую систему она описывает, а не на чём построена.

Глава 22. Чистая архитектура

Коротко, чистая архитектура:

• не зависит от фреймворков;
• легко тестируется;
• не зависит от пользовательского интерфейса;
• не зависит от базы данных;
• не зависит от каких-либо внешних агентов.

Внешние слои могут зависеть от внутренних, но не наоборот:

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

Главы 23–25

• Сделать систему тестируемой помогает шаблон простого объекта.
• Скрыть сложную логику можно за фасадами.
• Стоит почаще задаваться вопросом «а понадобится ли мне это?».

Глава 26. Корневой компонент

• Корневой компонент — тот, который создаёт, управляет и контролирует все остальные.
• Корневой компонент должен быть снаружи архитектуры системы.

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

Глава 27. Сервисы

• Сервисы слабо-связаны, но так бывает не всегда.
• Сервисы помогают достичь независимого деплоя, но так тоже бывает не всегда ¯_(ツ)_/¯
• Архитектура определяется не сервисами как таковыми, а границами между значимыми компонентами системы.

Глава 28. Тесты

• Тесты — часть системы.
• Если тесты сильно связаны с компонентами, то небольшое изменение может уронить сотни тестов.

Что дальше

В шестой части книги описываются детали реализации: БД, веб, фреймворки; а также несколько примеров. Это я рекомендую прочесть внимательно самим.

Вместе с этой книгой советую прочитать пару других:

• Чистый код, Робрет Мартин
• Читаемый код или программирование как искусство, Д. Босуэлл, Т. Фаучер

И ссылки из конспекта:

Если понравился пост

• Подписаться на RSS
• Твитнуть
• Фейсбукнуть
• Звездануть
• Поддержать

• Книги
• SOLID
• Архитектура

Источник: bespoyasov.ru

Анализ бизнес-правил

Пример извлечения бизнес-правил

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

Обзор

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

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

Альтернативные подходы

Альтернативные подходы к интеллектуальному анализу правил — ручные и автоматизированные.

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

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

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

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

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

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

См. Также

• Бизнес-модель
• Бизнес-процесс
• Подход бизнес-правил
• Экспертная система
• Соглашение об уровне обслуживания (SLA)
• Система управления бизнес-правилами (BRMS)

Ссылки

Дополнительная литература

• Barbara Von Halle (2001). Применяются бизнес-правила. Вайли. ISBN 0-471-41293-7
• Джанет Уолл (2006). Правила майнинга из Кодекса: разумность или безумие?

Внешние ссылки

• передовыми методами анализа правил вики-книгой.

Источник: alphapedia.ru