481

Примеры / Re: Сценарий использования выдачи книги

« : 28 Марта 2016, 11:59:24 »

Уважаемые аналитики, помогите, пожалуйста еще с одной:
Мне требуется дополнить диаграмму сущность-связь для описания модели автоматизации библиотеки.

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

482

Примеры / Re: Аннулирование сущности в любой момент времени. Как отобразить?

« : 28 Марта 2016, 11:47:04 »

Я бы посмотрел в сторону Interrupting Edge (http://www.uml-diagrams.org/activity-diagrams.html). Другой способ все-таки использовать не диаграммы деятельностей, а диаграммы автоматов.

Дельный совет как по части возможностей диаграмм деятельности для решения обозначенной задачи, так и по части переосмысления выбора вида диаграмм.
В сети есть пример, поясняющий использование interrupting edge:

483

Примеры / Re: Продажа автомобилей

« : 26 Марта 2016, 12:47:22 »

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

484

Примеры / Re: Аннулирование сущности в любой момент времени. Как отобразить?

« : 26 Марта 2016, 10:48:10 »

нужно создать комплексное надсостояние с переходом из псевдосостояния выхода в само себя (см. пример во вложении).

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

485

Примеры / Re: Продажа автомобилей

« : 26 Марта 2016, 10:25:23 »

Поправил диаграмму. Надеюсь, что теперь я всё правильно понял. За исключением замечания по поводу перехода к уровню реализации, но с этим постараюсь что нибудь придумать этой ночью.

Если продолжать рассмотрение примера, то следует заметить, что рисование структурированной диаграммы ВИ (со связями между ВИ: <<include>>, <<extend>>) оправдано лишь после того, как составлены описания ВИ. В отрыве от описаний пунктирные стрелочки несут мало смысла и являются лишь поводом для гипотез, действительно ли "выбор автомобиля" является частным случаем "выбора клиента".

486

О Сайте и Форуме / Re: Правила работы на форуме uml2.ru

« : 26 Марта 2016, 08:47:43 »

Друзья,

Очень прошу соблюдать правила форума, описанные в первом сообщении этой темы!

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

487

Примеры / Re: Activity diagramm. Как направить один объектный узел сразу двум узлам управления

« : 20 Марта 2016, 21:18:03 »

"Ты не мудри, ты пальцем покажи...", - из очень "бородатого" анекдота 

Пример диаграммы, в которой один объектный курсор форкается и передаётся двум принимающим узлам, дан во вложении к этому сообщению.

488

Примеры / Re: Activity diagramm. Как направить один объектный узел сразу двум узлам управления

« : 20 Марта 2016, 17:26:39 »

Тоже быльём поросло, но я как НЛО могу встрять. Своё встревание предваряю замечанием, что, на мой взгляд, часть стандарта UML, описывающая объектные потоки в моделях деятельности, очень перемудрённая .

По стандарту fork подразумевает параллелизм, в том смысле, что он может его реализовать. Но параллелизм [после fork] возникает не во всех случаях. Если fork для объектных потоков, это значит, что любой входящий объектный токен копируется на каждый исходящий объектный поток. Если их готовы принять узлы, куда ведут потоки, то они [параллельно] проходят дальше. Если не готовы, то они стоят и ждут, когда их примут.

Datastore по стандарту не занимается рассылкой копий объектных токенов как таковой. Datastore сохраняет в себе копии всего того, что в него пришло (в единственном экземпляре). И за счёт этого "размноженный объектный токен" может пройти по разным исходящим потокам. 

P. S. Два объектных потока, исходящих из деятельности, предполагают, что у неё есть два выходных параметра (объектных узла), и из каждого такого узла, в общем случае, выйдут разные объектные токены. То есть, для объектных потоков такая конструкция не аналогична fork, как в случае потоков управления. Придётся либо помещать "объектный fork" явно вне деятельности, либо моделировать размножение внутри деятельности с явным указанием двух или более однотипных out-параметров, через которые будут выходить копии токенов.

489

Примеры / Re: Программа для изучения иностранного языка

« : 20 Марта 2016, 16:12:31 »

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

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

Так как у пользователя единственный наследник, то модель нисколько не потеряет, если её упростить -- убрать пользователя и провести коммуникацию между студентом и вариантом использования "Зарегистрироваться". Смысл будет прежним. Если, заводя пользователя, Вы имели в виду, что студенты -- это зарегистрированные пользователи, то модель неудачна. По смыслу связи между действующими лицами выходит, что студенты, являясь пользователями, могут зарегистрироваться, т. е. они не обязательно зарегистрированные, или они могут регистрироваться повторно. Более точная модель содержала бы два действующих лица, не связанных между собой: 1) незарегистрированный пользователь, который может зарегистрироваться; 2) зарегистрированный пользователь, который может Войти, Пройти тест и т. п.

490

Примеры / Re: Диаграмма классов для такси-сервиса

« : 20 Марта 2016, 13:51:00 »

Решила начать с описания сущностей.
Получилась такая диаграмма https://drive.google.com/file/d/0By6RSFsXZ70jT054WEdOSEVSeGM/view?usp=sharing
Всячески приветствую комментарии и критику.

Поздновато, конечно, подключаться, есть риск, что уже неактуально.

Смотрите, janna, как узнать по Вашей модели, с кем пользователь, скажем, Иван, может разделить оплату заказа? Со всеми? Или ни с кем? Или только со своей гёрл-френдом Марьей? Надо от Ивана провести связи к его гёрл- и бой-френдам.

Второе, придумка приделать хвостик к заказу, где будет лежать всё то, что относится к новой фиче, -- это здорово. Вопрос в том, достаточно ли одного хвоста разделённому заказу? Скажем, три поросёнка поехали на такси в Дальнее Бутово присмотреть участок под домик. Наф-наф, такой, говорит:
-- Надоело мне за всех платить, давайте рассплитим.
Делать нечего, рассплитили.
Но даже если мы опутаем поросят дружественными связями, как отследить, что все трое оплатили свою часть. Janna, давайте сделаем заказу столько хвостов, сколько было "поросят", сплитящих оплату. На каждом поросячьем хвостике будем делать зарубки: принял ли поросёнок предложение участвовать в сплите; оплатил ли он свою долю и т. п. Ну и, понятное дело, хвост нужно соединить со своим хозяином-свином.