Да конечно. На диаграммах у тебя есть обобщенная роль - зарегистрированный пользователь, которая в любом случае требует авторизации

Вот я нарисовал ДА для ВИ "Войти в систему". Что-то мне тут не нравится, а что именно - не знаю.

Сразу скажу, что форма авторизации будет примерно как и на этом форуме, т.е. сразу же будет видна. А если пользователь авторизован, то вместо формы авторизации будет выводиться краткая инфа про пользователя.

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

Если же описывается ВИ уже уровня систему, то вероятно можно описать все на диаграмме последовательсти с запуском сессии или передачей кукис
Вот такое мое мнение.
Кроме того, если вы запоминаете историю посещения, то в зависимости от пользователя отображается посещенный им последним ресурс. Имхо варианты есть

Вот у меня возникли трудности с описанием ВИ "проверять корректность работы системы, устранять ошибки и проблемы связанные с потерей информации и т.п."
Я вот как-то не пойму, что тут надо описать
Подскажите плиз.

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

Всем доброго времени сутокЁ
Вот и снова я.
После небольшого "перерыва" приступаю опять к диплому.
Сессия почти сдана.

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

Ага. Прошу прощения. Попутал.


Значит на данный момент у меня имеется: какие-никакие требования к системе. Описание требований. Вроди как выявили участников системы. Описали основные ВИ. Сделали для них Диаграммы активности.

Теперь, я думаю, пора проектировать классы и архитекруту БД. Посоветовавшись на работе, пришли к выводу, что вначале лучше разобраться с БД, а потом с классами.
Вопрос такой. Действительно ли я уже могу переходить к описанным действия или лучше еще что-то сделать. И правильно ли то, что вначале лучше проектировать БД, а потом классы?

Здравствуйте, Андрей.  Рад, что вы вновь с нами. Надеюсь, сессия сдана успешно?

Теперь о нашей задаче. Сделаем ряд выводов
1. Задача в целом довольно прозрачная и пока не затрагивает никаких финансовых вопросов. Поому мы с вами опустили в общем-то как таковое бизнес-моделирование, заменив его контектсным моделированием или моедлью окружения: выделили действующих лиц, определили их интересы, утвердились в вариантах использования системы этими действующими лицами.

2. что не сделано? - нет концептуальной модели предметной области, т.е. либо модели бизнес-объектов, либо ИЛМ. Вы как раз хотите этим занятся, но обратите внимание - это часть работы по исходному моделированию общей бизнес-модели или модели контекста.

3. требования ваши на мой взгляд еще не сформулированы на сто процентов. Например есть вариант испоьзования - Регистрировать пользователя - причем он прописан вами уже на уровне системы, а не бизнеса. Тем не менее, какое требование поддерживает ваш ВИ? На мой взгял ряд требований - основным из которых является: система предоставляет доступ к ресурсам согласно правам доступа пользователей. Из этого следует связанные с ним требования: система должна предоставлят возможность авторегистрации, система должна различать пользователей, система требует авторизованного входа и т.п. Все эти требования уже фиксированы на уровне описание ВИ, но мне кажется, что их следует сформулировать более строго и связать с контекстом. Тут же нужно выявлять и бизнес-правила - т.е. условия или ограничения имеющие четко выраженное значение. Возраст пользователей не ниже 18 лет.

2. что не сделано? - нет концептуальной модели предметной области, т.е. либо модели бизнес-объектов, либо ИЛМ. Вы как раз хотите этим занятся, но обратите внимание - это часть работы по исходному моделированию общей бизнес-модели или модели контекста.

3. требования ваши на мой взгляд еще не сформулированы на сто процентов. Например есть вариант испоьзования - Регистрировать пользователя - причем он прописан вами уже на уровне системы, а не бизнеса. Тем не менее, какое требование поддерживает ваш ВИ? На мой взгял ряд требований - основным из которых является: система предоставляет доступ к ресурсам согласно правам доступа пользователей. Из этого следует связанные с ним требования: система должна предоставлят возможность авторегистрации, система должна различать пользователей, система требует авторизованного входа и т.п. Все эти требования уже фиксированы на уровне описание ВИ, но мне кажется, что их следует сформулировать более строго и связать с контекстом. Тут же нужно выявлять и бизнес-правила - т.е. условия или ограничения имеющие четко выраженное значение. Возраст пользователей не ниже 18 лет.

Простите, мне не совсем понятно, что такое ИЛМ?

По третьему пункту: т.е., если я правильно понял, Вы предлагаете добавить требования системы полбзователю? Или как? Я что-то тут не совсем понял...
Может еще не проснулся?

Простите, мне не совсем понятно, что такое ИЛМ?

ИЛМ - информационно логическая модель то ест полноатрибутивная модель данных со всеми определениями но без ориентации на кокретную субд

По третьему пункту: т.е., если я правильно понял, Вы предлагаете добавить требования системы полбзователю? Или как? Я что-то тут не совсем понял...
Может еще не проснулся?

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

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

Так это получается, что любое действие системы - есть требование к системе?

Так это получается, что любое действие системы - есть требование к системе?

Ну мне трудно так сразу ответить, но собственно да. Есть внешние события, которые вы и описали, и будут еще внутренние события. Пока мы обсуждаем функциональные требования и бизнес правила, т.е. что должна делать система в ответ на события генерируемые пользователями раз, временем два, чем еще?
В общем можно так и сказать, что каждое требование определяет будущее действие системы

А в каком виде лучше все это оформить?
Всмысле требования к системе? Просто их перечислить?

А в каком виде лучше все это оформить?
Всмысле требования к системе? Просто их перечислить?

текстовый формат, док, эксель - в чем удобнее. И нумеруйте требования, возможна иерархия требований.
Можете попробывать EA для этого использовать

Так. Я вот подумал сейчас и понял, что мне немного непонятно.
Можно показать пример?
Например возьмем такой ВИ "Просмотр общей информации о системе".
Какие там требования к системе могут быть

Так. Я вот подумал сейчас и понял, что мне немного непонятно.
Можно показать пример?
Например возьмем такой ВИ "Просмотр общей информации о системе".
Какие там требования к системе могут быть

смотрите описание. вы же навреняка пишете: пользовтаель выбрал то-то, система сделала то-то.
Т.е. получается
Т11: Система должна предоставить общую информацию при входе пользователя в систему
Общая информация: сведения о модулях тестирования, информация о назначении сайта, правила регистрации и тп.п Т.е. то что есть на главной странице или на сайте, та информация которая не требует регистрации
Т12: Система должна предоставить дополнительную информацию в соотвествии с правами доступа
Т121: Система должна идентифицировать пользователя по логину и паролю.
БП1: Логин - является уникальным для системы
БП2: Пароль должен быть не менее 6 символов и может состоять из цифр и букв латинского алфавита и не начинаться с цифры

Что-то в этом духе