4456

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

« : 05 Декабря 2006, 10:27:29 »

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

Ну хорошо, зайдем с другой стороны. Сложно подобрать критерии к рекомендательным подходам. Вот примеры:
1. Когда зашел у нас спор с другом на счет бух. учета в Банках.
Он в этом спец. и говорит: "У нас в нашем бухучете все на перекосяк шаг влево, шаг вправо - растрел, так работать невозможно. Весь мир уже работает по другому, международный стандарт бухучета (забыл я как он называется). Вот он носит рекомендательный характер, и есть регулирующие органы, ревизоры. Если ты сможешь им доказать, что ты сделал правильно, то тя не оштрафуют если нет, то пипец те."
А я ему говорю: "Что за фуфло ваш международный бухучет, если нельзя все расписать до винтика и строгизх мат. формул. Это как же получается как хочу так и ворочу?"
Он: "А вот так, поверь мне что так лучше."
(Рассказал в краце и без деталей, надеюсь смысл понятен)
И спорили мы до 5 утра под пивко Причем нас было два техноря, а он один
Для меня тогда это тоже было шоком, как так бухучет и без строгих правил. А сейчас ты требуешь строгих правил к творчесому процессу.
2. Был у нас в инсте С++ и был курсовик, надо было что-то реализовать, используя Классы. Я и реализовал, переделав из структурной программы алгоритм по игре в шахматы или шашки (я уж не помню). Программа работала верно и все было ок, пока препод (очень грамотный мужик) не посмотрел в код и сказал, что иерархия классов реализована не правильно и сказал как надо было бы реализовать.
В програмирование тоже нет строгих критериев релизации, есть только патерны, которые нам видимо тоже надо реалтзованвать и для ЮМЛ. Посади 10 человек реализовать программу и все они напишут поразному, у всех будет работать в итоге, но код будет у кого-то правильнее а у кого-то вообще кривой.
3. Из форумов по "проектированию БД".
Есть БД, построенная со всеми правилами нормализации до 3ей формы, но она будет работать медленее в некоторых случаях, чем правильно денормализованная.

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

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

У меня критерий один: Нужно мне или моей организации черкать БМ или нет, если нет, то не делам, если что-то не понятно или требует закзчик, то делаем.
Для учебных целей думаю БМ не нужна, черкайте сразу СМ.

З.Ы. Если не возражаешь, то запостю данный тред на www.sql.ru. Или ты это сделай в разделе "Разработка ИС".

4457

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

« : 05 Декабря 2006, 09:58:38 »

2 galogen & Kolan
Ну зачем сразу наезжать?? "Мы же культурные люди" (с)

На счет зависимости:

http://www.sparxsystems.com/resources/uml2_tutorial/uml2_classdiagram.html

Dependencies
A dependency is used to model a wide range of dependent relationships between model elements. It would normally be used early in the design process where it is known that there is some kind of link between two elements but it is too early to know exactly what the relationship is. Later in the design process, dependencies will be stereotyped (stereotypes available include «instantiate», «trace», «import» and others) or replaced with a more specific type of connector.

http://www.visualcase.com/tutorials/class-diagram.htm

A dependency exists between two elements if changes to one will affect the other.  If for example, a class calls an operation in another class, then a dependency exists between the two.  If you change the operation, than the dependent class will have to change as well.  When designing your system, the goal is to minimize dependencies.

http://en.wikipedia.org/wiki/Class_diagram#Dependency_.28UML.29

A dependency exists between two defined elements if a change to the definition of one would result in a change to the other. This is indicated by a dashed arrow pointing from the dependent to the independent element.

В общем, как всегда мнения разные, но сходство в одном - зависимости надо минимизировать.
Пример привел Kolan, когда в методе возвращается или присутствует параметр типа другого Класса.
Вот наглядный пример:
http://cnx.org/content/m11658/latest/listvisitors.png

4458

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

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

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

Энто как из всех диаграмм?? А разве Тогезер не может форвадить в код Дельфи из ДК?? А разве нет там языка OCL? Можно попробовать почитать www.mda-delphi.ru, м.б. поможет.

Мы не хотим идти до конца и реализовывать все до кода, а хотим построить только модель.
Если есть такое желание, то можешь открыть свою ветку, чем сможем поможем, а потом сольем воедино

4459

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

« : 04 Декабря 2006, 09:59:42 »

"Тип" - относится к интерфейсу
"Класс" - к реализации,
те это несколько разные вещи.

Не совсем понял.....

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

зависимости
Например метод класса А возвращает объект класса В - это зависимость.

Да. Т.е. Если в объявочной части Класса содержится другой Класс, исключая ассоциацию.

теоретическую или модельную
Together считает что это ассоциация.

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

4460

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

« : 01 Декабря 2006, 10:54:22 »

Технология RUP предполагает для бизнес моделирования:
1. построение модели вариантов использования бизнеса (не удачные термины для русского, что можно предложить?)

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

1а. Определение действующих лиц так или иначе заинтересованных в данной системе (пользователи системы, поставщики системы, кураторы системы, субъекты суперсистемы)

Я бы еще добавил, что это внешние по отношению к нам участники. Т.е. опираясь на пример, на данной ДВИ должен быть актер Студент, а Регистратора быть не должно быть на данной ДВИ.
И еще все же наверное не к Системе а к нашему бизнесу. Потому что Систему мы определяем позже.

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

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

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

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

Хотелось немного добавить. VOPC - это 'View Of Participating Classes' - "Представление Классов Участников", т.е. тех Классов, которые учавствуют в ДП, ДС, ДА. Т.о. VOPC - это реализация ВИ, которая включает ДК и ДП, ДС, ДА.

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

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

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

Ну дык, ты же описал, вроде так и должно быть. Можно реализацию БВИ представлять не ввиде ДА, ДС и т.д., а ввиде текста, т.е. в виде Сценария БВИ

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

Ну используй кто не велит? И это будет правильно

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

Проблемма трассировки есть, по крайне мере в Розе. Но не надо подходить так координально.
Мне кажется, что вся модель Система должна быть в одном проекте.

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

Придумки хорошие. Теперь надо расписать Системную Модель и т.д., а потом вернуться к Vision.

4461

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

« : 01 Декабря 2006, 00:36:47 »

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

4462

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

« : 01 Декабря 2006, 00:35:22 »

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

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

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

В сегоднешенем обучении новым предметам есть несколько причин:
1. Нет достаточных учебных пособий именно для ВУЗов, т. о. курс читают как получится
2. Студентам некогда вникать, кушать хочется. Как сказал наш замдек - "Раньше студенты учились и подрбатывали, а сейчас они работают и подучиваются" Студент толкь опотом поймет, что он упустил за время обучения.
3. Не достаток времени у преподов и квалификации (тя не берем)

4463

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

« : 30 Ноября 2006, 02:04:46 »

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

4464

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

« : 30 Ноября 2006, 02:03:53 »

Вот мне и кажется, что в практике и есть основная проблема, нам ее просто критически не хватает! Рядовому студенту даже представить сложно как выглядит Бизнес процесс. Даже если он выучил методологию ARIS наизусть, то когда ему скажут, к примеру: "Спроектируй БП, описав работу материального отдела бухгалтерии!". Не удастся, потому что как работает бухгалтерия для него остается загадкой. Может в этом и кроется проблема...

Практики не хвататет не только студенту, но и всем кто начинает изучать ЮМЛ и все что с ним связано, поэтому и был создан предыдущий и этот сайт ....
На самом деле, по сути, не так важно для учебных целей досканально знать БП "работу материального отдела бухгалтерии", важна методология, даже если он опираясь на базовые данные без деталей, опишет как надо, то  это уже отлично. Практика тут кроется немного в другом, т.к. прочитав тонны макулатуры не сделает с 10ок примеров, то он не бует знать в сущности ничего.

4465

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

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

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

З.Ы. Ты же хотел оригинальную идею, вот она: сделать тулз для ЮМЛ используя ЮМЛ Или ты уже не доволен?

4466

Примеры / CASE Tool

« : 29 Ноября 2006, 10:02:16 »

Вот я тут подумал, и решил, а почему бы нам не попытаться описать и разработать ЮМЛ модель нового CASE-Средства, поддерживающего ЮМЛ.

План действий такой:
1. Описание
2. Системная Модель (СМ) + Аналитическая Модель (АМ)
3. Дизайн модель (ДМ)

Как будет время стану пополнять данный раздел.

Начнем.....

4467

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

« : 29 Ноября 2006, 09:57:03 »

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

Знал бы как, настроил Ты наверное поставил авторизовывать себя  на 60 мин., поэтому и вылетел или одновременно лазил и в админку и в форум. Можно сделать бэк и скопировать сообщение, а потом заново запостить. У меня вообще просто высветилась что ваше сессия закончилась, но пост не стерся, а остался на той же странице ответа.

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

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

4468

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

« : 29 Ноября 2006, 09:51:33 »

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

Ну не совсем. MDA - это технология тоже. Мы просто привыкли под MDA понимать, ДК и OCL, что не совсем верно:

MDA (Model Driven Architecture) is a flagship initiative of the OMG (Object Management Group)
presenting a new vision of how application systems should be developed and managed.

Вот статейка: http://www.metamaxim.com/download/documents/MDAv1.pdf
И описание с OMG: http://www.omg.org/mda/images/mda_text.gif

4469

О Сайте и Форуме / Re: Как мне нравится новый форум?

« : 29 Ноября 2006, 09:32:12 »

2Keen_G Спасибо за лестный отзыв

Жаль только регистрироваться заново пришлось

А что поделать, главное ник успел свой оторвать

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

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

4470

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

« : 28 Ноября 2006, 15:44:40 »

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