Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Если я вас правильно понял, то однонаправленная ассоциация это как-бы абстрактное понятие, которое используется на начальном этапе проектирования и впоследствии в коде уже принимает вид либо агрегации, либо композиции. Верно я уловил смысл?Не совсем. Я не говорил об однонаправленности. Одно или дву направленность - это другой момент. Кстати тоже относящийся к реализации.
Что касается дальнейшей спецификации - я уже говорил, что не использовал ДВИ для этой цели.Спасибо, Гриша. Никак не мог понять, почему ты говоришь о ДВИ при специфицировании ВИ. Я понимаю, что на диаграмме 4 яйца сворачиваются в 1. Я интересуюсь, как в этом случае формируется текстовая (другой я все равно не знаю) спецификация
Мне нравится, из этих диаграмм уже хорошо видны различия ролей и цели пользователей.Спасибо. А как правильно все-таки формулируются CRUD ВИ и далее специфицируются?
Замечаний (не очень существенных) два:
1) использовать CRUD, о котором здесь уже говорили, чтобы визуально разгрузить диаграммы
2) вместо "запросить отчёт" использовать "получить отчёт"
1.Выйти/войти - вообще не ВИ.Согласен, я тоже сказал, что это не может быть ВИ. Но в таком случае где следует описать процедуру входа в систему, возможность забыть пароль и потребовать его восстановления?
2. У родителя/ученика - посмотреть примечания два раза. И если бы я был проектировщиком системы, я бы дал им разные ВИ и разные наборы доступов, а не одинаковые, но это к самой диаграмме не относится.Я думаю это просто ошибка
3. Что за особая сиреневая связь между учителем и "просмотреть расписание"?Просто выделенная связь - дефект копирования
4. Создание примечаний у учителя - надо по другому назвать. Не ясно что делает ВИ.Там Записать примечание, а что не понятно, кому примечание пишется?
Прошу передать меня инквизиции если я пишу ересь:) Пока что я уверен в своей позиции:)На костер его, богохульника!
Точно так же как Activity на диаграмме и её подробное описание. Это то же самое, только в разных представлениях.По стандарту (если я не заблуждаюсь) все это можно считать разным способ реализации варианта использования
Это вы спрашивали?
При этом еще у каждого подпотока ведь могут быть какие-то свои альтернативы, нехарактерные для других. Просто у меня у самого мало настоящего практического (живого) опыта. Только академический. Хотя студенты играют по-взрослому, но все равно есть искусственность.Вопрос звучит так: Может быть кто-нибудь сталкивался с подобной проблемой - невозможностью настройки огибания одной из пересекающихся связей на диаграмме?Мне кажется это вопрос к разработке. Напишите, пожалуйста, английскую версию вопроса. Я отправлю поддержкеПричем, не огибаются общие связи (тип common). Гуглил, искал на форуме сообщества sparx, но ничего похожего не нашел...
Ну, если бы надо было описать такое ВИ в спецификации, это выглядело бы примерно так:Красиво, спасибо. Но, видимо, мне не удается донести свою мысль.
Смотря что подразумевать под "технически"
Помимо описания основных и альтернативных потоков ВИ, я бы еще добавил прототип интерфейса работы с ВИ. Т.к. ценю наглядность, а прототип как раз и указывает на очевидно необходимый функционал.
- для выявления и описания целей пользователей по отношению к разрабатываемой системе;
- для визуализации ролей пользователей и различий между ними.
Лично я, компоновал бы CRUD действия в один ВИ по типу "управление пользователями", "управление расписанием" - если эти ВИ доступны/ не доступны всем акторам одинаково.Ага, спасибо.
Если же, например, кому-то доступно выставление оценок, а кому-то только просмотр, то разделял бы в разные ВИ
