Привет
Проверте pls ВИ диаграмму на тему e-learning

Ну во-первых, БД не нужна на Диаграмме. Т.к. это уже сисистема, т.е. реализация, которая заложена внутри ВИ.

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

В-третьих:
Что такое "добавить ресурс"?? Что за ресурс
А Админ разве не коннекектится??
Что такое "Проверка Юзера"?
М.б. лучше не "Арандж класс", а "Провести занятия"?

Ну препод создает курс и добавлает ресурсы, типа мултимедия или какие нибудь лекции. Cтудент заходит в систему и может пользоваться этими ресурсами.
А на счет проверки юзера я думала что кто то должен проверять кто входит в систему и что это должен делать админ 
Значит админа можно не показывать?

Ну препод создает курс и добавлает ресурсы, типа мултимедия или какие нибудь лекции. Cтудент заходит в систему и может пользоваться этими ресурсами.

Так это похоже, что это один ВИ - "Создать/Добавить Курс". А уже реализация будет - "Создать Курс, добавить ресурсы. Если Курс создан, то выбрать его и добавить новый ресурс"

А на счет проверки юзера я думала что кто то должен проверять кто входит в систему и что это должен делать админ 
Значит админа можно не показывать?

Ну так проверяет же Система. Не так ли?? Или при входе юзверя, посылаеятся сообщение Админу  и он уже говорит "Approved"?!
Админ может понадобиться для добавления юзерей и назначения прав.

Кстати, насчет Логона, то лучше показать, что у вас юзер, который логинится и от него наследуются все остальные юзверя.

Насчет "Start Virt Class" и "Performance Control" - разве это происходит совместно с Инструкторм?? Если да, то тогда правильно, если нет, то ... В общем, нужна спецификация ВИ, чтобы точно сказать.

Почему от глаголных ВИ у вас наследуются существительные ВИ?

З.Ы. Английские имена подобраны не очень корректно. Например "Performance Control" больше подходит для devices. А вот "Check knowledges" больше подходит для people. Да и "Start Virt Class" не очень подходит.

Вот мой вариант на разбор:)

Необходимо для начало определиться что за систему мы моделируем.
Электронных обучений много и они серьезно отличаются друг от друга.
То что есть студент у нас всегда это понятно.
Учителя как такового может и не быть в системе. (например intuit.ru)
Университет есть всегда со своими актерами, но опять же он может и не работать с системой непосредственно, и иметь всего несколько актеров включая учителя\набивщика контента.

Итак, цели сторон.

Цели:
 
Университет.   Заработать деньги
      - Предоставить обучение
      - Организовать курсы и получение денег за них
      - Организовать выдачу дипломов
      - Организовать получение денег за дипломы (обучение)
      - Организовать взаимоработу студента и учителя   

Студент.    Получить диплом\образование
      - получить знания
      - получить навыки
      - научиться их использовать

Учитель.   Заработать деньги
      - Учить студентов
      - Предоставлять курсы
      - Предоставлять проверку обучения
      - Предоставлять оценку знаний и умений

Каковы актеры?

- Студент - 100% есть:); 1...n
Учитель - может и нету непосредственно. В нашей системе пусть будет т.к. без учителя нет и обучения, есть только самообучение. А университет это не самообучение ИМХО. Хотя у нас и пытаются эти элементы вводить.
- Учитель 1...n
- Админ; 1; пригодится всегда.
Вроде бы и все, если по минимуму. Никаких проверок, секретарей и т.п.

Можем приступать к "придумыванию" того что могут делать люди с системой. Что очень близко к UseCase-ам.

Студент может:
- Зарегистрироваться (оплата или другое условие поступления все системы)
- Учавствовать в обучении
   - Читать лекционный материал
   - Выполнять практические занятия
   - Выполнять лабы, тестовые задания (ИМХО тоже самое ПЗ)
- Учавствовать в проверке знаний
   - Сдавать тесты
   - Сдавать контрольные
   - Сдавать экзамен
- Учавствовать в общении с учителем и собутыль...ой, соучащимися.
   - Задавать вопрос учителю
   - Обсуждать тему\проблему с соучащимися + модерация\помощь от учителя.
- Получить диплом.
   (возникает вопрос за что? какие он курсы слушал? Мы этого в системе не учитывали и не учитываем, т.к. слишком много и красиво будет, хотя может тогда и диплом давать не честно при помощи системы, но система выдуманная, того и делаем чего хотим;))

Учитель может:
- Помещать материал
   - Создавать лекции
   - Создавать лабы, тз, пз.
- Проверять\оценивать знания
   - Давать тестовые задания
   - Проводить экзамен
- Участвовать в общении
   - Обсуждать тему\проблему с студентами, преподавателями.

Админ может:
- Регистрировать пользователей (ну и удалять, править, думаю это всем понятно)
   - Учителя
   - Студента
- Участвовать в общении (пусть уж он и секретарем и саппортом у нас будет)

Ну вообщем-то и все. Хватит для первого прогона да и еще для системы - плода больного воображения.

Маладца, очень все прозрачно, ясно и доступно. И главное без особых изысков и понятно. А то что потом вопросы будут возникать, так это очень прекрасно.
Завтра постараюсь сочинить ответ:-)

Очень жду.
Просто не имею опыта создания больших систем.
Незнаю как правильно все делать с точки зрения UML.
Где необходимо указывать связи а где нет.

Буду рад разбору.

А вот картинки содержат много ошибок.
Общая диаграмма.
Это скажем так ВИ типа облако или небо, но что-то явно непользовательское.
В одной книжке, пока не скажу в какой не помню, есть такие рекомендации:
Следуй правилу WAVE
W - моделируй или описывай не как, а что нужно делать - what
A - укажи кому это надо, ради кого это действует - actor
V - какое значение получается в ходе ВИ - value (результат)
E - процесс воспринимается как неделимая совокупность действий - entire

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

Диаграмма учитель
Кислое с пресным. Так нельзя. ВИ это действие, глагол! или отглагольное существительное.
Стрелка с с треугольником это обобщение. Одно обобщается другим, или наследует. Стрелка указывает на родителя, дочки наследуют все от родителя и дополняют его чем-то своим.
Стрелка extend расширение  указывает на ВИ, который расширяется. Работает и используется тогда, когда расширяющий ВИ возникает вследствие некого условия.
То есть у вас проверка знаний "расширяет" поставить оценку. При этом связь должна быть между актером и ВИ поставить оценку, а по идее должно быть наоборот. Логика, проверка знаний предполагает выставление оценки, но только при условии ее полного выполнения (на некий нижний проходной балл). И с инклюдами у вас заморочка мне кажется. Логика теряется. Кстати include как раз направлен на ВИ, который подключается. Т.е. стрелка показывает направление чтения. один ВИ включает другой. Включение тоже надо рассматривать осторожно. Включение имеет смысл тогда, когда Актеру нет явной енобходимости начинать некий процесс или процесс тесно интегрирован с другим процессом.
Проверка знаний включает просмотр работ студентов. А что есть другие виды? Почему же их нет? А если он один, то не следует ли описать это в сценарии?
Я даже что-то и растерялся, даже не смог придумать сценарий:-))

Ну про остальное, позже. Хорошо?

Рассмотрим к примеру диаграмму Администратор.


ВИ::Регистрация. По сути должен восприниматься как абстрактный ВИ, поскольку он обощает два других показанных на диаграмме. Однако логика не понятна.
Поясню примером: ВИ::Принять платеж, обощает такие варианты как: Принять платеж наличными, Принять платеж по кредитной карте, Принять платеж по банковскому чеку. Т.е. Нет ВИ принять платеж, есть его модификации, но есть нечто общее во всех вариантах, что и обобщается.

ВИ:: дипломирование. Можно ли назвать этот процесс целостным, можно ли описать его в виде последовательности действий, причем количество таких действий порядка 10. Каковы его временные рамки. Из картинки видно, что ВИ обобщается через один другой ВИ. Зачем тогда дипломирование, может сразу Выдать диплом

Давайте расссмотрим две цели Студента:
1. Изучить материал
2. Проверить знания

На уровне БМ (масштаб - университет) получаем:
1. Один Актер: Студент
2. Два ВИ:
а. Изучить материал
б. Проверить знания


На уровне СМ (масштаб - Система) получаем:
1. Два Актера:
а. Студент
б. Преподователь (это работник Университета, который нужен для релизаци наших двух БВИ)
3. Несколько ВИ:
а. Со стороны Преподователя:
- Добавить материал (для изучения, для практик, для тестирования и т.д.)
б. Со стороны Студента:
- Изучить материал (прочитать добавленный матераил для изучения, поделать практические занятия и т.д.)
- Пройти тест
в. Появляется еще один ВИ - "Получить помощь"
Данный ВИ взаимодействует с двумя актерами: Студентом и Преподователем.
Т.е. С. задает вопрос, а преподователь отвечает на него.

Это мое видение данной модели.

Тут возникает резонный вопрос. Почему мы сделали один ВИ "Получить Помощь"? Хотя его можно и разбить на два ВИ - С->"Добавить вопрос" и П->"Добавить ответ". Здесь мы обращаемся к главной парадигме ВИ - каждый ВИ должен нести цель. Для ВИ "Добавить ответ" нет как таковой цели, если нет вопроса. Во-вторых, получается что ВИ "Добавить вопрос" остается незаконченным, да и цели нет у С просто добавить вопрос, у него цель получить ответ.

Теперь возникает вопрос, а почему мы все-таки разделили один ВИ "Изучить материал" на два - "Изучить материал" и "Добавить материал". На уровне Системы это два законченных ВИ, в принципе не зависящих друг от друга и имеющих свои цели для С и П. П не волнует есть ли студент или нет, у него цель добавить в данном случае материал, он за это деньги получает. А у С цель изучить, что дали, он за это деньги платит и его не волнует как будет туда добавлен материал.

Остальное добавляем по вкусу....

Надеюсь, что adanovenus опубликует окончательный вариант своей модели, чтобы другим участникам было окончательно ясно.

To: Galogen

А вот картинки содержат много ошибок.
Общая диаграмма.
Это скажем так ВИ типа облако или небо, но что-то явно непользовательское.
В одной книжке, пока не скажу в какой не помню, есть такие рекомендации:
Следуй правилу WAVE
W - моделируй или описывай не как, а что нужно делать - what
A - укажи кому это надо, ради кого это действует - actor
V - какое значение получается в ходе ВИ - value (результат)
E - процесс воспринимается как неделимая совокупность действий - entire

Все правильно говорите, ошибку понял.
Наверное привычка выработалась и сработала делать из UseCase-ов Вариант Использования Актером системы, непосредственно само действие, т.е. я опускаюсь до диалога актера с системой.
Просто проекты очень маленькие и дабы устранить все нюансы и все параметры прописать немного отхожу от UML получается.

Отлично подметили про Generalization, из него делаю UseCase цель а ее описывают ряд действий  необходимых для реализации. Вы правы не ЮМЛ уже получается.
Далеко я отошел:(

Просто клиенты обычно довольно долго въезжают в ЮМЛ, поэтому видимо за пол года сполз на неформальные диаграммы.
Наверное прийдется думать, как поступить... Тратить время на объяснение что такое UseCase model и как ее понимать, или использовать такие упрощенные схемы...

Спасибо за замечания, весьма благодарен:)

To: bas

Согласен выкинем админа на..., из системы нашей:)

Давайте расссмотрим две цели Студента:
1. Изучить материал
2. Проверить знания

Ну цели громко сказано... ИМХО если честно, то цель: ДИПЛОМ и\или ЗНАНИЯ.
А изучить материал может быть и задачей и необходимостью.
Проверка знаний тоже самое.
Тоесть филосовский вопрос.
Можно согласиться что цели\задачи:
1. Изучить материал
2. Проверить знания
Но нужно учесть что не в абстрактной и неидеальной модели в нашей голове это неправда.
Уж больно недавно я выпустился:)) Простите не смог пройти мимо таких целей.

И все же более чем согласен, хорошая модель:

На уровне СМ (масштаб - Система) получаем:
1. Два Актера:
а. Студент
б. Преподователь (это работник Университета, который нужен для релизаци наших двух БВИ)
3. Несколько ВИ:
а. Со стороны Преподователя:
- Добавить материал (для изучения, для практик, для тестирования и т.д.)
б. Со стороны Студента:
- Изучить материал (прочитать добавленный матераил для изучения, поделать практические занятия и т.д.)
- Пройти тест
в. Появляется еще один ВИ - "Получить помощь"
Данный ВИ взаимодействует с двумя актерами: Студентом и Преподователем.
Т.е. С. задает вопрос, а преподователь отвечает на него.

Отлично все расписано.
Наверное я слишком вдаюсь в мелкие вещи, нюансы и т.п.

bas - Спасибо!

Вобщем вот что у меня без админа получилось, ну собственно по описанию bas-a.
Жду комментариев, хотя диаграмма очень простая, навернуться так сказать вроде негде...

П.С. А вот получение диплома от системы... Мне кажется весь бизнес сейчас в этом заключен во многих ВУЗах.

Согласен выкинем админа на..., из системы нашей:)

Никого мы выкидывать не будем. Это был только пример разложения высокоуровневых целей. Добавлять Админа надо, но это Вы уже сами.

Давайте расссмотрим две цели Студента:
1. Изучить материал
2. Проверить знания

Ну цели громко сказано... ИМХО если честно, то цель: ДИПЛОМ и\или ЗНАНИЯ.
А изучить материал может быть и задачей и необходимостью.
Проверка знаний тоже самое.
Тоесть филосовский вопрос.
Можно согласиться что цели\задачи:
1. Изучить материал
2. Проверить знания
Но нужно учесть что не в абстрактной и неидеальной модели в нашей голове это неправда.
Уж больно недавно я выпустился:)) Простите не смог пройти мимо таких целей.

Я что-то не совсем понял, куда была напрвлены эта реплика Толи в чисто филосовский аспект либо в практический. Если первое, то это не ко мне
А если по делу, то см. тему Декомпозиция.

П.С. А вот получение диплома от системы... Мне кажется весь бизнес сейчас в этом заключен во многих ВУЗах.

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

По Диаграмме. Можно на ней и не указывать обобщения. Т.к. имея большую систему, Вы просто погрязните в "Яйцах". Это все можно описать либо в сценария, либо в комментах, либо сделать несколько ДД или ДП. На диаграмме это желательно не указывать. Если подходить с точки зрения текстового описания (как учил Юрий Булуй), то ВИ - это главы/разделы в нашей спецификации.

Дорисовываем диаграмму с Админом и получим хорушую CДВИ.