В теме 16 ответов, и 5 участников, последнее обновление сделано пользователем 
skan201 12 г, 11 мес. назад.
-
Сообщения
-
Помогите разобраться.
Объясню проблему на пальцах.
Мы — разработчики программного продукта — инструмента прототипирования программных интерфейсов. В двух словах, инструмент позволяет собирать экраны пользовательского интерфейса программ, сайтов, веб-приложений из виджетов (окна, панели, кнопки, поля, списки, таблицы и т.д.) и объединять их в единый прототип посредством связи типа «событие-действие». Теперь мы решили пойти дальше и превратить программу в инструмент проектирования, внедрив в программу возможность моделирования на языке UML. Однако, добавить тул, позволяющий просто рисовать UML-диаграммы без привязки к прототипу, отстранённо от прототипа — это неполноценное решение. Требуется, чтобы была однозначная, прозрачная, логически выстроенная связь экранов интерфейса с UML-диаграммами.В связи с возникшей задачей, появились вопросы:
1. имеет ли место в UML сущность «Интерфейс пользователя» или «Экранная форма» (либо что-то подобное: GUI, графическое представление и т.п.)?
2. Если да, то в каких диаграммах корректно её использование?
3. С какими сущностями и каким типом отношений они связываются?Крайне полезно было бы увидеть конкретные примеры.
Также, если вам известны инструменты, позволяющие проводить моделирование на UML и отрисовывать экранные формы — сориентируйте, пожалуйста.Надеюсь на вашу помощь!
Лично мне неизвестно классическое применение экранных форм в UML-моделировании, как неизвестна и подобная сущность в самой нотации.
Но: можно и отойти от классики, то бишь:
1) Использовать элемент "Класс" или "Объект", которые являются универсальными в подобного рода вещах, со стереотипами.
2) Так как нотация об этом нам ничего не говорит, то и вариантов здесь масса. На мой взгляд имеет смысл применение экранных форм практически во всех UML-диаграммах (кроме развертывания): диаграммы вариантов использования (ассоциация юз кейсов с затрагиваемыми скринами), последовательностей (сообщения между lifelines, затрагивающие UI, ассоциировать со скринами), activity (то же самое, что и последовательностей), классов (ассоциация сущностей доменной модели с соответствующими скринами по их управлению), состояний (переходы состояний -> какой UI их вызывает) и т.д.
3) Сущности — зависит от диаграммы применения (читай, практически все). Связи — чтобы оставаться UML-compliant, вариант имхо только dependency со своими стереотипами.У меня иногда возникало желание и была необходимость провести подобного рода моделирование — оно очень наглядно, пусть и выходит за рамки классики UML. Поэтому идеяочень хорошая (только вот к ней вдовесок нужен мощный и удобный UML-редактор, что не так-то имхо и просто сделать).
Навскидку я тоже не встречалась с применением экранных форм в UML — моделировании как полноценными участниками диаграмм. Что приходит в голову: полезным инструментом была бы tracebility matrix, показывающая, к примеру, на какой форме реализуется каждый из юз-кейсов.
Sparx Enterprise Architect, на мой взгляд, самый удобный инструмент для построения UML-диаграмм, хоть и не идеальный. В нем можно добавить диаграмму типа Extended — > User Interface, создать экран интерфейса и при желаний залинковать на любые другие элементы из остальных диаграмм. Но лично я никогда эту возможность не использую, т.к., с одной стороны, в Enterprise Architect очень ограниченные возможности по созданию интерфейсов, с другой стороны, получается ненаглядно.И еще одна мысль: было бы здорово, если можно было бы генерировать динамический прототип на основе макетов пользовательского интерфейса и диаграммы активности. Т.е. пользователь при построении и описании диаграммы задавал бы события, по которым происходит смена экрана, а потом на основании этого получался бы прототип.Да, только стоит помнить о применимости такого подхода… Наиболее часто activity diagrams применяются дл визуализации сценариев юз кейсов, которые как мы знаем желательно отвязывать от деталей интерфейса
Лично мне неизвестно классическое применение экранных форм в UML-моделировании, как неизвестна и подобная сущность в самой нотации.
Но: можно и отойти от классики, то бишь:
1) Использовать элемент "Класс" или "Объект", которые являются универсальными в подобного рода вещах, со стереотипами.
У меня иногда возникало желание и была необходимость провести подобного рода моделирование — оно очень наглядно, пусть и выходит за рамки классики UML. Поэтому идеяочень хорошая (только вот к ней вдовесок нужен мощный и удобный UML-редактор, что не так-то имхо и просто сделать).Спасибо за наводку, думаю действительно самым простым и понятным вариантом будет представление экранных форм в виде объектов со стериотипом <<user interface>> — <<интерфейс пользователя>> и использование их в большинстве диаграмм на равных правах с другими объектами (классами).
Кстати, о UML-редакторе. Нам не хотелось бы перегружать UML-редактор обилием параметров и свойств сущностей. Хотелось бы объять самое важное, часто используемое, применяемое, отбросив редко-используемые "фичи" и сделав UML-редактор достаточно простым.
В связи с этим ещё 1 просьба:
не могли бы Вы описать функциональность образцового для Вас UML-редактора. Что должно быть обязательно? Что можно отбросить? Какой из существующих UML-редакторов (сред моделирования UML) кажется Вам наиболее удачным?Что приходит в голову: полезным инструментом была бы [b]tracebility matrix[/b], показывающая, к примеру, на какой форме реализуется каждый из юз-кейсов.
Интересная идея!
Однако, всё же, думаю, что это менее наглядно, чем использование в UML-диаграммах объектов (классов) со стереотипом <<user interface>>. Наверное, traceability matrix отлично подойдёт в качестве дополнения к use-case диаграмме. Она позволит представить связь юз-кейсов с экранами интерфейса в более компактной и структурированной форме. К тому же, можно реализовать автоматическое постороение traceability matrix на основе диаграммы use-case, и, наоборот, построение диаграммы use-case на основе traceability matrix.
Взяли себе на заметку, спасибо!
И еще одна мысль: было бы здорово, если можно было бы генерировать динамический прототип на основе макетов пользовательского интерфейса и диаграммы активности. Т.е. пользователь при построении и описании диаграммы задавал бы события, по которым происходит смена экрана, а потом на основании этого получался бы прототип.
Думаю, что это возможно реализовать. Только при построении диаграммы активности при задании событий нужно будет явно указывать конкретный элемент интерфейса, слушающий событие — объект события, и элемент интерфейса, выполняющий действие при свершении события — объект действия. Главное — чтобы процесс построения диаграммы активности не становился намного более долгим, трудоёмким и менее приятным из-за необходимости выполнения этих действий.
Благодарю за предложение, думаю — оно также претендует стать реальностьюНе могли бы Вы описать функциональность образцового для Вас UML-редактора. Что должно быть обязательно? Что можно отбросить? Какой из существующих UML-редакторов (сред моделирования UML) кажется Вам наиболее удачным?
Добрый день!
Не скажу, что перепробовал много UML-редакторов, но меня лично полностью устраивает в этом плане Sparx EA. Что еще пробовал: Case Complete, Visio, Rational Rose и ряд других, менее известных (уже и не вспомню).
Полезные вещи, которые на мой взгляд стоит реализовать:
1. Поддержку всех UML-элементов и связей для выбранного вами вида диаграмм, ибо определить, что важнее, а что можно откинуть, мне кажется относительно субъективным.
2. UML-compliance или не давать юзерам выставлять неверные связи.
3. Копирование элементов из имеющихся на диаграмме по зажатому Ctrl (крайне экономит время).
4. Возможность выставлять кастомные стереотипы.
5. Ярлычки на элементах на диаграмме, позволяющие выполнить быстрое действие. В EA появилось вроде бы с версии 7 или 7.5. Очень полезная вещь. Советую тщательно изучить эту функциональность в EA.Что можно отбросить:
1. Детальные свойства элементов. Если ваша задача — предоставить тул для рисования, а не для построения детальных моделей, то все, что вам нужно — это рисовальщик.
2. Привязку к сетке для выравнивания элементов на диаграмме. Не знаю почему, но меня она бесит.
3. Исходя из пункта 1 выше — все, что не нужно для рисовальщика. Исходя из этого же — не нужен, в принципе, и подробный model browser, и traceability matrix. Вернее, все это я предложил бы оставить на следующие релизы.не могли бы Вы описать функциональность образцового для Вас UML-редактора. Что должно быть обязательно? Что можно отбросить? Какой из существующих UML-редакторов (сред моделирования UML) кажется Вам наиболее удачным?
Я использую Sparx Enterprise Architect. Пробовала и другие инструменты, но в конечном итоге всегда возвращалась к нему. Попытаюсь вспомнить наиболее важные на мой взгляд особенности:
1. Необходимое и достаточное количество элементов, доступных в зависимости от выбранной диаграммы
2. Возможность добавлять комментарии к элементам с помощью элемента Note
3. Инструменты по управлению внешним видом элементов (кстати, не самые удобные)
4. Широкий набор типов отношений между элементами и возможность их изменять в процессе
5. Валидация UML моделей
6. Возможность настройки автоматической нумерации элементов
7. Возможность задавать кратность связи между элементами (1..1, *..1 и т.п.)
8. Возможно, мелочь, но: более удобного способа соединения элементов, чем в EA, я не встречала нигде: в каждом элементе при наведении курсора показывается область для соединения с другим элементом. Не надо нажимать никаких дополнительных действий — кликнул и потащил.
9. Traceability matrix: немного громоздкая, но все же очень полезная.
10. Возможность задавать свои стереотипыОсобенности, от которых можно отказаться (на основании личного опыта использования EA):
1. Кодогенерация на основании UML моделей
2. Генерация документации (фича полезная, но реализована не лучшим образом, поэтому не использую)
3. Я бы значительно урезала возможность настройки свойств элементов: процентов 70 не использую.Благодарю за детальный ответ! Несколько вопросов:1. Необходимое и достаточное количество элементов, доступных в зависимости от выбранной диаграммы
4. Широкий набор типов отношений между элементами и возможность их изменять в процессе1. Поддержку всех UML-элементов и связей для выбранного вами вида диаграмм, ибо определить, что важнее, а что можно откинуть, мне кажется относительно субъективным.
Не подскажете, где можно найти полный перечень UML-элементов и связей между ними (желательно с картинками)?
5. Валидация UML моделей
Имеется в виду, проверка UML моделей на соответствие правилам построения UML моделей? Кстати, возможно Вы подскажете, где подробно описаны эти правила (посмотрел спецификацию UML — достаточно объёмный и, на мой взгляд, не самый доступный документ; к тому же, хотелось бы на русском языке)?
3. Я бы значительно урезала возможность настройки свойств элементов: процентов 70 не использую.
Полностью согласен с Вами, не хочется добавлять лишнего. Поэтому, собственно говоря, и исследую, что действительно требуется
Не подскажете, где можно найти полный перечень UML-элементов и связей между ними (желательно с картинками)?
Хороший вопрос.
Идеальный вариант, конечно, спецификация OMG, но, как вы сами сказали, документ нечитабелен.
Мне очень нравится вот этот ресурс: http://www.uml-diagrams.org/uml-24-diagrams.html
Описание там тоже во многом техническое, но UML — такой язык, что по мере углубления в дебри (всякие редкоиспользуемые элементы, связи и концепции) становится сложно объяснять нотацию на пальцах.
Обратите внимание (если будете консолидировать информацию из различных источников), что есть разница в именовании элементов, их поведении и т.д. в зависимости от версии UML. Множество хороших книг, которые считаются признанными учебниками, уже устарели. Поэтому убеждайтесь всегда, что речь идет о UML 2.4. Кстати по ссылке выше именно 2.4 версия и описана.Поэтому убеждайтесь всегда, что речь идет о UML 2.4. Кстати по ссылке выше именно 2.4 версия и описана.
Предлагаете брать за основу UML последней версии 2.4. Beta 2? А ничего страшного, что она бета?
На самом деле, слышал, что UML последних версий критикуют (пример привести не могу: услышал звон, не знаю где он). Правда, неправда?На эти вопросы я вам вряд ли смогу ответить… Про критику ничего не слышал. А насчет беты — думаю, не многое изменится по выходу финальной версии. Тем более, если что и изменится, то это будет на такой глубине, которую вы едва ли даже покроете в инструментарии.В связи с возникшей задачей, появились вопросы:
1. имеет ли место в UML сущность "Интерфейс пользователя" или "Экранная форма" (либо что-то подобное: GUI, графическое представление и т.п.)?
2. Если да, то в каких диаграммах корректно её использование?
3. С какими сущностями и каким типом отношений они связываются?В языке UML имеется стереотип (boundary), с помощью которого моделируются сущности-интерфейсы. При помощи этого стереотипа можно показывать экранные формы в виде объектов на диаграммах Sequence и Collaboration (или Communication в UML-2), а также на диаграмме классов, соответственно тоже в виде класса boundary. На диаграмме классов классы-boundary связываются с другими классами системного анализа, такими как entity и control с помощью ассоциации. Entity, control и boundary — стереотипы для классов и объектов системного анализа.
Если это кого-нибудь заинтересует, то могу представить соответствующие примеры.
Вы должны авторизироваться для ответа в этой теме.
