Форум Сообщества Аналитиков

Дисциплины => Системный Анализ и Требования => Тема начата: bas от 27 Ноября 2008, 12:41:49

Название: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: bas от 27 Ноября 2008, 12:41:49
Золотухина Е.Б. и сотоварищи опубликовали свою очерередную статью по их пониманию ВИ - Способ описания функциональных требований к системе и ее функций с использованием стандартов и универсального языка моделирования (http://www.interface.ru/home.asp?artId=16728)

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

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

З.Ы. Вроде они отошли от Rational и перешли к ЕА :)
Название: Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: Виталий Григораш от 27 Ноября 2008, 12:54:38
Ну взяли они просто Features переименовали в Requirements :)
Название: Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: bas от 27 Ноября 2008, 12:57:47
Ну да, еще взяли ВИ и переименовали в функции :)
Название: Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: Irr от 27 Ноября 2008, 13:24:07
Просмотрел бегло статью, но одна фраза меня просто убила: "Таким образом, для моделирования требований к АС мы будем использовать элемент требование "Requirement", а функций, реализующих требование, элемент "Use Case"."
Ну, то, что юзкейс у Золотухиной функция, было известно давно.
З.Ы. Вроде они отошли от Rational и перешли к ЕА :)
Ну, в 2006 году она уже показывала и Rose, и EA для сравнения. И уже упоминала о RaQuest.
А статью сейчас почитаю :-) Интересно, появились ли какие-либо новые идеи за 2 последних года...
Название: Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: Григорий Печенкин от 27 Ноября 2008, 14:00:40
Стиль забавный.

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

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

А комбинация алгоритма с экранными формами прямо-таки для нас придумана, как раз сейчас у меня на столе лежит очень похожая картинка.
Название: Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: bas от 27 Ноября 2008, 14:15:45
А комбинация алгоритма с экранными формами прямо-таки для нас придумана, как раз сейчас у меня на столе лежит очень похожая картинка.
Только ИМХО, Формы не должны быть в отельной дорожке и должны быть связаны с Действиями хотябы трейсом, а не виртуальной горизонтальной линией :)
Название: Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: Irr от 27 Ноября 2008, 15:06:58
Прочитала. Все тоже самое, что читалось в 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. Что скажут знатоки?
Название: Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: mouse от 27 Ноября 2008, 17:10:58
Ириш, согласно ГОСТ 34.003-90:

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

1.4 задача автоматизированной системы; задача АС: Функция или часть функции АС, представляющая собой формализованную совокупность автоматических действий, выполнение которых приводит к результату заданного вида                                     en AS problem
Название: Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: Galogen от 27 Ноября 2008, 17:28:11
Вот видите какой прозорливостью обладали наши ГОСТописцы. Хотя во фразе чувствуется ирония, но на самом деле ее нет.

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

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

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

Стройно? А если изменить слово вариант использование на функцию?
Основное действующее лицо имеет цель
Цель фиксируется в функции (чьей?)
Функция обращается к обязанности системы достичь эту цель
Система исполняет (не исполняет) свою обязанность
Название: Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: Irr от 27 Ноября 2008, 18:12:00
Отлично! По п.2 получены ответы. ГОСТы авторы статьи знают. Снимаю. Спасибо, Mouse, Galogen!
П. 3 это придирка к стилю, тоже можно снять.
Остались претензии по п. 1 и 4.

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

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

З.Ы. Опять же бред говорить про ГОСТ в общем не ссылаясь на конкретный, а м.б. они это сделали специально чтобы их не улечили в подлоге
Название: Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: bas от 27 Ноября 2008, 18:38:55
Тут проблема неоднозначности англоязычной терминалогии и нашей. Если отбросить мишуру понятий, наверное не ничто не мешает понимать под Use case функцию системы.
Эд, а в том то и разница, что у функции просто некая цель\задача выполнения (ну любое действие имеет некую низкоуровневую цель\задачу), а ВИ - это цель именно ПОЛЬЗОВАТЕЛЯ. И вот в этом большая разница.
Название: Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: bas от 27 Ноября 2008, 19:03:39
Ирр,

5. Т.к. у Золотухиной все перевернуто, то непонято что же "конкретно она имела в виду ..." Хотя частично Виталий дал ответ
6. А ее ДД вообще какой-то ужас, спецификация ЮМЛ летит в сад.
Название: Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: Юрий Булуй от 28 Ноября 2008, 00:10:58
Только цитаты ... "Сравнение определения схемы функциональной структуры с определением модели Use Case Model, определения функции системы и элементов "Use Case" показывает, что эти модели и элементы сопоставимы друг с другом. ...
Таким образом, для моделирования требований к АС мы будем использовать элемент требование "Requirement", а функций, реализующих требование, элемент "Use Case".

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


Название: Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: Galogen от 28 Ноября 2008, 17:13:08
Поскольку тут философский диспут, то я продолжу:

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

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

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

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

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

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

Если следовать логике Саши, что функция имеет цель уровня задачи и возможно более высокого уровня, а use case- это цель пользователя, то только ли в этом различие?
Название: Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: bas от 28 Ноября 2008, 19:44:48
Эд,

А как твои утверждения коррелируют с определение ГОСТ:
функция автоматизированной системы; функция АС: Совокупность действий АС, направленная на достижение определенной цели
Название: Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: Galogen от 29 Ноября 2008, 00:01:05
Эд,

А как твои утверждения коррелируют с определение ГОСТ:
функция автоматизированной системы; функция АС: Совокупность действий АС, направленная на достижение определенной цели
А я и не пытаюсь искать корреляции, я просто рассуждаю в слух, словомудрствую так скать.

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

Сейчас в бизнесе мы видим некое торжество процессного подхода.

Недостатки фунционального подхода известны, они проявляются и в функциональной оргструктуре. Основной - конфликт интересов-целей.

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

Вот мне и кажется (крещусь часто), что Use case - это процесс, т.е. некий поток событий продвигающий субъекта к цели (или не продвигающий - это уж как предусмотрим). Причем ясно что движение к цели может быть разнопутевым, но все равно эти пути много имеют общего.

Функция же она не подчинена синтетической задачи достижения цели, она просто исполняет свою функцию.

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

т.е. функция в строгом понимание - это функция
функция в свете экономики и иже с ней - задача
в программирование - самостоятельный кусок программы, организованный для совместного использования и возвращающий значение, тамеще выделяют процедуру - которая как бы ничего не возвращает но которая исполняет команду и меняет состояние системы
во многих языка нет процедур есть только функции:
функции, меняющие данные;
функции, меняющие состояние;
функции-операторы(исполняют команды, но наверное это близко к функции меняющей состояние)
Название: Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: bas от 01 Декабря 2008, 10:29:13
В какой-то мере я с тобой согласен. ВИ естественно облегчает процесс формирования требований:
1. Направлен на достижение цели конечного ПОЛЬЗОВАТЕЛЯ
2. Представляет Тр в виде сценария, что облегчает его понимание и воспринимается как нечто целое, а не обрывок.
Название: Re: Способ описания функциональных требований к системе и ее функций, Золотухина Е Б
Отправлено: Юрий Булуй от 01 Декабря 2008, 11:30:37
Строго говоря, если брать определение функции по ГОСТ -- то оно по сути гласит, что ф-я это совокупность действий  людей, железа и ПО направленная на достижение определенной цели. И ничего в данном определении не говорится про то, ЧЬЯ это цель! Это отдается на откуп конкретного ТЗ. А с юзкейсом все понятно -- это цель Actor-а. Определение по ГОСТ не дает возможности говорить об эквивалентности функции АС и юзкейса. Но зато вполне позволяет использовать в документах ГОСТ юзкейсы :-) -- т.к. на основании определений можно утверждать, что юзкейсы а) направлены на достижение определенных целей -- более того, мы явно идентифицируем эти цели, б) описывают ту самую "совокупность действий". Это становится некой доказательной базой в случае, если на стороне заказчика сидит человек, утверждающий что он знает ГОСТы ... а у нас есть желание писать юзкейсы. Но это не скорее всего не будет работать, если у ГОСТовцев есть собственные традиции в описании требований по ГОСТ.