Форум Сообщества Аналитиков
Дисциплины => Проектирование => Тема начата: Vitaly от 02 Февраля 2010, 00:43:11
-
Интересует вопрос, насколько целесообразно использовать ВИ диаграмму для описания сложных систем, где количество вариантов использования системы очень большое. Имеет ли смысл разбивать ИС диаграмму на части, группируя таким образом по подсистемам? Особенно интересен практический опыт. Спасибо.
-
vit, так и нужно делать
А сколько у вас ВИ? Примерный порядок
-
Я все-таки побрюзжу. Не следует говорить о просто диаграмме ВИ. Сама по себе она имеет малое значение.
Сама декомпозиция - пожалуй, наиболее распространенный (если не единственный) способ борьбы со сложностью.
-
Сама декомпозиция - пожалуй, наиболее распространенный (если не единственный) способ борьбы со сложностью.
Эд, что ты подразумеваешь под декомпозицией?
-
Ну, собственно, одним из методов анализа является декомпозиция
Потому, да, если большое и сложное, значит, однозначно, бить на логические куски и "есть по частям" ))
-
Ну, собственно, одним из методов анализа является декомпозиция
Потому, да, если большое и сложное, значит, однозначно, бить на логические куски и "есть по частям" ))
Да, только есть понятие структуризации, а есть понятие декомпозиции. Относительно ВИ применяется первое.
-
Эд, что ты подразумеваешь под декомпозицией?
http://ru.wikipedia.org/wiki/Декомпозиция (http://ru.wikipedia.org/wiki/Декомпозиция)
-
А сколько у вас ВИ? Примерный порядок
Вообще, количество операций может быть достаточно большим. К примеру, 50 - 100. Конечно, все это можно запихнуть в описание ВИ, а сам ВИ назвать неким обобщающим словом, но ценность такой диаграммы будет невысока. Декомпозиция решила бы проблемы, но знаю, позволяет ли UML декомпозировать ВИ диаграммы?
-
Вообще, количество операций может быть достаточно большим. К примеру, 50 - 100. Конечно, все это можно запихнуть в описание ВИ, а сам ВИ назвать неким обобщающим словом, но ценность такой диаграммы будет невысока. Декомпозиция решила бы проблемы, но знаю, позволяет ли UML декомпозировать ВИ диаграммы?
Все зависит от того какого рода декомпозицию Вы предпримете.
Например, у Вас на верхнем уровне описание бизнес-процесса или бизнес-процессов.
Ви могут быть разложены по бизнес-процессам, тогда вы создаете пакеты по имени бизнес процессов и там уже делаете свои ВИ
Можно пойти иначе со стороны действующих лиц
Или сначала разложить систему на подсистемы и модули и уже назвав пакеты их именами разложить ВИ
-
Я воспринимаю ВИ как оглавление вначале книги, как нечто что помогает организовать структуру требований. И в этой роли ВИ для меня очень полезны. Поэтому все случаи, когда я сталкивался с большим количеством ВИ, с моей точки зрения это были примеры неправильно написаных ВИ (странно, когда оглавление больше чем книга).
Группировать диаграмму ИС на части, группируя по подсистемам – я не делаю.
Помню или могу себе представить 3 ситуации, когда это приходило (или могло прийти) в голову.
1-я ситуация:
Я наанализировал много ВИ, понял (или пообщался с проектировщиком) сколько у меня компонент в системе и хочу разложить все по полочкам.
Здесь проблемы в том, что:
1) ВИ компонентов - это ВИ другого уровня, они не соответствуют ВИ системы.
2) почти все ВИ системы, затрагивают несколько компонент, поэтому устанавливать принадлежность к какому-то одному компоненту некорректно.
Поэтому в любом случае придется перерабатывать ВИ.
2-я ситуация:
Перед началом анализа я решил «упростить» себе задачу анализа путем декомпозиции. По каким-то причинам мне понятно, сколько у меня компонент и я хочу выявлять и анализировать требования отдельно по компонентам.
Здесь у меня проблема в том, что мне не проще, а наоборот сложнее работать с компонентами:
1) Например, у меня два компонента: клиент и сервер. В процесс анализа незаметно вкрадывается задача проектирования взаимодействия между клиентом и сервером
2) Описывая требования для компонента легко потерять настоящие цели проекта.
Готов предположить, что после выполнения работы проектировать станет легче, но намного ли? Думаю, что в эту ситуацию попадают те, кто пытается совмещать роли аналитика и проектировщика.
3-я ситуация:
Мне все равно надо писать ТЗ на компоненты, т.к. компоненты будут изготавливливаться разными организациями.
Если такая ситуация возникла, нужно как-то справляться с проблемами описанными в пп. 1-2 , но в этом случае понятно зачем.
-
Появилась идея - можно создать столько ВИ, сколько нужно, но при этом создать не одну, а необходимое число ВИ диаграмм, каждая из которых покрывает определенную функциональность. Т.е. не создавать одну большую с 100 ВИ, а создать несколько небольших диаграмм. Одних и тех же актеров можно переиспользовать на разных диаграммах. ВИ также можно переиспользовать в случае необходимости. Вроде современные тулы создают объекты ВИ и актеров, которые не привязаны к конкретной диаграмме.
-
Появилась идея - можно создать столько ВИ, сколько нужно, но при этом создать не одну, а необходимое число ВИ диаграмм, каждая из которых покрывает определенную функциональность. Т.е. не создавать одну большую с 100 ВИ, а создать несколько небольших диаграмм. Одних и тех же актеров можно переиспользовать на разных диаграммах. ВИ также можно переиспользовать в случае необходимости. Вроде современные тулы создают объекты ВИ и актеров, которые не привязаны к конкретной диаграмме.
В правильном направлении двигаетесь :)
-
Спасибо :)