Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => Тема начата: Galogen от 16 Декабря 2006, 21:45:34
-
Основой любого аналитического процесса или просто анализа есть декомпозиция.
Возьму на себя смелость сформулировать понятие декомпозиция.
Декомпозиция - это процесс упрощения чего-либо без потери целостности.
Существуют разные виды декомпозиции: функциональная, структурная, объектная, по физическому процессу.
Декомпозиция предполагает иерархическое подчинение нижних уровней верхним. Декомпозиция не меняет сути декомпозируемого объекта или явления, а лишь уточняет его, упрощает, помогает снять неопределенность или локализовать ее.
Когда говорят о структурных методах анализа, декомпозиция воспринимается как обычное явление, сопуствующее методикам структурных методик.
Однако когда мы переходим к вариантам использованиям, нам рекомендуют быть очень внимательным к этому понятию.
К примеру в книге Эрика Нейбурга и Роберта Максимчука "Проектирование баз данных с помощью UML" издательства Вильямс от 2002 года на стр. 45 читаем "на рис.3.5 представлена общая модель бизнес-прецендентов (модель содержит 1 ВИ::Обслуживание резидента и большое количесвто актеров). Прецедент "Обслуживание резидента" содержит множество ВИ и видов деятельности. Заметим, что здесь речь идет не о функциональной декомпозиции, а просто о более высоком уровне абстракуции, который позволит лучше понять контекст".
Однако, если бы я проводил анализ, используя IDEF0, то действовал примерно так.
Контекст - Обслуживание резидента
О диаграмма - Оказание медпомощи, Получение счета, Выполнение постановлений, Управление клиническими записями, Ответ на запрос
Каждая из выше перечисленных функций может быть декомпозирована вплоть до элементарных действий.
В чем тогда разница? Чем отличается ВИ в UML и функция в IDEF0 или другой структурной методики?
ВИ всегда возвращает результат и всегда есть неделимая последовательность действий.
А Функция? разве что-то другое. По определению функция есть результат преобразования аргументов, в чем разница...
Хотелось бы услышать от знающих ответы на поставленные вопросы, желательно с примерами и обоснованием...
-
ВИ ничего не "возвращает".
Прецедент есть совокупность сценариев (граф), часть ветвей готорого приводит к успешному завершению прецедента, а часть - к неуспешному. Прецедент не является чёрным ящиком, как детерминированная функция, у которой выход определяется входом, а имеет предусловия, условие запуска, действия участников, постусловия, гарантии и т.д. Если считать, что определённые действия участников в ходе прецедента могут быть представлены вектором дискретных переменных, то это можно каким-то образом уподобить функции, но я не вижу в этом смысла.
-
ВИ ничего не "возвращает".
Вот те на, а что же он возвращает? Дает? создает в ходе исполнения?
Прецедент есть совокупность сценариев (граф), часть ветвей готорого приводит к успешному завершению прецедента, а часть - к неуспешному. Прецедент не является чёрным ящиком, как детерминированная функция, у которой выход определяется входом, а имеет предусловия, условие запуска, действия участников, постусловия, гарантии и т.д. Если считать, что определённые действия участников в ходе прецедента могут быть представлены вектором дискретных переменных, то это можно каким-то образом уподобить функции, но я не вижу в этом смысла.
ну и что, функция тоже есть детерменированная последовательность действий. функция по-разному может быть прочитана, все-таки я имел в виду не математическое определение функции - синус, косинус, логонормальное распределение, а все-таки понятие функции в IDEF0... В чем основное отличие? Почему функция не может иметь предусловий, постусловий, гарантий и т.п.
К чему я это? Просто одно и тоже можно называть по-разному и спорить до хрипоты. Покажите четкую разницу одного от другого, дайте примеры, если видете разницу.
И про декомпозицию, кстати, не слово. Насколько я понимаю, тут-то весь перец. Функция IDEF декомпозируема, ВИ не декомпозируемый.
Функция IDEF = активность, деятельность, работа, процесс, аналогично в DFD.
Что есть ВИ - работа - сценарий или совокупность сценариев.
Функциональный блок IDEF, DFD - то же есть совокупоность работ и сценариев, единственная разница, что описывается не последовательность действий, а логика взаимоотношения действий.
Если и есть разница, то это разница в том, что функция(в понимании структурной методики) - есть нечто не обязательно последовательное, но логически взаимоувязанное, приносящее результат.
ВИ - есть последовательность действий, рабочий процесс, работа, алгоритм = синоним сценарию IDEF3 (workflow)
Разница примерно в следующем - первое дает взаимное расположение например улиц и объектов на улицах, второе как из пункта А попасть в пункт Б - маршрут, основанный на карте, созданной в первом случае...
Вместе с тем ВИ - есть просто заголовок для некой последовательности, сама последовательность описывается диаграммой деятельности либо просто сценарием,
ВИ тоже могут взаимодействовать: расширять, включаться, обобщаться. Но нет иерархии...
Заканчиваю:
Вывод:
1. Ваши замечание в целом понятны, но ответа фактически не содержат. Доказательная база слишком скудна. Не репрезентативной выборки
2. Про декомпозицию не сказали не слова. Хотя цель вопроса уточнить понятие декомпозиция, и перенести его на UML, где и в каком контектсе его использовать. Почему более детальное рассмотрение чего-либо не есть суть декомпозиции?
-
1. В старом форуме я приводил ссылку на статью "Why Usa cases are not functions", там можно и посмотреть более детально.
2. В общем виде можно сказать, что UC это в первую очередь ЦЕЛЬ ... а не действие. И именно функция может быть декомпозирована до элементарных операций. Причем, говоря о декомпозиции, подразумеваем, что функция строго состоит из последовательности операций. UC тоже могут быть декомпозированы, но в терминах декомпозиции ЦЕЛЕЙ пользователя по отношению к системе. Хотя более корректно говорить не о декомпозиции целей, а о контексте, который задает например outmost UC для других UC ... это очень хорошо показано у Коберна, когда он вводит понятие уровней юзкейсов. Близко к этому -- RUPовское Business UC - System UC. BUC -- по сути контекст для SysUC. Эта грань -- она с одной стороны достаточно четкая, с другой стороны (особенно с позиций функционального анализа) может показаться не вполне четкой. Но она еть :-). Например, можно выстроить функциональную декомпозицию по ЦЕЛЯМ, но сложно (или невозможно) будет выстроить "иерархию" UC по функциям, ввиду ортогоноальности природы UC и функций. Да, у них может быть пересечение (если описывать функционально предметную оласть и ее же потом описать на UC), но повторюсь, что в одном UC может присутствовать множество функций и наоборот.
-
ВИ всегда возвращает результат и всегда есть неделимая последовательность действий.
А Функция? разве что-то другое. По определению функция есть результат преобразования
аргументов, в чем разница...
На минуту представим, что ВИ - это компонент системы (так оно в принципе и есть, если
смотреть на систему со стороны USECASE). Ну вот... в системном анализе есть очень важный принцип:
Иерархической структуре системы можно поставить в соответствие иерархическую структуру
функций компонентов. На верхнем уровне этой структуры находится цель системы, на
достижение которой направлены функции компонентов, которые можно трактовать как цели
функционирования компонентов. Надеюсь, понятно к чему я клоню... Простите, "те же яйца,
только сбоку"
Декомпозиция - это процесс упрощения чего-либо без потери целостности.
GALOGEN, ну просто я бы сказал Декомпозиция - операция разложения целого на части. Вот
смущает фраза "без потери целостности". Дело в том что при декомпозиции мы разбиваем систему на уровни иерархии и подсистемы. Для дальнейшего рассмотрения и изучения их отдельнодруг от друга. Просто мы выделяем существенные связи между компонентами системы, уже для проведения обратной операции - агрегирования
ИМХО надо в другую тему перенести посты, а то от бизнес-процессов далековато ушли
-
To Keen_G
ИМХО надо в другую тему перенести посты, а то от бизнес-процессов далековато ушли
Ну почему же, думаю довольно близко. Хотя согласен, нужна четкая структуризация категорий, куда и можно было бы обратится. Согласен декомпозиция - деление на части. Почему без потери целостности, это потому, что нам требуется не просто декомпозиция, а декомпозиция в контексте.
Да хочу сказать, что я вполне отдаю себе отчет в различии ВИ и функции в понимании структурного подхода. Однако я не нахожу четких доказательств или четких определений, которые позволяют показать - это "яйца", а это "не яйца".
Кроме того, я действую по принципу адвоката дьявола, т.е. кидаю тему, и ожидаю от участников ответов, думаю таким образом, мы прийдем к единому пониманию с одной стороны, а с другой стороны выработаем формулу, которую можно донести до других
Keen_G, а чем разбиение цели на подцели, отличается от разбиение функции на подфункции и действия?
-
1. В старом форуме я приводил ссылку на статью "Why Usa cases are not functions", там можно и посмотреть более детально.
Юрий, спасибо. Не можешь (можете? как лучше:-)) напомнить ссылку, старый форум скорее всего почил в бозе
2. В общем виде можно сказать, что UC это в первую очередь ЦЕЛЬ ... а не действие. И именно функция может быть декомпозирована до элементарных операций. Причем, говоря о декомпозиции, подразумеваем, что функция строго состоит из последовательности операций. UC тоже могут быть декомпозированы, но в терминах декомпозиции ЦЕЛЕЙ пользователя по отношению к системе. Хотя более корректно говорить не о декомпозиции целей, а о контексте, который задает например outmost UC для других UC ... это очень хорошо показано у Коберна, когда он вводит понятие уровней юзкейсов. Близко к этому -- RUPовское Business UC - System UC. BUC -- по сути контекст для SysUC. Эта грань -- она с одной стороны достаточно четкая, с другой стороны (особенно с позиций функционального анализа) может показаться не вполне четкой. Но она еть :-). Например, можно выстроить функциональную декомпозицию по ЦЕЛЯМ, но сложно (или невозможно) будет выстроить "иерархию" UC по функциям, ввиду ортогоноальности природы UC и функций. Да, у них может быть пересечение (если описывать функционально предметную оласть и ее же потом описать на UC), но повторюсь, что в одном UC может присутствовать множество функций и наоборот.
Интересно. Однако в чем ортогональность описания множеством функция и множеством UC? Насколько я помню, есть ортогональность структурного подхода и объектного подхода. Но UC - к ООП никакого вроде отношения не имеет?
Далее: цель - стратегия,
функция - тактика?
Так стоит понимать?
Вообще в программировании я понимаю под функцией некоторое атомарное действие, имеющее одну тему: соединиться с сервером, выбрать БД, подготовить запрос, выполнить запрос, вывести данные запроса и т.п.
Однако в моей постановке вопроса все-таки имеется ввиду не функция программы, а функция = функциональный блок = процесс. В чем все-таки отличие между функцией и процессом, что кого включает? Опять же у меня есть некоторый ответ, но он меня не удовлетворяет, поскольку я не могу подобрать хороших примеров и доказательств.
Простите мою настырность, но она идет от моих студентов, порой они ставят меня в тупик, а я не нахожу слов для доказательств.
Вот Keen_G считает, что это одно и тоже по сути. Другие оппоненты это отрицают.
Книгу Коберна держу как настольную, но все равно до конца не могу ее понять. Что занчит ВИ уровня неба, уровня горизонта, уровня моря? Это что декомпозиция? Декомпозиция контекста, декомпозиция цели, декомпозиция функции, декомпозиция объекта? В чем различия?
Объектную декомпозицию понимаю, декомпозицию функций понимаю, декомпозиция цели - мне кажется то же что и декомпозиция функций, а что понимать под декомпозицией контекста, Смещение точек зрения? Перемещение точки зрения, фокусного расстояния? С перспективы птичьего полета, до более близкого расстояния. Тогда вероятно понятно, разный уровень наблюдения. Высоко - много, но не детально, низко - узко, но детально?
Например, можно выстроить функциональную декомпозицию по ЦЕЛЯМ, но сложно (или невозможно) будет выстроить "иерархию" UC по функциям, ввиду ортогоноальности природы UC и функций.
Да мысль понятна, действительно, по UC не выстроешь. Можно ли выдвинуть такую мысль: ВИ это потребности пользователей, это разные точки зрения на роль системы (в отличии от необходимости единой точки зрения в SADT)....?
-
Я, в принципе, хотел сказать ту же мысль, что и Юрий. Т.е. у ВИ мы отталкиваемся от целей.
Да, декомпозиция целей похожа на декомпозицию функций, но не до бесконечности, а на 2-3 уровня, далее это уже не цель а средство реализации.
Согласен, что остановиться бывает очень сложно и хочется все бить и бить, но все же целевая деомпозиция более ограниченая. Я не могу четко сказать когда нужно декомпозировать, а когда не нужно. Свою мысль я попробовал высказать в примерах, в электронном обучении.
-
1. В старом форуме я приводил ссылку на статью "Why Usa cases are not functions", там можно и посмотреть более детально.
Юрий, спасибо. Не можешь (можете? как лучше:-)) напомнить ссылку, старый форум скорее всего почил в бозе
Google рулит :) Но для тебя даже так.
-
Юрий, спасибо. Не можешь (можете? как лучше:-)) напомнить ссылку, старый форум скорее всего почил в бозе
Ссылку уже кинули :-), можно на "ты" ... :-).
Интересно. Однако в чем ортогональность описания множеством функция и множеством UC? Насколько я помню, есть ортогональность структурного подхода и объектного подхода. Но UC - к ООП никакого вроде отношения не имеет?
Далее: цель - стратегия,
функция - тактика?
Так стоит понимать?
...
Книгу Коберна держу как настольную, но все равно до конца не могу ее понять. Что занчит ВИ уровня неба, уровня горизонта, уровня моря? Это что декомпозиция? Декомпозиция контекста, декомпозиция цели, декомпозиция функции, декомпозиция объекта? В чем различия?
Объектную декомпозицию понимаю, декомпозицию функций понимаю, декомпозиция цели - мне кажется то же что и декомпозиция функций, а что понимать под декомпозицией контекста, Смещение точек зрения? Перемещение точки зрения, фокусного расстояния? С перспективы птичьего полета, до более близкого расстояния. Тогда вероятно понятно, разный уровень наблюдения. Высоко - много, но не детально, низко - узко, но детально?
...Да мысль понятна, действительно, по UC не выстроешь. Можно ли выдвинуть такую мысль: ВИ это потребности пользователей, это разные точки зрения на роль системы (в отличии от необходимости единой точки зрения в SADT)....?
Что касается уровней UC у Коберна. Это взгляд с разных точек зрения, уровень неба это обощение. У юзкейсов уровня неба и экотры могут быть разные, и цели у них разные. Коберн говорит про то, что UC summary (небо), объединяют в себе цели разных экторов (уровня user goal - "море"). Второй аспект это время выполнения этого UC -- дни, недели ... А уровень моря, это выполнил -- пошел покурил, потом такой же другой взял (например открытие счетов), то что проходит "одной транзакцией".
Когда говорим о соотношении summary и user goal UC, то, как я говорил, это не обязательно будет "строгое" включение UC уровня user goal в summary. Если бы каждый шаг summary был бы строго одним UC уровня user goal, то это можно было бы считать декомпозицией, а так этого может и не быть ...
Справедливости ради следует отметить, что часто происходит и "функциональная" декомпозиция, особенно если переходим от уровня summary, к user goal, т.к. например в UC "Получить кредит" (эктор Клиент) уровня Summary, может быть цель пользователя-клерка "Оценить кредитный риск Клиента". Это будет несколько похоже на функциональную декомпозицию, но как сказал Александр во-первых кол-во уровней ограничено (мы уже не можем декомпозировать до элементарных оперций, которые делает клерк для оценки риска, ибо это уже не юзкейсы а его целостный сценарий ... а при функциональной декомпозиции это все ФУНКЦИИ только разного уровня детализации), во-вторых мы рассуждаем в терминах целей, а в третьих смотрим, как вы справделиво заметили, с другой стороны ... с внешней стороны (Эктор -- всегда будет outside of scope).
-
Если можно подведу итог дискуссии.
Итак вариант использования, прецедент, use case, процесс - конечная НЕДЕЛИМАЯ последовательность событий, возникающих в системе для удовлетворения потребности действующего лица, инициирующего эту последовательность.
В самом определении присутствует слово НЕДЕЛИМАЯ, а значит имеющая смысл лишь только как целое. Если рассматривать части такого процесса, как самостоятельные элементы, теряется смысл использования. "Не выкинишь слов из песни". При этом можно считать, что при успешном завершении процесса участник достигает цели использования, а при не успешном не достигает. Т.е. в определенном смысле, участник заранее не знает, какой результат принесет вариант использования. Очевидно, что он ожидает успешность выполнения, но возможен и сбой. Таким образом, ВИ в определенной степени похож на транзакцию, которая либо осуществляется либо нет.
При этом конечность и неделимость не припятствует выделению другой последовательности внутри рассматриваемого ВИ. Здесь просматривается аналогия с вложенными транзакциями.
ВИ можно рассматривать как некоторую законченную программу действий, которая хотя и допускает членимость в своей реализации, но имеет смысл лишь как цельная структура.
-
Ну и слово "цель" куда-нить прикрутить и совсем будет хорошо :)
-
для удовлетворения потребности действующего лица - чем не цель?
-
Я бы сказал так:
ВИ - это конечная НЕДЕЛИМАЯ последовательность событий, которая описывает как должна Система взаимодействовать с Пользователями (Актерами), чтобы достигнуть определенной бизнес цели.
Скомбинированно из определения Galogen и http://en.wikipedia.org/wiki/Use_case
-
Интересный абзац у Коберна в его книге "Современные методы описания функцию требований к системе".
ВИ и функциональная декомпозиция. Если вы применяете методы структурной декомпозиции, будет полезна функциональная декомпозиция в ВАРИАНТАХ ИСПОЛЬЗОВАНИЯ. Однако если вы занимаетесь ОО проектирование, примите во внимание следующее...
стр. 176 и далее.
Или стр. 172 оригинального английского издания:
Use cases and functional decomposition If you are using structured decomposition techniques,
then the function decomposition in the use cases is probably useful to your work. However, if you are doing object-oriented design, then there are some special notes to take.
A SPECIAL NOTE TO OBJECT-ORIENTED DESIGNERS
Use cases can be said to form a functional decomposition, or function hierarchy. This has shown itself to be useful for the purposes of constructing and communicating behavioral requirements. The writing is easy to understand, and the behavior rolls up neatly into higher and higher levels. It makes life easier on the people who have to agree on what the system must do.
Как говорится, нет комментариев, а у кого есть?
-
Я бы сказал, что декомпозиция есть как раз усложнение, а не упрощение.
То, что у банка что есть функция "выдать кредит" - это просто.
То, что "выдать кредит" - это:
1) Идентифицировать заёмщика
2) Проверить платёжеспособность и кредитную историю
3) Желания заёмщика
4) Принять решение о возможности выдачи кредита и условиях кредитования
5.а) Оформить и зверить кредит, выдать деньги
5.б) Запросить дополнительные подтверждения платёжеспособности
5.в) Отказать в кредите
- уже сложнее.
То, что "проверить платёжеспособность и кредитную историю" - это:
4.1) Запросить бюро кредитных историй
4.2) Рассмотреть динамику возвращния кредитов и составить прогноз
4.3) Запросить МВД, проверить признаки схемы "отмывания" денег
4.4) Учитывая желаемые условия кредитования, расчитать риск
4.5) Расчитать взвешенную прибыльность кредита для банка, принять решение
- довольно сложно.
А конкретные вычислительные модели и технологиии прогнозирования в "составить прогноз" - это совсем сложно :) .
Хотя для конкретного нового сотрудника банка
"выдать кредит", пользуясь регламентом, который получен в результате декомпозиции вплоть до "Зайти в Пуск->Клиент бюро кредитных историй, заполнить паспортные данные, нажать на кнопку "Проверить"",
гораздо проще, чем "выдать кредит" при отсутствии регламента.
-
Хотя для конкретного нового сотрудника банка
"выдать кредит", пользуясь регламентом, который получен в результате декомпозиции вплоть до "Зайти в Пуск->Клиент бюро кредитных историй, заполнить паспортные данные, нажать на кнопку "Проверить"",
гораздо проще, чем "выдать кредит" при отсутствии регламента.
Однако я думаю, что тот кто берет кредит сначала получает некую бумагу разрешающую ему это сделать?
Потому мы при автоматизации и отбрасываем некоторую часть этого процесса, причем как видим солидную. Просто где-то в систему ставим поле- разрешающий документ для выдачи кредита, который по логике вещей должен появится, когда посетитель пришел его получать, и оператору отсается выполнить тривальные действияю
Однако твой вывод меня сразил - декомпозиция усложняет картину
-
Я в принципе согласна с предыдущим оратором. И если бы мой нижний на форуме поднимал вопрос, надо ли меня поздравить, меня бы это не порадовало.
А по сути вопроса - считаю, что поздравлять надо тогда, когда хочется, и тех, кого хочется, безотносительно тематичности отношений.
Вы бот? Если не ответите на это сообщение, будете удалены.