Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - [прилетело НЛО и...]

Страницы: « 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 »
106
Про стандарт, хоть тема про EA. В VP та же ботва (из-за стандарта).(

107
Можно подметить особенность нынешнего стандарта UML: на диаграмме свойство Generalization Set, названное в метамодели UML isCovering, отображается как {complete}/{incomplete}. Зачем-то введена синонимия причём раздельная: для абстрактного синтаксиса один термин, для конкретного синтаксиса -- другой. А то бы всё было слишком просто, такова логика авторов стандарта?

108
Sparx / Re: Кооперация
« : 09 Декабря 2019, 10:58:41 »
Хотя нет, нашел!
Спасибо, Galogen!

109
Sparx / Re: Кооперация
« : 04 Декабря 2019, 02:33:44 »
Можно решить, что кооперация -- плохой способ моделировать паттерн [весь]. Что же делать? Можно вспомнить что в UMLе есть штуковина, внутри которой классы чувствуют себя вполне нормально, внутри которой можно рисовать и ассоциации, и обобщения, и реализации, и зависимости. Это пакет:

И есть в UMLе изобретение авторов языка Ада (того самого) -- параметризованный пакет:

Только вот зависимость связывания, согласно последним веяниям, должна рисоваться как зависимость, не как реализация.
Итак, паттерн можно моделировать  пакетом. Участники паттерна и связи между ними становятся элементами пакета. Структура описывается диаграммой, вроде той, что выше. Для описания поведения в состав пакета можно включить кооперацию и внутри неё смоделировать взаимодействие экземпляров участников. Использование паттерна описывается как конкретизация пакета [см. на диаграмме выше].
P. S. У предложенного способа есть недостаток. Связи между классами, соединёнными по рецепту паттерна оказываются отдельно от этих классов. Они лежат в пакете -- конкретизации параметризованного пакета. Где лежат сами эти классы [мне] неясно.

110
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-инги. То есть использование паттерна -- это не использование кооперации, которая его моделирует.

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

112
Написанное мною, не соответствует стандарту UML 1.4. В первом UML описание стандарта языка строилось вокруг диаграмм, т. е. вокруг ранее независимых нотаций, брошенных в плавильный котёл UML. Поэтому в стандарте UML 1.4 есть определение диаграммы объектов. С переходом ко второй версии точка зрения авторов стандарта сместилась. Софтина, работающая с UML-моделью -- трансформатор, кодогенератор, анализатор -- не интересуется диаграммами, видит общую кучу элементов модели и связей между ними, вычленяя то, что её интересует по типам элементов и связей, а не по факту принадлежности элементов одной и той же диаграмме или разным. В подобном виде переписан стандарт UML. В стандарте UML 2.4.1 нет определения не только для диаграммы объектов, но и для диаграммы классов. Также в стандарте UML 2.4.1  приводится иллюстрация, являющаяся смешением диаграммы деятельности с диаграммой классов. Видимо, авторов стандарта увлекала идея сплавления подъязыков UML в единое целое. В последней версии стандарта постулируется зыбкость границ между разными типами диаграмм (контрастирующая с привычным ходом составления самих диаграмм в какой-либо UML-среде).

113
Мне представляется, что когда-то местом для описания диаграмм сделали UML Reference Manual и т. п. руководства. Стандарт не так уж много внимания уделял диаграммам в прошлом. В этом плане последняя версия в приложениях сравнительно много говорит о диаграммах. Появился кусок метамодели UML, посвящённый диаграммам. На UmlObjectDiagram даже одно ограничение навесили.

114
Цитировать
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 почему-то навело меня на мысль о том, что тут могут иметься в виду расширяющие или включённые ВИ.

115
Во многих источниках информации указано, что 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.

116
Интересный сайт. Даты указаны в ноябре 2018. И крупными буквами: "событие отменено".
Наверное, так и надо.

117
Вроде того (с поправкой, что речь идёт о текстовых описаниях, которые могут предшествовать UML-диаграммам и/или дополнять их).
Есть статья 2002 года, не мейнстрим, но есть.

118
Всё верно, если пишется ВИ ЧЯ+УМ. Т. к. такие ВИ пишутся часто, то есть повод не рассматривать другие ВИ.

119
В книге Коберна (впервые я о нём услышало через ксенолингвист как о Кобурне) есть и о недопустимости, есть и о полезности расширения описаний сведениями о GUI (см. 17.4). Заметим себе, что Коберн пишет о ВИ, как о способе описания функциональных требований. Отсюда, мне кажется, не следует делать вывод, что применение ВИ исчерпывается этим. Коберн увязывает наличие/отсутствие описания "кнопок" с уровнем цели ВИ. При разборе ошибок (см. 19), сведения о GUI вытираются из описаний ВИ с областью действия "система как ЧЯ" и целью "уровня моря". Можно конечно, ограничиться рассмотрением и написанием только таких ВИ, если стоит такая цель.
Про Джекобсона написало в личку.


 

120
В Curricula SE2014 на "требования" заложено 30 часов. Перечень тем дан на стр. 31. В аппендиксе, начинающемся со стр. 70 даны примеры конкретных учебных планов. Так в универе Миссисипи "требования" дают в осеннем семестре 3 курса в рамках дисциплины "Введение в программную инженерию", а также в рамках прака по программной инженерии на 4м году бакалавриата. В Rose-­‐Hulman тоже осенью 3 курса дают дисциплину, название которой совпадает с темой обсуждения. На стр. 86 даны подробные сведения о Rose-­‐Hulman'овском курсе. В частности, указана веб-страничка со всеми материалами.
 

Страницы: « 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 »