Здравствуйте, я начинаю осваивать азы проектирования и хотелось бы начать теорию применять к практике. Достойная задача (на мой взгляд) для этого появилась. Мне необходимо спроектировать и реализовать систему построения отчетов пользователями через ВЕБ-интерфейс на сайте. Система будет содержать очень большое количество фич. Очень буду признателен, за любую помощь при проектировании.

Итак действующие лица (ДЛ)
1) Незарегистрированный пользователь
2) Зарегистрированный пользователь
  2.1) Пользователи-инсайдеры
  2.2) Пользователи компаний-контрагентов
  2.3) Админы-инсайдеры
  2.4) Админы компаний-контрагентов

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

Рисую БВИ для основного внешнего по отношению к системе пользователя (надеюсь, что здесь мне не удалось сильно накосячить?)
Затем перехожу на более низкий уровень взаимодействия актеров в системе. Посоветуйте, плз, как корректно (или принято) строить детализированную модель с древовидной (постепенной) проработкой деталей? Примеры, которые идут с ЕА смотрел, но пока много чего не доходит.

Очень рекомендую почитать Коберна.
Если говорить о БВИ, то граница - это наша организация или отдел(ы) и их БИЗНЕС потребности по отношению к границе. У вас же граница БВИ - это Система, а Система - это граница для СВИ.

Большое спасибо за ценное замечание - выходит, что мне БВИ вообще не нужна. Коберна обязательно буду изучать, сейчас пока штудирую "Язык UML. Руководство пользователя". Или Вы считаете, что это неверная последовательность для изучения предметной области?

Наверное, тогда мне следует пересмотреть тему созданного топика. Попробую изменить вопрос к сообществу: какие сейчас мне необходимо выполнить шаги для успешного выполнения этапа проектирования? Как получить, на выходе иерархическую модель, которую смогут читать другие разработчики и главное однозначно трактовать ее? И можно ли в принципе получить на выходе более-менее качественный продукт, в процессе изучения технологии?

Hose, тут следует сделать такое замечание.

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

Вариант использования позволяет ответить на вопрос что нужно, что нужно делать, отталкиваясь от потребностей пользователя системы.

UML сам по себе это одно из средств проектирования, документирования будущих решений. ВИ может (но не обязательно) задавать контекст для аналитической и проектной деятельности.

ВИ достаточно самостоятельный инструмент, он по своей природе не объектно-ориентирован, хотя в определенных подходах интегрирован в UML и управляет ходом разработки (о чем я упомянул выше)

В Вашем случае (диаграммы) - там нет бизнес-вариантов использования. Ваши ВИ это системные ВИ, правда большая часть все-таки не сами ВИ, а скорее части более крупных ВИ.

Например. первая диаграмма - заполнение формы поисковых критериев - вопрос, а зачем в чем цель заполнения поисковых критериев? По сути так можно сказать о каждом из ваших ВИ. У меня ощущение, что тут один ВИ - сформировать требуемый отчет, в котором есть шаги - указания критериев, выбора столбцов, постановка в очередь, просмотр результата - но эти шаги это не ВИ, в них нет цели пользователя. В лучшем случае они есть ВИ уровня моря (подфункции), некоторые кусочки функциональности, которые мы выделили в ВИ по каким-то признакам, но вот каким? Мне не ясно

Вторая диаграмма с учетом замечаний сделана более профессионально. Здесь можно понять зачем пользователь использует систему

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

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

Вот это очень интересная тема! Я правильно понял, что здесь Вы ведете речь о RUP? Я немного читал о нем, но в планы входит глубокое изучение.

В Вашем случае (диаграммы) - там нет бизнес-вариантов использования. Ваши ВИ это системные ВИ,

Я уже понял это из поста уважаемого bas.

Например. первая диаграмма - заполнение формы поисковых критериев - вопрос, а зачем в чем цель заполнения поисковых критериев?

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

меня ощущение, что тут один ВИ - сформировать требуемый отчет

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

Вторая диаграмма с учетом замечаний сделана более профессионально. Здесь можно понять зачем пользователь использует систему

На самом деле это не вторая а первая (во времени) диаграмма. Но это не суть важно Разработка начиналась именно с нее. Она показалась мне достаточно громоздкой (требование 5-10 ВИ на одной диаграмме) и я начал заниматься расчлененкой. Как показал опыт не очень успешно...

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

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

Это моя работа

Вот это очень интересная тема! Я правильно понял, что здесь Вы ведете речь о RUP? Я немного читал о нем, но в планы входит глубокое изучение.

Не только, но в основном да. Существуют и другие подходы ICONIX например.

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

Прекрасно. Тогда вопрос. Сформулированные потребности пользователь вводит в систему независимо от того будет он формировать отчет тут же или нет? Т.е. есть ли между актом формирования критериев и актом формирования отчета неопределенная пауза? Т.е. чтобы сформировать отчет нужно указать критерии. Но указание критериев вполне сознательная и независимая работа.

Тут следует исходить из критериев - одобрит ли мой начальник если я целый день занимаюсь формированием критерия? формирование критерия - это отдельная бизнес-задача приводящая систему в иное состояние и дающая определенное бизнес-велью? Это достаточно коротки независимый сеанс работы с системой (не путайте только сеанс работы с веб-системой)

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

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

На самом деле это не вторая а первая (во времени) диаграмма. Но это не суть важно Разработка начиналась именно с нее. Она показалась мне достаточно громоздкой (требование 5-10 ВИ на одной диаграмме) и я начал заниматься расчлененкой. Как показал опыт не очень успешно...

Пакет Вам помогут? Ясно же, что некоторые моменты диаграммы можно рассматривать независимо - того же администратора с его фунциями

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

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

Другой закон обучаются через ошибки и рефлексию, обратную связь

1. http://www.google.ru/#hl=ru&source=hp&q=use+case+driven+development

2. Вам уже Эд намекнул на то, что ВИ - это в первую очередь НЕ диаграмма, а текст. Начните писать хотя бы основные сценарии ВИ, там будет более понятно как перегруппировать ВИ и что Вы под каждым ВИ понимаете.

3. Переименуйте тему плиз во что-то более внятное

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