646

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 09 Октября 2014, 10:43:17 »

Коллеги,

если Вам интересно осуществлять экспертизу студенческих ошибок, то предлагаю поупражняться вот на этом тексте. Буду признателен за ваши ценные комментарии и конструктивные предложения.

Имя: Добавить нового пользователя
ID: 1
Краткое описание: ВИ описывает создание нового пользователя
Действующие лица: Администратор
Предусловие:
1.Администратор авторизован в системе.
2.У администратора должны быть данные о новом пользователя для создания учетной записи.

Постусловие: Пользователь зарегистрирован в системе “Электронная школа”
1.0 Основной поток:
   1.Администратор делает запрос на регистрацию нового пользователя.
   2.Система предоставляет возможность для выбора роли пользователя
   3.Администратор выбирает роль пользователя
   4.Система предоставляет форму для заполнения личных данных о пользователе в зависимости от роли
   5.Администратор заполняет предоставленную системой форму и сохраняет
   6.Система сохраняет пользователя в базе данных
   7.Система выводит сообщение об успешном сохранении данных
   8.Система предлагает администратору добавить нового пользователя

Альтернативные потоки:
1.1Данный пользователь уже существует в системе (ответвление шага 5)
   1.Система выдает сообщение, о том, что данный пользователь уже зарегистрирован в системе.
   2.Возврат к пункту 2 основного потока.

1.2Не все обязательные поля заполнены (ответвление шага 5)
   1.Система выдает сообщение, о том, что пропущено поле для заполнения
   2.Возврат к пункту 4 основного потока.

Ограничения:
1.Пароль должен состоять из набора латинских букв и цифр,  должен быть не менее 6 символов символов.
2.Логин должен содержать не меньше 6 цифр.
3.ФИО должен состоять из русских букв, начиная с заглавной буквы.
4.При заполнении поля “Класс” выбирается число от 1 до 11 включительно и без пробела ставится буква русского алфавита: А, Б, В ,Г ,Д.
5.Адрес должен состоять из букв русского алфавита и цифр и не должен превышать 50 символов.
6.Дата рождения ставится в соответствии с предложенным календарем.
7.Email представляет собой стандартную форму электронного почтового ящика.
8.Администратор может выбрать только одну из ролей, либо ученик, либо учитель.
9.Мобильный телефон должен состоять из 11 цифр, начиная с 8

647

Обучение / Re: Инструментальные средства информационных систем

« : 06 Октября 2014, 20:36:53 »

Читает предмет другой преподаватель. Мне был интересен возможный состав курса.
На самом деле, то что Вы предложили, это то, что было в голове, просто выразил несколько иначе.

648

Реализация / Re: Реализация отношений между классами

« : 05 Октября 2014, 21:37:49 »

Если я вас правильно понял, то однонаправленная ассоциация это как-бы абстрактное понятие, которое используется на начальном этапе проектирования и впоследствии в коде уже принимает вид либо агрегации, либо композиции. Верно я уловил смысл?

Не совсем. Я не говорил об однонаправленности. Одно или дву направленность - это другой момент. Кстати тоже относящийся к реализации.
Ассоциация - это абстракция связи. Ассоциация отражает отношение между двумя и более классами. Агрегация и композиция - частный случай ассоциации, определяющий более точный смысл такой связи.
Просто прямое воплощение ассоциации по смыслу (но не всегда) сводится к агрегации или композиции.

649

Реализация / Re: Реализация отношений между классами

« : 05 Октября 2014, 13:49:43 »

Разница как раз в реализации.

Ассоциация - это семантическая концепция, а агрегация или композиция - реализация связи в коде. Ассоциация в общем смысле связь типа has a, т.е. связь принадлежности. В зависимости от силы связи принадлежности - она сводится или к агрегации (share) или композиции.

С другой стороны можно привести и ассоциации типа многие-ко-многим, которые не могут быть сведены к агрегации или композиции.

650

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 02 Октября 2014, 20:49:37 »

Что касается дальнейшей спецификации - я уже говорил, что не использовал ДВИ для этой цели.

Спасибо, Гриша. Никак не мог понять, почему ты говоришь о ДВИ при специфицировании ВИ. Я понимаю, что на диаграмме 4 яйца сворачиваются в 1. Я интересуюсь, как в этом случае формируется текстовая (другой я все равно не знаю) спецификация

651

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 02 Октября 2014, 18:20:20 »

Мне нравится, из этих диаграмм уже хорошо видны различия ролей и цели пользователей.

Замечаний (не очень существенных) два:
1) использовать CRUD, о котором здесь уже говорили, чтобы визуально разгрузить диаграммы
2) вместо "запросить отчёт" использовать "получить отчёт"

Спасибо. А как правильно все-таки формулируются CRUD ВИ и далее специфицируются?

652

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 02 Октября 2014, 18:18:56 »

1.Выйти/войти - вообще не ВИ.

Согласен, я тоже сказал, что это не может быть ВИ. Но в таком случае где следует описать процедуру входа в систему, возможность забыть пароль и потребовать его восстановления?

2. У родителя/ученика - посмотреть примечания два раза. И если бы я был проектировщиком системы, я бы дал им разные ВИ и разные наборы доступов, а  не одинаковые, но это к самой диаграмме не относится.

Я думаю это просто ошибка

3. Что за особая сиреневая связь между учителем и "просмотреть расписание"?

Просто выделенная связь - дефект копирования

4. Создание примечаний у учителя - надо по другому назвать. Не ясно что делает ВИ.

Там Записать примечание, а что не понятно, кому примечание пишется?

653

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 02 Октября 2014, 13:35:40 »

Вот студенты выполнили работу над ошибками и сформировали немного иное представление. 
Буду рад замечаниям и предложениям.

654

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 01 Октября 2014, 13:30:12 »

Прошу передать меня инквизиции если я пишу ересь:) Пока что я уверен в своей позиции:)

На костер его, богохульника!

Точно так же как Activity на диаграмме и её подробное описание. Это то же самое, только в разных представлениях.

По стандарту (если я не заблуждаюсь) все это можно считать разным способ реализации варианта использования

Кстати, если кому-то интересны рекомендации RUP по этому вопросы, то сюда

655

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 30 Сентября 2014, 21:15:57 »

Это вы спрашивали?

Ага При этом еще у каждого подпотока ведь могут быть какие-то свои альтернативы, нехарактерные для других. Просто у меня у самого мало настоящего практического (живого) опыта. Только академический. Хотя студенты играют по-взрослому, но все равно есть искусственность.

656

Sparx / Re: Удобное отображение пересечения связей на диаграммах в среде Sparx EA

« : 30 Сентября 2014, 21:08:49 »

Вопрос звучит так: Может быть кто-нибудь сталкивался с подобной проблемой - невозможностью настройки огибания одной из пересекающихся связей на диаграмме? Причем, не огибаются общие связи (тип common). Гуглил, искал на форуме сообщества sparx, но ничего похожего не нашел...

Мне кажется это вопрос к разработке. Напишите, пожалуйста, английскую версию вопроса. Я отправлю поддержке

657

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 30 Сентября 2014, 17:57:40 »

Ну,  если бы надо было описать такое ВИ в спецификации,  это выглядело бы примерно так:

Красиво, спасибо. Но, видимо, мне не удается донести свою мысль.

Каждый ВИ обладает определенной целостностью и имеет общие предусловия и постусловия.
Скажем, ясно что изменение расписания невозможно, пока не будет создано само это расписание. Как это все увязывается в единой спецификации варианта использования?

658

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 30 Сентября 2014, 16:48:54 »

Кстати, скетчи интерфейсов при иллюстрации сценариев взаимодействия, мы тоже активно практикуем.

659

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 30 Сентября 2014, 16:47:46 »

Смотря что подразумевать под "технически"
Помимо описания основных и альтернативных потоков ВИ, я бы еще добавил прототип интерфейса работы с ВИ. Т.к. ценю наглядность, а прототип как раз и указывает на очевидно необходимый функционал.

Спасибо. Под технически я имел в виду, как формируется спецификация при этом. Ведь по сути нет такого ВИ как Управление расписанием: скорее есть набор действий, имеющий  некоторые общие черты: создать расписание, изменить расписание, скопировать расписание. Как на Ваш практический взгляд это выглядит?

660

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 30 Сентября 2014, 14:17:10 »

- для выявления и описания целей пользователей по отношению к разрабатываемой системе;
- для визуализации ролей пользователей и различий между ними.

Логично, и как это будет потом синхронизироваться с окончательными вариантами вариантов использования?

От себя добавлю:
- как иллюстрированное содержание
- как инструмент планирования работы