Анализ предметной области. Идентификация и систематизация функций системы. Атрибуты системы. Скрытые и типовые функции. Функции бизнес-логики

Деятельность, направленная на выявление реальных потребностей заказчика, а также на выяснения смысла высказанных требований, называется анализом предметной области (бизнес-моделированием, если речь идет о потребностях коммерческой организации). Анализ предметной области – это первый шаг этапа системного анализа, с которого начинается разработка программной системы. Разработчики должны научиться

1. · понимать язык, на котором говорят заказчики;

2. · выявить цели их деятельности;

3. · определить набор решаемых ими задач;

4. · определить набор сущностей, с которыми приходится иметь дело при решении этих задач.

Моделирование предметной области является в RUP опциональной и выполняется для самих разработчиков, Заказчик является экспертом предметной области и не нуждается в ее моделировании.

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

В зависимости от конкретного проекта по усмотрению бизнес-аналитиков при анализе ПО могут создаваться следующие артефакты: глоссарий терминов предметной области, диаграмма бизнес-сущностей (классов ПО), диаграммы взаимодействия объектов ПО (моделирование связей), диаграммы бизнес-процессов или состояний, диаграммы функционеров (бизнес-актеров) и их функциональные обязанности, модели, описывающие состояния и условия перехода из одного в другое.

Диаграмма сущностей предметной области (business entity)

Цель: выявление и документирование бизнес-сущностей и их атрибутов.

Бизнес-сущность — некий объект ПО или концептуальное понятие ПО, характеризуемое набором данных (существенных признаков), прямо или косвенно связанное с проектируемой программной системой.

Бизнес-сущности – это кандидаты в классы и объекты ПС, отвечающие за ввод, изменение, удаление и хранение данных (атрибутов).

Методика выявления бизнес-сущностей: чтение текста концепции и анализ имен существительных.

Модель бизнес-актеров и их функциональных обязанностей (бизнес-функций) строится в представлении Use Case View в папке Business Use Case Model (при вызове шаблона rational unified process) на диаграмме ВИ.

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

Business Actor — это штатная единица (действующее лицо, функционер) в предметной области, который взаимодействует с ПС, либо не взаимодействует, но является участником бизнес-процесса. Чаще всего это штатный работник предприятия или должность (генеральный директор, главный инженер, экономист, зам. директора по производству и т.д.), но может быть и обособленной штатной системой, исполняющей определенные функциональные обязанности (например: кран, весы-транспортеры и т.д.).

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

 

Атрибуты системы. Скрытые и типовые функции. Функции бизнес-логики.

Требование (requirement) -- желательное свойство, характеристика или условие, которым должна удовлетворять система в процессе своей эксплуатации.

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

функциональные требования (Functionality)

требования удобства использования (Usability)

требования надежности (Reliability)

требования производительности (Performance)

требования возможности сопровождения (Supportability)

символом "+" обозначены дополнительные условия, к которым относятся:

проектные ограничения

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

требования к графическому интерфейсу пользователя

физические требования

юридические требования

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

Если Х действительно является функцией системы, то имеет смысл следующее предложение: система должна выполнять «Х»

Категории функций

Очевидные – их выполнение очевидно для пользователя. В основном, это функции бизнес-логики работы системы. Они являются ответом на главный вопрос анализа: «Что должна делать система?».

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

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

Анализ функциональных требований. Трассировочная матрица

Большинство пользователей (заказчиков) не в силах сформулировать конкретные и четкие функциональные требования к системе, а ограничивается лишь их концептуальным описанием в форме пользовательских требований (User Requirements).

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

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

Пользовательские требования и соответствующие им функции системы сохраняются в трассировочной матрице (таблице) (Traceability Matrix).