Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Gevorg

Страницы: 1 2 3 4 5 6 7 8 »
1
мне интересно, только никакой возможности приехать в Мск,
так что билет просить не буду :-(
Саш, ты там хоть насчёт материалов постарайся заполучить. плз.

интересно, а как пройти тест?
мне тоже интересно.

Эд, а ты тест от Фёдора Новикова, что я тебе присылал с материалами его курса, пробовал?

2
то ще й з України наші поздоровлення:

щоб у твоїй хаті, крім хліба-солі,  водилися-не-переводилися:
- сало з горілкою,
- пиво з лящем копченим.

А головне - друзі та колеги, щоб було кого пригощати...
 ;)



3
Обучение / Re: Задачки для аналитиков?
« : 09 Сентября 2008, 13:57:11 »
Думаю, что смысл этой загадки вот в чем.

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

Но есть и другой путь решения подобной задачи. Такой способ решения, для которого важны вот эти слова...
"Датчанин пьет чай". Вы можете представить себе этого датчанина? Я - нет. Я раньше полагал, что в Дании пьют кофе :)


+1, вот она, соль-то задачки: низзя про контекст забывать, там есть много чего полезного....

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

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

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

очень поучительно, составил себе правило:
если задача не решается, или затраты на её решение неоправданно большие - ищи, как понизить уровень абстракции.

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

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

5
Помница, Gevorg обещал помочь с постановкой курса. Ау, Юра, я готов....
Эд, давай в личке соберём мои результаты по 3G-проекту и что вокруг него поднасобиралось, а потом выложим людям на обсуждение.

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

пока могу что-то определённое сказать только про исходное состояние:
"стою на асфальте, в лыжы обут" - и задаю себе 2 вопроса:
- то ли лыжы не те,
- то ли асфальт сильно на лыжню похож? :-)

Вроде  и UML не плохо знаю (и  людям преподаю и сам использую),
И по части "объектно-ориентированного анализа и дизайна ПО" не новичок: и проектировал и сам программил.
И с паттернами хоть и не на "Ты" а только слегка на "Вы", но знаком.

А лыжы(RUP)  - ну никак не идут :-(
не то что в работе, но и в простом понимании.

7
Итого имеем ...
1) "... то прямой и четкий ответ я дать не могу, так как не силен в RUP." ...
2) отсутствие четкого понимания используемых терминов "Аналитическая модель приложения и Проектная модель",
вне контекста RUP ...
отсутствие чёткого понимания используемых терминов ещё не признак отсутствия за ними полезных понятий и полезного опыта их использования.
я заинтерсовался классификацией Дениса, в её состоянии As Is.

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

Денис, мне действительно интересно знать, что Вы для себя подразумеваете под терминами "Аналитическая модель приложения и Проектная модель"?
Если можно - примеры или просто описание структуры этих моделей.

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

8
Мне интересно, но что такое "модель дизайна"?
Модель предметной области? Аналитическая модель приложения? Проектная модель?
Модели анализа, дизайна и имплементации являются композитными артефактами классического RUP.
RUP может быть не всем интересен...

а вот это уже и мне интересно.

Denis, помогите разобраться, почему при всём уважении к RUP,
я Вашу классификацию моделей воспринимаю намного естественнее, чем RUP-ую?

Для начала у меня вопросы:
1. Ссылочки, где это описано у "знающих людей",
2. Что лично Вы подразумеваете под приведёнными классами моделей?
3. Какое лично у Вас отношение к RUP?
Просто не интересно? Или
интересно, но во многом не согласны с предлагаемыми концепциями
и поэтому - не приемлемо?

2 BAS: это уже похоже на Off-Topic,
подскажи, где правильное место таким вопросам?

9
http://ychernyavskiy.moikrug.ru/

чего нужно от сособщества:
материалы, новости, отзывы, консультации, критика.

чего могу привнести:
выносить личный опыт и наработки на суд общественности.

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

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

Ну, а далее, трассировка уже дело техники
эта техника разделяется на 2 части:
1. Притрассировать к этому объекту-чучелу атрибута все внешние ссылки. Это действительно просто.
2. Придумать какой-то логичный способ подключения этого объета к классу.
Здесь очевидно, что можно  в дереве проекта перетянуть объект-атрибут на соответствующий класс и он ляжет рядом с атрибутом, по которому был создан.
Но следует помнить, что внутри ЭА никакой связи с атрибутом у этого объекта нет:
атрибут можно переименовать, изменить тип, видимость и т.д., на объекте это никак не отразится.

Так самое обидное, что в РаКвэсте есть возможность естественным образом трассировать требование на атрибут или функцию, это нормально показывается в матрице.
И что теперь? Отказываться от трассировки требования на атрибут в РаКвэсте только потому, что эту связь не увидишь в ЭА?

11
Зато очень порадовала фича в диаграмме взаимодействия:

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

Цитируя Эда: "Очень, понимаешь, системно получается" :)

12
Уж очень напрашивается эти отдельные элементы-поля экранных форм страссировать с атрибутами классов
да и кнопочку на форме иногда очень нужно связать с функцией в каком-нить классе, - и тоже нет такой возможности в ЭА.

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

13
Вот, есть в ЭА диаграммы классов, в классах задаём атрибуты с типами данных, всё как положено.

Есть не менее приятные возможности рисовать модели GUI с отдельными элементами-полями.

Уж очень напрашивается эти отдельные элементы-поля экранных форм страссировать с атрибутами классов, - ан-нет:

атрибуты классов на диаграммы отдельными элементами никак не ложатся, непосредственная трассировка к ним - полный ампоссибл.... обидно :-(

14
в теме Enterprise Architect: Практика использования
http://www.uml2.ru/forum/index.php?topic=190.270
Эдуард(Galogen) предложил обсуждение жалоб и восхищений возможностями ЭА вынести в отдельную тему.

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

15
Практические наработки - выложить в фак,
теоретческие рассуждения "О чем думают эти чуваки в спарксе" оставить здесь и все.
Практические наработки в этой теме рождаются и созревают.
А в фак они попадают уже очищенными от сопутствующих обсуждений и отшлифованные.
Еще бы эта Ира выкладывала вовремя :-( А не копила по 3-4 месяца
Это не Ира тормозит, а добротный результат созревает в законный срок.

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

Страницы: 1 2 3 4 5 6 7 8 »