136
Sparx / Re: отразить на диаграмме свойства Generalization Set
« : 15 Декабря 2019, 02:24:27 »
Про стандарт, хоть тема про EA. В VP та же ботва (из-за стандарта).(
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 »
137
Sparx / Re: отразить на диаграмме свойства Generalization Set
« : 09 Декабря 2019, 11:06:52 »
Можно подметить особенность нынешнего стандарта UML: на диаграмме свойство Generalization Set, названное в метамодели UML isCovering, отображается как {complete}/{incomplete}. Зачем-то введена синонимия причём раздельная: для абстрактного синтаксиса один термин, для конкретного синтаксиса -- другой. А то бы всё было слишком просто, такова логика авторов стандарта?
139
Sparx / Re: Кооперация
« : 04 Декабря 2019, 02:33:44 »
Можно решить, что кооперация -- плохой способ моделировать паттерн [весь]. Что же делать? Можно вспомнить что в UMLе есть штуковина, внутри которой классы чувствуют себя вполне нормально, внутри которой можно рисовать и ассоциации, и обобщения, и реализации, и зависимости. Это пакет:
И есть в UMLе изобретение авторов языка Ада (того самого) -- параметризованный пакет:
Только вот зависимость связывания, согласно последним веяниям, должна рисоваться как зависимость, не как реализация.
Итак, паттерн можно моделировать пакетом. Участники паттерна и связи между ними становятся элементами пакета. Структура описывается диаграммой, вроде той, что выше. Для описания поведения в состав пакета можно включить кооперацию и внутри неё смоделировать взаимодействие экземпляров участников. Использование паттерна описывается как конкретизация пакета [см. на диаграмме выше].
P. S. У предложенного способа есть недостаток. Связи между классами, соединёнными по рецепту паттерна оказываются отдельно от этих классов. Они лежат в пакете -- конкретизации параметризованного пакета. Где лежат сами эти классы [мне] неясно.
И есть в UMLе изобретение авторов языка Ада (того самого) -- параметризованный пакет:
Только вот зависимость связывания, согласно последним веяниям, должна рисоваться как зависимость, не как реализация.
Итак, паттерн можно моделировать пакетом. Участники паттерна и связи между ними становятся элементами пакета. Структура описывается диаграммой, вроде той, что выше. Для описания поведения в состав пакета можно включить кооперацию и внутри неё смоделировать взаимодействие экземпляров участников. Использование паттерна описывается как конкретизация пакета [см. на диаграмме выше].
P. S. У предложенного способа есть недостаток. Связи между классами, соединёнными по рецепту паттерна оказываются отдельно от этих классов. Они лежат в пакете -- конкретизации параметризованного пакета. Где лежат сами эти классы [мне] неясно.
140
Sparx / Re: Кооперация
« : 03 Декабря 2019, 22:01:52 »
Если жирно некротредить, то можно сказать следующее.
Текущий стандарт UML (который возможно отличается от стандарта из 2010 года) говорит, что кооперация -- это пачка взаимодействующих экземпляров. Если рисуется диаграмма составной структуры, показывающая "кишки" кооперации вроде:
, то роли там можно соединять только коннекторами (но не ассоциациями/агрегациями/композициями, не обобщениями, не реализациями). Так что некоторые картинки, нарисованные по ссылке, которая протухла, невозможны по текущему стандарту. Надо сказать, что и диаграмма с www.uml-diagrams.org, которую я использую, тоже нарушает стандарт. Т. к. внутренности ролей на ней не ролевые, как положено по стандарту, а интерфейсные как по стандарту не положено. Стандартные внутренности ролей -- это вложенные в роли части (parts) и/или свойства (properties). Так что по стандарту кооперация Observer должна рисоваться иначе (тут другая одноимённая кооперация, но смысл тот, что ни атрибутов, ни операций у ролей не должно быть):
Между тем, в стандарте делается некоторый финт. Говорится, что якобы есть альтернативная нотация:
"Альтернативная нотация" соединяет классы (ну, или интерфейсы) и кооперацию какими-то связями. Что это за связи, стандарт не может объяснить. Попытки проводить аналогии с классами, у которых можно по диаграмме составной структуры нарисовать диаграмму классов, где кишки (parts) класса вынуты наружу и нарисованы как классы, к которым проведены ассоциации. Соединяет ли кооперацию с классом (ну, или интерфейсом) ассоциация? Гм. По мне, сомнительно это. Из-за того, что экземпляр класса поучаствовал во взаимодействии, описанном при помощи кооперации, проводить ассоциацию? Ну уж нет.
Как бы там ни было, стандарт не разрешает рисовать подобные картинки:
Далее...
Если используется кооперация, т. е. создаётся CollaborationUse, то с экземплярами, подставляемыми на роли, она по стандарту соединяется зависимостями. Важное слово тут -- экземпляры. Стандарт не позволяет подставлять классы на роли.
Моделирование паттернов проектирования как параметризованных коопераций в связи со сказанным сопряжено такими моментами:
1) Параметрами (а не ролями!) кооперации, моделирующей паттерн, должны быть участники (participants) паттерна. У Observer это Subject, Observer и ConcreteObserver.
2) Роли в кооперации задают имена, с которыми экземпляры участников паттерна будут фигурировать на диаграммах взаимодействия.
3) Использование паттерна (т. е. увязка классов друг с другом по его рецепту) -- это конкретизация параметризованной кооперации. По параметризованной кооперации, моделирующей паттерн, создаётся другая кооперация -- её конкретизация. Они соединяются зависимостью связывания, в которой прописываются bind-инги. То есть использование паттерна -- это не использование кооперации, которая его моделирует.
Текущий стандарт UML (который возможно отличается от стандарта из 2010 года) говорит, что кооперация -- это пачка взаимодействующих экземпляров. Если рисуется диаграмма составной структуры, показывающая "кишки" кооперации вроде:
, то роли там можно соединять только коннекторами (но не ассоциациями/агрегациями/композициями, не обобщениями, не реализациями). Так что некоторые картинки, нарисованные по ссылке, которая протухла, невозможны по текущему стандарту. Надо сказать, что и диаграмма с www.uml-diagrams.org, которую я использую, тоже нарушает стандарт. Т. к. внутренности ролей на ней не ролевые, как положено по стандарту, а интерфейсные как по стандарту не положено. Стандартные внутренности ролей -- это вложенные в роли части (parts) и/или свойства (properties). Так что по стандарту кооперация Observer должна рисоваться иначе (тут другая одноимённая кооперация, но смысл тот, что ни атрибутов, ни операций у ролей не должно быть):
Между тем, в стандарте делается некоторый финт. Говорится, что якобы есть альтернативная нотация:
"Альтернативная нотация" соединяет классы (ну, или интерфейсы) и кооперацию какими-то связями. Что это за связи, стандарт не может объяснить. Попытки проводить аналогии с классами, у которых можно по диаграмме составной структуры нарисовать диаграмму классов, где кишки (parts) класса вынуты наружу и нарисованы как классы, к которым проведены ассоциации. Соединяет ли кооперацию с классом (ну, или интерфейсом) ассоциация? Гм. По мне, сомнительно это. Из-за того, что экземпляр класса поучаствовал во взаимодействии, описанном при помощи кооперации, проводить ассоциацию? Ну уж нет.
Как бы там ни было, стандарт не разрешает рисовать подобные картинки:
Далее...
Если используется кооперация, т. е. создаётся CollaborationUse, то с экземплярами, подставляемыми на роли, она по стандарту соединяется зависимостями. Важное слово тут -- экземпляры. Стандарт не позволяет подставлять классы на роли.
Моделирование паттернов проектирования как параметризованных коопераций в связи со сказанным сопряжено такими моментами:
1) Параметрами (а не ролями!) кооперации, моделирующей паттерн, должны быть участники (participants) паттерна. У Observer это Subject, Observer и ConcreteObserver.
2) Роли в кооперации задают имена, с которыми экземпляры участников паттерна будут фигурировать на диаграммах взаимодействия.
3) Использование паттерна (т. е. увязка классов друг с другом по его рецепту) -- это конкретизация параметризованной кооперации. По параметризованной кооперации, моделирующей паттерн, создаётся другая кооперация -- её конкретизация. Они соединяются зависимостью связывания, в которой прописываются bind-инги. То есть использование паттерна -- это не использование кооперации, которая его моделирует.
141
UML SysML и пр. / Re: Почему объектная диаграмма больше не поддерживается стандартом UML
« : 09 Октября 2019, 10:46:28 »
Не знаю и не берусь предсказать. Если будет технология и инструменты, соответствующие этим (пока чрезмерным, на мой взгляд) выразительным возможностям UML 2.5.1, то прогресс пойдёт.
142
UML SysML и пр. / Re: Почему объектная диаграмма больше не поддерживается стандартом UML
« : 06 Октября 2019, 14:40:07 »
Написанное мною, не соответствует стандарту UML 1.4. В первом UML описание стандарта языка строилось вокруг диаграмм, т. е. вокруг ранее независимых нотаций, брошенных в плавильный котёл UML. Поэтому в стандарте UML 1.4 есть определение диаграммы объектов. С переходом ко второй версии точка зрения авторов стандарта сместилась. Софтина, работающая с UML-моделью -- трансформатор, кодогенератор, анализатор -- не интересуется диаграммами, видит общую кучу элементов модели и связей между ними, вычленяя то, что её интересует по типам элементов и связей, а не по факту принадлежности элементов одной и той же диаграмме или разным. В подобном виде переписан стандарт UML. В стандарте UML 2.4.1 нет определения не только для диаграммы объектов, но и для диаграммы классов. Также в стандарте UML 2.4.1 приводится иллюстрация, являющаяся смешением диаграммы деятельности с диаграммой классов. Видимо, авторов стандарта увлекала идея сплавления подъязыков UML в единое целое. В последней версии стандарта постулируется зыбкость границ между разными типами диаграмм (контрастирующая с привычным ходом составления самих диаграмм в какой-либо UML-среде).
143
UML SysML и пр. / Re: Почему объектная диаграмма больше не поддерживается стандартом UML
« : 05 Октября 2019, 23:45:46 »
Мне представляется, что когда-то местом для описания диаграмм сделали UML Reference Manual и т. п. руководства. Стандарт не так уж много внимания уделял диаграммам в прошлом. В этом плане последняя версия в приложениях сравнительно много говорит о диаграммах. Появился кусок метамодели UML, посвящённый диаграммам. На UmlObjectDiagram даже одно ограничение навесили.
144
Системный Анализ и Требования / Re: Давайте поговорим про Use Case и функции. В чем отличия?
« : 05 Октября 2019, 02:20:58 »Цитировать
Use cases are no longer required to express some needs of actors...Тут стандарт всего лишь соглашается с Коберном и проч., считающими, что помимо ВИ уровня моря, могут быть ВИ других уровней.
Цитировать
Use cases are no longer required to... be initiated by an actor.Чтение перечня багов стандарта UML почему-то навело меня на мысль о том, что тут могут иметься в виду расширяющие или включённые ВИ.
145
Системный Анализ и Требования / Re: Давайте поговорим про Use Case и функции. В чем отличия?
« : 28 Сентября 2019, 22:03:09 »Во многих источниках информации указано, что use case - это некая цель, которую желает достич пользователь с помощью системы.
Цитата: Kirill Fakhroutdinov
Use cases are no longer required to express some needs of actors and to be initiated by an actor.Написанное относится к UML, начиная с версии 2.5.
146
Обучение / Re: Analyst Days EU. Первая европейская конференция по системному и бизнес-анализу
« : 12 Сентября 2019, 23:38:14 »
Интересный сайт. Даты указаны в ноябре 2018. И крупными буквами: "событие отменено".
Наверное, так и надо.
Наверное, так и надо.
147
Теория моделирования и нотации / Re: Теория и принципы моделирования
« : 06 Августа 2019, 13:03:55 »
Вроде того (с поправкой, что речь идёт о текстовых описаниях, которые могут предшествовать UML-диаграммам и/или дополнять их).
Есть статья 2002 года, не мейнстрим, но есть.
Есть статья 2002 года, не мейнстрим, но есть.
148
Теория моделирования и нотации / Re: Теория и принципы моделирования
« : 06 Августа 2019, 00:01:47 »
Всё верно, если пишется ВИ ЧЯ+УМ. Т. к. такие ВИ пишутся часто, то есть повод не рассматривать другие ВИ.
149
Теория моделирования и нотации / Re: Теория и принципы моделирования
« : 05 Августа 2019, 19:33:07 »
В книге Коберна (впервые я о нём услышало через ксенолингвист как о Кобурне) есть и о недопустимости, есть и о полезности расширения описаний сведениями о GUI (см. 17.4). Заметим себе, что Коберн пишет о ВИ, как о способе описания функциональных требований. Отсюда, мне кажется, не следует делать вывод, что применение ВИ исчерпывается этим. Коберн увязывает наличие/отсутствие описания "кнопок" с уровнем цели ВИ. При разборе ошибок (см. 19), сведения о GUI вытираются из описаний ВИ с областью действия "система как ЧЯ" и целью "уровня моря". Можно конечно, ограничиться рассмотрением и написанием только таких ВИ, если стоит такая цель.
Про Джекобсона написало в личку.
Про Джекобсона написало в личку.
150
Обучение / Re: Учебный академический курс "Инженерия требований"
« : 03 Августа 2019, 01:19:58 »
В Curricula SE2014 на "требования" заложено 30 часов. Перечень тем дан на стр. 31. В аппендиксе, начинающемся со стр. 70 даны примеры конкретных учебных планов. Так в универе Миссисипи "требования" дают в осеннем семестре 3 курса в рамках дисциплины "Введение в программную инженерию", а также в рамках прака по программной инженерии на 4м году бакалавриата. В Rose-‐Hulman тоже осенью 3 курса дают дисциплину, название которой совпадает с темой обсуждения. На стр. 86 даны подробные сведения о Rose-‐Hulman'овском курсе. В частности, указана веб-страничка со всеми материалами.