6031

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

« : 04 Декабря 2006, 14:10:29 »

Господа!
Давайте сначала определимся с терминологией.
Читаем http://wikipedia.org

Класс (программирование) — некая сущность, которая задает некоторое общее поведение для объектов.

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

Фактически объектно-ориентированное программирование чаще всего сводится к созданию некоторого количества классов, описанию связей между этими классами и их свойств, и дальнейшей реализации полученных классов. Графическое представление некоторого количества классов и связей между ними называется диаграммой классов. Объектно-ориентированный подход за время своего развития накопил множество рекомендаций (паттернов) по созданию классов и иерархий классов.
Подробнее смотри: http://ru.wikipedia.org/wiki/Класс_(программирование)

Объект наряду с понятием «Класс», является важным понятием объектно-ориентированного подхода в программировании. Под объектом подразумевается некоторая сущность, обладающая состоянием и поведением. Как правило при рассмотрении объектов выделяется, что объект принадлежат одному или нескольким классам, которые в свою очередь определяют поведение объекта. Так же часто у объектов выделяется время жизни, то есть время создания объекта и время его уничтожения.
В большинстве языков Объектно ориентированных языков программирования (таких как Java, C++ или С#), объекты являются экземплярами некоторого заранее описанного класса (однако например в таком языке как JavaScript понятие класс не используется вовсе). Объекты в таких языках создаются с помощью конструктора класса, и уничтожаются либо с помощью деструктора класса (например, в C++), либо автоматически с использованием Garbage collector-а(в Java, C#).

Таким образом, класс - есть некая абстракция, а вовсе не интерфейс, как утверждает уважаемый Kolan.

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

Уважаемый bas, естественно ER частный случай ДК, состоящей из из классов-сущностей и не включающая граничные и упраляющие классы. А вот наличие последних и отличает ДК от ER.

Насчет зависимости думаю никто из вас не прав.

a dependency in computer science is a state in which one object uses a functionality of another object. This may cause changes on implementation of one object that can affect implementation of another object.
К сожалению нет русской статьи остается читать только английскую
http://en.wikipedia.org/wiki/Coupling_(computer_science)
очень примечательно.

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

Про последнее. Можно понимать так, что если некое свойства класса А, есть класс В, то между классом А и классом В есть устойчивая связь - читай ассоциация - а какая тут множественность, кардинальность и т.п.?

6032

Примеры / Re: CASE Tool

« : 04 Декабря 2006, 13:44:52 »

Давайте лучше реализуем forvard engineering из всех диаграмм для Delphi. Я буду оч. рад

Больно ты крут:-) BOLD и ECO такого не делают, а там не нам чета коллективчик. В ECO реализован переход от ДК и ДС пока, а как ты предполагаешь трансформировать юзкейсы?

6033

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

« : 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, наследование)

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

6034

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

« : 02 Декабря 2006, 21:12:52 »

Спасибо Юрий за интерес к теме.
Полностью согласен по всем пунктам. Единственное но. Курс мой не проектирование. Проектирование они будут учить на 4 курсе во втором семестре. Тогда какая моя цель - очень неоднозначная. Во-первых, я не должен брать на себя функции чтения материалов по проектированию - вроде для этого цельный семестр и 200 часов аудиторных занятий. Мой курс существенно скромнее всего-то 100. Правда я взял на себя смелость и следующий за ним курс переделал в похожий. В результате получил  нечто такое: первый семестр - основы системного анализа, структурные методы анализа, практика использования IDEF на базе BPWin, практика моделирования предметной области на базе IDEF1x с использованием ERWin. 2 семестр - объектно-ориентированный анализ на базе UML и RR. Стараюсь давать такие навыки как:
1. сбор первичной информации - на самом деле крайне тяжело, поскольку фактически я не могу заставить или обеспечить студентам возможность реального сбора информации, а только стимулирую их играть роль разработчиков сам играя роль заказчика. Реально - туго, практически никто не задает никаких дополнительных вопросов, хотя я даже написал целый шаблон таких вопросников - глухо как в танке.

2. Анализ первичной информации с выделением и уяснением главной и всех других целей системы - тут используется BPWin, причем я подчеркиваю - BPWin - это как карты Таро или натальные карты в гороскопе или магический квадрат Пифагора - просто средство оганизовать мысль и донести ее до других в некоторой определенной стандартом форме.

3. Уменеие на основании анализа предложить синтезированное решение в области ИС.

Мне приходится конечно затрагивать вопросы жизненого цикла и проектирования, даже требовать некоторого условного прототипирования. Например в 1 семестре - хотя бы БД на аксессе, во втором семестре - реализация приложения на дельфи, используя технологию BOLD MDA. На мой взгляд я даю НАВЫКИ в технологии, даже делаю на этом акцент. Пусть ты не понял теорию, но обязан понять технологические приемы - и они куда как конкретные: построил модель данных - конвертируй ее в БД аксесс и посмотри как работает твоя БД, аналогично тому, что ты хотел? Аналогично с диаграммой классов - сделал диаграмму - конвертируй ее в BOLD приложение и посмотри что получилось - удобно? просто сделать то, что ты хотел? НЕТ - переделывай модель!!!
НЕ ДОХОДИТ - ответы есть, они Вами перечислены и другими, но что делать, как сделать преподавание таким, чтобы в среднем все-таки результат был - пусть троечный, но был??

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

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

6035

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

« : 01 Декабря 2006, 20:30:02 »

А вот тут ты сам ответил себе на вопрос. У нас тоже был сопрмат не из легких предметов. Но все его понимали и знали, хотя никто ничего дополнительно не читал. Только лекции с семинарами и учебники с методами и все. Так что в лево вправо это уже не то. Если те интересно, то ты будешь копать дальше, если нет, то ты должен знать все что в рамках курса и можешь даже сдать на 5.

Да ответил, но тот же сопромат: нужно рассчитать нагрузку на некую балку, которая хитро закреплена. Все же ясно, сложно, но решаемо: есть формулы, подходы, точные решения, математические заметь, строго формализованные.
А у нас? все расплывчато, сделал так, а почему так? Чем руководствоваться? Математической логикой - а что это есть? Предикативные высказывания? Или просто здравый смысл? А какой он здравый? Для одного это вполне здраво, для другого другое?
Где критерии? Критерии в неком формальном подходе, но верен ли он?
Да удается сделать проект, он вполне работоспособен, значит мы верно шли?
Пропагандируем его всемерно и вдруг ничего успешного у других не получается. Кажестя человек бъется бъется - но никак. Нет потому критерия, правильно это или нет, так или не так.

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

6036

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

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

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

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

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

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

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

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

6037

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

« : 01 Декабря 2006, 18:30:59 »

ОК, исправлю, сенкс.

ага наш модератор вообще русского не знает:-))

6038

Примеры / Re: CASE Tool

« : 01 Декабря 2006, 18:30:06 »

Спасибо, то что надо. Надеюсь ты не коворишь этим, что все уже сделано до нас?! Я не хочу разрабатывать до конца данную тулзу, я хочу лишь построить модель.

Этого я не знаю, возможно сделано, возможно нет.

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

6039

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

« : 01 Декабря 2006, 13:41:23 »

Ну почему же не удачный? Слово Бизнес клубоко вошло в нашу жизнь: бизнес процессы, бизнес подразделение и т.д. Я бы назвал это как Бизнес Модель ВИ

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

Можно еще делать один пакет для Актеров и другие пакеты разбивать по функциональным блокам, если ситема большая.

А что внешние действующие лица - это не актеры:-)

Ну вот что приходит на ум, когда не надо:
1. Когда Система не сложная
2. Когда бизнеса как такого нет, т.е. нет или мало внешних участников
3. Когда Система уже построена и надо ее задокументировать, т.о. лучше идти от СМ

Критерии плиз, четкие неоднозначно понимаемые критерии, + см. выше
Проблема системного анализа по ИС - нет четкий критериев, а критерии должны быть четкими и не двусмысленными, как в математике и никак иначе.

Ну используй кто не велит? И это будет правильно
/quote]
Попробуй, а я посмотрю:-))

6040

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

« : 30 Ноября 2006, 21:05:26 »

Keen_G...

Полностью согласен, практика - основа всего. Можно прочитать кучу материала, но если не дать пощупать, все это бесполезно.
Потому я и кричу, помогите, посоветуйте, как донести до человека важность.
Думаю, мои студенты будут полностью солидарны с Вашими 90%. А накой это надо. За 6 лет, я выслушивал разные мнения от студентов, причем в первую очередь умных и неглупых, которые имею вполне неплохую практику разработки проектов. Большинство считают, а зачем делать всякие модели-  пустая трата. Вы нас мол учите технологии COM, Java Beans, Ecllipce и т.п. Я обычно отвечаю, а также языкам Питон, ТСЛ, АДА85, Кобол, и т.п.
Времени-то откуда взять, научитись сначала понимать один язык...

Однако я же участвую в защите дипломов, и когда студент защищается видно, что получается. 100% не могут составить грамотные требования к системе. Да некоторым удается сделать неплохой проект, чаще всего не с нуля, а как продолжение, на базе 1с или еще чего, но... практически не возможно продолжать их дело. Ставил эскперимент - в течение 2 лет подряд делал с ребятами 1 проект. Первый должен был сделать моделть и некий прототип, а второй продолжить усовершенствания. И что в итоге? Либо мне самому все пришлось бы писать от начала до конца(но это не мой принцип), либо просто каждый день заниматься со студентом все свободное время. Последнее не против, но так получилось, что они просто не хотят брать знания, просто упираются изо всех сил.

Вот Вы говорите нужна практика, согласен, нужна даже не практика, а стимул. Например, мы заплатим Вам 30 тыс рублей за этот проект - и откуда чего берется:-)

Но мои занятия как раз ведь и построены по приниципу приобретения опыта: есть примеры, постоянно объясняю. Например - идет лаба, сижу с парой студентов и обсуждаем их проект. Я смотрю на него как сторонний наблюдатель и задаю вопросы по ходу, а почему так, а это что, а как это понять, а объяните что тут. а как вы думаете, если это- постановка задачи и ее дать программисту - он сможет сделать, то что вы написали? Практически с каждой парой говорю половину занятия (около часа). И заметьте никто не записывает, не задает вопросы, не уточняет, не отстаивает свое убеждение.

Пример. Задание: существует компания, которая занимается выполнением заказов по почте, телефону и т.п.
Скажем книги. Она размещает рекламу о себе, подготавливает тематические каталоги, которые рассылает по почтам и другим общественным местам, принимает заказы от людей, и выполняет их. Отправляет заказы курьером или почтой наложенным платежем либо с полной оплатой ранее.
Книги заказывает у издательств, складирует их где-то у себя в офисе. Грантирует выполнение заказа в течение месяца в зависимости от дальности клиента.
Предлагается проанлизировать работу компании и предложить решение по переводу системы на веб-технологию, то есть разработать Интернет-магазин (1), систему управления складом (2)
Т.е. работают 2 студента -1 делает магазин, второй складскую систему.
Есть некоторое неформализованной описание работы.

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

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

А ведь в описание четко определе общий сценарий действий.

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

Что делать? Как мотивировать? Тут посоветовали ставь мол не больше 3 вообще за весь курс, и не сходи с пути. Через пару - тройку лет все будут бояться и учиться.

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

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

6041

Примеры / Re: CASE Tool

« : 30 Ноября 2006, 20:31:36 »

Собственно возражать не буду.
Просто посмотри блог Константина Грибачева
http://mda-delphi.ru/blog/grikon/

6042

Примеры / Re: CASE Tool

« : 29 Ноября 2006, 14:19:51 »

Саша, а уверен, что сил хватит разработать свой инструмент?

6043

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

« : 28 Ноября 2006, 17:18:14 »

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

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

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

6044

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

« : 28 Ноября 2006, 15:14:02 »

Их очень много хороших и разных. Вот взять хоть гибкие:
http://www.maxkir.com/sd/newmethRUS.html
Можно так же спор на старом форуме почитать:
http://www.ezforum.org/uml2/uml2-about20-0-asc-15.html

А так хотя бы MDA ее куда деть??

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

6045

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

« : 28 Ноября 2006, 15:09:08 »

Отвечу так. Есть такое понятие как ГОС - государственный обучающий стандарт.
А он определяет направление и темы. К тому же изучение UML само по себе никого не научит системному мышлению. К сожалению получается, что так. Хотя мне думается то лукавство.
UML хорош, но он слишком объемен. Только просто прочитать внятно семантику и синтаксис этого языка - одного курса не достаточно, да + еще хоть какой-то инструмент освоить. ГРАМОТНО.
А в общем так получилось исторически, может со временем я и уйду от SADT, или буду рассматривать их кратко. Но пока считаю как инструмент обучения IDEF0 DFD IDEF3 IDEF1x - очень хороши . Тем более диаграмма активности - а чем вам не IDEF3 или DFD. А диаграмма состояния чем не DFD, да и use case считай упрощенная DFD, без явного связывания. Миниспецификация - тот же сценарий варианта использования. Думаю UML дает слишком много свободы, потому его начинать изучать раньше других методологий не верно. К тому же говорить, что UML есть язык ООП, не совсем корректно, да разные есть причины, хотя бы потому, что студенты еще не проходили ООП:-)) А структурное программирование все-таки понятнее. Тем не менее никто все равно не понимает, что SADT и есть система ориентированная на структурный подход программирования.

NIN. Акцесс тут вовсе не причем. Просто Акцесс под рукой, и переход туда не требует знаний каких-то. А в Дельфи? Я что на занятиях еще буду объяснять как работать в дельфи, учить всяким подходам - BDE ID FIB и другие? А своим то главным делом когда займусь?
А так - всего занятие и нужно из ERwin перекинуть в акцесс, там ничего не делая!!!!!! просто посмотреть, получившуюся схему данных, и попробывать ввнести в таблицы данные используя всякие фичи акцессовские - подтаблицы и прочее. Очень удобно для быстрого прототипирования... А потом кто сказал что акцесс отстой? вовсе нет, для определенных задач очень даже не плохо. У меня куча проектов аксессовских - прекрасно работают в течение 6 лет и никаких сбоев....

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