Мы используем cпособ описания функциональных требований к системе и ее функций с использованием стандартов и универсального языка моделирования от авторов:
Алфимов Р.В., Красникова С.А., Золотухина Е.Б. (сертифицированный специалист по решениям IBM Rational, преподаватель в Учебно-Консалтинговом центре компании "Интерфейс").
Значительной популярностью при разработке автоматизированных систем в настоящее время в России пользуется универсальный язык моделирования (Unified Modeling Language - UML). Несмотря на безусловные плюсы, использование UML сопряжено с рядом трудностей методического характера, на которые мы хотели бы обратить внимание читателя. Прежде всего, в UML вводится собственный понятийный аппарат, в рамках которого традиционные термины и понятия, связанные с созданием автоматизированных систем и используемые в течение десятилетий, заменяются на термины и понятия, не нашедшие пока в полной мере отражения в международных и отечественных стандартах в области информационных технологий.
Особенно это касается базового элемента языка UML "Use Case", который трактуется отечественными переводчиками как "вариант использования", "прецедент". При этом контекст, в котором переводится термин, не учитывается. Несмотря на то, что понятие активно используется уже довольно давно - путаницы возникает все больше и больше. Так, участники некоторых Интернет- форумов дошли до того, что сравнивают "Use Case" с техническим заданием. По мнению авторов, все это обусловлено стандартным описанием UML, не связанным с процессом разработки автоматизированных систем (АС), а также упущенной возможностью при переводе оригинала такое сопоставление произвести. К тому же существующие современные методики создания программных систем от ведущих мировых производителей, основанных на использовании UML и других нотациях, к сожалению, большинству отечественных разработчиков в оригинале просто не доступны.
Как печальный итог, использование терминов и понятий UML, по существу представляющих собой ошибки отечественных переводчиков, в недостаточной мере знакомых с процессами создания АС, привели к тому, что в различных средствах информации появились статьи, книги, модели и прочие источники, имеющие откровенные ошибки в трактовке процессов, моделей, документов, связанных с созданием АС. Особенно это явно проявилось при описании предметной области и определения требований к АС.
В данной статье представлен способ описания функциональных требований к АС и ее функций с использованием стандартов в области информационных технологий, современных методологий создания АС, и диаграмм "Use Case Diagram" и "Actvity Diagram" универсального языка моделирования UML 2.0. Авторы рассчитывают, что использование "Use Case" в контексте определения требований в соответствии со стандартами создания АС приобретет большую ясность.
Итак, рассмотрим процесс определения требований согласно действующим отечественным стандартам.
При использовании стандартов создания АС в соответствии с [1, 2] на стадии "Техническое задание" в документе техническое задание (ТЗ) фиксируются функциональные и нефункциональные требования к АС. Схема функциональной структуры АС разрабатывается на стадии "Эскизное проектирование" и "Техническое проектирование", описание автоматизируемых функций АС производится на стадии "Техническое проектирование".
При разработке АС в соответствии с [1] должны быть отслежены связи между функциональными требованиями к системе и функциями системы, их реализующими. Функции системы в свою очередь должны быть детально описаны.
В табл. 1. представлены стадии работ по созданию АС и документы, формируемыми на стадиях, связанных с описанием требований и функций [1-3].
Как видно из табл. 1, создание АС на стадиях 3-5, подразумевает подготовку:
- технического задания;
- предварительной схемы функциональной структуры системы (эскизное проектирование);
- окончательной схемы функциональной структуры (техническое проектирование);
- описания автоматизируемых функций системы.
Таблица 1. Стадии создания АС и документы, связанные с требованиями к АС и функциями, их реализующими
|
№ стадии по ГОСТ 34.601-90 |
Наименование |
Документы, модели, создаваемые на стадиях по ГОСТ 34.602-89, ГОСТ 34.201-89 |
ГОСТ, в котором описан документ |
|
3 |
Техническое задание |
Техническое задание (ТЗ) |
ГОСТ 34.602 |
|
4 |
Эскизное |
Схема функциональной структуры |
РД 50-34.698-90 п. 2.3. |
|
5 |
Техническое |
Схема функциональной структуры |
|
|
Описание автоматизируемых |
РД 50-34.698-90 п. 2.5 |
В соответствии с [4] ТЗ на АС есть документ, оформленный в установленном порядке и определяющий цели создания АС, требования к АС и основные исходные данные, необходимые для ее разработки, а также план-график создания АС.
В ТЗ определяются:
- требования к системе в целом;
- требования к функциям (задачам), выполняемым системой;
- требования к видам обеспечения.
Функциональные требования к системе определяют, действия системы, которые она должна выполнять. Функциональные требования реализуются через функции системы [5]. Под функцией АС подразумевается совокупность действий АС, направленная на достижение определенной цели или аспект определенного поведения системы [6], а под задачей - функция или часть функции АС, представляющая собой формализованную совокупность автоматических действий, выполнение которых приводит к результату заданного вида [4].
Не функциональные требования есть ограничения, накладываемые на работу системы, и стандарты, которым должна соответствовать система [5].
В схеме функциональной структуры [7] отображаются элементы функциональной структуры АС (подсистемы АС), автоматизированные функции и (или) задачи (комплексы задач), совокупности действий (операций), выполняемых при реализации автоматизированных функций только техническими средствами (автоматически) или только человеком.
В описании автоматизируемых функций [7] приводят:
- перечень подсистем АС с указанием функций и (или) задач, реализуемых в каждой подсистеме;
- описание процесса выполнения функций;
- необходимые пояснения к разделению автоматизированных функций на действия (операции), выполняемые техническими средствами и человеком.
Теперь рассмотрим определение требований с использованием понятия "Use Case". Как уже говорилось ранее, в стандарте UML отсутствует привязка к стадиям создания АС, однако, производители CASE - средств для работы с UML и методологий использования UML, как правило, предлагают схожие подходы к работе с требованиями.
Рассмотрим, например, подход компании Sparx System, являющейся производителем инструментария Еnterprise Architect, поддерживающим создание моделей предметной области и АС с использованием UML 2.0. Ими предложен шаблон модели требований, представленный на рис. 1. На рис. 2 представлен пример модели требования с использованием шаблона.
Как видно из шаблона модели требований и его примера для моделирования требований предлагается использовать элемент UML "Requirement". Для моделирования функций системы предлагается использовать элемент "Use Case". При этом элемент "Use Case" в описании UML, представленном в инструменте Еenterprise Architect, трактуется следующим образом: "Use Case elements are used to build Use Case models. These describe the functionality of the system to be built. Use Case Model describes a system's functionality in terms of Use Cases".
Другими словами, элемент "Use Case" используется для построения модели "Use case Model". Модель "Use case Model" используется для описания функциональности системы.
Под функциональностью системы в соответствии с [8] понимается совокупность свойств программного средства, определяемая наличием и конкретными особенностями набора функций, способных удовлетворять заданные или подразумеваемые потребности.
В спецификациях OMG UML ( UML Superstructure Specification, v2.0, p. 17 ) элемент "Use Case" определяется как: "The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system".
Другими словами, элемент "Use Case" определяет последовательность действий системы, которые она может выполнять, включая ее взаимодействие с пользователем системы.
Рис. 1. Способ моделирования требований к системе
Рис. 2. Пример реализации требования
В дополнении к сказанному выше, хотелось представить определение модели "Use Case Model" из популярного в нашей стране и за рубежом процесса разработки систем Rational Unified Process компании IBM: "The use-case model is a model of the system's intended functions and its environment …"[5] (рис. 3).
Рис. 3. Определение модели "Use Case Model"
Модель "Use case Model" есть модель предполагаемых функций системы и ее окружения, и служит контрактом между клиентами и разработчиками. Модель используется как существенные входные данные в деятельности по анализу, проектированию и тестированию.
В табл. 2 представлено сравнение определений схемы функциональной структуры в соответствии с ГОСТ и модели "Use Case Model", функции системы и элемента "Use Case" в соответствии с описанием UML 2.0.
Таблица 2. Сравнение определений моделей и их элементов
|
Определение схемы функциональной структуры |
Определение модели "UseCaseModel" |
|
В схеме функциональной структуры отображаются элементы функциональной структуры АС (подсистемы АС), автоматизированные функции и (или) задачи (комплексы задач), совокупности действий (операций), выполняемых при реализации автоматизированных функций только техническими средствами (автоматически) или только человеком |
Use Case elements are used to build Use Case models. These describe the functionality of the system to be built. Use Case Model describes a system's functionality in terms of Use Cases |
|
Определение функции |
Определение элемента "UseCase" |
|
Совокупность действий АС, направленная на достижение определенной цели. Описание процесса выполнения функции включает необходимые пояснения к разделению автоматизированных функций на действия (операции), выполняемые техническими средствами и человеком |
The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.
|
Сравнение определения схемы функциональной структуры с определением модели Use Case Model, определения функции системы и элементов "Use Case" показывает, что эти модели и элементы сопоставимы друг с другом.
Таким образом, для моделирования требований к АС мы будем использовать элемент требование "Requirement", а функций, реализующих требование, элемент "Use Case".
В соответствии с [2] описание функционального требования должно включать, связанные с требованием: функции системы, пользователей системы, печатные документы, импортируемые/экспортируемые данные, правила и ограничения, нефункциональные требования, связи между функциональными требованиями, экранные формы.
Предлагается описывать функциональное требование к системе и функции, его реализующие, с использованием следующего шаблона. Описание шаблона дано на примере описания конкретного требования.
Шаблон описания требования
Общие сведения о требовании
|
1. |
Требование |
Должно быть автоматизировано формирование отчета об остатках товара |
|
2. |
Цель, которая будет |
Оперативное получение информации о текущих остатках на складе компании |
|
3. |
Причина возникновения |
Требование руководителя компании |
|
4. |
Пользователи, которым |
Руководитель компании |
|
5. |
Источник данных (ручной ввод, использование записей БД, данных из смежной системы) |
Отчет должен формироваться на основе записей в базе данных, содержащих информацию о количестве остатков товара на складе |
|
6. |
Правила, связанные с |
Отчет формируется в двух экземплярах |
Функции, реализующие требования
|
№ |
Название функции |
|
1. |
Формирование отчета "Остатки товара" |
Связи между требованием и функциями
В разделе должно быть представлена модель, отображающая связи между требования и функциями, реализующими требование, и если требуется, описание связей. Модель "Требование и функции":
Описание процесса выполнения функции
В разделе должны быть представлены модели процесса выполнения функции и их описание. Основные этапы формирования отчета:
Поиск товара:
Печать отчета:
Состав, экранных форм, связанных с функцией
|
№ |
Название экранной формы |
|
1. |
Главное меню |
|
2. |
Создать отчет |
|
3. |
Товар не найден |
|
4. |
Предварительный вид отчета |
|
5. |
Сообщение о печати |
Описание печатных форм
|
№ |
Название печатной формы |
|
1. |
Отчет об остатках |
Описание импортируемых/экспортируемых данных (импортируемых данных нет)
|
№ |
Импортируемые данные |
|
1. |
|
№ |
Экспортируемые данные |
|
1. |
Нефункциональные требования, связанные с функциональным требованием
Временной регламент
Если требуется в разделе указывается время выполнения функции. Время формирования отчета не должно превышать 5 сек.
Надежность
Если требуется в разделе указывается требования к надежности выполнения функции.
Точность
Если требуется, в разделе указывается требования к характеристики необходимой точности выполнения функции.
Достоверность
Если требуется, в разделе указывается требования к достоверности результатов выполнения функции.
Связи с другими функциональными требованиями
Если требуется, в разделе указываются связи между требованиями.
Данный шаблон рекомендуется использовать при создании документа "Описание автоматизируемых функций" и схемы функциональной структуры. Использование шаблона существенно облегчит понимание требований системы и их реализации, как со стороны заказчика, так и со стороны разработчика, что позволит в свою очередь уменьшить количество ошибок, связанных с неправильно определенными требованиями.
В заключении нам хотелось бы отметить, что перед применением UML для описания предметной области и систем необходимо изучить методики бизнес моделирования и разработки систем, которые предполагается использовать, и лишь затем перейти к созданию соглашений по моделированию с использованием UML. На наш взгляд, это конструктивный путь позволяющий избежать методических проблем, связанных с трактовкой терминов, а также обеспечить эффективное использование возможностей UML.
