361

Задачи студентов / Re: диаграммы последовательностей

« : 06 Декабря 2016, 23:17:49 »

Evelina123,
составитель пособия, по которому Вас учат, имел в виду следующее:
"Создать диаграмму" -- по его версии, значит: выбрать нужный пункт в меню среды моделирования. После "создания" в Вашем проекте должны появиться три пустые диаграммы последовательности (по одной для каждого прецедента).
Пункты 2 и 3 -- это наполнение созданных пустых диаграмм. Сначала Вы добавляете на них элементы (линии жизни объектов и действующих лиц), затем -- связи (сообщения).
Чтобы оценивать диаграммы, которые Вы нарисовали, во-первых, нужно видеть ту версию текста задания "Библиотека", которую выдал Ваш преподаватель, во-вторых, будет лучше, если Вы будете прикладывать не файлы Visio, а скриншоты диаграмм, сохранённые как GIF, и приложенные к Вашим сообщениям.

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

На диаграмме классов (лаба 3) у атрибута сначала следует указать его имя, затем после двоеточия его тип. Классы Вы выделили не очень удачно. Никаких других пользователей кроме библиотекарей в Вашей системе нет. Зачем тогда заводить отдельно класс Библиотекарь и класс Пользователь? ЧитательскийБилет хранит сведения о читателе, но сведения о том, что читатель взял или вернул книгу следует хранить в объектах другого класса, связанного с читательскимбилетом. О книгах в Вашей системе хранятся разные сведения: об экземпляре книги (который выдают и принимают) и книге как позиции в каталоге (с названием, перечнем авторов и т. д.). Это тоже разные классы.

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

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

362

UML SysML и пр. / Re: Как указать что человек работает в нескольких компаниях (UML, кратность)?

« : 25 Ноября 2016, 10:01:56 »

Эрикссон и Пенкер в своём бизнес-паттерне Занятость выделяют занятость (как таковую), должность (как позицию в штатном расписании) и назначение на должность (как материализованную связь между должностью и занятостью). См. Business Modeling With UML: Business Patterns at Work

363

UML SysML и пр. / Re: Внутренний переход параллельного композитного состояния

« : 24 Ноября 2016, 03:28:28 »

При таком подходе, я полагаю, "площадка" становится чем-то вроде оперения у стрелки псевдозвена.

Дочитало стандарт 2.5 до описания конкретного синтаксиса. Нашло там стрелки, у которых кружки являются частью оперения (или острия), и про которые подчёркнуто, что это не две части диаграммы, а одна. К моему сожалению, это не части диаграмм состояний, а потерянные и найденные сообщения на диаграммах последовательности. Интересно, к какой версии стандарта кружки отделятся и заживут своей жизнью.)
На своей родной планете уже видело "творческое использование" найденных сообщений (безымянных) как своего рода "начальных псевдосостояний" на диаграмме последовательности. Объяснение "творчества":
-- А это у вас что?
-- А это у меня отмечено, откуда всё начинается.

364

Примеры / Re: Рефакторинг диаграммы состояний

« : 11 Ноября 2016, 01:37:31 »

Ну вот экзотическое решение с состоянием подмашины. Если у Ok и Avail разные кишки, то подмашину ещё придётся и экстендить. Из пушки по воробьям.

365

Примеры / Re: Рефакторинг диаграммы состояний

« : 10 Ноября 2016, 00:34:38 »

В 1996-м, описывая версию диаграмм для Statemate, он уже такого себе не позволял. Аналогично в 2004 в версии для Rhapsody. Оттуда и цитировалось. В 1987м в "On the formal semantics of statecharts" "вертолётная площадка" вообще оказывается набалдашником на конце "исторического входа" в состояние, непосредственно обрамляющее её. Т. е. три соавтора уговаривали его за "крючки" и уговорили. В версии электронных часов 1988-го года "On visual formalisms" схожий с фиг. 14 фрагмент решён им иначе (фиг. 22).
И, наконец, рассматривая драфт рисунка к статье, на которую Вы сослались, в "Statecharts in the making" (фиг. 20), мы видим в исходнике "крючки".) То есть, верстальщик не понял, почему "крючок", и испортил диаграмму!)

По теме: покружив так и этак, решило, что размер примера не даёт в достаточной мере оценить размер выгоды, получаемой после рефакторинга. Сначала у нас 3 состояния и 5 переходов (в сумме 8 ). Потом 4 состояния и 4 перехода (те же 8 ). Или 4 состояния + 4 перехода + 1 "верт-площадка" (ого, 9). Наконец, 4 состояния + 4 перехода + 2 псевдосостояния (ого-го, 10). По примитивной "количественной оценке" получаем, что первый вариант рефакторинга не упрощает диаграмму, а два других усложняют. Введя в исходную диаграмму больше подсостояний, можно ощутить движение к лучшему.

Но если считать не по стандарту, т. е. нестабильные вершины рассматривать как начала/продолжения переходов, то оценка всегда 8.

366

Примеры / Re: Рефакторинг диаграммы состояний

« : 08 Ноября 2016, 19:33:43 »

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

367

UML SysML и пр. / Re: Внутренний переход параллельного композитного состояния

« : 12 Октября 2016, 16:02:17 »

Стандарт пишет, что квалификаторы принадлежат memberEnd'ам ассоциации, не оконечным классам. (И даже, что рисовать квалификатор надо не как "бородавку" на классе, а как "присоску" на ассоциации.) Это значит, что от B зависит ассоциация. Описание связанных ей классов A и C может не содержать упоминания B, и классы могут быть независимы от B.
И, конечно, в стандарте (как и в книгах) мне не попался ни один пример с квалификатором-классом.

368

UML SysML и пр. / Re: Внутренний переход параллельного композитного состояния

« : 11 Октября 2016, 02:29:30 »

Вот уж не знаю, откуда рисовать зависимость к B. От ассоциации?)

369

Примеры / Re: Курсовой проект - Книжный магазин

« : 09 Октября 2016, 13:22:36 »

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

370

UML SysML и пр. / Re: Внутренний переход параллельного композитного состояния

« : 09 Октября 2016, 12:49:39 »

Что вызывает сомнение - то, что перечислимый тип может участвовать в ассоциации?

Привычнее видеть, что у класса есть атрибут перечислимого типа и проведена зависимость от класса к типу. Привычка идёт от увиденного в книгах и т. п. В стандарт не лазило. Как по мне, data type и enumeration недоклассификаторы, в том смысле, что их "экземпляры" не соединяются с экземплярами классов, а являются значениями их слотов.

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

В верхней части рисунка у класса C починённое положение, а у A и B -- главное. Они полноправные партнёры в связи, C -- их обслуживает, обеспечивая сохранение свойств связи. В нижней части рисунка полноправны A и C, а B уточняет связь. StateBehaviour -- часть состояния. Разумно связать их ассоциацией (композицией). Тот факт, что поведение каждого типа (по входу, по выходу и внутренняя деятельность) у состояния может быть не более чем одно, удобно показать квалификатором.

Можно предположить, что дело в "звучании" терминов - "ФИНАЛЬНОЕ состояние", "переход по ЗАВЕРШЕНИЮ". Явно звучит "Конец", "Финиш", "Уже всё". И тут внутренний переход, что явно предполагает продолжение - непорядок!.

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

371

Примеры / Re: Курсовой проект - Книжный магазин

« : 08 Октября 2016, 11:48:21 »

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

372

Примеры / Re: Материалы (ТЗ) мастеркласса по созданию требований к BTS (с ЛАФ)

« : 08 Октября 2016, 11:36:05 »

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

373

Примеры / Re: Помогите разобраться в терминах

« : 08 Октября 2016, 11:26:14 »

Подсистема в разных проекциях отображается на разные элементы UML. На диаграмме вариантов использования она может быть представлена как subject (если моделируем её использование) или как actor (если моделируем не её, а другую подсистему, элементом контекста которой является подсистема-actor). В модели логической структуры подсистема представлена пакетом со стереотипом <<subsystem>>. В модели реализации подсистема отображается в компонент с тем же стереотипом.
На всякий случай, подсистемы независимы лишь отчасти. В противном случае система рассыпется в набор несвязанных между собой фрагментов, не образующих единого целого.

374

UML SysML и пр. / Re: Внутренний переход параллельного композитного состояния

« : 07 Октября 2016, 16:23:52 »

Попробую на зуб. Сомнительным кажется соединение класса с перечислимым типом с помощью ассоциации (SimpleState-*--*-TypeStateBehaviour). М. б. соединить SimpleState со  StateBehaviour, а TypeStateBehaviour сделать типом квалификатора при этой связи?
Пользуясь случаем врублю офтопик. Стандарт против внутренних переходов по завершению. А, собственно, почему?

375

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

« : 03 Октября 2016, 14:27:52 »

Задача стоит вот такая "Разработка информационной системы поэтапной сборки шкафа автоматики управления выключателем"

К этой задаче относятся 4 "яйца" в левом нижнем углу диаграммы. Если толковать расширительно, то м.б. + "яйца" правой половины. Да и то, возникают вопросы как может быть автоматизирована сборка, программирование, исправление монтажа. Закупка и моделирование могут рассматриваться как этапы "жизненного цикла", но не сборки как таковой.
Предлагаю дать другие имена "мужикам"-отделам: "специалист по качеству", "специалист по сборке".
Совет по стилю: "мужиков" расставить по границам диаграммы, "яйца" сложить в её середину. Стараться рядом с "мужиком" класть те яйца, с которыми он связан. Избегать по возможности пересечения связей.