376

Примеры / Re: use-case. Реализация продукции хлебопекарни.

« : 03 Октября 2016, 01:27:54 »

Можно отметить общее свойство обоих Ваших диаграмм, похожее на ошибку. Если полагать, что Вы моделируете бизнес-процесс, и читать их по стандарту, то неясно, что именно лежит внутри границ "сабжекта", подвергаемого моделированию. На диаграмме ВИ "мужиками" (действующими лицами) изображают внешние элементы контекста, лежащие за границами "сабжекта". Т. е., если Вы моделируете пекарню, то те, кто в пекарне работает, не могут быть "мужиками" на диаграмме. Они внутри границ, а не вне. Их помещают на диаграммы классов, диаграммы взаимодействия как исполнителей. Функции исполнителей моделируют как их операции, а не как ВИ. "Мужики" пекарни -- это покупатели продукции, сборщики налогов, пожарники и т. п. (все они не работают в пекарне!).
Аналогично, если в модели конструкторского бюро Вы считаете инженера "мужиком", то это какой-то "заграничный" инженер, которому, к примеру, лень что-то конструировать и он подписал бюро на субподряд.
Подобная ошибка проиллюстрирована на сайте, куда Вас однажды я уже направляло. Вот такая картинка:

Красным покрашены "мужики", которых на диаграмме быть не должно.
Так вот, если учитывать всё это, то диаграммы про пекарню моделируют X = пекарня - менеджер - бухгалтер - кладовщик - экспедитор (здесь "-" -- это "минус"). По-моему, X -- это пекари, тестоместы и т. д. Вряд ли можно ожидать, что для бухгалтера они будут оформлять накладную, а для кладовщика вести учёт остатков.
Возможно Вы моделируете какую-то систему, автоматизирующую деятельность пекарни, связанную с реализацией её продукции. Тогда работники пекарни могут быть её "мужиками". Но сомнительно, как мне кажется, что клиент сам с помощью этой системы будет организовывать свои денежные расчёты. Для расчётов есть банки.
Аналогично можно рассмотреть модель про бюро. Если из него вычесть упомянутые на диаграмме отделы, то что останется? Если моделируется система, автоматизирующая работу, то вряд ли её пользователем будет отдел целиком, но сотрудник отдела может быть.
Укажите, какая перед Вами стоит задача! Вы просите рассмотреть ответы, не открывая, решениями чего они являются. В результате нам остаётся лишь гадать, чего от Вас требуется.
P. S. Всё то, что Вы включили в оформление накладной скорее является включениями в работу с заказом. Например, без "внесения характеристик и количества продукции" в заказ нельзя выполнить проверку наличия товара. Мне представляется, что большая часть накладной -- это сведения из заказа.

377

Примеры / Re: use-case. Реализация продукции хлебопекарни.

« : 02 Октября 2016, 16:18:44 »

Т.е. лучше будет убрать линии ассоциаций от расширений?

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

378

Примеры / Re: use-case. Реализация продукции хлебопекарни.

« : 30 Сентября 2016, 00:42:23 »

Спасибо, очень занимательное руководство.
Но во первых там целый комплекс диаграмм, а не только ДВИ
А во вторых, при всём уважении к парням из Rational, похоже на инструкцию "Как правильно забивать гвозди нашим микроскопом"

А в-третьих, ю-к-диаграмму можно таки использовать как перечень бизнес-процессов предприятия. О чём изначально и шла речь.
А в-четвёртых, известно, что в IBM/Rational -- все малахольные, но возможности использования нотации из-за этого не сужаются.
А в-пятых, основные проблемы автора топика не связаны с выбором нотации. Выбора у него, собственно и нет.

379

Примеры / Re: use-case. Реализация продукции хлебопекарни.

« : 30 Сентября 2016, 00:36:32 »

Спасибо, но разве это метод H. E. Eriksson'а and M. Penker'а У них нотация обозначения вроде бы совершенно иная?

Я не сразу поняло, о чём Вы. Признаю за собой заблуждение относительно E&P-метода, полистав ссылку. Полагало, то рейшеналовские "мужики с гвоздями в голове и треснутые яйца" являются развитием идей E&P. Добавлю, что и за E&P признаю заблуждение. Полагать, что их Process-диаграмма является размеченной стереотипами диаграммой деятельности, сейчас не осталось никакой возможности. А представить её юз-кейс-диаграммой можно вполне.

380

Бизнес-анализ и Целеполагание / Re: Как перейти из основн сценария об общих полях к сценарию о заполнении уникальных

« : 29 Сентября 2016, 08:14:04 »

Общее лучше описать один раз в основном потоке.

381

Примеры / Re: use-case. Реализация продукции хлебопекарни.

« : 29 Сентября 2016, 08:12:09 »

"Rational Edge" 11.2002

382

Бизнес-анализ и Целеполагание / Re: Как перейти из основн сценария об общих полях к сценарию о заполнении уникальных

« : 27 Сентября 2016, 22:12:20 »

Заполнение уникальных для каждого типа автомобиля полей можно описать как отдельные подчинённые потоки. Переход к ним в основном потоке может выглядеть так:
N. В зависимости от введённого типа автомобиля выполняется соответствующий подчинённый поток ("Ввод сведений о грузовике" либо "Ввод сведений о легковушке").

383

Примеры / Re: use-case. Реализация продукции хлебопекарни.

« : 27 Сентября 2016, 22:01:49 »

Нотация не виновата. Метод H. E. Eriksson'а and M. Penker'а позволяет использовать нотацию и [конкретно] диаграмму вариантов использования для бизнес-моделирования.

384

Обучение / Re: Подскажите начинающему ассистенту преподавателя

« : 07 Сентября 2016, 18:14:59 »

Так ведь стало лучше, или тоже ерунда?

Свою предыдущую рекомендацию -- взять чужой готовый хороший пример -- я продолжаю считать актуальной.

На диаграмме классов ассоциацию между Отправлением и Типом отправления замените на зависимость Отправления от Типа.
На диаграмме последовательности было бы логичнее сначала добавлять заказ созданному клиенту, а затем добавлять отправления в заказ. Отправление, являющееся частью заказа, т. о. подчинённое ему, ведёт себя с заказом "не по рангу". Кроме того, на диаграмме антипаттерн "телепатия": как Отправление может догадаться, что создан заказ и пора посылать ему сообщение "добавь меня"? Никак. Откуда у отправления может возникнуть ссылка на только что созданный заказ?

Диаграмма состояний могла бы обрести смысл, если бы фиксировала переходы между разными состояниями (способами поведения) объектов. Как пример, при составлении заказа в него можно добавлять отправления, но в созданный и отправленный заказ добавлять что-либо поздно.

385

Обучение / Re: Подскажите начинающему ассистенту преподавателя

« : 06 Сентября 2016, 18:14:31 »

Что Вы показываете на диаграмме, зависит от того, с какой целью Вы её рисовали. Вы не привели никаких описаний, поэтому диаграммы можно оценивать лишь как есть -- т. е. по соответствию/несоответствию правилам UML. Операции представляют в модели ответственности объектов класса, они же являются обработчиками принятых объектами сообщений. Но в модели, которую Вы представили, это не так.

386

Обучение / Re: Подскажите начинающему ассистенту преподавателя

« : 06 Сентября 2016, 11:32:20 »

Коммуникационная диаграмма перепутана с диаграммой последовательности.
На диаграмме классов есть Заказ, но из диаграммы вариантов использования не следует, что какие-либо действия с заказом совершаются.
Сигнатуры атрибутов ещё куда ни шло (действительно ли нужно указывать типы латиницей?), но у операций -- нет слов. В дополнение к этому замечанию укажу, что ни одно сообщение с диаграмм взаимодействия нельзя связать ни с одной операцией. Поясняю, если объект-сотрудник посылает сообщение "наклеивает номера" объекту-отправлению, это значит, что у отправления есть операция "наклеивает номера" и это оно -- отправление -- их наклеивает.
Диаграмма состояний бессмысленна. Entry и exit -- это действия по входу и выходу, а не события, вызывающие смену состояний. Таковые события следует указывать на переходах.

Подсказать в такой ситуации можно следующее: на русском языке есть достаточное количество учебников (обычно, переводных) с учебными примерами по UML. Там бывают ошибки, но более мелкие, чем те, что указаны выше. Используйте примеры из проверенных источников.

387

Примеры / Re: На сколько правильный пример диаграммы?

« : 31 Августа 2016, 14:44:43 »

11ая глава стандарта UML2.5. Только тут есть отступления от стандартной нотации. Кроме того, в стандарте, как обычно, накручено так, что OCL я бы применил с большей уверенностью.

388

Примеры / Re: На сколько правильный пример диаграммы?

« : 30 Августа 2016, 19:07:49 »

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

389

Примеры / Re: На сколько правильный пример диаграммы?

« : 30 Августа 2016, 11:16:50 »

Мне нравится, как у Амблера написано про годные гибкие модели: http://agilemodeling.com/essays/whenIsAModelAgile.htm Что у модели есть цель и аудитория, что она достаточно подробна, достаточно точна  и достаточно непротиворечива. В этом смысле любую модель можно критиковать, определяя свою цель, свой уровень подробности, точности, непротиворечивости.
Пример, похожий на [1] даётся далее в главе 6

поэтому тут можно усмотреть чисто методические причины.
[2] Когда было проще с проходом в здания, такое практиковалось и, насколько мне известно, официально не запрещено.
[3] Может. У нас физику читали преподы с другого факультета (физфака). А наши преподы мучили студентов-геологов.
[4] Имеет смысл отделить описание курса от прочтения курса, если мы хотим идти дальше учебного эскиза. 

390

Примеры / Re: На сколько правильный пример диаграммы?

« : 30 Августа 2016, 10:16:43 »

Если верить этому переводу...

Это перевод первой редакции книги (про "первый" UML). Вот мы и раскрыли тайны "кухни". При подготовке перевода второй редакции поленились снова перевести диаграмму, взяли готовую из предыдущего перевода, не обратив внимание на то, что у неё в разных редакциях разные версии.