Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Galogen

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 »
3676
Примеры / Re: Курсовые работы по UML
« : 15 Января 2009, 20:18:18 »
У меня .uml пометился как StarUML проект. Но конечно не открылся в нем.

Смотрю продуктовый магазин - интересная цель познакомится с основами продуктового магазина :)

Схема №1. представляет вроде DFD диаграмму поскольку иллюстрирует потоки данных (информационные потоки). Хотя по духу ею не является.

Диаграмма последовательности не верна по сути.
Если это описание некоторого процесса регистрации поступления товара, то нужно манипулировать не понятиями классов, а понятиями объектов.
Т.е. Новая карточка товара и Старая карточка товара - это разные объекты. Хотя это замечание меркнет с корректность использования самой нотации

Скачал таки программу и посмотрел картинки
1.  Use case диаграмма - это типичное заблуждение тех, кто имел некоторый опыт функциональной декомпозиции. Это пособие - как не надо делать подобные вещи

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

Ясно, что это нечто вроде бизнес-моделирования, но имхо сумбурно невнятно и непонятно

3677
Спасибо за Ваш интерес.

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

1 уровень: допуск. Студент допускается к сессии, если он имеет все зачеты, определенные в учебном плане. Могут существовать студенты, которым сессия продлевается по той или иной причине (это уже определяет декан)
К моменту начала сессии все ведомости по зачетам должны быть проставлены.
Если студент не получил к этому моменту зачет - ставиться незачтено.
Студент все-таки может получить зачет,но уже по квитку (разрешению получать зачет). Основание следует хранить, так как оно подкрепляется к ведомости в будущем.
У нас в вузе считается что зачет получен если студент набрал не менее 26 баллов, а в случае дифзачета - 52 балла.

2 уровень экзамены.
Студент допускается к экзамену только при наличии допуска к сессии.
Если по этому предмету нет зачета, а только экзамен, то допускает к экзамену преподаватель, который ведет этот предмет
Если студент не сдает 2 или 3 экзамена - то есть основание к отчислению (хотя обычно студенту продлевается сессия и дается возможность пересдать вне сессии в оговоренный срок)

Посещаемость в целом, а также факт сдачи экзаменов вне сессии учитывается при расчете совокупного рейтинга за семестр, который влияет на назначение или не назначение стипендии

Цитировать
2. Что подразумевается под заданиями? Это самостоятельные работы, которые надо выполнить в течение пары или задания, выполнение которых по факту нужны для получения допуска до сдачи экзамена?
Пример. предмет Информатика. Есть скажем 9 лабораторных работ. Необходимо выполнить каждую работу и возможно сдать коллоквиум (тест) по ней (зависит от преподавателя и предмета). Общее число пар - 18, получаем 1 задание на 2 занятия. Разбалловка определяется исходя из 50 баллов за семестр, т.е. примерно 50/9 за задание
В принципе для поулчения зачета или допуска можно набрать 26 баллов, т.е. при этом часть заданий может быть не выполнено.
Для определенности примем, что среди 9 заданий назначается скажем 6 строго обязательных, а остальные дополнительные для получения максимального балла. Т.е. 6 заданий студент должен выполнить обязательно, чтобы получить допуск

Цитировать
3. Карается ли минусовкой баллов не в срок сданное задание?
Я обычно делаю так. Сроком сдачи считается момент контрольной точки. Их у нас 3 в течение семестра. Т.е. если студент сдает работу до контрольной точки получает максимум возможного, если после, то производим уменьшение балла (если в период от 1 до 2 контрольной точки 0.8 от возможной оценки, если между 2 и 3 контрольной точкой 0.6 от возможной точки).
Т.е. вероятно нужно хранение настраиваемого правила снижения оценки в зависимости от срока сдачи (простановки оценки). Правда делать это жестко не стоит, причины сдачи не вовремя могут быть и объективные

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

Но для чистоты эксперимента - мы только поставщики сырья.

Итак, кто будет Аналитиком, постановщиком?

Также неплохо бы иметь некоторого Рецензента

3679
Еще наверное Эдуард принимает экзамены в конце каждого семестра по отдельным Дисциплинам, результатом которого ставится:
1. Оценка от 2 до 5
2. Явка - явился или нет
Экзамен и Зачет могут сдавать только допущенные Студенты по результатам семестра.
Да это так. Я могу принимать экзамены. При этом экзамены принимает лектор. Практику может вести и другой преподаватель. Именно этот преподаватель и выставляет семестровую оценку в баллах
оценка ставится действительно в виде неудовлетворительно, удовлетворительно, хорошо и отлично. Однако ставится балл за экзамен исходя из 50.
Тут следует учесть что разные вузы могут иметь разные системы оценивания

Цитировать
Также мне бы как Преподавателю хотелось иметь возможность выкладывать Лекции, Книги, Ресурсы и другие Документы, которые необходимы для обучения Студентов. А Студенты должны иметь возможность пользоваться этими Документами.
Мне думается это имеет мало отношения к ИС аттестации студентов

Цитировать
Мне бы НЕ хотелось отмечать посещение Студентов вручную. Хочется чтобы сам Студент приходя на Лекцию отмечался около стола Преподавателя.
Это скорее из области фантастики и усложняет задачу, мало чего внося в нее

Цитировать
У нас в Институте есть КИС, которая хранит данные по всем поступившим Студентам. Хочется иметь возможность импорта Студентов по необходимым  группам в ИС "Учета успеваемости".
Вопрос чем будет отличаться ИС "Учета успеваемости" от ИС "Аттестация студента"

Цитировать
Также необходима возможность составления проверочных заданий в ИС. Чтобы Студент мог проходить эти тестовые задания и по результатам этих тестов выставлялась оценка. Тесты могут быть итоговыми (зачет, экзамен) или в качестве ДЗ несколько раз в семестр.
Такое пожелание можно рассматривать в качестве возможного требования

Цитировать
Необходима возможность ведения списка необходимых Заданий (ДЗ, Курсовые, Зачет, Экзамен и т.д.) по каждому предмету в каждом семестре, чтобы была возможность Студентам либо их проходить самим (тесты), либо загружать сделанные задания, либо выставлять оценки Преподавателю вручную. Необходимо в любой момент вычислить задолжников по предметам.
Это предполагает уже подключение подсистемы учебно-методического комплекса УМК, который разрабатывается преподавателем и вводится в виде некоторого плана-графика.

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

Работник деканата - должен иметь возможность определять итоговые данные по студентам группы, по группам, по факультету в целом. Проставлять допуски на сессию по данным, которые будет предоставлять преподаватель

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

3680
Начинаю постановку.

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

Как у лектора у меня может быть 1 группа или несколько групп (поток) на одной лекции. Лекции я могу читать по одному предмету, а могу и по нескольким в семестре.

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

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

Обычно количество отчетных занятий (т.е. занятий с оценокй) фиксировано и меньше чем общее число занятий (пар). Ну скажем я веду базы данных и у меня всего 18 пар (36 часов лабораторных), количество заданий скажем 8. Общая стоимость дисциплины в семестре 50 баллов. Я раскидываю их на 8 занятий, исходя из собственных соображений.

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

В конце семестра в Экзаменационной ведомости я указываю также рейтинг за семестр (не более 50 баллов). При этом может быть просто допуск, зачет (тогда я должен записать зачтено или не зачтено дату и подпись), дифзачет (т.е. почти то же самое что и зачет но с оценкой, которая равна рейтингу в семестре + балл за зачет, всего до 100 баллов)

у нас принято
52-69 удовлетворительно
70-84 хорошо
85 -100 отлично

Ну для начала достаточно?

3681
По "ИС аттестация студентов" я бы мог быть источником информации, все-таки преподаватель и представляю о чем идет речь.

Единственно , что хотел уточнить, что автор предложения понимает под аттестацией студентов: контроль успеваемости или более объемно?

3683
А почему бы нам не сделать аналогичную игру. Я могу быть поставщиком требований :)

Т.к. топик будет большой, то здесь будем давать ссылки на основные сообщения:

1. Команда проекта:
http://www.uml2.ru/forum/index.php?topic=1106.msg11617#msg11617

2. План действий:
http://www.uml2.ru/forum/index.php?topic=1106.msg11611#msg11611
2.1. Подробный план по работе над пп. 2.1-2.3
http://www.uml2.ru/forum/index.php?topic=1106.msg11693#msg11693

3. Шаблоны Документов:
http://www.uml2.ru/forum/index.php?topic=1106.msg11645#msg11645

4. Постановка Задачи:
http://www.uml2.ru/forum/index.php?topic=1106.msg11612#msg11612
http://www.uml2.ru/forum/index.php?topic=1106.msg11613#msg11613
http://www.uml2.ru/forum/index.php?topic=1106.msg11614#msg11614

5. Концепция от veta, StUtk, bustor (последнее обновление - 01.03.2009)
http://www.uml2.ru/forum/index.php?topic=1106.msg12632#msg12632
ДБО см. в п. 6

6. Диаграмма Бизнес Объектов (последнее обновление - 28.04.2009)
http://www.uml2.ru/forum/index.php?topic=1106.msg13782#msg13782

3684
Интересно, в качестве примера использовался пример с сайта компании unify?

3685
Sparx / Re: Enterprise Architect + PHP Doc.
« : 30 Декабря 2008, 22:14:51 »
Кукарача, извините, но это очень частный вопрос. Ни чем определенным помочь не могу. Все -таки советую постараться задать влвпрос на самом форуме ЕА

3686
Отвечая на данную тему, задумался и пришел к выводу - не прав тот, кто задает вопросы, не правы и те, кто отвечает.

К счастью - те, кто отвечает не правы меньше.

Теперь несколько слов об основах.

1. Диаграмма Ви должна быть максимально простой
2. Чтобы быть простой она должна содержать как можно меньше структурных элементов(инклюд, экстенд, обобщение)
3. Инклюд означает, что базовый вариант не может быть исполнен без включение сопутствующего ВИ
4. Чаще всего ВИ включамый бывает неполным - т.е. не  может иметь экземпляров, но бывает и полным - т.е. вполне самостоятельным
5. Расширяющие ВИ чаще всего бывают неполными
6. Расщиряемые ВИ не зависимы от расширяющих, если сравнивать с инклюдами
7. Расширяющие ВИ чаще все-таки неполные, т.е. не имеют экземпляров

Резюме. В обсуждаемом случае лучше иметь два независимых ВИ: авторизация и регистрация. ЭТо не инклюд 100%, но и как расширение тоже не тянет. Просто регистрация - есть предусловие для авторизации

3687
Sparx / Re: Enterprise Architect + PHP Doc.
« : 29 Декабря 2008, 21:52:35 »
Мне думается с этим вопрос Вамлучше обратится на форум самого продукта. Посоветовать можно только:
1. настроить схему трансформации с учетом этих самых PHPDoc (кстати это что? heredoc имеется в виду или нет?)
2/ воспользоваться возможностями Automation Interface и создать в какой-то студии хороший парсер для php кода

Насчет PHPDoc посмотрел. Может имеет смысл посмотреть а КАК ЕА конвертит JavaDoc, если успешно - сделать по аналогии

3688
Хочу еще заметить, что форма ВИ не догма. Это же не математика со строгим доказательством и каноническими формами. Это скорее практика жизни, эмпирика. До нас и после нас 1000 людей будут сталкиваться с одинаковыми проблемами и пытаться одинаково их решить.

Будет ли создан четкий математический аппарат позволяющий четко и конкретно определить - это математически верный ВИ, а это не. Думаю вряд ли.

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

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

Хорошо или нет сказать: Пользователь вводит данные для авторизации?
С одной стороны вроде хорошо - мы не стесняем проектировщика в средствах - пусть сам определяет ЧТО это за данные
Но ... а как проверить что данные авторизации достаточны? Разве не определеннее и не яснее сказать Пользователь вводит Логин и Пароль, а в доптребования написать Логин - строка не менее 6 символов только латинского алфавита
Пароль - строка не менее 8 символов
Резонный вопрос, а куда пользователь вводит данные каким способом?

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

Более того многие авторы (авторитеты) призывают не описывать ВСЕ ВИ, или не описывать все ВИ одинаково.

Для отдельных достаточно краткого описания, для других нужны детализированные многостраничные описания.

Розенберг в своей книге посвященной использованию ICONIX, вообще утверждает - нечего парится. ВИ - это два абзаца (два параграфа) - 1 для основного потока в стиле обмена мячом, другой для альтернатив. Причем сразу в описании нужно использовать и выделять названия ПРЕДМЕТНЫХ классов и даже форм (интерфейсов). По его мнению это не нарушает принципов инкапсуляции - все что видно пользователю может быть элементарно использовано. Следует избегать описания внутренности черного ящика

3689
1. ВИ "авторизация"
цель:
- получения доступа к ресурсам сайта
краткое описание:
- пользователь запрашивает форму авторизации
- система предлагает ввести логин/пароль
- пользователь вводит данные
- система обрабатывает данные и предоставляет или отказывает в доступе

2. ВИ "регистрация"
цель:
- возможность авторизоваться
краткое описание:
- пользователь запрашивает форму регистрации
- система предоставляет форму
- пользователь вводит данные
- система регистрирует пользователя

1. ВИ "Авторизоваться"
цель:
- получения доступа к ресурсам сайта
краткое описание:
- пользователь идентифицирует себя в системе
- система обрабатывает данные идентификации и
   если данные верны предоставляет доступ к ресурсам сайта
   иначе предлагает "Пройти регистрацию" (точка расширения Пользователь системе неизвестен или введены ошибочные данные)
Результат: в интересах пользователя - получен доступ к ресурсам
                в интересах держателей системы -  не предоставлен доступ к ресурсам неизвестному посетителю
Т.е. подключение ВИ пройти регистрацию возникает при возникновении определенной ситуации

2. ВИ "Пройти регистрацию"
цель:
- возможность получения доступа к ресурсам сайта
краткое описание:
- пользователь регистрируется в системе
- система регистрирует пользователя (или сообщает пользователю что регистрация прошла успешно)
Результат: в интересах пользователя - получена возможность получить ресусры сайта
                в интересах держателей системы  - получена информация о пользователе ресурсов

Обратите внимание, что я устранил даже намек на реализацию. Нет форм, нет требуемых данных. Предположим об этом подумают на стадии проектирования ВИ. Показано только ЧТО делает пользователь и ЧТО делает система.



А вообще процесс разработки итерационный

3690
Что такое ВИ? ВИ - это некий функционал, предоставляемой системой. ВИ "Логин" - авторизация пользователя, то есть это ВИ позволяет пользователю войти, если он ввёл правильный(известный системе) логин/пароль. Без регистрации залогиниться ну никак не получится, а это значит, что выполнение одного ВИ зависит от другого ВИ. А отношение расширения - это лишь дополнительный функционал, выполняемый при определённом условии, однако, без выполненного ВИ "Регистрация" залогиниться не получится, то  есть не будет работать ВИ "Логин". ИМХО =)
А что есть функционал? Я такого термина не понимаю.
ВИ - это способ описания того, что ДОЛЖНА сделать система, чтобы ДОСТИЧЬ цели пользователя. Т.е. ВИ содержит некую поступательную (в смысле движения к цели) сововкупность действия как системы, так и пользователя. Как говорит Коберн некое соглашение, контракт. Контракт часто используемый термин в иностранной литературе

Цитировать
Опаньки...) а ведь мы тут рассматриваем Use Case, в котором важна функциональность системы, а последовательность действий - это уже другое. Тут рассматривается статика, только то, что предоставляет система - функия авторизации, функция регистрации, функция оформления заказа и т.д.. имхо...)
Включение, как Вам объяснили - это обязательный акт. По Вашему, регистрация включается в код авторизации всегда - действительно ли пользователь существует или нет.

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

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 »