Учусь в универе на специальность инженер АСУ, 5й курс. Тема курсовой "проектирование клиент-сервера для тренажера крана".
Писал, пока не возникла необходимость построения UML диаграмм. С UML знаком очень плохо, можно сказать я в нем полный 0.
Вот построил диаграмму прецедентов. Прошу оценить. Теперь мне необходимо построить диаграммы объектов и классов. Читая информацию из различных источников ничего не понял. Посоветуете может что-нибудь?
Объектом автоматизации здесь является процесс обучения машинистов крана.

Интересно, кто мне прислал сообщение об этой работе? Вроде, я не подписывался?

Тем не менее, по сути.

Вы знаете, для первого раза диаграмма меня порадовала, с учетом того, что, как Вы написали, раньше этим не занимались!
Складывается впечатление, что Вы понимаете, что рисуете.

Первые замечания (не все, чтобы перегрузки не было):

1. Каким инструментом моделирования Вы пользовались? Если MS Visio, то это инструмент рисования картинок, а не моделирования. Но этот инструмент явно не контролировал Ваши действия. В UML стили изображения отношений между элементами имеют смысл. Отношения между субъектами и прецедентами - это ассоциации. Они показываются сплошными стрелками с открытой стрелкой, или вообще без стрелок (чаще всего, ведь в данном случае они обозначают последовательности взаимодействий между субъектом и прецедентом для достижения цели субъекта, а не одностороннюю передаче информации). То, что нарисовали Вы, означает, что, например, элемент "Госгортехнадзор", очень уважаемый (в прошлом) орган, является потомком элемента "Выдать лицензию".
Если бы Вы пользовались инструментом моделирования, он не позволил бы создать такую связь.

2. То, что Вы нарисовали, называется "Диаграмма бизнес-прецедентов". (Термин use case на русском по разному обозначают, я пользуюсь словом "прецедент"). На диаграмме Вы показали бизнес-процессы, которые выполняются при обучении и допуска к работе.
Диаграмма прецедентов сродни каталогу, который перечисляет процессы и их участников, ничего не говоря об их очередности. У Вас в одном месте очередность указана ограничением {если...}. Вряд ли это можно считать ошибкой, но UML этого не предусматривает. Предусловия перечисляются в текстовом описании прецедента.
Очень часто бизнес-модель разделяют в несколько уровней (Не подумайте. что на одной диаграмме, имеются ввиду уровни моделирования!).
Верхний уровень - общий бизнес процесс, например "Подготовка специалиста". Этот процесс описывается в виде текста и/или с помощью диаграммы деятельности. Действия в этой диаграмме - бизнес-прецеденты более низкого уровня, те, которые Вы нарисовали. (См. RUP, Моделирование больших систем при бизнес-моделировании, или книжку Коберна). Вот в диаграмме деятельности верхнего уровня и показывается очередность, если Вам важно это показать.

3. На диаграммах прецедентов не принято определять метки для ассоциаций. Т.к. правилами языка установлено, что взаимодействие с прецедентом должно реализовать цель субъекта. Но, если с прецедентом взаимодействуют два или больше субъектов, то реализуется цель только одного из них. Другие помогают! Ассоциация с субъектом, цель которого выполняется, должна быть помечена ключевым словом <<primary>>. Тогда другие метки будут просто не нужны. И так все понятно.

4. Название прецедента должно отражать цель первичного субъекта. У студента есть желание "столкнуть", наконец, экзамен. Соответствующий прецедент должен называться "Сдать экзамен" или "Сдача экзамена". Это зависит от языковых традиций. В англоязычных странах принята неопределенная форма глагола, в русскоязычных - отглагольное существительное в именительном падеже. Но это неважно, главное одинаково. 

На первый случай и так много информации.
Желаю успехов.

Спасибо Вам большое за ответ и за советы!

Каким инструментом моделирования Вы пользовались? Если MS Visio, то это инструмент рисования картинок, а не моделирования. Но этот инструмент явно не контролировал Ваши действия. В UML стили изображения отношений между элементами имеют смысл. Отношения между субъектами и прецедентами - это ассоциации. Они показываются сплошными стрелками с открытой стрелкой, или вообще без стрелок (чаще всего, ведь в данном случае они обозначают последовательности взаимодействий между субъектом и прецедентом для достижения цели субъекта, а не одностороннюю передаче информации). То, что нарисовали Вы, означает, что, например, элемент "Госгортехнадзор", очень уважаемый (в прошлом) орган, является потомком элемента "Выдать лицензию".
Если бы Вы пользовались инструментом моделирования, он не позволил бы создать такую связь.

Это я постарался учесть

То, что Вы нарисовали, называется "Диаграмма бизнес-прецедентов". (Термин use case на русском по разному обозначают, я пользуюсь словом "прецедент"). На диаграмме Вы показали бизнес-процессы, которые выполняются при обучении и допуска к работе.
Диаграмма прецедентов сродни каталогу, который перечисляет процессы и их участников, ничего не говоря об их очередности. У Вас в одном месте очередность указана ограничением {если...}. Вряд ли это можно считать ошибкой, но UML этого не предусматривает. Предусловия перечисляются в текстовом описании прецедента.
Очень часто бизнес-модель разделяют в несколько уровней (Не подумайте. что на одной диаграмме, имеются ввиду уровни моделирования!).
Верхний уровень - общий бизнес процесс, например "Подготовка специалиста". Этот процесс описывается в виде текста и/или с помощью диаграммы деятельности. Действия в этой диаграмме - бизнес-прецеденты более низкого уровня, те, которые Вы нарисовали. (См. RUP, Моделирование больших систем при бизнес-моделировании, или книжку Коберна). Вот в диаграмме деятельности верхнего уровня и показывается очередность, если Вам важно это показать.

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

На диаграммах прецедентов не принято определять метки для ассоциаций. Т.к. правилами языка установлено, что взаимодействие с прецедентом должно реализовать цель субъекта. Но, если с прецедентом взаимодействуют два или больше субъектов, то реализуется цель только одного из них. Другие помогают! Ассоциация с субъектом, цель которого выполняется, должна быть помечена ключевым словом <<primary>>. Тогда другие метки будут просто не нужны. И так все понятно.

Не совсем понял про <<primary>> как это обозначается? Т.е. каждую ассоциацию с субъектом нужно пометить таким образом? Метки я пока оставлю, чтобы не запутаться при описании диаграммы.

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

Это тоже постарался исправить.

Какие еще будут замечания? И какие остались?

Вот переделанная диаграмма

Если Вы использовали инструмент моделирования, то м.б. обратили внимание, что у модельных элементов есть свойства. Одно из свойств - это текстовое описание. Его очень полезно заполнять, чтобы потом использовать при описании моделей (диаграмм).
Среди параметров есть такие, как стереотип и ключевые слова. Для нужных ассоциаций там нужно написать слово primary.
Если это инструмент рисования, то вместо ваших меток нужно написать <<pimary>>. В угловых скобках помещаются текстовые обозначения стереотипов и ключевых слов.
Ключевое слово primary у ассоциации означает, что ассоциированный субъект для этого прецедента является первичным; остальные связанные субъекты - вторичные, они помогают выполнить цель первичного субъекта.
Студент пришел на экзамен с целью "спихнуть". Его ассоциация первичная. Профессор сидит за столом и по мере сил "помогает" студенту сдать экзамен. Без его участия прецедент невыполним. Но он вторичный: у него нет цели принять экзамен.
Учебный центр обращается за лицензией (первичный), надзорный орган дает лицензию (за плату!) - вторичный.

Абстрактные прецеденты (включаемые и расширяющие) соединяются с основным прецедентом пунктирной линией с открытой стрелкой. Связь с включаемым прецедентом (общая часть многих прецедентов) от основного прецедента к включаемому имеет стереотип includ (если пользуетесь "рисовальщиком", пишите метку <<includ>>. Связь с расширяющим прецедентом - от расширяющего к основному, стереотип extend.

Студент пришел на экзамен с целью "спихнуть".

У студента есть желание "столкнуть", наконец, экзамен.

Видимо у Вас большой опыт общения со студентами. А судя по повторам и негативной окраске, этот опыт далеко не положительный 

У студента есть желание "столкнуть", наконец, экзамен.Его ассоциация первичная. Профессор сидит за столом и по мере сил "помогает" студенту сдать экзамен. Без его участия прецедент невыполним. Но он вторичный: у него нет цели принять экзамен.

Учебный центр обращается за лицензией (первичный), надзорный орган дает лицензию (за плату!) - вторичный.

[/quote]
В Ваших примерах и диаграмме топикстартера не хватает контекста. В зависимости от контекста Профессор и Надзорный орган могут быть как вне рамок систем, так и внутри нее.

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

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

Эдуард! Я не хочу никого обидеть! Мне просто нужно было привести "зрелищные" примеры, которые были бы понятны "человеку с улицы" (Студента я тоже не хочу обидеть! Он самостоятельно впервые сразу сделал неплохую работу!)

Что касается "первичности" и "вторичности", то в действительности все зависит от контекста.
В данном случае контекст - обучение. Обучающийся реализует свои цели независимо от того, в какой бизнес-системе выполняется тот или иной бизнес-процесс.
Именно студент приходит на экзамен, и именно УЦ просит у Надзора лицензию.
Бизнес-модель вполне реальная, к IT отношения имеет мало, если не будет развиваться в сторону автоматизации.

Если ты не согласен с моими объяснениями первичности и вторичности, сверься с таким авторитетом, как RUP.

Что касается моего опыта, то я всегда был троечником. Но Учителей своих почти всегда уважал и, как ни странно, они меня уважали.
Со студентами общался, когда учился во втором ВУЗе. В первом общался с курсантами.
В настоящее время только с племянниками, которым некогда учиться: они зарабатывают и подучиваются в свободное от работы время. Может быть, мне не повезло с племянниками, а может быть - с госполитикой поддержки образования.
Но последнее лучше обсуждать не на этом сайте!

lnew, не хотел вас обидеть, если все-таки обидел, простите. Просто мне подумалось, что вы преподавали, и большинство студентов не сдают, а "спихивают" экзамен. Для меня (я преподаватель) такая картина (правда не массовая) знакомая.

Если ты не согласен с моими объяснениями первичности и вторичности, сверься с таким авторитетом, как RUP.

Я не выступаю против авторитета RUP, и не буду спорить, чтобы не уводить тему в другое русло обсуждения. Однако я считаю, что синтаксис, семантика и прагматика диаграмм использования предполагает, что вариант использования (прецедент по-вашему) это вариант использования чего-то (какой-то системы) и при использовании этой системы Первичным действующим лицом, она (эта система) может прибегать к услугам внешних ВТОРИЧНЫХ систем, для достижения цели ее использования первичным

В Ваших примерах и диаграмме топикстартера не хватает контекста. В зависимости от контекста Профессор и Надзорный орган могут быть как вне рамок систем, так и внутри нее.

Не понятно что значит "не хватает контекста". Видимо я на столько не образован, так уж вышло. Теперь я постарался обозначить первичные и вторичные субъекты. На сколько верно сделано, что исправить?

И что главное меня сейчас тревожит, это необходимость построения диаграмм объектов и классов. .

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

Я строил диаграмму в редакторе yEd graph editor, остальные тоже там пробую строить. Скачал программы для пострения UML-диаграмм, но разобраться пока в них не смог.

Ээээ..., дорогой!
Да это только вершина! И, может быть, ненужная?

Все равно, сначала сомнения:

1. Бизнес-процесс "Пройти обучение" всегда имеет подпроцессы "Изучить теорию", "Пройти практику" и "Пройти тестирование". Соответственно, я думаю, это включаемые прецеденты: стрелки д.б. наоборот, и д.б. метки <<includ>>.
2. Если УЦ участвует в создании отчета, все правильно. Если же отчет создает инструктор, а потом сдает его в УЦ, линия к УЦ необязательна. А если линию убрать, то и primary на линии "Инструктор - Создать отчет" будет ненужным.
К этой диаграмме больше придраться не могу!

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

Система, которую Вы, как я понял, уже сделали, решает только часть того, что нарисовано! Что именно? Может быть, эти прецеденты выделить цветом?

Тогда можно будет обсудить, что делать дальше. И поподробнее о системе. Именно это и спросил Galogen (про контекст).

Эдуард!

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

Только ленивый не использует пример банкомата.
Если мы моделируем банкомат, прецедент "Получение денег", то клиент - первичный субъект, процессинг - вторичный.
Все то же самое, моделируем систему банкоматов. Соответственно, процессинг включен в систему как некий компонент. Наверное, есть какие-то вторичные субъекты, я их не знаю.

А если мы моделируем бизнес-процессы университета? В отношениях с Министерством все понятно, граница - стена университета. А экзамен - это бизнес-процесс? Без сомнения. Но оба участника так или иначе являются внутренностью университета. Давайте договоримся об условных границах. Границами, по UML, являются субъекты. Если у процесса два субъекта, только один из них м.б. первичным.
Тут пустые размышления могут довести до парадокса "черепахи и олимпийца"!
Договоримся считать системой преподавательский стол, а дальше - нет проблем: пинг-понг!

Если интересно, я могу рассказать, почему использую термин "прецедент". И почему термин RUP "Development Case" я перевел как "Адаптированный процесс". Скажи, где. Не для широкой публики!

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

Тема курсовой "проектирование клиент-серверного приложения для тренажера иммитатора крана", т.е. мне нужно обеспечить взаимодействие инструктора с обучаемым через сеть (ethernet либо wi-fi). Сам клиент-сервер я еще не разрабатывал, разработка будет уже моим дипломом. Эти диаграммы входят у меня в исследование объекта автоматизации. Т.е. после исследования я предлагаю ее автоматизировать, там, скорее всего, уже будет другой набор uml-диаграмм. М.б. я не верно и слишком широко описал систему. Объект автоматизации это, получается, взаимодействие обучаемого и инструктора в процессе обучения.

Договоримся считать системой преподавательский стол, а дальше - нет проблем: пинг-понг!

Дык, и я о том же самом. Всегда нужно указывать контекст, scope. Тогда я буду понимать Вас близко к однозначному.  Все условности возникают из разно понимаемых контекстов. Потому и следует говорить - вот вам моя условность в таком-то контексте...

Если интересно, я могу рассказать, почему использую термин "прецедент".

И почему термин RUP "Development Case" я перевел как "Адаптированный процесс". Скажи, где. Не для широкой публики!

1. в своем блоге
2. Но лучше в блоге сообщества

ps там и обсудим термин "прецедент", а причем тут development case, тоже объясните там

Тема курсовой "проектирование клиент-серверного приложения для тренажера иммитатора крана"Объект автоматизации это, получается, взаимодействие обучаемого и инструктора в процессе обучения.

Точно! Зачем вам что-то знать о лицензии? ведь это никакого отношение к программному обеспечению имитатора крана нет.

Попробуйте не спешить с диаграммами, а сначала сделать следующее:
1. определить действующих лиц
2. определить их ответственности и обязанности
3. возможно определить несколько сценариев типичного поведения в ходе обучения (это можно изобразить с помощью диаграмм деятельности)
4. нарисовать диаграмму использования, если потребуется