CC BY
177
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ
УДК 004.415.2
Е.А. Черткова КОНЦЕПЦИЯ СПЕЦИФИКАЦИИ ТРЕБОВАНИЙ ДЛЯ ПРОЕКТИРОВАНИЯ КОМПЬЮТЕРНЫХ ОБУЧАЮЩИХ СИСТЕМ
Изложен подход к специфицированию требований к компьютерным обучающим системам методом визуального моделирования на основе использования прецедентов. В качестве базового процесса выбран универсальный процесс (Rational Unified Process), направляющий создание артефактов как представлений системы с заданными требованиями. Показано, что полное представление системы возможно только через совокупность визуальных моделей состояния, поведения и изменения состояний.
E.A. Chertkova COMPUTERS SYSTEMS DESIGN SPECIFICATION CONCEPTION REQUIREMENTS
This work contains an approach of the requirements specifications for computer education systems, using the visual modeling method, based on the use cases. The Rational Unified Process was selected as a base process, guiding the creation of the artifacts, to serve as a representation of the system with all the requirements needed. As it is shown in this work, the full representation of the system is possible, only if all the conditions, behavior and condition changes visual models are included.
Введение
Составной частью компьютерных технологий обучения являются электронные средства обучения с программными компонентами, в том числе - компьютерными обучающими системами, которые относятся к классу программных систем.
Для современных крупных проектов в этой области характерны, как правило, большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними, требующие тщательного моделирования и анализа. Информационные и программные компоненты компьютерной обучающей системы имеют локальные задачи и цели функционирования (например, модуль генерации учебно-тренировочных заданий, модуль представления
моделей обучаемых и протоколов их работы) и т.д. При этом должно осуществляться взаимодействие модулей в рамках единой программной системы.
Как отмечают ведущие специалисты в области разработки программного обеспечения и, в частности, компьютерных обучающих систем, технологический этап проектирования является наиболее сложным, так как на этом этапе трудно осуществить формализацию задач проектирования. Это обусловливает актуальность разработки новых методов автоматизированного проектирования компьютерных обучающих систем как одного из приоритетных направлений современного этапа развития образовательной сферы [1].
Несмотря на большое разнообразие подходов, методов и технологий создания программных систем, существуют базовые процессы, реализуемые в ходе разработки программных продуктов. Фундаментом любой программной системы является спецификация ее функций и действий, формирование которой обычно называют «разработка требований». При специфицировании требований осуществляется формализация всей совокупности информации по требованиям с пошаговым наращиванием уровня детализации моделей системы.
Данная статья посвящена разработке концепции специфицирования функциональных требований к компьютерным обучающим системам с использованием языка визуального моделирования Unified Modeling Language (UML).
В качестве основы объектной технологии проектирования выбран процесс Rational Unified Process (RUP), назначение которого - повышение результативности проекта, выраженной в экономической эффективности, создании системы высокого качества и успешного внедрения [2].
Проблема требований
Системы программного обеспечения по своей природе являются неосязаемыми, абстрактными, сложными и, по крайней мере, в теории, бесконечно изменяемыми. Поэтому, когда заказчик высказывает требования к системе нечетко, он предполагает, что впоследствии сможет их уточнить, изменить и дополнить.
Для отечественной индустрии создания программных систем, в том числе и компьютерных обучающих систем, нет статистических данных о влиянии различных типов проблем разработки на бюджет и сроки проектов. Однако зарубежная статистика показывает, что устранения ошибок в определении требований к системе в процессе разработки в зависимости от этапа жизненного цикла проекта могут достигать от 30 до 50% общего бюджета разработки. При этом, несмотря на дополнительные вложенные средства, выполнение 25-33% проектов не завершается [3].
В середине 90-х гг. ведущими зарубежными аналитиками были проведены исследования состояния индустрии разработки программного обеспечения, которые свидетельствуют, что с начала 70-х годов наблюдается кризис программирования, впервые отмеченный в США. Для этого кризиса характерен чрезвычайно низкий процент успешных проектов по созданию программного обеспечения. Наиболее полными и значимыми явились исследования компании Standish Group, организации ESPITI (European Software Process Improvement Training Initiative - Европейская инициатива по обучению совершенствования процесса программирования) и Каперса Джонса.
Известны результаты исследований компании Standish Group итогов выполнения более 23 тысяч проектов, связанных с разработкой в основном коммерческого программного обеспечения, в 364 американских компаниях. В отчете [4] представлены следующие основные выводы:
- 31% проектов, от общего числа изученных, оказались закрыты до своего завершения;
- 53% проектов по созданию программного обеспечения превысили свой первоначальный бюджет более чем на 50%;
- в больших компаниях только 9% проектов по созданию программного обеспечения были выполнены в срок и уложились в рамки бюджета. Для средних и малых компаний аналогичные значения возрастают до 16 и 28% соответственно.
В отчете Standish Group указаны три наиболее часто встречающихся ключевых фактора, создающих проблемы в проектах:
- недостаток исходной информации от клиента: 13% всех проектов;
- неполные требования и спецификации: 12% проектов;
- изменение требований и спецификаций: 12% всех проектов.
Таким образом, если считать, что приведенные в исследовании Standish Group цифры представляют реальное положение дел в программной индустрии, то осуществлению, по крайней мере, трети проектов препятствуют проблемы, непосредственно связанные со сбором и документированием требований, а также управлением ими.
Если в исследованиях Standish Group, как и в ESPITI, содержатся качественные данные о влиянии требований как фактора риска на разработку программного обеспечения, то в исследованиях К. Джонса даны количественные оценки последствий ошибок в требованиях [5]. Ошибки требований занимают первое место среди оставшихся недоработок и составляют примерно одну треть всех неустраненных дефектов.
Таким образом, эти исследования служат доказательством того, что ошибки требований - наиболее распространенная категория ошибок при разработке систем, а стоимость устранения таких ошибок, как правило, - одна из самых высоких.
Интерпретация и уровни требований
Одна из проблем, существующих в индустрии программного обеспечения, - это отсутствие общепринятых определений терминов, которыми мы пользуемся для описания нашей работы. Разные эксперты, говоря об одном и том же документе, называют его и требования пользователя, и требования к программному обеспечению, и функциональные требования, и т.п. Заказчики зачастую считают, что требования - это развитая концепция продукта, предназначенная для разработчиков. Те, в свою очередь, полагают, что это детальная разработка интерфейса пользователя. Универсального определения требований нет. В данной работе будем использовать определение требований, предложенное IEEE (Institute of Electrical and Electronics Engineers) и отраженное в стандарте «Standard Glossary of Software Engineering Terminology» как [6]:
1) условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2) условия или возможности, которыми должна обладать система или системные компоненты, чтобы удовлетворять стандартам, спецификациям или другим формальным документам;
3) документированное представление условий или возможностей для пунктов 1 и 2.
Для определения требований к разрабатываемой системе целесообразно рассмотреть
взаимодействие системы с пользователем, представив систему как «черный ящик», взаимодействующий с системной средой (рис. 1).
При этом полное определение системы возможно описывать по методу, предложенному Аланом Дэвисом, рассматривая следующие пять основных категорий элементов [7].
1. Вводы системы. Описывается содержимое ввода, а при необходимости и протокол ввода. Этот класс может содержать значительный объем сведений и подвергаться частым изменениям, особенно в средах графического пользовательского интерфейса, мультимедиа и Интернета.
2. Выводы системы. Описываются поддерживающие устройства вывода, такие как речевой вывод или видеотерминал, а также протокол и форматы генерируемой информации.
3. Функции системы. Отображение вводов в выводы и их различные комбинации.
4. Атрибуты системы. Типичные нефункциональные требования: надежность, удобство сопровождения, пропускная способность, которые должны учитывать разработчики.
5. Атрибуты системной среды. Дополнительные нефункциональные требования: способность системы функционировать в условиях определенных операционных ограничений и нагрузок, а также совместимость с операционной системой.
Ввод
О
Система
с>
Вывод
Атрибуты системной среды
Атрибуты
системы
Функции
Рис. 1. Элементы системы
Рассмотрение этих категорий элементов системы позволяет задать полный набор требований к программному обеспечению. Описание отличительных особенностей системы во многом напоминает высокоуровневые требования и тоже реализуется в виде утверждений, которые, однако, имеют более широкое содержание. Подробное описание отличительных особенностей системы может быть объективно проанализировано группой тестирования и выражено в различных требованиях. Если требование не удается протестировать, то в спецификацию оно не включается.
Для того чтобы требования были сосредоточены на поведении системы и изменялись только тогда, когда изменяется поведение, не следует указывать требования, не являющиеся необходимыми подробностями проектирования или реализации, а также информацию по управлению проектом и тестированию. Информацию, касающуюся вариантов проектирования или процессов, используемых при ее построении, целесообразно отделить от требований, описывающих внешнее поведение системы, и представить в специальном классе, называемом ограничениями проектирования.
Важно подчеркнуть следующее: в реальной деятельности по разработке требований и проектированию, поскольку процесс должен носить итеративный характер, выявление требований, их определение и принятие проектных решений циклически чередуются. То есть принятые требования приводят к выбору определенных вариантов проектирования, а те в свою очередь могут инициировать новые требования. Например, если в начальных требованиях для компьютерной обучающей системы был заложен модуль клиент/доступ к дан-ным/ОШ1, то альтернативой ему может явиться навигационный интерфейс, преимущества которого были выявлены на этапе проектирования. Именно в этом и состоит суть эффективного управления требованиями.
Принципы спецификации требований
Практика разработки сложных компьютерных обучающих систем показала, что полная и однократная формализация требований в начале жизненного цикла системы невозможна, прежде всего, из-за разных представлений заказчика и разработчиков о деталях назначения системы, функций и возможностей реализации при доступных ресурсах. Для полномас-
1 Graphic User Interfase - графический интерфейс пользователя.
штабного отражения требований к проекту системы необходимо формирование не единого однородного по формату документа требований, а совокупности спецификации требований. В соответствии с этим выводом рекомендуется осуществлять следующие этапы документирования и специфицирования требований.
Первым этапом является создание документа-концепции проекта, представляющего высокоуровневое определение системы и отражающего основные требования к системе заинтересованных лиц. Этот документ является основой общего понимания мотивов построения системы и создает договорную основу для более подробных технических требований.
На этапе создания концепции и системного анализа формируются цели разработки проекта компьютерной обучающей системы, выбираются методы и алгоритмы решения основных и функциональных задач, а также формулируются предварительные критерии качества создаваемых программ.
Вторым этапом всесторонней спецификации проектируемой системы является моделирование требований. В качестве входной информации выступают неформальные требования заказчиков, а результатом этого процесса являются модели спецификации проектных конструкций компьютерной обучающей системы [8].
Целесообразно разработать три категории моделей: модели состояний, модели поведения и модели изменения состояния. Эти модели дают более формальное определение различных сторон (представлений) системы:
- модели состояний детализируют требования к данным;
- модели поведения обеспечивают детализированные спецификации для функциональных требований;
- модели изменения состояния охватывают два вида требований, - они призваны отразить, каким образом действие функций приводит к изменению данных.
Современные объектно-ориентированные методы проектирования программных систем диктуют представление моделей в виде диаграмм на языке визуального моделирования (Visual Modeling Language) - в данной работе это язык UML. Обычно диаграмма служит целям моделирования одной из сторон системы - состояния, поведения или изменения состояния. Заметное исключение составляет диаграмма классов, которая определяет все три аспекта - состояние и поведение объектов, и, косвенно, изменения состояния объектов.
Конструирование диаграмм необходимо осуществлять в параллель, и в результате каждой последующей итерации к ним добавляются новые детали.
Каждая диаграмма дает представление об определенной стороне системы. Взятые вместе диаграммы дают возможность разработчикам и пользователям компьютерных обучающих систем взглянуть на предлагаемое решение с разных точек зрения, выделяя одни его стороны и игнорируя другие. Ни одна из диаграмм в отдельности не дает полного определения системы. Систему можно понять только через взаимосвязанный набор диаграмм.
Третьим этапом спецификации проектируемой системы является итерационная интерпретация завершенных моделей. В то время как разработчики должны следовать строго определенному процессу разработки, решение о том, какая из моделей должна играть роль «движущей силы» разработки, в значительной мере зависит от предпочтений аналитика. Опыт автора данной работы позволяет рекомендовать в качестве наиболее важных типов моделей при проектировании компьютерных обучающих систем диаграммы прецедентов и модели классов, которые целесообразно конструировать параллельно. При этом с каждой новой итерацией разработки глубина и степень детализации спецификации возрастает.
Специфицирование требований на основе прецедентов
Одним из методов описания поведения системы для современной методологии объектно-ориентированного проектирования является метод прецедентов (вариантов использо-94
вания) [8]. Прецеденты целесообразно использовать не только как средство описания требований к системе, но и на протяжении всего жизненного цикла программного обеспечения.
Основанный на прецедентах способ описания функциональных требований отражает взаимодействие пользователей с системой. Этот подход целесообразно использовать в рамках предлагаемой концепции специфицирования требований для проектирования компьютерных обучающих систем, поскольку именно прецеденты в языке моделирования UML являются представлением требований к системе.
Выявление прецедентов для компьютерной обучающей системы целесообразно осуществлять на основе анализа документа-концепции и рассмотрении акторов (actors)1 и их целей. При этом прецеденты представляют собой следующие компоненты общей модели системы:
- завершенный фрагмент функциональных возможностей (включая основной поток логики управления, его вариации и исключительные условия (альтернативные потоки);
- фрагмент внешненаблюдаемых функций;
- ортогональный фрагмент функциональных возможностей;
- фрагмент функциональных возможностей, инициируемый субъектом;
- фрагмент функциональных возможностей, который представляет субъекту ощутимый полезный результат, достигаемый в пределах одного прецедента.
Графическая модель прецедентов может сопровождаться неформальными описаниями, а также диаграммами последовательности и кооперации для отдельных прецедентов, примеры которых представлены на рис. 1 и 2.
* Ю О Q Q
Пользов...
1. Студент вводит в поля формы свое имя и пароль
Форма идентификации : Управление Профиль : Доступ : Права Интерфейс входа профилям... Проф... доступа
1: Прием имени и пароля(СИаг, char)
2. Интерфейсная форма передает полученные данные в управляющий класс
3. Запрос на поиск профиля по полученным данным
4. Поиск профиля с данным именем и паролем
5. Загрузка найденного профиля
6. Загрузка прав доступа к модулю, закрепленных за даннмы профилем
2: приемДанных(
3: наПоиск( j
Поиск( )
5: Загрузка()
6: Загрузка( )
Рис. 2. Диаграмма последовательности для прецедента «Идентификация»
4
Эти дополнительные описания и построение диаграмм следует выполнить для каждого прецедента. На основе этой информации можно прийти к обобщениям, необходимым для выявления потенциальных классов.
Предлагаемый подход специфицирования состояний, направляемый прецедентами, обладает следующей особенностью. После того, как выявлены прецеденты для проектируемой компьютерной обучающей системы, а представление о системе с точки зрения взаимо-
1 Понятием «актор» определяется то, что взаимодействует с нашей системой, например, пользователь или другая система.
действия определено с помощью диаграмм последовательности, объекты, используемые в этих диаграммах, приводят к выявлению классов.
Для лучшей стратегии реализации требований в проект системы по предложенному алгоритму в данной работе использован процесс ЯиР, который имеет концептуальную направленность перевода системных требований в виде диаграмм и спецификаций в технические инструкции реализации системы [2].
1: Прием имени и пароля(сИаг, с...
к——Ю
: Пользователь Форма идентификации : Интерфейс __________ _________входа_________
О
Управление профилями і Менеджер ______________профилей
Зі наПоиск( ) і 5і Загрузка( ) Л.
4і Поиск( )
А
I
6і Загрузка( )
Профиль : Профиль пользователя
Q
Доступ і Права доступа
Рис. 3. Диаграмма кооперации для прецедента «Идентификация»
Заключение
Исследование показало, что для эффективной реализации объектно-ориентированного проектирования компьютерных обучающих систем необходимо полномасштабное отражение требований к проекту системы, включающее высокоуровневое определение системы в виде документа-концепции и специфицирование требований в виде моделей системы.
Разработанные принципы специфицирования требований предполагают формализацию всей совокупности информации по требованиям с повышением уровня детализации моделей системы. Для представления различных сторон функционирования системы предлагается разработка трех категорий моделей: состояний, поведения и изменения состояния.
Предложен способ описания функциональных требований к компьютерным обучающим системам, основанный на прецедентах, которые являются представлением требований к системе в языке моделирования Unified Modeling Language. В качестве базового процесса использован Унифицированный процесс Rational Unified Process для создания артефактов проекта как представлений компьютерной обучающей системы с заданными требованиями.
ЛИТЕРАТУРА
1. Софиев А.Э. Визуальное моделирование компьютерных обучающих систем с использованием Unified Modeling Language / А.Э. Софиев, А.М. Вендров, Е.А. Черткова // Труды XII Всерос. науч.-метод. конф. «Телематика’2005». СПб., 2005. Т. 1. С. 255-256.
2. Якобсон А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. СПб.: Питер, 2002. 496 с.
3. Леффингуэлл Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход / Д. Леффингуэлл, Д. Уидриг; пер. с англ. М.: Издат. дом «Вильямс», 2002. 448 с.
4. The Standish Group. Charting the Seas of Information Technology - Chaos. The Standish Group International, 1994.
5. Jones C. Revitalizing Software Project Management / C. Jones // American Programmer 6, 7; June, 1994. Р. 3-12.
6. IEEE Std 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology. Los Alamitos, CA: IEEE Computer Society Press, 1990.
7. Davis A. Achieving Quality in Software Requirements / A. Davis // Software Quality Professional 1, 3; June, 1999. Р. 37-44.
8. Черткова Е.А. Применение объектно-ориентированного моделирования для разработки компьютерных обучающих систем / Е.А. Черткова // Технологии Интернет - на службу обществу: сборник статей по материалам Всерос. науч.-практ. конф. Саратов: СГТУ, 2005. С. 394-396.
Черткова Елена Александровна -
кандидат технических наук,
доцент кафедры «Техническая кибернетика и автоматика»
Московского государственного университета инженерной экологии
