Рассмотрение требований к языкам спецификации.

Первоисточник: http://www.csis.hku.hk/research/techreps/document/TR-89-09.pdf

Автор перевода: Губань Б.И.

Авторы: T.H. Tse and L. Pong**

Department of Computer Science

The University of Hong Kong

Pokfulam Road

Hong Kong

РЕЗЮМЕ

Рассмотрим особенности, которые наиболее желательны в языках спецификации, используя за основу 6 базовых языков: PSL, SADT, EDDA, SAMM, HOS и RSL.

Ключевые слова и фразы: Техническое задание, язык спецификации, системная разработка.

ВВЕДЕНИЕ

Техническое задание на информационную систему важно по нескольким причинам: оно служит в качестве средства связи между пользователем и разработчиком системы, и систематизировано представляет текущее состояние реального мира, его проблемы и будущие потребности; она позволяет разработчику системы, представить реальные мировые проблемы, в других формах, которые являются более управляемыми с точки зрения размера, сложности человеческого понимания и технологичности компьютера; оно служит в качестве основы для разработки, реализации, тестирования и обслуживания целевой системы. Для того, чтобы все цели технического задания были выполнены, мы нуждаемся в мощном языке спецификации. Целый ряд авторов (например, [9, 21, 13, 36, 38]) независимо предложил желательные функции языка спецификации. В разделе 2 данной статьи , мы объединим эти функции и представим их в контексте технологического процесса. Затем в разделе 3, мы используем предложенные функции в качестве основы для рассмотрения некоторых из представленных языков спецификации.

НЕОБХДИМЫЕ ХАРАКТЕРИСТИКИ ЯЗЫКА СПЕЦИФИКАЦИИ

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

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

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

Мы знаем, что есть авторы, которые могут возразить против наличия взгляда инженера на разработку информационных систем. Примеры - Checkland, Land and Mumford [5, 18, 23], которые расценивают развитие систем как процесс деятельности человека. Они предлагают, чтобы акцент был сделан по таким проблемам как понимание воздействий изменения, ориентируемого людьми на проект и пользовательское участие в течение процесса разработки. Было бы интересно понять, как наше предложение о желательных особенностях языка спецификации вписывается в эту альтернативную структуру. Однако это вне области данной работы.

АБСТРАКЦИЯ РЕАЛЬНОГО МИРА

Язык спецификации требований - средства, которыми пользователи могут сделать модель реального мира и определить его проблемы и требования. Это - мост между средой проектирования и пользователями, включая аналитиков систем, проектировщиков и конечных пользователей. Мы должны гарантировать, что этот интерфейс понятен ко всем затронутым. Обычная маркетинговая фраза "легкий в использовании" слишком размыта, чтобы руководством в разработке. Вместо этого мы считаем это существенным для языка, является наличие следующих свойств:

ДРУЖЕСТВЕННЫЕ ОТНОШЕНИЯ К ПОЛЬЗОВАТЕЛЮ ЯЗЫКА СПЕЦИФИКАЦИИ

Для пользователей было бы трудно использовать полностью новый язык спецификации требований из-за нескольких причин:

а) Есть инерционный эффект с точки зрения пользователей. Они не желают пробовать новый метод, с которым не знакомы.

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

В результате практики являются довольно колеблющимися, чтобы использовать новые инструменты, которые вовлекают незнакомый формальный язык [10, 20, 21]. Когда мы предлагаем новую среду проектирования систем, мы не должны изобретать полностью новый язык, с надеждой, что это, окажется лучшим в мире. Вместо этого мы должны попытаться использовать доступный язык спецификации, который имеет больше всего преимуществ и уже доказал популярность среди практиков.

ЯЗЫКОВОЙ СТИЛЬ

а) Текстовый язык

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

С другой стороны, требования, определенные на естественном языке, могут вызвать двусмысленности, так как они могут быть интерпретироваться по разному различными людьми. Как указано DeMarco [11] и других работах, стандартная английская проза не является подходящей даже для спецификаций, которые обработаны вручную. Языки, у которых есть лучший определенный синтаксис и немного более ограничительная семантика, были бы более предпочтены. Эти языки более формальны в природе и напоминают язык программирования или математический язык.

б) Графический язык

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

Графика находится в двух измерениях, в то время как текст находится в одном измерении. Что дает дополнительную степень свободы в представлении.

Графика более полезна в показе иерархической структуры сложных систем и более

естественна в описании параллелизма.

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

Есть предел числу понятий, которые могут разумно быть проведены в краткосрочной памяти о человека [22]. Человек, читающий графику, может смотреть поверхностно и углубиться, чтобы детализировать после некоторой степени ознакомления. Если ты читаешь текст, то нужно читать с деталями и резюмировать скелетные понятия впоследствии.

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

в) Гибридные языки

Зачастую непрактично определять спецификацию требований только с точки зрения единственного графического или текстового языка. Хотя графические языки лучше чем текстовые языки в представлении краткого обзора сложной ситуации, текстовые языки расценены как лучшие инструменты для детального описания. Хотя у формальных языков есть точная семантика, их значения часто объясняются через естественные языки. поэтому мы нуждаемся в языке, который существует больше чем в одном формате. Разумное подмножество спецификации, по крайней мере в более высоких уровнях абстракции, должно существовать и как формальные и неофициальные версии. Спецификация должна быть конвертируемой от одной формы к другой так, чтобы пользователи, аналитики, проектировщики, конструкторы и менеджеры могли общаться эффективно. Человек должен рассматривать только ту версию, которая самым соответствующим образом подходит его пониманию и его потребностям. Формальная непосредственная корреспонденция должна быть поддержана среди различных синтаксисов языка спецификации, так, чтобы не было никакой ошибки или спора.

СЛОЖНОСТЬ

Как указано в [39], сложность - главный барьер к пониманию проблем системы. Язык спецификации требований должен обеспечить средство для улучшения концептуальной ясности проблем. Есть два способа достигнуть этой цели:

а) Разделение Логических и Физических Особенностей

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

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

б) Многоуровневая абстракция

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

Чтобы позволить пользователям связать спецификацию требований с реальными проблемами, язык спецификации должен помочь им усовершенствовать целевую систему естественным способом. Целевые подсистемы должны быть настолько отдельными насколько возможно. Интерфейс между любыми двумя подсистемами должен быть сведен к минимуму, но определен явно. Это уменьшит сложность, избежит неправильного понимания, и сделает возможным анализ двух подсистем различными людьми. Модули системы, созданные таким образом, могут быть общими компонентами многократного использования, независимыми от родительских модулей, вызывающих их. Кроме того, конечный механизм должен быть встраиваемым в среду проектирования, чтобы помочь пользователям проверить, действителен ли каждый логический шаг обработки и может ли группа дочерних модулей точно заменить соответствующий родительский модуль.

МОДИФИЦИРУЕМОСТЬ

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

МАНИПУЛЯЦИЯ ПРЕДСТАВЛЕНИЙ

ИНСТРУМЕНТЫ ДЛЯ МАНИПУЛЯЦИИ

а) Формализм

Чтобы устранить проблемы двусмысленности во время построения и выполнения целевой системы, спецификация требований должна быть выражена в точном описании с уникальной интерпретацией. Должна присутствовать формальная структура. Это помогает уменьшить вероятность недоразумения между различными проектировщиками. В то же самое время, автоматизированные инструменты, основанные на формальной структуре, могут использоваться, чтобы утвердить последовательность и законченность спецификации. Кроме того, учитывая сложность и область современных систем, ручные методы развития и обслуживания очень неэффективны. Фазы выполнения и обслуживания могут быть сделаны "автоматизированными" более легко, если присутствует формальная структура.

б) Жёсткость

Разработка систем, поскольку это осуществляется в подарке, испытывает недостаток в теоретическом фоне. В других технических дисциплинах инженеры могут предоставить пользователям гарантируемую степень уверенности, сопоставляя практику с теорией, следовательно гарантируя, что продукт без ошибок. Для разработчика систем невозможно так сделать [26]. Чтобы решить проблему, процесс развития систем должен быть поддержан теорией, так, чтобы правильность выполнения могла быть доказана и проверена против пользовательскими требованиями. Множество теоретических методов уже доступно в информатике для проверки правильности программного обеспечения. Мы должны быть уверены, что язык спецификации требований поддержан математическим фондом и может быть использован в соответствующих методах.

ПРЕОБРАЗОВАНИЯ

а) Поддержка различных ситуаций разработки

В [8, 19, 31] оговорено, что различные модели необходимы для различных ситуаций развития в зависимости от окружающей среды, акцента и стадии развития. Например, иерархическая диаграмма может быть полезной как краткий обзор целевой системы. Другая модель, показывая алгоритмические детали может быть более полезна при выполнении. Третья модель в математической форме может использоваться для того, чтобы доказать правильность выполнения. Таким образом спецификации требований могут быть преобразованы от одного стиля или примечания в другой. Это поднимает проблему определения, эквивалентны ли модели фактически в семантике. Это та причина, почему модели должны быть поддерживать жёсткость.

б) Прозрачность Формализма

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

НЕЗАВИСИМОСТЬ ПРОЕКТА И ВЫПОЛНЕНИЯ

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

КОНСТРУКЦИЯ РЕАЛЬНОЙ СИСТЕМЫ

Спецификация требований может быть рассмотрена как контракт между пользователем и разработчиком систем. Во время постройки целевой системы у нас должно быть независимое средство решения, выполнил ли разработчик контракт. Элементы в спецификации должны вести к завершению проекта и его выполнению. Другими словами, механизм перекрёсной ссылки должен быть обеспечен на языке спецификации, чтобы помочь нам проверить последовательность между указанной системой и конечной версией. Это позволяет нам проверить, что все функции и определенные ограничения выполнены в разработанной системе. Это также гарантирует, что операции в законченной системе отвечают требованиям, описанным в спецификации. Кроме того, в случае выполнения в автоматических генераторах объектного кода, таких как Информационные Средства Разработки, механизм перекрёсной ссылки должен также быть автоматизирован.

3 ОБЗОР ЯЗЫКОВ СПЕЦИФИКАЦИИ ТРЕБОВАНИЙ

В этой секции мы рассматриваем шесть языков спецификации требований, а именно, PSL, SADT, EDDA, SAMM, HOS и RSL, которые были отобраны для исследования по следующим причинам:

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

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

в) Они все еще активно используются при разработке.

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

д) Заключительная причина - прагматическая. Мы включали некоторые языки, потому что они знакомы авторам.

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

ЯЗЫК ОПИСАНИЯ ПРОБЛЕМЫ (PSL)

PSL [34, 33] был разработан проектом ISDOS в университете Мичигана и в настоящее время является коммерческим продуктом, выставленным на продажу ISDOS Inc., Это была часть первого главного проекта в определении языка спецификации требований формально и его анализе автоматически. Операторы PSL покрывают системную структуру, потоки данных, структуры данных, системное поведение и руководство проектом. Их синтаксисы и семантика формально основаны на подходе связи сущностей [6]. Описательные комментарии на естественном английском языке могут также быть включены, чтобы увеличить удобочитаемость. Пример PSL показан в иллюстрации 2.

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

PSL не был спроектирован для какой либо специфической методологии разработки систем. Когда были сделаны попытки использовать PSL как входной язык в Системном Алгоритме Оптимизации и Дизайна [24, 25], он должн был быть изменён, чтобы удовлетворить среде. Впоследствии была разработана система META/GA [34, 37], чтобы решить проблему. Вместо использования стандартизированного PSL для всех приложений, формальное описание нестандартного PSL может быть определено для данной разработки переведено к МЕТА системе. Описания систем могут быть сформулированы в новой спецификации PSL. Этот подход был проверен на структурных методологиях [11, 16, 40], и результаты положительны. Основной пользовательский интерфейс, однако, все еще формален.

СТРУКТУРНАЯ МЕТОДИКА АНАЛИЗА И ПРОЕКТИРОВАНИЯ (SADT)

SADT [12, 30] был разработан SofTech Inc., спецификация составлена из иерархии диаграмм SADT, каждая из которых является сетью полей, представляющих действия, как показано в иллюстрации 3. Стрелки в четырех сторонах каждого блока представляют Ввод, Вывод, Управление и Механизм для вовлеченной деятельности. Действия и данные ввода-вывода могут анализироваться нисходящим видом согласно строгим синтаксическим и семантическим правилам, так, чтобы могла быть определена многоуровневая спецификация. Схема индексации представлена так, чтобы отношения полей и стрелок на различных уровнях могли быть легко прослежены.

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

SADT обеспечивает графическое средство проблем и их решений. Спецификация может быть изменена и прослежена на целевую систему, но очень зависит от дизайна конечной системы. Хотя SADT предоставляет аналитикам систем полезную визуальную помощь, большое количество (приблизительно 40) примитивных конструкций вносят определенные препятствия для пользовательского понимания. Кроме того, понятие Механизма может ввести в заблуждение аналитиков имеющих дело с физическими проблемами реализации.

Несмотря на сложную природу графических примечаний, SADT был проектирован только для ручной разработки систем. Нет никакого основного формализма. Любой язык может использоваться как внедренный язык. Правила для анализа последовательности и законченности спецификации не описаны. "Очевидные" требования могут быть опущены. Следовательно нет никакой гарантии гладкого перехода к автоматическим средам проектирования.

EDDA

DDA [35] является попыткой усовершенствовать SADT, включающей математические формализмы, для того чтобы статические и поведенческие свойства спецификации могли быть проанализированы автоматически. EDDA существует в двух формах: графический G-EDDA предназначенной для человеческого понимания и символической S-EDDA для компьютерной обработки. Он фактически идентичен SADT. Пример показан в иллюстрации 4. Так как у двух форм есть соответствующие синтаксисы и идентичная семантика, они могут быть легко преобразованы из одного в другой. Расширенная сеть Петри [28, 29] используется как математическая модель для формального семантического определения. Переходы в сетях Петри соответствуют действиям в SADT, а позиции в сетях Петри соответствуют элементам данных. Для поддержки сложной структуры SADT, EDDA расширяет понятие сетей Петри, включая предикаты и окрашенные лексемы при переходах и позициях. Время задержки и вероятности активации также включены для анализа поведенческих свойств целевых систем.

EDDA - попытка добавить формализм к существующему графическому языку. У него есть все позитивные характеристики SADT. Кроме того, у него есть текстовое представление, которое находится во взаимно-однозначной корреспонденции графическому представлению. Язык формален с математической моделью, прозрачной пользователям. Спецификации являются поддающимися изменению и могут быть прослежены на целевые системы, но как SADT, они весьма зависят от дизайна процесса конечных систем. У EDDA есть три главных недостатка:

а) Он ограничен SADT и не может быть связан с другими структурными методологиями.

б) Не каждые из 40 особенностей SADT имеют сетевую копию Петри. Даже там, где такая связь существует, большое количество понятий и примечаний препятствует пользовательскому пониманию.

в) Даже если пользователь знаком с SADT, он должен изучить полностью новый текстовый язык S-EDDA.

СИСТЕМАТИЧЕСКИЙ МЕТОД МОДЕЛИРОВАНИЯ ДЕЯТЕЛЬНОСТИ (SAMM)

SAMM [17, 27, 32] был разработан Boeing Computer Services Co., языковая конструкция - комбинация графики и теоретических нотаций. Целью языка была машинная обработка. Спецификация состоит из контекстного дерева диаграмм деятельности и диаграмм условия. Типовое контекстное дерево показано на иллюстрации 5 (a). Язык является описанием для диаграмм деятельности, выраженных в иерархической форме. Типовые диаграммы деятельности показаны на иллюстрации 5 (б). Язык определяет отношения между действиями и потоками данных. Хотя он подобен диаграммам SADT по внешности, диаграмма деятельности не показывает Управления или Механизмы. Подробные действия и данные определены через таблицы данных и диаграммы условий (рисунок 5 (б) и (в)), которые объясняют описания и структурируют данные ввода-вывода.

Каждый элемент SAMM может быть сформулирован математически. Математические модели позади деревьев контекста и диаграмм деятельности маркированы деревьями и направленными графами, соответственно. Полное описание систем, таким образом, является структурой дерева, узлы которго, в свою очередь, есть графы потока. Таким образом, чтобы проанализировать спецификацию, может быть применена теория деревьев и графов. Последовательность спецификации, можно проверить, проверяя, является ли каждая диаграмма деятельности связанным графом и достижима ли каждая вершина от некоторого входной вершины за конечное число переходов.

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

3.5 HIGHER ORDER SOFTWARE (HOS)

HOS [14, 15] является языком спецификации требований, разработанным Higher Order Software Inc, чтобы поддержать автоматизацию методологии HOS, также известной как функциональная модель жизненного цикла. Язык был известен первоначально как AXES, а название, HOS было популяризирован Джеймсом Мартином [20, 21].

HOS спроектирован, чтобы поддержать весь процесс разработки систем и генерировать доказуемо правильное описание системы. Он основана на формальной модели, созданной на ряде математических аксиом. HOS представляет систему как двоичное дерево, назваемое картой управления, как показано в иллюстрации 6. Каждый модуль в системе - математическая функция, представлена как узел двоичного дерева. Ввод и вывод модулей представлен доменами и cубдоменами функций. Дерево также описывает, как функции переходят в подфункции. Методы декомпозиции определены математически. Среда проектирования [1, 15] была сделана для обработки декомпозиции и сгенерирации кода, бравильность которых может быть доказана автоматически. Таким образом, формально поддержана многоуровневая спецификация. Древовидная структура может быть далее динамически преобразована в граф, который полезен для понимания поведенческих свойств целевой системы.

HOS существует в двух эквивалентных формах — графической и текстовой. Есть взаимно-однозначная связь между этими двумя представлениями, таким образом одно представление может быть преобразовано в другое или прослеженной через другого. Логические характеристики систем отделимы от физических. Спецификации являются независимыми от дизайна и реализации, и легко поддаются изменению. Язык формален и математически обоснован. К сожалению, хотя HOS пытается скрыть математику от пользователя, результат не кажется естественным. Например, ввод и вывод процесса сопровождается стандартными математическими функциями.

3.6 ЯЗЫК ОПЕРАТОРОВ ТРЕБОВАНИЙ (RSL)

RSL [2, 3, 4] был разработан TRW Defence and Space Systems Group. Он определяет программные требования с точки зрения обработки путей, каждый из которых представляет последовательность обработки шагов, подключающих прибытие входного сообщения (или стимула) к поколению соответствующего сообщения вывода (или ответа). Каждый шаг обработки известен как Альфа.

Пути обработки и шаги представлены в графической форме, известной как сети требований или просто R-сети, как показано в иллюстрации 7. Чтобы поддержать пошаговое усовершенствование в разработке систем, описание любой Альфы в R-сети может быть заменено многими более низкими Альфами. В отличие от SADT, если проектировщики RSL захотят, чтобы конечная документация генерировалась только в одном уровне, а не как иерархия R-сетей, промежуточные шаги декомпозиции могут быть не зарегистрированы. И только плоская сеть будет показана в конечной форме.

RSL может также быть представлен в текстовой форме. Операторы состоят из четырех основных конструкций, а именно, элементов, отношений, атрибутов и структур. Первые три конструкции определяют непроцедурные аспекты требований в стиле, подобном подходу связи сущностей. Структуры используются, чтобы определить поведенческие требования системы. Графические и текстовые представления RSL эквивалентны. Операторы структуры - фактически результат проектирования R-сетей в одномерном пространстве. Таким образом, R-сети могут быть определены явно через интерактивный графический инструмент, или неявно через операторы структуры.

Математический формализм RSL прозрачен для пользователя. Логические характеристики целевых систем могут быть отделены от физических характеристик. Спецификации являются независимыми от дизайна и реализации, поддающимися изменению и могут быть прослежены на целевые системы. Главный недостаток RSL состоит в том,что он хоть и поддерживает пошаговое усовершенствование, но не отражает полученное в документации. Конечная спецификация в ее плоской форме может быть непонятна пользователям, которые не были связаны с процессом разработки.

4. ЗАКЛЮЧЕНИЕ

Мы исследовали желательные особенности языков спецификации требований и использовали их как основание для того, чтобы делать обзор шести установленных языков. Резюме показано в Таблице 1. В большинстве исследованных языков были предложены формальные и/или математические описания для разработки информационных систем. Также было предложено использование графики, чтобы дополнить (кроме SAMM) текстовыми языками для определения подробностей. Проблема сложности целевых систем также была исследована. Иерархическая основа используется в большинстве спецификаций (кроме RSL) и логические характеристики целевых систем отделимы от физических.

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

Только один проект, обсуждаемый в этой статье, использует понятие использования существующего языка как отправная точка для математической структуры. Это SADT. Хотя он используется как графический язык для EDDA, но EDDA не столь популярен как другие структурные инструментальные средства из-за сложности его графических примечаний. Кроме того, EDDA принимает только текстовый ввод и генерирует графику впоследствии, и следовательно формализм не прозрачен пользователю.

БЛАГОДАРНОСТИ

Авторы обязаны Профессору Иану Анджеллу, Профессору Берни Коэну, Профессору Джону Кэмпбэлу и Профессору Рональду Стэмперу для их ободрительных комментариев и предложений.

ССЫЛКИ

[1] USE.IT Reference Manual, Higher Order Software, Inc., Cambridge, Massachusetts (1982).

[2] M.W. Alford, ‘‘The software requirements methodology (SREM) at the age of four’’, in Proceedings of the 4th Annual International Computer Software and Applications Conference (COMPSAC ’80), IEEE Computer Society Press, New York, pp. 866−874 (1980).

[3] M.W. Alford, ‘‘Software requirements engineering methodology (SREM) at the age of two’’, in Advanced System Development / Feasibility Techniques, J.D. Couger, M.A. Colter, and R.W. Knapp (eds.), Wiley, New York, pp. 385−393 (1982).

[4] M.W. Alford, ‘‘SREM at the age of eight: the distributed computing design system’’, IEEE Computer 18 (4): 36−46 (1985).

[5] P.B. Checkland, System Thinking, System Practice, Wiley, New York (1981).

[6] P.P. Chen, ‘‘The entity-relationship model: towards a unified view of data’’, ACM Transactions on Database Systems 1 (1): 9−36 (1976).

[7] B. Cohen, W.T. Harwood, and M.I. Jackson, The Specification of Complex Systems, Addison Wesley, Wokingham, UK (1986).

[8] M.A. Colter, ‘‘Evolution of the structured methodologies’’, in Advanced System Development / Feasibility Techniques, J.D. Couger, M.A. Colter, and R.W. Knapp (eds.), Wiley, New York, pp. 73−96 (1982).

[9] M.A. Colter, ‘‘A comparative examination of systems analysis techniques’’, MIS Quarterly 10 (1): 51−66 (1984).

[10] A.M. Davis, ‘‘The design of a family of application-oriented requirements languages’’, IEEE Computer 15 (5): 21−28 (1982).

[11] T. DeMarco, Structured Analysis and System Specification, Yourdon Press Computing Series, Prentice Hall, Englewood Cliffs, New Jersey (1979).

[12] M.E. Dickover, C.L. McGowan, and D.T. Ross, ‘‘Software design using SADT’’, in Structured Analysis and Design, State of the Art Report, J. Hosier (ed.), vol. 2, Infotech, Maidenhead, UK, pp. 99−114 (1978).

[13] R. Rock-Evans (ed.), Analyst Workbenches, State of the Art Report, Infotech Pergamon, Maidenhead, UK (1987).

[14] M. Hamilton and S. Zeldin, ‘‘Higher order software: a methodology for defining software’’, IEEE Transactions on Software Engineering SE-2 (1): 9−36 (1976).

[15] M. Hamilton and S. Zeldin, ‘‘The functional life cycle model and its automation: USE.IT’’, Journal of Systems and Software 3 (3): 25−62 (1983).

[16] M.A. Jackson, System Development, Prentice Hall International Series in Computer Science, Prentice Hall, London (1983).

[17] S.S. Lamb, V.G. Leck, L.J. Peters, and G.L. Smith, ‘‘SAMM: a modeling tool for requirements and design specification’’, in Proceedings of the 2nd Annual International Computer Software and Applications Conference (COMPSAC ’78), IEEE Computer Society Press, New York, pp. 48−53 (1978).

[18] F.F. Land and R.A. Hirschheim, ‘‘Participative systems design: rationale, tools, and techniques’’, Journal of Applied Systems Analysis 10: 91−107 (1983).

[19] R.J. Lauber, ‘‘Development support systems’’, IEEE Computer 15 (5): 36−46 (1982).

[20] J. Martin, Program Design which is Pro vably Correct, Savant Institute, Carnforth, Lancashire, UK (1983).

[21] J. Martin, An Information Systems Manifesto, Prentice Hall, Englewood Cliffs, New Jersey (1984).

[22] G.A. Miller, ‘‘The magic number seven, plus or minus two: some limits on our capacity for processing information’’, Psychological Review 63: 81−97 (1956).

[23] E. Mumford, Designing Human Activity Systems, Manchester Business School, Manchester (1983).

[24] J.F. Nunamaker, Jr., ‘‘A methodology for the design and optimization of information processing systems’’, in System Analysis Techniques, J.D. Couger and R.W. Knapp (eds.), Wiley, New York, pp. 359−376 (1974).

[25] J.F. Nunamaker, Jr., B.R. Konsynski, Jr., T. Ho, and C. Singer, ‘‘Computer-aided analysis and design of information system’’, Communications of the ACM 19 (12): 674−687 (1976).

[26] D.L. Parnas, ‘‘Software aspects of strategic defense systems’’, American Scientist 73: 32−440 (1985).

[27] L.J. Peters and L.L. Tripp, ‘‘A model of software engineering’’, in Proceedings of the 3rd International Conference on Software Engineering (ICSE ’78), IEEE Computer Society Press, New York, pp. 63−70 (1978).

[28] J.L. Peterson, Petri Net Theory and the Modeling of Systems, Prentice Hall, Englewood Cliffs, New Jersey (1981).

[29] W. Reisig, Petri Nets: an Introduction, EATCS Monographs on Theoretical Computer Science, vol. 4, Springer, Berlin (1985).

[30] D.T. Ross and K.E. Schoman, ‘‘Structured analysis for requirements definition’’, in Classics in Software Engineering, E. Yourdon (ed.), Yourdon Press Computing Series, Prentice Hall, Englewood Cliffs, New Jersey, pp. 365−385 (1979).

[31] O. Shigo, K. Iwamoto, and S. Fujibayashi, ‘‘A software design system based on a unified design methodology’’, Journal of Information Processing 3 (3): 186−196 (1980).

[32] S.A. Stephens and L.L. Tripp, ‘‘Requirements expression and verification aid’’, in Proceedings of the 3rd International Conference on Software Engineering (ICSE ’78), IEEE Computer Society Press, New York, pp. 101−108 (1978).

[33] D. Teichroew and E.A. Hershey III, ‘‘PSL / PSA: a computer-aided technique for structured documentation and analysis of information processing systems’’, in Advanced System Development / Feasibility Techniques, J.D. Couger, M.A. Colter, and R.W. Knapp (eds.), Wiley,New York, pp. 315−329 (1982).

[34] D. Teichroew, P. Macasovic, E.A. Hershey III, and Y. Yamamoto, ‘‘Application of the entityrelationship approach to information processing systems modelling’’, in Entity-Relationship Approach to Systems Analysis and Design: Proceedings of the 1st Conference on Entity- Relationship Approach, P.P. Chen (ed.), North-Holland, Amsterdam, pp. 15−39 (1980).

[35] W. Trattnig and H. Kerner, ‘‘EDDA: a very-high-level programming and specification language in the style of SADT’’, in Proceedings of the 4th Annual International Computer Software and Applications Conference (COMPSAC ’80), IEEE Computer Society Press, New York, pp. 436−443 (1980).

[36] A.I. Wasserman, P. Freeman, and M. Porcella, ‘‘Characteristics of software development methodologies’’, in Information Systems Design Methodologies, a Feature Analysis: Proceedings of the IFIP WG 8.1 Working Conference, T.W. Olle, H.G. Sol, and C.J. Tully (eds.), North-Holland, Amsterdam (1983).

[37] Y. Yamamoto, An Approach to the Generation of Software Life Cycle Support Systems, Ph.D. Thesis, The University of Michigan, Michigan (1981).

[38] S.S. Yau and J.J.-P. Tsai, ‘‘A survey of software design techniques’’, IEEE Transactions on Software Engineering SE-12 (6): 713−721 (1986).

[39] R.T. Yeh and P. Zav e, ‘‘Specifying software requirements’’, Proceedings of the IEEE 68 (9): 1077−1085 (1980).

[40] E. Yourdon, Modern Structured Analysis, Yourdon Press Computing Series, Prentice Hall, Englewood Cliffs, New Jersey (1989).

Рисунок 1 — Схема концепции процесса разработки

Рисунок 2 — Пример PSL спецификации

Рисунок 3 — Пример SADT спецификации.

Рисунок 4 — Пример S-EDDA спецфикации

Рисунок 5 а — Пример SAMM контекстного дерева.

Рисунок 5 б — Пример SAMM диаграммы активности.

Рисунок 5 в — Пример SAMM диаграммы состояний.

Рисунок 6 — Пример HOS спецификации.

Рисунок 7 — Пример R-сети

Таблица 1 - Резюме Желательных Особенностей Языков Спецификации Требований