6046

Примеры / Конкурс оригинальных примеров

« : 27 Ноября 2006, 21:58:40 »

Может замутим идею конкурса самого оригинального использования UML для описание каких-то систем, процессов и т.п. Нужно только фонд создать премиальный:-))

6047

Другие Методологии / А такие есть?

« : 27 Ноября 2006, 21:56:45 »

Что касается структурно-функциональных методологий, то, по-моему, они, не успев обрести программную плоть, испарились как вид. Ну немного их используют экономистя с информационным уклоном, или бизнес консультатнты для пуска пыли в глаза. Еще IDEF0 где-то как-то мелькает, и то чаще всего не по стандарту. По DFD вообще ничего найти не возможно, то есть не успел обрести электронную жизнь. А что еще отстается? Некие "чистые комнаты?", теоретико-множественные переходы? сети Петри крашенные и нет? Вот сети мне нравятся, но как их использовать для описание ИС - непонятно, хотя алгоритмы описывать прикольно, особенно если есть под рукой эмулятор....

А какие еще методологии? Чего-то на ум ничего не приходит...

6048

О Сайте и Форуме / Re: ПЕРЕЕХАЛИ

« : 27 Ноября 2006, 21:45:46 »

Ну вот, наконец-то мы переехали.
Надеюсь на еще более бурное обсуждение вопросов связанных с ЮМЛ.

Две темы уже объявлены. Ждемсъ реакции:-))

6049

RUP EUP AUP OpenUP / Правильное использование RUP и других методологий

« : 27 Ноября 2006, 19:08:10 »

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

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

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

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

Процесс разработки в некотором законченном виде, есть средство общения и взаимопонимания между разными участниками. Ясно, что когда ты сам ставишь задачу, сам ее реализуешь, то будешь делать так как тебе удобно, лишь бы был хороший конечный результат. Будешь ли ты моделировать или проектировать на бумажке или использовать RR, не важно, вероятно ты сразу будешь делать прототип и БД.

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

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

Обычный ход разработки системы - независимо от ее природы, основан на принципах системного анализа и предполагает
1. Постановку и определение цели
2. Определение границ моделирования
3. Анализ системы - определение законов ее функционирования и структуры ее предметнойй области
4. Синтез системы - получение алгоритмов законов функционирования для достижения поставленной цели

В разных методологиях это реализовано по разному.

Остановимся на RUP.

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

Технология RUP предполагает для бизнес моделирования:
1. построение модели вариантов использования бизнеса (не удачные термины для русского, что можно предложить?)
1а. Определение действующих лиц так или иначе заинтересованных в данной системе (пользователи системы, поставщики системы, кураторы системы, субъекты суперсистемы)
1б. Определение вариантов использования, т.е. потребности или интересы действующих лиц по отношению к системе
Обычно я делаю этот этап следующим образом:
1. Делаю пакет: Внешнее представление
2. В нем делаю два пакета как минимум: Внешние действующие лица и Варианты использования
3. Пакет варианты использования по необходимости сразу разбиваю на подсистемы, если они очевидны, либо пытаюсь это сделать изучая действующих лиц и близость ВИ по смыслу и их владельцам


2. постоение модели бизнес объектов - модели реализации бизнес ВИ.
2а. определение исполнителей
2б. определение сущностей

Следуя за Вендровым, я делаю этот этап следующим образом:
1. делаю пакет Внутренее представление (модель объектов)
2. делаю пакет Исполнители
3. делаю пакет Сущности
4. формирую организационные модули если система сложная
либо создаю кооперации бизнес реализации ВИ
Для каждой такой реализации делаю VOPC
Правильно я делаю или нет, не знаю. Логично - кажется да, но так ли это?

Потому хотелось бы получить ответы на ряд вопросов
1. Когда требуется проводить бизнес моделирование? Хотелось бы услышать рекомендации, чтобы понять необходимсоть этого этапа.

2. Каков типичный сценарий реализации процесса бизнес моделирования? Т.е. какие шаги нужно предпринимать и какие артефакты получать. (читал я rup розовский, там столько всего наворочено, что голова начинает болеть уже через 5 минут)

3. Столкнулся с такой трудностью:
Предположим есть
ВИ: зарегистрироваться на курс
участники: Студент и Регистратор(исполнитель)
Описание:
Студент выбирает из каталога курсы (4 основных и 2 альтернативных)
Регистратор проверяет соблюдение всех условий (студент оплатил обучение, курс не закрыт и прочее)
Регистратор вносит курсы в программу обучения студента

тут можно конечно все расширить...

Все в общем понятно, строим ДК типа VOPC для данного ВИ
Очевидно
исполнитель Регистратор
сущности: График прохождения, Курсы, Студент (его запись в системе)
заинтересованное лицо: бизнес эктор - Студент

Сразу возникает проблема. Создаю сущностный класс с названием Студент, но он уже есть! Использовать для него название типа Профиль студента, не очень красиво. Не так видна семантика.
Не делаю сущность студент - а использую самого Эктора Студент чтобы показать связи.
Для наглядности все окей, но не в наглядности только дело.
Я потратил много времени на создание БМВИ и естественно все что натворил, хочу использовать дальше. Добавлять операции, артибуты и т.п.

Как быть? Я для себя делаю такой ход - сохраняю БМВИ отдельно. копирую ее и дальше уже с некоторыми изменениями использую в дальнейших этапах, т.е. пытаюсь добиться автоматизма при переходе от этапа к этапу..

Но все это мои придумки, а как на самом деле следует поступать???

6050

Обучение / Методика преподавания структурного-функционального анализа

« : 27 Ноября 2006, 14:54:48 »

На протяжении 6 лет я преподаю в одном университете предмет, связанный с изучением теориетических основ информационых процессов и систем. Задача предмета состоит в том, чтобы научить студентов производить формальное описание систем, проводить декомпозицию систем с целью снятия сложности, формализовать предметную область.
Результатом практических занятий является построение функциональных, структурных и инфологических моделей системы.
На первом этапе используются структурные методы IDEF0, IDEF3, DFD, Idef1x.
Студенты должны научится создавать формализованное описание системы, выделять ее из окружения, научится декомпозировать ее, описывать законы функционирования и как результат формировать функциональные требования к системе.
Для общего понимания в конце проекта предлагается сгенерировать БД в MS Access.
В качестве исходного задания предлагаются различные системы с подробным но неформализованным описанием процессов в ней.
В качестве примера: работа отдела кадров вуза, работа приемной комиссии, интернет-магазин,
склад, производство, кадровое агентство, риэлтерская контора, и т.п.
Задания составлены так, чтобы студент смог понять общую картину, либо стимулировать его на задание дополнительных вопросов с целью выяснение деталей и подробностей.
Однако я столкнулся с проблемой того, что в итоге даже очень продвинутые студенты практически не справляются с заданием полностью.
Основные проблемы - слабая логика, непонимание для чего это нужно, несерьезное отношение к синтаксису и семантики используемых методологий.
Пробывал разные подходы к объяснению материала:
1.Ничего кроме лекций не объяснял, давал полную творческую свободу. Главное, чтобы было логично и понятно.
2. Сначала показывал пример использования, подробно разбирал этапы, предложил шаблон моделирования и создания описания. В результате - либо бездумное копирование
описания с небольшими изменениями в семантике системы, либо такое напридумывают, что хоть стой хоть падай.
3. Создал жесткое описание, с четко выделенными ограничениями, описанием основных процессов и списка функций. Большинство не может выдержать ограничений, все равно пытаются чего-то нафантазировать
4. Сделал симбиоз строго описание и возможности пофантазировать.

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

Я тут подумал, может как-то преподаю не правильно, может слишком сложно даю предмет, и многое от них хочу? Может надо как-то по другому пойти?
Да понимаю предмет сложен, слишком многое зависит от контекста, нет четких критериев как в математике той же.

Поделитесь опытом, как преподаете Вы, или как преподавали Вам и вы считаете, что владеете предметом....