Золотухина Е.Б. и сотоварищи опубликовали свою очерередную статью по их пониманию ВИ - Способ описания функциональных требований к системе и ее функций с использованием стандартов и универсального языка моделирования

Статья весьма неоднозначная. Давайте обсудим.

Просмотрел бегло статью, но одна фраза меня просто убила: "Таким образом, для моделирования требований к АС мы будем использовать элемент требование "Requirement", а функций, реализующих требование, элемент "Use Case"."

З.Ы. Вроде они отошли от Rational и перешли к ЕА

Ну взяли они просто Features переименовали в Requirements

Ну да, еще взяли ВИ и переименовали в функции

Просмотрел бегло статью, но одна фраза меня просто убила: "Таким образом, для моделирования требований к АС мы будем использовать элемент требование "Requirement", а функций, реализующих требование, элемент "Use Case"."

Ну, то, что юзкейс у Золотухиной функция, было известно давно.

З.Ы. Вроде они отошли от Rational и перешли к ЕА

Ну, в 2006 году она уже показывала и Rose, и EA для сравнения. И уже упоминала о RaQuest.
А статью сейчас почитаю :-) Интересно, появились ли какие-либо новые идеи за 2 последних года...

Стиль забавный.

"Так, участники некоторых Интернет- форумов дошли до того..."
"Как печальный итог... привели к тому, что в различных средствах информации появились статьи..."
"...из популярного в нашей стране и за рубежом процесса разработки систем Rational Unified Process..."

А по существу... конечно, после Коберна определение шагов в виде "Поиск товара" и "Закрытие окна" режет слух. Но, в общем, предлагаемый подход, имхо, ничем не хуже других, хоть я и не понимаю, как он решает проблемы, обозначенные во вступлении.

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

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

Только ИМХО, Формы не должны быть в отельной дорожке и должны быть связаны с Действиями хотябы трейсом, а не виртуальной горизонтальной линией

Прочитала. Все тоже самое, что читалось в 2006 году.
О хорошем:
Эта статья редкий случай, когда предлагается работающая на практике инструкция по разработке моделей разных уровней детализации.
А теперь о плохом:
1. при чем здесь UML? В этом документе вообще нет ссылок на спецификации UML, а определения Use Case и др. даются либо в трактовке RUP, либо цитатами из файла помощи средства моделирования. Да-да, и этой ссылке "В спецификациях 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"." вплоть до указания страницы p.17 текст совпадает с текстом хелпа средства моделирования EA.

2. "Под функцией АС подразумевается совокупность действий АС, направленная на достижение определенной цели или аспект определенного поведения системы [6], а под задачей - функция или часть функции АС, представляющая собой формализованную совокупность автоматических действий, выполнение которых приводит к результату заданного вида [4]."
По этой цитате возникает впечатление: если не натянули определение use case на функцию, так мы определение функции дотянем до use case! Интересно, в ГОСТах определение функции такое? Прям через слово "подразумевается"?

3. "В табл. 2 представлено сравнение определений схемы функциональной структуры в соответствии с ГОСТ и модели "Use Case Model", функции системы и элемента "Use Case" в соответствии с описанием UML 2.0."
эээ в соответствии описанием UML откуда?
Хотя... это частный случай п.1

4. "элемент UML "Requirement"" - меня терзают смутные сомнения, что в спецификации UML нет элемента Requirement. Что скажут знатоки?

Ириш, согласно ГОСТ 34.003-90:

1.3 функция автоматизированной системы; функция АС: Совокупность действий АС, направленная на достижение определенной цели                  en AS function

1.4 задача автоматизированной системы; задача АС: Функция или часть функции АС, представляющая собой формализованную совокупность автоматических действий, выполнение которых приводит к результату заданного вида                                     en AS problem

Вот видите какой прозорливостью обладали наши ГОСТописцы. Хотя во фразе чувствуется ирония, но на самом деле ее нет.

Однако дейстивтельно что есть функция вообще? Правило преобразование входа в выход! Ясный перец, что данное преобразование делается с некоторой целью. Найти синус, косинус и т.п.

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

Вот коллега Коберн дает такую схему:
Основное действующее лицо имеет цель
Цель фиксируется в варианте использования
Вариант использования обращается к обязанности системы достичь эту цель
Система исполняет (не исполняет) свою обязанность

Стройно? А если изменить слово вариант использование на функцию?
Основное действующее лицо имеет цель
Цель фиксируется в функции (чьей?)
Функция обращается к обязанности системы достичь эту цель
Система исполняет (не исполняет) свою обязанность

Отлично! По п.2 получены ответы. ГОСТы авторы статьи знают. Снимаю. Спасибо, Mouse, Galogen!
П. 3 это придирка к стилю, тоже можно снять.
Остались претензии по п. 1 и 4.

Ну и добавлю вопрос к знатокам требований и use case:
5. Я по этой статье поняла так: требования выявляются и формируются в виде списка Requirement-ов, а каждый элемент этого списка требований порождает один или несколько use case? Т.е. у нас есть модель требований (Requirements), покрывающая все предполагаемые изменения, и страссированная с ней модель use case, которая так же покрывает все предполагаемые изменения, но описывает более детально, в виде целевых функций.
Правильно ли я поняла ход мысли авторов стати и суть способа? Если да, вы согласны с таким выделением требований и use case?
Galogen, если мы проведем аналогию с приведенной тобой схемой Коберна, то у нас получится, что Требования из статьи - это цели действующих лиц, правильно?
6. И еще вопрос к знатокам UML:
Смотрим на описание процесса выполнения функции, к сожалению, рисунки не пронумерованы, ссылку поставить не могу:
А из Activity может выходить более чем 1 control flow? Например, товар найден, товар не найден.

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

Так у Золотухиной все такие статьи

1. Ага, а еще есть интересная ссылка прямо на диск С из текста статьи:
Use Case elements are used to build Use Case models. These describe the functionality of the system to be built.

2. Ну про функцию и задачу уже сказали


3. Если посмотреть на РД 50-34.698-90, из которого было вырвано определение СФС, то получается что СФС не имеет ничего общего с ДВИ:
http://www.rugost.com/index.php?option=com_content&task=view&id=178&Itemid=63

4. "элемент UML "Requirement" - это элемент SysML

З.Ы. Опять же бред говорить про ГОСТ в общем не ссылаясь на конкретный, а м.б. они это сделали специально чтобы их не улечили в подлоге

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

Эд, а в том то и разница, что у функции просто некая цель\задача выполнения (ну любое действие имеет некую низкоуровневую цель\задачу), а ВИ - это цель именно ПОЛЬЗОВАТЕЛЯ. И вот в этом большая разница.

Ирр,

5. Т.к. у Золотухиной все перевернуто, то непонято что же "конкретно она имела в виду ..." Хотя частично Виталий дал ответ
6. А ее ДД вообще какой-то ужас, спецификация ЮМЛ летит в сад.

Только цитаты ... "Сравнение определения схемы функциональной структуры с определением модели Use Case Model, определения функции системы и элементов "Use Case" показывает, что эти модели и элементы сопоставимы друг с другом. ...
Таким образом, для моделирования требований к АС мы будем использовать элемент требование "Requirement", а функций, реализующих требование, элемент "Use Case".

Забавно -- сначала делается вывод, что UC и функции на основании определений всего лишь СОПОСТАВИМЫ, а потом предлагается их ЭКВИВАЛЕНТНОСТЬ ... сильное предположение.

Поскольку тут философский диспут, то я продолжу:

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

Требование - некое условие, которому должна соответствовать система. Функциональное требование, веротяно, некоторое условие, некоторая отвественность, которая должна системой исполнятся

Можно ли провести равенство между требованием и функцией? Очевидно нет.

Если верно высказывание:
use case - это требование
и
требование - это не функция
то просто исходя из транзитивности, можно допустить, что use case - это не функция.

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

тогда можно ли сказать, функция не имеет цели, цель имеет процесс? Опять не точно и не верно, тот же IDEF0 построен на мой взгялд почти на равенстве цели и функции,

Если следовать логике Саши, что функция имеет цель уровня задачи и возможно более высокого уровня, а use case- это цель пользователя, то только ли в этом различие?