4471

Обучение / Re: Опыт преподавания объектно-ориентированного подхода в моделировании, анализе

« : 27 Декабря 2007, 23:01:02 »

Виктор, на 100% согласен. Инерция, вернее, масса - большая сила. У вас она еще больше. Я имею в виду массу . Но тут проблема еще в том, что помимо маассы студентво, есть еще одна критическая масса - масса преподавателей. Я не знаю как у вас в МГУ, но у нас точно до взрыва недалеко, вернее до антивзрыва. Средний возраст преподавателя 55 лет, а его отлучение от реального производственного процесса - лет 25-30. В теоретической химии, физики мало, что серьезного произошло, но в самих технологиях как минимум поменялось пару поколений, а в ИТ-технологиях вообще все происходит прямо на глазах.

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

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

Вот и получается - даем то, что есть и как понимаем.

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

Однако. Бог с этим, главное не это, главное то, что удается все-таки заложить в головы.

Вот Вы говорили, что Вам удается добиться этого - сужу по итогам сессии (с ваших слов).

Я пока могу сказать, что справляются максимум 20%, т.е. 5-6 человек из группы. И, кажется, - это вполне нормальный результат. Результат деятельности части этих 20%  я опубликовал тут: http://www.uml2.ru/forum/index.php?topic=445.msg6655#msg6655.
Посмотрите на досуге. Может дадите критику, чего посоветует. Хотя там больший упор на структурные методы, однако суть от этого меняется не существенно.

4472

Теория моделирования и нотации / Re: Разница между decision и concurence

« : 27 Декабря 2007, 21:11:51 »

BAS? пьяный что ли? Может по-английски

4473

Примеры / Re: Задачи на построение диаграммы вариантов использования

« : 27 Декабря 2007, 21:10:46 »

Григорий, критикуйте по существу и вносите свои изменения и аргументы

Программу я Вам могу скинуть. Если что!

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

4474

Теория моделирования и нотации / Разница между decision и concurence

« : 27 Декабря 2007, 12:51:23 »

Как мы знаем для разветвления потоков управления в диаграммах видов деятельности используется decision. Переход осуществляется в результате выполнения некоторого условия, которое задается guard condition. Очевидно, что каждая ветвь перехода должна содержать взаимоисключающие условия. guard condition, таким образом, есть аналог условного оператора или оператора выбора., либо то, что в IDEF3 понимается под XOR.

разделение потоков на паралельные незавивисимо исполняемые ветви достигается использование concurence или синхронизации.

Возникла кулуарная дискусси, что и когда использовать.

Золотухина пишет, что concurence можно использовать для множественного выбора, тогда на ветви перехода ставиться guard. Но что она под этим понимает?

Оппонент мой считает что разницы в использовании concurence и decision типа нет, если мы ставим guard.

Мое же мнение, что добавление guard при использовании concurence позволяет тонко регулировать суть распараллеливания, которая достигается в IDEF3 использованием OR и AND.

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

Прошу собственно высказаться в пользу или анти моего мнения.

4475

Примеры / Задачи на построение диаграммы вариантов использования

« : 27 Декабря 2007, 11:57:20 »

Хочу начать цикл задач по различным UML диаграммам.

Лучший способ обучения, делать и обсуждать, получая рефлексию.

Задача 1.
Требуется разработать модель программной системы автоматизации работы службы такси.
Служба такси предоставляет услуги по пассажирским перевозкам. Служба не имеет собственного таксопарка, а работает по договору с водителями, имеющими личный автомобиль. Каждый водитель имеет свой позывной и график работы. Служба имеет несколько точек-стоянок по городу, на которых водитель может дожидаться поступления близлежащего заказа.
С системой работает два диспетчера. Первый диспетчер занимается приемом заказов, второй распределением заказов между водителями. При приеме заказов клиент сообщает свое текущее местонахождение и телефон, а также адрес назначения. Фиксируется время приема заказа, а также время его выполнения. Для определения оптимального маршрута по городу используется геоинформационная система. Клиент может сделать предварительный заказ, т.е. заказать такси в определенное место к определенному времени.
Клиент идентифицируется номером телефона. Система хранит информацию о заказах клиента и вычисляет его рейтинг, что позволяет клиенту со временем получать накопительную скидку. При желании клиент может сообщить о себе дополнительную информацию (ФИО, другие телефоны и т.п.), что позволит его более точно идентифицировать. Если с заказом были какие-либо проблемы (ложный вызов, неоплата и т.п.), этот факт фиксируется, и телефон заносится в черный список.
Бухгалтерия анализирует отчеты о заказах, выполненных каждым водителем, и на основании их проводит денежные расчеты с водителями. Аналогично, заработная плата диспетчеров зависит от количества принятых заказов. Система также должна обеспечивать отчеты о заказах, выполненных за период времени, выполненных конкретным водителем и заказах конкретного клиента.
Нарисовать диаграмму прецедентов (use case diagram) системы автоматизации работы службы такси.

Возможный результат построения диаграммы вариантов использования

4476

Проектирование / Re: Моделирование иерархической базы данных

« : 26 Декабря 2007, 19:57:13 »

Уважаемый Gotyou.

С превеликим моим удовольствием. Если я чем-то помог, значит не зря копчу небо.

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

4477

Обучение / Re: Опыт преподавания структурного анализа

« : 26 Декабря 2007, 19:37:57 »

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

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

Для знакомства почтенной публики с результатами работы открываю доступ по адресу:
http://www.isuct.ru/~ivt/sadt/

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

Было бы ценно, если кто-то высказался бы по проекту

4478

xP Xd Agile ICONIX пр. / Re: Agile and Iterations

« : 26 Декабря 2007, 17:30:02 »

Боюсь - это так - в качестве оборота речи

4479

xP Xd Agile ICONIX пр. / Re: Agile and Iterations

« : 26 Декабря 2007, 16:50:12 »

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

Например в компании, где я работаю, имено так и делается, хотя плана итераций там особо нет, делается на интуиции

4480

Примеры / Re: Задачка на диаграмму классов (концептуальную)

« : 26 Декабря 2007, 09:32:19 »

В прочем, давайте расставим точки над i.

Задача чисто учебная. Полная ее формулировка такова:
Требуется разработать модель системы управления проектами.
Компания состоит из отделов, в которых работают работники. Отдел отвечает за ноль, один или несколько проектов. Компания имеет название, адрес и телефон. Отдел имеет название и руководителя-работника. Проект имеет название и сроки. Каждый служащий характеризуется именем, адресом и участвует в одном или нескольких проектах. Каждый проект имеет руководителя-работника. Работник выполняет в проекте одну или несколько ролей (например, программист, проектировщик).
Нарисовать концептуальную модель – диаграмму классов (class diagram), иллюстрирующую состав системы управления проектами.

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

Если поставить вопрос так: достаточно ли этих сведений для реализации единственно верного решения? То ответ ясен - не достаточно

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

Что имеет смысл изменить в формулировке (добавить, убрать) чтобы добиться по возможности единственного решения

4481

Примеры / Re: Задачка на диаграмму классов (концептуальную)

« : 26 Декабря 2007, 08:33:59 »

Ден, цель пока не достигнута.

Предложено всего два варианта по сути, более того вариант от Сергея построен на примерном описание, а не оригинальном. За что он меня отругал

Интересно понять, чего собственно не хватает? Какие вопросы у аналитика требований могут возникнуть к такому описанию?

Например, у меня возникают такие:
1. Не означает ли тот факт, что руководитель отдела, отвественного за тот или иной проект, и есть руководитель проекта?
2. Руководитель  проекта назначается из работников компании или это может быть сторонний человек?
3. Какая информация о роли должна моделироваться. Например, я вообще бы сделал роль атрибутом в некоторой сущности Назначение (Проект, Работник, Роль), а Роль сделал бы перечислением.
4. Могут ли отделы состоять из подразделений?

Ну и наконец, какие навыки должна проверить задача в данной формулировке?

4482

Проектирование / Re: Моделирование иерархической базы данных

« : 26 Декабря 2007, 08:20:07 »

Уважаемый Gotyou.

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

Во-первых, иерархическая модель данных представляет собой подкласс теоретико-графовых моделей.
Во-вторых, связью Требование-Проект, Вы уже нарушаете принцип иерархичности. Почитайте например Карпову  Базы данных. Модели, разработка, реализация. Питер, 2001 (стр. 39)
В-третьих, использование XML вовсе не означает, что ваша БД будет иерархической, с чего Вы такое придумали?

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

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

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

ORM вообще-то из другой немного оперы. ORM - это не нотация

Насчет понятия связей и их проектирования, что они значат и как работают, советую все-таки почитать например Крёнке. Теория и практика построение баз данных. 9-е издание, Питер 2005

4483

Бизнес-анализ и Целеполагание / Re: Вопрос по "оригинальной методике бизнес моделирования" от автора Е.Б. Золотухина

« : 25 Декабря 2007, 21:04:23 »

Саш, да нет. Я почему и прибег к помощи переводчика. Прочитал раз, прочитал два. Не фига не понял чего там автор пытается сказать.

Все у него кто-то там прыгает бегает, через что-то перескакивает, а до чего доскакались так и не понял. Запустил промт, вроде перевод ну относительно гладкий, а смысл ускользает.

Идея вроде понятная, но что пытается объяснить автор? Толи что русские нетерпеливые, плохо знают предметную область, либо пытаються все сразу описать, вместо того, чтобы дать краткое содержание, которое постепенно уточнять.

Поясни что ты сам понял?

4484

Обучение / Re: Опыт преподавания объектно-ориентированного подхода в моделировании, анализе

« : 25 Декабря 2007, 20:58:06 »

Да уж, черт ногу сломит.

То, что математика программистам не помешает - это понятно. Она у ваших студентов из ушей плещится.

Так же может и неплохо, что Ваш курс идет на 5, а может мигрировать на 4 курс. Ребята все-таки к этому моменту более зрелые, чем в начале 3 курса, когда они практически еще второкурсники.

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

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

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

У Вас вроде больше готовят вторых, у нас первых.

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

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

В целом программы на сайте http://dit.isuct.ru можно найти и так еще кое-какую информацию

4485

Бизнес-анализ и Целеполагание / Re: Вопрос по "оригинальной методике бизнес моделирования" от автора Е.Б. Золотухина

« : 25 Декабря 2007, 18:29:27 »

Перевод в Промт 8 со стандартными словарями

Российские Программисты

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

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

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

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

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

Специалист по проблемной области не пытался общаться отлично. Он управлял непрерывной неполнотой связи, взаимодействуя с программистами лично и смотря, что они произвели. Luke Hohmann (1998) именует это как "сокращение двусмысленности" в коммуникации.

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

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

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

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

Ничего не понял