
- •Оглавление
- •1. Введение
- •2. Лр №1. Разработка бизнес-правил.
- •2.1. Цель работы.
- •2.2. Общие сведения о проекте.
- •2.3. Проблема локализации.
- •2.4. Создание проекта на основе пустого шаблона.
- •2.5. Основные элементы интерфейса.
- •2.6. Виды бизнес-правил.
- •2.7. Определение типов требований.
- •2.8. Определение атрибутов требований.
- •2.9. Определение атрибутов бизнес-правил.
- •2.10. Создание требований посредством матрицы атрибутов.
- •3. Литература.
2.5. Основные элементы интерфейса.
Интерфейс «IBM Rational RequisitePro 7.0.1.0», приведен на рис. 2.6. Рассмотрим основные элементы.
Панель инструментов предназначена для быстрого доступа к наиболее часто используемым командам приложения. При наведении курсора мыши на кнопку панели инструментов появляется подсказка, описывающая закрепленные за ней функции.
Проводник предназначен для навигации по проекту. Все основные артефакты (документы, требования, виды и пакеты) представлены в форме иерархического дерева. Проводник служит для выбора, просмотра и изменения артефактов проекта. Поддерживается технология «drug and drop» для перемещения артефактов между пакетами. Окно проводника связано с другими окнами приложения, отражая изменения, вносимые в открытый документ, вид или требование.
Описание артефакта появляется при выборе артефакта в окне, расположенном под окном Проводника.
Пакеты содержат связанную с требованиями информацию. Пакет может содержать в себе: документы (упорядоченные в алфавитном порядке), виды, сортируемые по типу, а внутри типа - по алфавиту, и требования (упорядоченные по типу и признакам). Разработчику предоставляется возможность вкладывать один пакет в другой.
Представления или Виды предназначены для отображения требований. Все требования, их атрибуты и взаимосвязи с другими требованиями представляются и управляются при помощи представлений. Приложение предоставляет возможность строить запросы, фильтрующие и упорядочивающие требования и их атрибуты.
Рисунок 2.6. Интерфейс IBM Rational RequisitePro.
2.6. Виды бизнес-правил.
В рамках цикла лабораторных работ необходимо определить структуру репозитария для хранения различных типов требований. Целесообразно начать с бизнес-правил, поскольку именно этот тип требований выявляется на начальных этапах анализа требований.
«Бизнес-правило» - это положение, определяющее или ограничивающее какие-либо стороны бизнеса. Его назначение - защитить структуру бизнеса, контролировать или влиять на его операции.
Следует отметить, что существует множество различных схем классификации бизнес-правил на виды. Одна из них, предложенная Карлом Вигерсом в его работе [1], приведена на рис 2.7.
Рисунок 2.7. Виды бизнес-правил.
Определения для каждого из приведенных на рис. 2.7. видов бизнес-правил и примеры их формулирования приведены ниже.
Факты (facts) - это верные утверждения о бизнесе. Они описывают связи и отношения между важными бизнес-терминами. Факты также называют инвариантами - неизменными истинами о сущности данных и их атрибутах. Обычно факты напрямую не преобразуются в функциональные требования к системе. Сведения о сущности данных, важных для системы, применяют в моделях данных, создаваемых аналитиком или архитектором базы данных.
Пример: «Доставка заказа оплачивается клиентом».
Ограничения (Constraints) определяют, какие операции могут выполняться в рамках системы. Как правило, при формулировании ограничений используются слова и фразы вида: должен / не должен, может / не может, только.
Пример: «При отгрузке заказа менеджер должен запросить у бухгалтера товарно-транспортную накладную и счет-фактуру».
Активаторы операций (Action enabler) - правило, при определенных условиях приводящее к выполнению каких-либо действий. Выражение вида «Если <некоторое условие верно или наступило определенное событие>, то <что-то произойдет>», - это ключ, который описывает активатор операции.
Пример: «Если заказанный товар отсутствует на складе, то заказ передается в производственный отдел».
Вывод (Inference) - это правило, устанавливающее новые реалии на основе достоверности определенных условий. Вывод создает новый факт на основе других фактов или вычислений. Выводы зачастую записывают в формате «если — то», применяемом при записи активаторов. Однако раздел «то» вывода заключает в себе факт или предположение, а не действие.
Пример: «Если оплата по счету не поступила в течение 15 дней, заказ считается отменённым».
Вычисления (Computations) – вид бизнес-правил определяющий вычисления, выполняемые с использованием математических формул и алгоритмов. В отличие от активирующих операции бизнес-правил, для реализации которых иногда приходится создавать специфические функциональные требования, правила вычислений в той форме, в которой они выражены, можно рассматривать в качестве требований к программному обеспечению.
Пример:
«Если сумма заказа составляет от 50 тыс.руб. до 100 тыс.руб., скидка составляет 5%».
«Если сумма заказа составляет от 100 тыс.руб. до 200 тыс.руб., скидка составляет 10%».
«Если сумма заказа составляет свыше 200 тыс.руб., скидка составляет 15%».
Еще одной разновидностью бизнес-правил можно считать термины, которые согласно рекомендациям «Rational Unified Process», следует хранить в отдельном документе под названием «Глоссарий».
Термины – важные для бизнеса слова, фразы и аббревиатуры.