Об UML и чертежах

Сегодня в голову пришла "крамольная" мысль. Даже жену спросил об этом.

Вот скажем как "всякие" сантехники или водопроводчики. Или токари чертежи читают.

Как?

Где их этому учат? В ПТУ вестимо.

И ничего. Читают и делают своё дело.

С разрезами, проекциями, фасками и прочими допусками.

Нам когда-то надо было сделать клапан для скороварки. Для походов. Ну пошли мы к токарю - объясняем. Он нам говорит - "чего вы на пальцах объясняете. Несите чертёж - сделаю". Так и получилось. Нарисовали чертёж. Принесли токарю. Он нам сделал, то, что нам было надо.

И ничего.

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

Так как же так получается, что люди с ВЫСШИМ образованием, в основной своей массе - НЕ ГОТОВЫ читать диаграммы UML. Ведь они не СЛОЖНЕЕ, чем чертежи. Которым кстати в школе учили. Азам. А уж в ВУЗах - и подавно. По себе знаю. У меня было много подобных дисциплин. И ничего. Никто не умер.

Сколько должно времени пройти, чтобы научились? Лет 50-т?

Начинать надо со школы? ВУЗов?

Ведь UML - явно - НЕ СЛОЖНЕЕ, чем чертежи.

Или "сантехники" умнее, чем "креативный класс"?

И ведь главное - ведь УМНЫЕ люди говорят - "не хотим читать ваш UML, мы в нём ничего не понимаем".

Проблема в UML? Или в "молодости технологии"? Или в менталитете?

Не понимаю.

У меня у жены кстати заказчики - читают UML. Откуда они "такие умные" взялись - не понимаю. Много вопросов по этому поводу задавал. Ответов - пока не получил.

Или я что-то не так трактую?

P.S. Меня тут "на просторах интернета" дружно "тыкали носом". Мол "прочитайте книжки про UML". Прочитал. И перечитал. Много всяких разных. Умных и не очень. "Отбашлял" денег авторам.

Того же Лармана перечитал. И много других. В количестве 6-ти штук.

Ну что могу сказать. Да ничего.

Кроме "рекламных лозунгов" типа "UML это круто" и "UML позволяет упрощать общение с заказчиками". А также обсуждений типа "какая стрелочка кошернее" - ничего не почерпнул оттуда. :-(

Может быть я такой дурак и не понимаю "гениальности замысла"?

И не умею "читать между строк"?

Я ИСКАЛ - МОТИВАЦИЮ. Что? Почему? Зачем?

ПОЧЕМУ - UML это - ЗДОРОВО. Не нашёл... :-(

Ни в одной из книжек.

Плохо искал?

P.P.S. У меня кстати родилась ещё одна "крамольная" мысль, что и RUP и XP и Agile -направлены на "сантехников" и "кодеров". Потому что предполагают "открытый формат", "незамороченность" и "нестатусность".

Может быть "у них там на Западе" - по-другому всё устроено?

P.P.P.S. Да! Никого не хочу "поругать" или задеть. Просто "со стороны наблюдаю". И не только на СВОЁМ опыте. Было бы это ТОЛЬКО на МОЁМ опыте. "В рамках отдельно взятого предприятия" - я бы и писать бы об этом не стал бы.

Ссылка. Templates in Object Pascal

Спасибо моему коллеге.

Он разыскал "оригинальный" документ. На сайте Embarcadero между прочим.

Правда по-моему исходный автор всё же либо Акжан Абдуллин, либо Анатолий Тенцер. Ну не важно....

Итак. Шаблоны и примеси в Delphi:

http://edn.embarcadero.com/article/27603

Вот откуда ноги растут вот этого:
http://18delphi.blogspot.com/2013/07/2_18.html
http://18delphi.blogspot.com/2013/07/2.html
http://18delphi.blogspot.com/2013/07/blog-post_8789.html
http://18delphi.blogspot.com/2013/07/blog-post_3683.html

Так что - я не САМ этот "велосипед" придумал.

Ссылка. Pascal Script

http://goodbyamerica.sourceforge.net/Pascal%20Script_rus.html

Что мне ОСОБЕННО в этом нравится?

Это - ТИПИЗАЦИЯ переменных и КОМПИЛИРУЕМОСТЬ кода.

Биндинг к нативным классам - отбрасываю. Он есть у всех. Даже у меня.

ОБЯЗАТЕЛЬНО прикручу это "куда-нибудь" к себе.

Во внерабочее время.

А потом - Python.

ОБЯЗАТЕЛЬНО.

И будут у меня - "батарейки в кубе".

P.S. Не спрашивайте - ЗАЧЕМ.

Именно, что во внерабочее время.

Некоторые марки коллекционируют ("о чём говорят мужчины"). Некоторые в горы ходят (я сам когда-то ходил).

Но! С некоторого времени - я ПОНЯЛ. Что программирование - это ЕДИНСТВЕННОЕ, что я РЕАЛЬНО УМЕЮ делать. И что мне РЕАЛЬНО нравится.

Ни зачем.

Просто - НРАВИТСЯ.

МОТИВАЦИЮ - я ВСЕГДА придумаю. Она ЕСТЬ у меня - для МНОГИХ моих разработок.

Но ГЛАВНАЯ мотивация - НРАВИТСЯ и всё.

Нравится прикручивать, откручивать, рефакторить, тасовать куски кода, рисовать диаграммы (http://18delphi.blogspot.com/2013/04/uml_21.html). Наблюдать - "как оно шевелится".. То что "своими руками сделано"... Игру "Жизнь" - надеюсь - все помнят...

Что уж кривить душой. НРАВИТСЯ - "удовлетворять свой интерес за чужой счёт".

(Хотя я бы поспорил бы - насколько он "чужой"...)

Хотел бы конечно когда-то "продать" Эверест.. Но не сложилось, что уж... А мог бы быть неплохой "стартап"...

Но. Программирование...

ПРОСТО - это ЕДИНСТВЕННОЕ, что я умею делать ХОРОШО.

И что - "заводит".

Просто "ходить на работу" и "делать что говорят" - неинтересно. Нужен - драйв.

Я его нахожу. Время от времени.

И при этом вполне себе эффективно (надеюсь) - работаю.

Когда-то Нечаев (http://18delphi.blogspot.com/2013/04/blog-post_9262.html) "и компания" пытались делать систему разработки для РАЯ (http://ru.wikipedia.org/wiki/%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9_%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA) с графической нотацией кстати.

Я тогда это воспринимал скептически. Но теперь - пришёл к тому, что хотел бы это реализовать.

Требования, UML, код, тесты. Всё  в одном флаконе.

Вот как-то так...

P.P.S. Посему - "глупо" спрашивать про мотивацию VCM (http://18delphi.blogspot.com/2013/09/blog-post_16.html http://18delphi.blogspot.com/2013/08/mvc.html) хотя она есть конечно же. И я всегда руководству - ПРЕДСТАВЛЯЛ свою мотивацию. И писал документы на сей счёт. Но - ГЛАВНАЯ мотивация - была такая - "сделать КРАСИВО".

Должно - НРАВИТЬСЯ работать. МНЕ - нравится.

P.P.P.S. А ещё я мечтаю - написать книжку (и в общем - есть что писать, коллеги - не дадут соврать). Про UML. Для "технарей". Без "лозунгов" типа "UML это круто... кто не использует UML - тот лох..." (http://18delphi.blogspot.com/2013/09/blog-post_8175.html) Просто как Я это ВИЖУ. В духе Джоэла (http://www.joelonsoftware.com/) что ли...

А ещё лучше - аналог "атласа машин и механизмов"  или "номенклатуры микросхем" (http://18delphi.blogspot.com/2013/04/uml_22.html http://18delphi.blogspot.com/2013/04/blog-post_5722.html http://18delphi.blogspot.com/2013/04/uml_19.html).

Все мои "потуги" и "писания" в блоге - только на это и направлены. Получается пока криво и косо (проприетарность - опять же). Но - будем работать...

Вот задумался... А нужен ли MVC-like фреймворк в Delphi

Всеволода Леонова об этом ещё в Казани спрашивали. Мол "почему в Delphi до сих пор нет MVC".

Что мне кажется....

Как "калька" с "реализации MVC от Apple" - по-моему - не нужен... И даже - "вреден".. Мне так кажется.

Но как развитие идей и подходов из DataAware, Visual Live Binding, TAction и DevExperss - по-моему - нужен и "полезен".

P.S. Говорил тут с коллегой. Он тоже сказал - "ПЕРВОЕ на чём бы я базировал бы MVC для Delphi - это Action'ы".

P.P.S. Кстати "кальку" с Apple - И СЕЙЧАС никто и НИКОМУ не мешает. Сделаь "базовый" класс TUIViewController. Там делать то - копейки.... Только - непонятно - зачем... По моему скромному мнению - MVC от Apple - НИКУДА НЕ ВЕДЁТ разработчика. Не ПОДТАЛКИВАЕТ его к ПРАВИЛЬНЫМ решениям. Можно на View ВСЮ логику нагрузить, а можно - на Controller. Никто и никак это не валидирует. Опять же - "вкусовщина". На откуп КОНКРЕТНОМУ программисту.

А фреймворк должен ВЕСТИ и ПОДТАЛКИВАТЬ к ПРАВИЛЬНЫМ решениям. Выполнять роль тьютора.

И НЕ МЕШАТЬ :-) по возможности.

САМЫЙ правильный фреймворк, который я видел - это STL. Он - РЕАЛЬНО ПОДТАЛКИВАЕТ.

ВСЕ начинают с for по count и ItemAtIndex, но ОЧЕНЬ БЫСТРО приходят к итераторам.

Косяки - вылезают - сразу.

За ним - VCL и FM.

Ну и потом - QT.

P.P.P.S. Я кстати когда читал книгу Страуструпа по C++. Давно. Лет 19-ть назад. У меня было ощущение УЖАСА. Копирующие кострукторы, некопирующие, операции присваивания. Когда и что ПРАВИЛЬНО делать? Понятное дело, что СОВСЕМ правильно - делать ВСЁ. Но надо ли?

Страуструп - оставил меня в растерянности.. Он - не объяснил мне...

Но КАК ТОЛЬКО я познакомился с STL - ВСЁ СТАЛО НА СВОИ МЕСТА. STL, как архитектура - САМ всё подсказывает и ВЕДЁТ.

Побольше бы таких фреймворков....

Чем мне не нравится MVC

Может быть я - дремучий. И НЕ ПОНЯЛ гениальность идеи.

Может быть.

Но!

Мне НЕ НРАВИТСЯ, что КОНТРОЛЛЕР знает про VIEW и управляет им.

А не наоборот.

А как же постулат (в частности от Apple) - "когда мы захотим поменять интерфейс - мы запросто сможем это сделать".

Как "запросто"?

Поменять ДВА слоя - КОНТРОЛЛЕР и VIEW? Или Выводить "абстрактные" контроллеры?

Или нагружать МОДЕЛЬ бизнес-логикой?

У "меня" всё перевёрнуто "с ног на голову" - VIEW -> CONTROLLER -> MODEL -> DATA.

Да и слоёв там БОЛЬШЕ.

ПРЕЦЕДЕНТ (View) -> (тут "прокладка", которая умеет транслировать Controler во View с учётом "неформальных правил") -> БИЗНЕС-ОБЪЕКТ ПРЕЦЕДЕНТА (Controller) -> ОБЛАСТЬ ВВОДА (ФОКУСА) (View) -> (тут "прокладка", которая умеет транслировать Controler во View с учётом "неформальных правил") -> БИЗНЕС-ОБЪЕКТ ОБЛАСТИ ВВОДА (Controller) -> ДАННЫЕ (Model) -> БД

Как-то так.. Как минимум.

Ну и идею того, что КОНТРОЛЛЕР вызывает контекстное меню (showMenuOnThisView), а ОБРАБАТЫВАЕТ логику меню VIEW - я НЕ ПОНИМАЮ.

По-моему - View должны находиться на "вершине иерархии". View - должны черпать логику и данные из НИЖЕЛЕЖАЩИХ слоёв.

Тут есть одна проблема - надо "точить" контролы View - либо в плане DataAware, либо в плане Visual Live Binding.

Ну мне как-то так видится....

Коротенько. Мой коммент в чужом блоге

http://roman.yankovsky.me/?p=896#comment-3024

По-моему - полезный...

Есть такая книжка - "психбольница в руках пациентов"

Есть такая книжка - "психбольница в руках пациентов" (http://royallib.ru/book/kuper_alan/psihbolnitsa_v_rukah_patsientov.html http://www.amazedev.com/files/Alan_Cooper_the_inmates_are_running_the_asylum_short.pdf).

Так она примерно об этом - http://18delphi.blogspot.ru/2013/09/blog-post_16.html

Что хочу сказать?

Надо всё переосмысливать.

И не гоняться за "серебряной пулей"...

Не устаю цитировать Джоэла...

http://local.joelonsoftware.com/mediawiki/index.php/%D0%90_%D0%B2%D0%B0%D1%88_%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_%D1%82%D0%B0%D0%BA_%D0%BC%D0%BE%D0%B6%D0%B5%D1%82%3F

Чем хороши "функциональные языки"? А ТЕМ, что они:

1. Позволяют КЕШИРОВАТЬ результат вычисления функции (с таблицами Брадиса - надеюсь ВСЕ знакомы).
2. Позволяют РАСПАРАЛЕЛИВАТЬ  процесс вычисления.

Почему? ПОТОМУ, что ВСЕ функции - ДЕТЕРМИНИРОВАННЫ. И НЕ НУЖДАЮТСЯ в "синхронизации".

Но!

Если НЕ ВСЕ функции детерминированны? Что делать?

Тут - "вроде вводят понятие монад". Но! Если функция "зависит от монады". то она сама является монадой? Ну как если таблицы Брадиса "меняются на лету"...

Или как? Может - http://18delphi.blogspot.ru/2013/07/blog-post_9746.html

Как МОНАДЫ "изнутри" устроены?

Что ИМЕННО позволяет МОНАДАМ быть "особыми", но в то же время "подсказывать компилятору" - как обрабатывать "момент недетерминированности"?

Haskell я ведь и САМ могу написать. Но! БЕЗ МОНАД. БЕЗ МОНАД - всё просто - результат функции (грубо говоря) складывается в "мапу" вида - "имя функции + значения её аргументов" => значения.

Ну как "таблицы Брадиса". sin(pi) = 1. "sin pi" => "1". "x^2 + y ^ 2" => ...

Пока есть ДЕТЕРМИНИРОВАННОСТЬ.

Но! Как только её - НЕТ, то появляются - МОНАДЫ.

И как они "помогают" компилятору? Не понимаю..

КАК "функция зависящая от МОНАДЫ" становится детерминированной? Ну чтобы все "плюшки" (кешируемость и параллизм) функциональных языков начинали работать?

"Назад к байтам".. Может быть кто-нибудь объяснит мне?

Неплохая чужая статья

http://www.webdelphi.ru/2013/09/kogda-s-firemonkey-rabota-nad-proektom-idyot-bystree/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+myDelphi+%28Delphi+%D0%B2+Internet%29

Хотя у меня есть к ней вопросы....

Чужая статья. Вот кстати тоже из разряда VCM vs. MVC

http://roman.yankovsky.me/?p=896

"зачатки" повторного использования "проектных решений".

Как и в DevExpress...

Что меня РАЗДРАЖАЛО в DevExpress - так это - ОБЩАЯ коробка TAction'ов.. Лежащая на MainForm. И тянущая за собой все ОСТАЛЬНЫЕ проектные зависимости... Именно поэтому я выдвинул "идею VCM" - http://18delphi.blogspot.ru/2013/03/vcm.html