256

UML SysML и пр. / Кому, зачем и когда нужен UML

« : 19 Декабря 2006, 13:57:08 »

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

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

Итак некая компания Х в городе Н занимается производством КИС. Проект возник как ответ на веления времени и был реализован на одном из предприятий страны С. Мало по малу другие компании и организации страны С стали интересоваться КИС. Это так сказать предыстория.

Беседа эе с коллекгами заключалась в том, что можно и нужно ли использовать UML в проектировании КИС, и если да, то как это возможно.
Мои оппоненты весьма не глупые люди с богатым опытом программирования и работы в разных ИТ-компаниях, высказали мысль, что UML и многие другие методики и языки моделирования - все это красивая игрушка для пускания пыли в глаза заказчику, не более.
Мотивация. КИС - сложная система с огромным количеством классов и связей между ними. Как можно представить даже часть такой системы в виде ДК и как отобразить все многообразией связей, которые возникают между объектами. Т.е. мысль такая - при реализации ДК даже небольшой части системы мы получим такую огромную диаграмму с такми количеством связей, что вся ее изобразительная значимость, ее информативность окажется бесполезной. И потом - зачем тратить огромное, гигантское количество времени на подготовку ДК, чтобы в будущем в общем никак ею не воспользоваться. При этом надо ее постоянно сопровождать, обновлять, если происходят изменения кода и т.д. и т.п.
Была высказана мысль, что время, которое потратит человек на создание такой модели существенно больше, чем он бы потратил на простое кодирование. Митивация: грамотный человек умеет строить код и без предварительного моделирования, а не грамотный - ну нам такие не нужны... Проводится мысль - может UML и неплохо, но для его овладения нужно много времени и средств, а его преподавания не поставлено на такую основу, как скажем химия, математика, физика, бухгалтерский учет и т.п. Поэтому - использование UML бессмысленно, бесполезно и даже вредно.
В их рассуждениях я заметил одну неточность на мой взгляд. Мои коллеги путают язык UML и процесс проектирования и кодирования(реализации). Я высказал мысль, что просто в компании нет грамотного процесса производства, не отработана его технологичность, а возможно просто пока вы либо не доросли до этого, либо в данной ситуации это вам не подходит - маленький коллектив - смешение ролей, когда программист является и системным аналитиком и проектировщиком и кодером и тестировщиком, а порой и внедренцем.

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

257

Теория моделирования и нотации / Что такое декомпозиция

« : 16 Декабря 2006, 21:45:34 »

Основой любого аналитического процесса или просто анализа есть декомпозиция.
Возьму на себя смелость сформулировать понятие декомпозиция.
Декомпозиция - это процесс упрощения чего-либо без потери целостности.
Существуют разные виды декомпозиции: функциональная, структурная, объектная, по физическому процессу.
Декомпозиция предполагает иерархическое подчинение нижних уровней верхним. Декомпозиция не меняет сути декомпозируемого объекта или явления, а лишь уточняет его, упрощает, помогает снять неопределенность или локализовать ее.
Когда говорят о структурных методах анализа, декомпозиция воспринимается как обычное явление, сопуствующее методикам структурных методик.
Однако когда мы переходим к вариантам использованиям, нам рекомендуют быть очень внимательным к этому понятию.
К примеру в книге Эрика Нейбурга и Роберта Максимчука "Проектирование баз данных с помощью UML" издательства Вильямс  от 2002 года на стр. 45 читаем "на рис.3.5 представлена общая модель бизнес-прецендентов (модель содержит 1 ВИ::Обслуживание резидента и большое количесвто актеров). Прецедент "Обслуживание резидента" содержит множество ВИ и видов деятельности. Заметим, что здесь речь идет не о функциональной декомпозиции, а просто о более высоком уровне абстракуции, который позволит лучше понять контекст".
Однако, если бы я проводил анализ, используя IDEF0, то действовал примерно так.
Контекст - Обслуживание резидента
О диаграмма - Оказание медпомощи, Получение счета, Выполнение постановлений, Управление клиническими записями, Ответ на запрос
Каждая из выше перечисленных функций может быть декомпозирована вплоть до элементарных действий.
В чем тогда разница? Чем отличается ВИ в UML и функция в IDEF0 или другой структурной методики?

ВИ всегда возвращает результат и всегда есть неделимая последовательность действий.
А Функция? разве что-то другое. По определению функция есть результат преобразования аргументов, в чем разница...

Хотелось бы услышать от знающих ответы на поставленные вопросы, желательно с примерами и обоснованием...

258

О Сайте и Форуме / испытание Hydra Project

« : 14 Декабря 2006, 10:13:54 »

bas, Evgene, Роман, Юрий Булуй, Keen_G, Денис Бесков-Доронин

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

Заранее благодарен. Эдуард Геннадьевич :-)

259

О Сайте и Форуме / Установлен новый бридж

« : 13 Декабря 2006, 20:24:02 »

Коллеги, друзья.

Вот набрался нахальства и переустановил мост интеграции joomla с smf
Кажется, получилось.

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

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

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

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

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

260

О Сайте и Форуме / переезд на новый форум и бридж

« : 12 Декабря 2006, 17:34:18 »

Хочу спросить общественность, нужно ли перейти к финальной устойчивой версии форума. Вышла версия smf 1.1 final, и есть более удобный мост интеграции joomla и форума.
Возможно проблем переезда и нет: делаем бэкап форума, ставим новый, ставим бридж, восстанавливаем БД, надеюсь все учетные записи сохранятся...
Что это дает, более безошибочная версия форума, боле устойчивая работа в целом.
Опасность - могут потеряться учетные записи и что-то еще.
К сожалению, хотя я и ставил форум, но серьезно с ним не занимался. BAS больше...

261

Системный Анализ и Требования / Основы системного анализа

« : 09 Декабря 2006, 21:12:07 »

Хочу начать тему по системному анализу, учитывая пожелания KEEN_G.

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

В любом случае именно принцип разнообразия или разносторонности и есть успех использования системного анализа. (Принцип Ashby).
Тут мне кажется и кроется успешность какого-либо в данном направлении + конечно опыт и  инженерное чутье.

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

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

Возникновение ООП парадигмы на мой взгляд было ответом на кризис создания программных систем в конце 70, начале 80. Тем не менее все принципы системного анализа были тогда известны. SADT технология создана в 67 если мне не изменяет память, а про DFD ходят легенды, что ее первое применение было сделано в 30 годы...

Продолжение следует... Мысли высказывать уже можно:-)

262

О Сайте и Форуме / Реализация проектов онлайн

« : 07 Декабря 2006, 18:59:04 »

я добавил на сайт нашего портала дополнительный компонент Hydra (http://hydramanager.com).
Это довольно простая, но думаю вполне удобная подсистема для ведения проектов в группе заказчик-исполнителя
Доступ к проекту может получить только авторизованный пользователь (появится пункт меню мои проекты)
Для доступа к проектом вы должны входить в группу проекта, пока туда входит администратор.
Для того чтобы начать работу над проектом, следует обратится к админу, и он пропишет вас в группу на соотвествующих правах: администратор проекта, лидер проекта, участник проекта или заказчик.

Надеюсь данное нововведение будет интересным

263

Бизнес-анализ и Целеполагание / Что такое бизнес-процесс?

« : 03 Декабря 2006, 19:14:16 »

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

Wikipedia (http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81)
говорит:
Проце́сс (от лат. processus — продвижение), — последовательная смена состояний стадий развития; Совокупность последовательных действий для достижения какого-либо результата.

Очевидно, второе определение в целом нам ближе.

А вот, что дает энциклопедия по поводу определения бизнес-процесс (http://ru.wikipedia.org/wiki/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81):

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

Как следует из определения, мы имеем явную экономическую или коммерческую направленность.

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

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

А если взять часть такой организации - например, управление факультетом - т.е. деканат.
Сам по себе деканат не явялется самостоятельной финансовой единицей, но является стуркутурной единицей. Можно ли в этом случае считать деятельность деканата - бизнес-процессом? Лично я не знаю...

Есть очень инетерсный язык - BPEL (англ. Business Process Execution Language) — язык на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой. BPEL расширяет модель взаимодействия веб-служб и включает в эту модель поддержку транзакций. Имеет смысл изучить, что же полагает это язык за бизнес-процесс, и не имеет ли смысл притсально его изучить, чтобы применять для описания бизнес-процессов...

С другой стороны вот определение варианта использования, или прецедента:
Прецеде́нт (англ. Use Case, а также: вариант использования, сценарий использования) — спецификация последовательности действий (варианты последовательности), которые может осуществлять система, подсистема или класс, взаимодействуя с внешними актёрами (англ. Actors).

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

Прецедент описывает взаимодействие программной системы с актёрами, имеющее вид последовательности сообщений. В понятие актёр входят люди, компьютерные системы и процессы.

Задачей проектирования программной системы является поиск таких классов для реализации прецедента, которые удачно сочетали бы в себе нужные роли и не создавали при этом излишних сложностей. Реализацию прецедента можно смоделировать в виде одной или нескольких коопераций. Кооперация — это реализация прецедента.

На диаграммах в UML прецедент отображается в виде эллипса. Внутри эллипса или под ним указывается имя элемента.

К прецедентам применимы следующие виды отношений:

    * Ассоциация (англ. Association)
    * Расширить (англ. Extend)
    * Включить (англ. Include)
    * Обобщение (англ. Generalization, наследование)

Надеюсь на продолжение темы...

264

UML SysML и пр. / Теория и практика использования диаграмм классов

« : 01 Декабря 2006, 20:16:54 »

Хотелось бы начать такую тему. Причина тоже ясна, неполное владение понятиями диаграммы классов(далее ДК)

И так, небольшой экскурс. Классы, являясь типами объектов, во многом берут свое происхождение от ER модели данных, где они преставляются сущностями. На самом деле классы, или объекты, есть типы данных. т.е. другой предок - это тип запись во многих процедурных языках.
Аппологеты реляционных БД так и утверждают, что класс = домен! Поскольку домен определяет тип хранимой информации и правила использования ее, допустимые действия. Класс или объект тоже имеет свойства - атрибуты (читай типы данных) и правила работы с ним - читай поведение.
Но не будем углублятся в дебри теории.

Взаимодействие классов на ДК может быть отрожено разными способами:
1. с помощью ассоциаций -устойчивых статических связей между классами различных групп. Здесь все более или менее понятно.
Просто ассоциация, которая дает возможности навигации из одного класса по экземплярам другого (очень близко к первичным и внешним ключам в ER)
Агрегации и композиции - определяющие связи типа состоит из, включает в. Агрегации более мягкие отношения, композиции более жесткие. Класс в агрегации может быть вполне не зависимым - налицо неидентифицирующая связь принадлежности, а класс - слабая но независимая сущность, композиция - наоборот идентифицирует объект - связь идентифицирующая, сущность зависимая. Примерно такая аналоги.
Обощение - связь наследования, похоже но не очень на категориальную связь тип-подтип

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

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

Хотелось бы услышать мнение специалистов в этих областях знаний, поскольку ДК - краеугольный камень всего процесса проектирования.

265

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

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

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

266

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

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

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

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

267

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

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

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

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

268

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

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

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

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

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

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