Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Из-за межгалатических расстояний до меня лишь недавно дошло, что прибегание человека, ищущего помощь в UML-моделировании сказки, -- следствие "пользы". Кто-то репостнул с пометкой, мол, в обучении хорошо использовать, кто-то прочёл и стал использовать: выдавать студентам для самостоятельного решения задания про uml-журавля с uml-лисицей.Умеют у нас сказку сделать былью
Некротединга псто
==============
Сайт umljokes помер. Диаграммы разошлись на незакавыченные цитаты в блоги.
Можно подметить особенность нынешнего стандарта UML: на диаграмме свойство Generalization Set, названное в метамодели UML isCovering, отображается как {complete}/{incomplete}. Зачем-то введена синонимия причём раздельная: для абстрактного синтаксиса один термин, для конкретного синтаксиса -- другой. А то бы всё было слишком просто, такова логика авторов стандарта?
Интересно, но даже плюсик поставить негде. Совсем форум по швам расползается:(
Написанное мною, не соответствует стандарту UML 1.4. В первом UML описание стандарта языка строилось вокруг диаграмм, т. е. вокруг ранее независимых нотаций, брошенных в плавильный котёл UML. Поэтому в стандарте UML 1.4 есть определение диаграммы объектов. С переходом ко второй версии точка зрения авторов стандарта сместилась. Софтина, работающая с UML-моделью -- трансформатор, кодогенератор, анализатор -- не интересуется диаграммами, видит общую кучу элементов модели и связей между ними, вычленяя то, что её интересует по типам элементов и связей, а не по факту принадлежности элементов одной и той же диаграмме или разным. В подобном виде переписан стандарт UML. В стандарте UML 2.4.1 нет определения не только для диаграммы объектов, но и для диаграммы классов. Также в стандарте UML 2.4.1 приводится иллюстрация, являющаяся смешением диаграммы деятельности с диаграммой классов. Видимо, авторов стандарта увлекала идея сплавления подъязыков UML в единое целое. В последней версии стандарта постулируется зыбкость границ между разными типами диаграмм (контрастирующая с привычным ходом составления самих диаграмм в какой-либо UML-среде).А куда это может нас привести, как Вы полагаете? Сплавление одни диаграмм в целом кажется разумным, но других выглядит почти безумием. Но возможно гениальным
Мне представляется, что когда-то местом для описания диаграмм сделали UML Reference Manual и т. п. руководства. Стандарт не так уж много внимания уделял диаграммам в прошлом. В этом плане последняя версия в приложениях сравнительно много говорит о диаграммах. Появился кусок метамодели UML, посвящённый диаграммам. На UmlObjectDiagram даже одно ограничение навесили.Ага, вот оно в чем дело. Спасибо.
Написанное относится к UML, начиная с версии 2.5.А для чего и как его теперь используют?
Интересный сайт. Даты указаны в ноябре 2018. И крупными буквами: "событие отменено".Да, как-то весьма странно.
Наверное, так и надо.
Всё верно, если пишется ВИ ЧЯ+УМ. Т. к. такие ВИ пишутся часто, то есть повод не рассматривать другие ВИ.Насчет описания белого ящика - это уже в терминах конкретной реализации, когда используется шаблон BCE - boundary control entity.
В книге Коберна (впервые я о нём услышало через ксенолингвист как о Кобурне) есть и о недопустимости, есть и о полезности расширения описаний сведениями о GUI (см. 17.4). Заметим себе, что Коберн пишет о ВИ, как о способе описания функциональных требований. Отсюда, мне кажется, не следует делать вывод, что применение ВИ исчерпывается этим. Коберн увязывает наличие/отсутствие описания "кнопок" с уровнем цели ВИ. При разборе ошибок (см. 19), сведения о GUI вытираются из описаний ВИ с областью действия "система как ЧЯ" и целью "уровня моря". Можно конечно, ограничиться рассмотрением и написанием только таких ВИ, если стоит такая цель.
Те варианты использования, который писал Айвар Якобсон, когда их изобретал, были "с кнопками", к слову сказать.Кстати, да. Позже я тоже об этом узнал где-то. Кстати, нет ли у вас в ксеноархивах, образчиков авторского стиля?
В Curricula SE2014 на "требования" заложено 30 часов. Перечень тем дан на стр. 31. В аппендиксе, начинающемся со стр. 70 даны примеры конкретных учебных планов. Так в универе Миссисипи "требования" дают в осеннем семестре 3 курса в рамках дисциплины "Введение в программную инженерию", а также в рамках прака по программной инженерии на 4м году бакалавриата. В Rose-‐Hulman тоже осенью 3 курса дают дисциплину, название которой совпадает с темой обсуждения. На стр. 86 даны подробные сведения о Rose-‐Hulman'овском курсе. В частности, указана веб-страничка со всеми материалами.
к сожалению, бакалавриату без опыта работы такой курс "читать" практически бесполезно
а так есть хороший образец по формулированию требований от INCOSE
https://www.coursera.org/learn/requirements-writing
