Для ВИ следуйте таким указаниям каждый ВИ должен иметь граничные классы управляющий класс и классы сущности, т.е. то что хранить будете.
Граничные классы - суть форму интерфейс
управляющие классы - суть программный код управляющий обработкой данных формы, процесса тестирования и обращения к БД
Правда тут не понятно - Разве ученик может просматривать информацию о классе? И какую информацию о классе? Знаете мне бы лично было бы неприятно, если бы мои результаты тестирования были доступны другим ученикам. Разные понимаете бывают ученики. Кроме того, а чем ваш пользователь отличается от ученика? Что пользователю для того чтобы посмотреть информацию о классе и об ученике, вовсе не надо авторизоваться? Довольно непонятная логика...
Теперь о моих фраза по поводу граничных и управляющих классах.Тут вроди как стало понятно. Спасибо.
А вообще совет - изучите хотя бы общие основы ООП и UML, хотя бы на www.intuit.ru
Интерфейс - грубо говоря, это класс, который отвечает за внешний вид отображения какой-л. информации, так?Не совсем, или совсем не так. Граничный класс и есть интерфейс системы, он возникает между user и системой, а не в место user.
Граничный класс - это например класс user с параметрами lastname, name, secondname, birthday, group. Так?
А Управляющий класс - это класс, где содержатся методы, например getUserInfo, getGroupInfo, getTest
Ну да ладно, раз у вас сделано так, значит такова постановка задачи, хотя мне она сильна неприятна в такой презентации
Да еще хотел спросить, а в каком инсрументе вы рисуете UML
Есть ссылки - на сайте производителя. Правда триал. Вопрос заключается в том, а следует ли использовать коммерческую программу, если да готовли напрмер вуз за нее заплатить..
Участник | Интерес |
Студент | пройти тест, исправить оценку, сдать экзамен, получить сертификат, диплом, повысить свое образование |
Преподаватель | Разработать тесты к курсу, получить отчеты по ученику, предмету, получение зарплаты |
Руководители системы | получить полную статистику по системе, предметам, ученикам, преподавателям, контролировать соответствия тестов программе, их сложность, эффективность и т.п. |
Родители | контролировать обучение своего ребенка, получать информацию о предметах, уровне преподавания, знать учителей, руководителей школы поименно и в лицо, иметь возможность связаться с ними |
Организатор курсов и тестирования (можно ли сюда включить службу тех. поддержки?) | проверять корректность работы системы, устранять ошибки и проблемы связанные с потерей информации и т.п. |
Провайдер Интернет услуг | Получение платы за доступ в Интернет(?) |
Внешние контролирующие органы | Проверка системы на соответствие выданному сертификату, разрешению, получение полной статистики по системе |
Выясняется, что тесты связаны с курсами, но с другой стороны вы сказали, что система тестирования вполне самостоятельная и независимая от курсов - налицо противоречие.
Поскольку все-таки система тетсирования внедряетсявсистему ДО, то вероятно вы будете использовать уже существующую систему авторизации, тогда ее можно сделать как внешнюю систему к которой система тестирования обращается и не рассматривать ее реализацию.
Андрей.
Гляньте краем глаза на www.intuit.ru, пусть вы не разрабатываете всю ДО, сосредоточте внимание на курсах и тестах, выбросите тексты лекций, а в остальном функции подобные.
1. Незарегенный - ради бога делает все что угодно, просто нигде это не фиксируется - а почему нет? Например родители хотят оценить уровень тестов, или работник министерства - да ради бога тестируйется на здоровье - только мы вас не контролируем, не оцениваем, дипломов не выдадим.
2. Зарегистрировался, появился у тебя профиль, тогда чтобы пройти тестирований - запишись мил человек на курс, тогда начнется ведение статистики, записи в зачетную книжку, все серьезно и грамотно
Вариант использования 2.
Войти в систему (уровень пользователя)
Основное действующее лицо: Зарегистрированный пользователь. Гость - это случайный посетитель. Т.е. в иерархии актеров, нужно сделать зарегистрированного пользователя. Ну не может гость никуда попасть, он же не известен системе. Конечно, можно быть зарегистрированным пользователм, но играть роль гостя, но все равно это не гость.
Область действия: Система электронного тестирования
Уровень: цель пользователя
Участники и интересы:
Зарегистрированный пользователь – хочет зайти в систему с определенными правами.
Предусловие: Пользователь зашел на сайт системы
Минимальные гарантии: Нет регистрации - нет и доступа к защищенным разделам.
Гарантии успеха: При успешной авторизации пользователь распознается системой и ему предоставляется доступ к разделам согласно его группе прав.
Основной сценарий:
1. Пользователь выбирает ссылку «авторизация».
2. Система выводит форму авторизации
3. Пользователь вводит необходимую информацию:
логин и пароль.
4. Система подтверждает введенные логин и пароль и предоставляет доступ к защищенным разделам согласно правам доступа
Расширения:
4а. Пара логин-пароль не верная
4а1. Система возвращает Пользователя на главную страницу.
4б. Пользователь забыл ввести пароль.
4б1. Система выводит сообщение о необходимости ввести пароль и возвращается пользователя на шаг 2.
Андрей, вот давайте порассуждаем на тему вашей дипломной работы.
Каковы ее цели? Продемонстрировать умение самостоятельно решать поставленные задачи, показать профессиональные навыки, возможно сделать полезную систему для эксплуатации.
Как показывает практика - студенты врядли способны сделать что-то действительно стоящее, в дальнейшем используемое. И тут беда не студента, а скорее руководителя. Часто руководитель не может поставить правильно задачу, и дает ее на откуп самому студенту. Часто преподаватель в общем-то не заинтересован в получении конечного продукта. Дело в том, что для получения нормального продукта сам руководитель должен участвовать на всех стадиях проектирования.
Здравствуйте, Владимир Николаевич.
У меня есть несколько вопросов на счет диплома.
Лично моя тема: "Подсистема тестирования системы дистанционного
обучения с использованием технологий интернет".
Так вот. Собственно вопросы:
1. Я так понимаю, что если система у нас "дистанционное обучение" - то
оно никак не связано с ДО и следовательно график прохождения тестов не
так важен, да?
2. Тестирование будет привязано к каким-то курсам или просто список
тестов? Если к каким-то курсам - то будет ли какой-то конечный
тест-экзамен. Можно ли будет сдать экзамен экстерном?
3. Будет ли у ученика несколько попыток пройти тест? Я думаю, что да.
Например трех попыток будет достаточно.
В зависимости от того, какие будут ответы на эти вопросы - будет
строиться система.
Здравствуйте, Андрей.
Я полагаю, что ответы на Выши вопросы Вы можете дать сами.
Я стараюсь по мере возможности не навязывать готовых решений.
Подумайте и сделайте логичный выбор...
Подсвиров В.Н.
P.S. Обратите внимание, что мы создаем подсистему тестирования (оболочку), а не ее содержание(сами тесты).
В таких условиях тесты могут иметь иллюстративное значение.
К чему я это - моделирование, документирование и прочее - важный этап работы, но все-таки цель - это конечный продукт. Потому совет - сделайет версию прототип как можно скорее, дайте преподавателю для тестирования, пусть поиграится, попробует потестировать с ее помощью студентов. В ходе экспериментов у него появятся идеи, другое видение, ошибки будут видны отчетливее....
Как вы планирует организовать регистрацию, каков ее механизм, алгоритм?
Далее какова процедура выбора и формирования тестов. Лично я использовал такую процедуру: после регистрации - студент выбирает нужный тест - для некого формируется уникальная неупорядоченная последовательность вопросов, которая записывается в БД. Далее согласно порядку отобранных вопросов выводится список вопросов, номера которых маскируются. Варианты ответов тоже выводятся в произвольном порядке.
Здесь нужно решать как выводит тест, весь целиком, или каждый вопрос отдельно? В каждом случае это может быть важно и зависеть от возможностей, нужно ли посоянное соединение или возможна потеря сессия и ее последующее восстановление, либо сессия отслеживается все время.
3. Поскольку тестирование невозможно без предварительной его подготовки, то требуется инструмент создания теста. А для этого нужно понять каие тесты будут, какие типы вопросов и ответов будут:
1. однозначный выбор,
2. многозначный выбор
3. вычисление
4. точный ответ
5. текстовое представление вопроса
6. графическое представление вопроса
7. возможность выбора ответа нажатием на графическую область и т.п.
Нужно или нет конвертация ранее подготовленных тестов? Например я разработал список вопросв и ответов в word, то могу напрмире сохранить его как текст, сделать некую разметку типа bbcode а потом эту разметку использовать для быстрого импорта тестов в систему
Как Вам такая система?Ну система как система, главное предусмотреть возможность изменения
Вообще конечно хотелось бы такую штуку сделать, но я пока не знаю, какРазработайте собственные теги. Тот кто будет делать тесты сможет эти теги вставлять, это может быть и xml схема, которую вы переведете в реляционную струткуру - много есть возможностей, но это можно пока и оставить
P.S. Обратите внимание, что мы создаем подсистему тестирования (оболочку), а не ее содержание(сами тесты).Вот не согласен в вашим руководителем. Оболочка должна отвечать всей возможной специфики тестов. Просто угадайка - не самый лучший вариант системы контроля знаниями. Если в вопросах и ответах возможны графические элементы, нужно продумать как эти графические элементы будут внедряться - сохранятся и т.п.
Расписали некоторые Варианты Использования.
Просьба проверить.
насчет иерархии пользователей.
А стоит ли слишком заморачиваться?
Зарегистрированный пользователь - это либо студент, либо руководитель, либо преподаватель, либо администратор.
Права доступа определяются группой, к которой они принадлежат. Группа определяет и информацию которую они могут просматривать, ...
ну вот я кое-что добавил...Лучше "Отправить данные" сделать в виде условия. одни из которых идет на Ок, а др. на отмену. И что это за условие перед концом "Отмена Регистрации"?
Добавил плавательные дорожки.
Правильно я сделал?
Да... и еще вопрос у меня.Это лучше оформить в виде альтернативного потока в Логине.
Вот такой ВИ.
Напоминание пароля.
Кто тут будет осн. действ. лицом? Зарегистрированный пользователь или Гость?
Я думаю, что Зарегистрированный пользователь.
Так как гостю не надо никакой пароль напоминать. Его у него просто нет в системе.
Лучше "Отправить данные" сделать в виде условия. одни из которых идет на Ок, а др. на отмену.А может быть тогда и "Ввести регистрационные данные" сделать в виде условия?
эти самые условия, их на какой дорожке надо рисовать?Наверно на системной?Конечно на системной, условие определяет система.
А может быть тогда и "Ввести регистрационные данные" сделать в виде условия?Нет, т.к. "Ввести регистрационные данные" - это действие, а ромб должен быть после этого действия на стороне клиента.
Цитироватьэти самые условия, их на какой дорожке надо рисовать?Наверно на системной?Конечно на системной, условие определяет система.
Мне не понравилось, что вы завершаете отмену регистрации ромбом. Ромб - точка принятия решения. Обычно для слияния потоков используются жирная черная черта (правда если идут параллельные потоки). Хотя, имхо, иногда можно отойти от стандарта, тем более если все ясно и понятно...
Нет, т.к. "Ввести регистрационные данные" - это действие, а ромб должен быть после этого действия на стороне клиента.Так а "Отправить регистрационные данные" - это тоже действие. Подразумевается, что в этом месте пользоватль жмет кнопку "Регистрация" или что-то подобное.
Ничего не понял. Вы об Ви пишите или функции. Что значит проверять корректность, кто его запускет(таймер или пользователь) чья это цель. Начните отсюда
2. что не сделано? - нет концептуальной модели предметной области, т.е. либо модели бизнес-объектов, либо ИЛМ. Вы как раз хотите этим занятся, но обратите внимание - это часть работы по исходному моделированию общей бизнес-модели или модели контекста.
3. требования ваши на мой взгляд еще не сформулированы на сто процентов. Например есть вариант испоьзования - Регистрировать пользователя - причем он прописан вами уже на уровне системы, а не бизнеса. Тем не менее, какое требование поддерживает ваш ВИ? На мой взгял ряд требований - основным из которых является: система предоставляет доступ к ресурсам согласно правам доступа пользователей. Из этого следует связанные с ним требования: система должна предоставлят возможность авторегистрации, система должна различать пользователей, система требует авторизованного входа и т.п. Все эти требования уже фиксированы на уровне описание ВИ, но мне кажется, что их следует сформулировать более строго и связать с контекстом. Тут же нужно выявлять и бизнес-правила - т.е. условия или ограничения имеющие четко выраженное значение. Возраст пользователей не ниже 18 лет.
Простите, мне не совсем понятно, что такое ИЛМ? :(ИЛМ - информационно логическая модель то ест полноатрибутивная модель данных со всеми определениями но без ориентации на кокретную субд
По третьему пункту: т.е., если я правильно понял, Вы предлагаете добавить требования системы полбзователю? Или как? Я что-то тут не совсем понял...у вас есть описание ВИ, но это еще не требования. Ви - получить книгу, требование - Система должна предоставить книгу по требованию. Данное требование связано стребование Система должна идентифицировать пользователей ну и т.п.
Может еще не проснулся? :)
у вас есть описание ВИ, но это еще не требования. Ви - получить книгу, требование - Система должна предоставить книгу по требованию. Данное требование связано стребование Система должна идентифицировать пользователей ну и т.п.
Так это получается, что любое действие системы - есть требование к системе?
А в каком виде лучше все это оформить?текстовый формат, док, эксель - в чем удобнее. И нумеруйте требования, возможна иерархия требований.
Всмысле требования к системе? Просто их перечислить?
Так. Я вот подумал сейчас и понял, что мне немного непонятно.смотрите описание. вы же навреняка пишете: пользовтаель выбрал то-то, система сделала то-то.
Можно показать пример?
Например возьмем такой ВИ "Просмотр общей информации о системе".
Какие там требования к системе могут быть ???