Способ описания функциональных требований к системе и ее функций с использованием стандартов и универсального языка моделирования

Авторы:   Алфимов Р.В., Красникова С.А., Золотухина Е.Б. (сертифицированный специалист по решениям 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.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

Товар не найден: 10

5.     

Закрытие окна "Создать отчет"

Создать отчет

 

6.     

Отображение окна "Предварительный вид отчета"

Предварительный вид отчета

 

 

7.     

Нажатие кнопки "Печать"

Предварительный вид отчета

"Печать": 8

"Отменить": 9

8.     

Вывод отчета на печатающее устройство

Окно "Сообщение о печати"

9.     

Закрытие окна "Сообщение о печати" и "Предварительный вид отчета"

Окно "Сообщение о печати", Предварительный вид отчета

"Печать": П1

"Отменить": П3

Постусловие 1: Отображено окно "Создать отчет". Содержимое полей окна "Создать отчет" сохранило введенные пользователем значения. Отчет распечатан

 

10. 

Сообщение о том, что товар не найден, закрытие окна "Товар не найден"

Товар не найден

Постусловие 2: Отображено окно "Создать отчет". Содержимое полей окна "Создать отчет" сохранило введенные пользователем значения. Отчет не сформирован

 

Постусловие 3: Отображено окно "Создать отчет". Содержимое полей окна "Создать отчет" сохранило веденные пользователем значения. Отчет не распечатан

           

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Состав, экранных форм, связанных с функцией

Название экранной формы

1.  

Главное меню

2.  

Создать отчет

3.  

Товар не найден

4.  

Предварительный вид отчета

5.  

Сообщение о печати

 

 

 

Описание печатных форм

Название печатной формы

1.  

Отчет об остатках

 

 

Описание импортируемых/экспортируемых данных (импортируемых данных нет)

Импортируемые данные

1.  

      

 

Экспортируемые данные

1.  

        

 

Нефункциональные требования, связанные с функциональным требованием

Временной регламент

Если требуется в разделе указывается время выполнения функции. Время формирования отчета не должно превышать 5 сек.

Надежность

Если требуется в разделе указывается требования к надежности выполнения функции.

Точность

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

Достоверность

Если требуется, в разделе указывается требования к достоверности результатов выполнения функции.

Связи с другими функциональными требованиями

Если требуется, в разделе указываются  связи между требованиями.

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

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

Список литературы 

  1. ГОСТ 34.601-90 "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ";
  2. ГОСТ 34.602-89 "ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ";
  3. ГОСТ 34. 201-89. ВИДЫ, КОМПЛЕКТНОСТЬ И ОБОЗНАЧЕНИЕ ДОКУМЕНТОВ ПРИ СОЗДАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ;
  4. ГОСТ 34.003-90. "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ";
  5. IBM/RATIONAL UNIFIED PROCESS;
  6. ГОСТ Р ИСО/МЭК 15026-2002. ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. УРОВНИ ЦЕЛОСТНОСТИ СИСТЕМ И ПРОГРАММНЫХ СРЕДСТВ;
  7. РД 50-34.698-90. "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ";
  8. ГОСТ 28806-90. ГОСТ КАЧЕСТВО ПРОГРАММНЫХ СРЕДСТВ. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ;

 

 

 


Страница сайта http://test.interface.ru
Оригинал находится по адресу http://test.interface.ru/home.asp?artId=16728